Messages in this thread | | | Date | Thu, 13 Jul 2000 20:15:19 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Do ramdisk exec's map direct to buffer cache? |
| |
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/
| |