Date: Thu, 13 Jul 2000 16:53:52 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
However, where cramfs shines is: _no_ fragmentation. Forget about block
device issues, it does data on 4 byte boundaries. That, together with
basically having very minimalistic meta-data (who needs meta-data anyway,
when it's all read-only: _just_ enough to find stuff and no more) is the
biggest win.
But you can't basically do these things if you want to be read-write. A
truly log-based approach (ie not just meta-data journalling) might work
out ok, actually, but most log-based stuff seem to want to have fairly
large caches in order to work well. Which in embedded spaces isn't exactly
a good idea.
The large caches are needed because log-based filesystems very quickly
tend to fragment files all over hell-and-gone. But if you're using
flash memory in your embedded device, this is much less of an issue,
since you aren't impacted by the seek times that you have when you have
to move heads over spinning media.
The real trick is being able to allocate on non-block boundaries, and
dealing with fragmentation issues as you delete files and create
irregularly shaped holes. Making a read/write filesystem that is
optimized for the characteristics of flash memory would certainly be
"interesting".
One potential problem with log-based schemes is that they tend to
rewrite many more blocks (for example, normally you have to rewrite
every single directory up to the root every time you so much as touch an
inode to update the atime). For flash memory, this is non-optimal since
you have a limited number of write cycles. Although modern flash
memories they've extended the number of write cycles significantly, it's
still an issue.
Of course, if you don't care about backing store, and want a pure
memory-based compressed ram disk, life is much easier --- but writing to
it is much less interesting, since it won't survive a reboot.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:18 EST