Re: partially encrypted filesystem

phillip_at_lougher.demon.co.uk
Date: 12/08/03

  • Next message: Richard B. Johnson: "Re: [OT] Rootkit queston" 
    To: "David Woodhouse" <dwmw2@infradead.org>
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/

  • Next message: Richard B. Johnson: "Re: [OT] Rootkit queston"

    Relevant Pages

    • Re: ext2/3: document conditions when reliable operation is possible
      ... When you say Linux filesystems do you mean "filesystems originally ... designed on Linux" or do you mean "filesystems that Linux supports"? ... the best filesystem for USB flash devices is probably UDF. ... If you yank a USB flash disk in the middle of a write, ...
      (Linux-Kernel)
    • Re: flashcopy
      ... Thanks for a valuable discussion on ESS flash copy feature! ... One question ...you said that unmounting source filesystems ... I have not seen any requirement of running fsck on target volumes ...
      (comp.unix.aix)
    • Re: [freebsd-current] re: fsck_4.2bsd: cannot alloc 4294967292 bytes for inoinfo
      ... filesystems on it I get a kernel panic ... and mounted it on the Soekris system, and as soon as I start to use ... This sounds very much like data corruption between the flash and the ... Try dd'ing off the first 1MB or so using valhalla and also using one ...
      (freebsd-current)
    • Re: mmap returns incorrect data
      ... > I have a system based on 2.5.59 kernel for arm. ... > running OK with all filesystems on a stratoflash chip, ... > moved the filesystems to a compact flash chip. ...
      (Linux-Kernel)
    Loading