On Thu, 13 Jul 2000, Theodore Y. Ts'o wrote:
> 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".
And the good thing is that we've already done that and it's already in 2.4
:) It's JFFS, a completely log-structured system optimized for direct
flash-memory access (no block boundaries needed, although it can work with
blocks as well). Do consider the 2.4-port early-alpha though (made by the
nice MTD team) - the version that really works is the 2.0 version.
There is a garbage-collector which collects and merges fragmentation
problems as the log wraps around, nicely providing a simple form of
wear-levelling as well (more intelligent levelling to come).
Eventually we'll manage to merge-in documentation for JFFS that actually
describe all these things.. :)
> 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.
JFFS does not do the atime updating for parent directories actually. That
might be considered broken but for the practical purposes that the system
is intended for (non-volatile storing of parameters/configurations in
embedded devices) it's not a big issue.
atime updates could be done of course but you'd waste node-size * depth
for each file update (nodes are 64 bytes and depth is normally not very
deep, and the GC will collect all this next time around, so it is not THAT
expensive, but it simply has not been an issue yet).
And since everything is written to a log, there is not the issue of
rewriting nodes, you never do that. You always write the newer nodes to
the end of the log. The only thing that ever erases sectors is the GC when
it runs, so you only waste space not rewrite-cycles if you do wasteful
accesses.
Bjorn W
Axis Communications AB
-
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:19 EST