Re: partially encrypted filesystem

[phillip]

dwmw2@xxxxxxxxxxxxx wrote:
> On Sat, 2003-12-06 at 00:50 +0000, Phillip Lougher wrote:
> > Of course, all this is at the logical file level, and ignores the 
> > physical blocks on disk.  All filesystems assume physical data blocks 
> > can be updated in place.  With compression it is possible a new physical 
> > block has to be found, especially if blocks are highly packed and not 
> > aligned to block boundaries.  I expect this is at least partially why 
> > JFFS2 is a log structured filesystem.
> 
> Not really. JFFS2 is a log structured file system because it's designed
> to work on _flash_, not on block devices. You have an eraseblock size of
> typically 64KiB, you can clear bits in that 'block' all you like till
> they're all gone or you're bored, then you have to erase it back to all
> 0xFF again and start over.

Curiously, I am aware of how flash and log structured filesystems work.

> 
> 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.
> 
> 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.

Phillip


-
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/