Re: partially encrypted filesystem

From: David Woodhouse
Date: Mon Dec 08 2003 - 06:40:06 EST


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.

Even if you were going to admit to having a block size of 64KiB to the
layers above you, you just can't _do_ atomic replacement of blocks,
which is required for normal file systems to operate correctly.

These characteristics of flash have often been dealt with by
implementing a 'translation layer' -- a kind of pseudo-filesystem --
which pretends to be a block device with the normal 512-byte
atomic-overwrite behaviour. You then use a traditional file system on
top of that emulated block device.

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

Given that design, compression just dropped into place; it was trivial.

--
dwmw2

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