Messages in this thread | | | From | phillip@lougher ... | Subject | Re: partially encrypted filesystem | Date | Mon, 08 Dec 2003 13:44:07 +0000 |
| |
dwmw2@infradead.org 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |