Here we are, finally: code. I do not make any claim that this code is
elegant, correct, complete, esthetically pleasing or that it will
refrain from eating your hard disk.
What this code will do is let you verify for yourself whether my
proposed approach to tailmerging for Ext2 is worth the effort. After
you build the mrg2 module you can go around and test various
partitions to see how much safe you would save with this tailmerging
approach:
mount /dev/hda9 /try-me -t mrg2 -o tails=tell
This is non-invasive, i.e., it doesn't write to the partition. I
think. :-)
I've tried this a few times myself and gotten some pretty impressive
results: 14 percent of data blocks saved for the linux source tree and
30% saved for the mozilla tree. Even better is what it does to
worst-case disk wastage. With no special handling of tail blocks Ext2
is quite capable of wasting 99.9% of your disk space in the worst
case. With this tailmerging algorithm the worst case improves to
about 50% wastage... much, much, better. Keep in mind it's not just
space savings at stake here - fewer blocks to read means less time
spent reading them. The question is: what is the bottom line
performance impact? I just don't know yet. Please help me and try
the code. Even better, *read the code* then try it.
This code has been tested far less than it should have been.
Basically, I tried a few test cases and fixed the obvious bugs that
came up, then zipped it and shipped it out. The merge/unmerge code is
a little more tested than the file operations code. There is one
thing you can be sure of: this is not thread safe. Yet. I'll look at
those issues next week.
And when this code is working perfectly it will still only be version
0.49999. Version 0.5 is the first version that will do incremental
tail merging, i.e., actually be useful. I'm thinking now about
algorithms and data structures for that because I think the first half
of this problem is pretty well licked. Please, you be the judge of
that.
Let me put in one more plug here. There is some urgency to this
tailmerging stuff because the trend is towards bigger and bigger
filesystem block sizes, Bigger blocks sizes means more potential
wastage of space in tail blocks. We really need the bigger blocks so
we can have bigger filesystems and faster I/O transfers, but the tail
fragmentation problem has to be solved before we can head much further
in that direction.
And finally, some credits: thanks to Hans Reiser for giving me the
idea to do this, to Stephen Tweedie for a timely push in the right
direction, Chris Mason for his war stories and helpful suggestions,
and Al Viro for keeping a watchful eye out for dragon attacks.
The patch is here:
http://innominate.org/~phillips/tailmerge.0.0.zip
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:13 EST