Contributed by Pedro Martelletto on from the filesystems whee dept.
As you may have noticed, I've been slowly adding UFS2 (which I will
refer to as 'FFS2' from now on) bits to the tree. That has caused some
confusion, so here are a few clarifying notes about it.
Unfortunately, having FFS2 in-tree doesn't yet mean you will be able to deploy that evil > 1TB plan you had in mind to store all your porn, er, I mean, data. What's being done right now is just basic instrumentation, which means the code will be there the day we decide to use it.
There are quite a few issues that need to be addressed before we can take full advantage of FFS2. The first and most urgent of them all is a quick and fast replacement for fsck. There's absolutely no point in supporting insanely huge file systems that will take a month to fsck. Now that VFS seems to be stable, this is priority #1 for me.
During the last Hackathon some time was devoted to the discussion of how to tackle this problem. The alternatives are not many and well known, one of them (softdep) being already in-tree for a while. However, it has corner cases, such as resource leaking in the form of unreclaimed inodes and blocks, thus not really eliminating the need for fsck. A background 'mark and sweep' garbage collection daemon to be run upon mount was proposed as a possible solution, and is currently under study. The main problem with such approach is how to pace it with userland. The process of checking if a given resource is allocated, updating metadata and flushing it back to disk would have to be done in a way not to leave the disk or the kernel in an inconsistent state, nor take over the CPU or crawl to death. But it definitely would be a very robust solution.
The other pending issues for FFS2 are making userland tools able to grok it and supporting larger disks. The former means making newfs, fsck, growfs and tunefs able to operate on FFS2 file systems. The latter means bumping daddr_t to 64 bits and having disklabel cope with the changes. This is needed so disk blocks at offsets > 32 bits can be read in, kept in the buffer cache and dealt with as 'ordinary' buffers. Getting FFS2 in allows us to do that, as it puts an end in the chicken-and-egg problem concerning daddr_t and FFS where the first wouldn't be bumped because the second didn't support it, and the second wouldn't be updated because the first hadn't been bumped.
Hopefully adding these bits will get some attention, and perhaps attract more people to join me on FS hacking. Cause that'll be a lot of work.
(Comments are closed)