[OT?]Re: partially encrypted filesystem

[Charles Manning]

On Tuesday 09 December 2003 02:44, phillip@xxxxxxxxxxxxxxxxxxx wrote:
> > JFFS2 was designed to avoid that inefficient extra layer, and work
> > directly on the flash. Since overwriting stuff in-place is so difficult,
> > or requires a whole new translation layer to map 'logical' addresses to
> > physical addresses, it was decided just to ditch the idea that physical
> > locality actually means _anything_.
>
> Maybe okay for a flash filesystem which is slow anyway, but many filesystem
> designers *are* concerned about physical locality of blocks, for example
> video filesystems.

Sure, just because JFFS2 choses to do something a certain way for a certain 
reason does not mean that others cannot choose to do something the different 
(or even the same) for a different reason.  The choices made in JFFS2 were 
done to work around the constraints of flash memory. When those are not 
present then 

Like JFFS2, YAFFS is also a log-structured flash file system that does not 
use a block device and does not assume physical data blocks can be updated in 
place. YAFFS uses a log structure for exactly the same reasons David 
presented (to get away from a physical location dependence - a killer for 
flash file systems). However, YAFFS uses fixed-size chucks as "log records" 
and is thus not really compression friendly. The differences between JFFS2 
and YAFFS are there for good reasons, beyond the scope of this discussion.

>
> > Given that design, compression just dropped into place; it was trivial.
>
> Or maybe 'not in(to)-place' :-) I don't think I was saying compression is
> difficult, it is not difficult if you've designed the filesystem correctly.

Effectively saying that a fs that can't easily support compression is badly 
designed is a dangerous over-simplfication/generalisation/slur. 

There are over 40 file systems for Linux - each is valid and exists because 
it does something that other fs don't do well or solve some particular 
problem.  Often, these fs jump through enough hoops of fire just to work 
effectively and adding compression could easily compromise the main goals of 
the fs.

As an example (that I'm familiar with :-)), I'd say that adding compression 
to YAFFS would at best compromise some of the YAFFS design goals and make it 
at best slower and at worst not be possible at all - without major upheaval. 
For those that simply *must* have compression on a YAFFS-based storage, I 
advise the use of a loop-mounted fs that provides compression (eg. cramfs) 
backed by a YAFFS file. This is being used in some products to great effect.  
It might seem that this adds extra overheads, but there is some saving 
because the whole file system does not have to carry the burden of 
compression etc.


-- CHarles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/