The last burst of checkins has brought Tux3 to the point where it
undeniably acts like a filesystem: one can write files, go away,
come back later and read those files by name. We can see some of the
hoped for attractiveness starting to emerge: Tux3 clearly does scale
from the very small to the very big at the same time. We have our
Exabyte file with 4K blocksize and we can also create 64 Petabyte
files using 256 byte blocks. How cool is that? Not much chance for
internal fragmentation with 256 byte blocks.
http://en.wikipedia.org/wiki/Fragmentation_(computer)
I wonder how well Tux3 will perform with 256 byte blocks. Actually,
I don't really see big problems. We should probably be working mostly
with tiny blocks in initial development, because little blocks generate
bushy trees, and bushy trees expose boundary conditions much faster
than big blocks. Which is exactly what we need now if we want to get
stable early. Plus it helps focus on allocation strategy: more little
blocks means more chances for things to go wrong by fragmentation.
Let's keep that issue front and center throughout the entire course of
Tux3 development.
(When we get closer to the kernel port I will switch to working mainly
with 512 byte blocks, which is the finest granularity supported by
Linux block devices at present.)
Anyway, the question naturally arises: what next? There are so many
issues remaining, big and small. Some of the big ones:
* Atomic Commit - we want to know if Tux3's new forward logging
strategy is as good as I have boasted, and indeed, does it work
at all? And what is the commit algorithm exactly?
* Versioning - very nearly the entire reason for Tux3 to exist,
although we are now beginning to see evidence that even as a
conventional non-versioning filesystem, Tux3 is not without its
attractions.
* Coalesce on delete - without this we can still delete files but we
cannot recover file index blocks, only empty them, not so good.
* ...
