On Mon, Apr 14, 2008 at 10:20 AM, Chris Mason <chris.mason@xxxxxxxxxx> wrote: > Thanks to Bob Copeland for taking the time to submit this for mainline. > Please don't mistake the resulting debate as a sign we don't appreciate the > effort of making it available and getting it reviewed. Sure, no worries... > Unlike all the device drivers we don't want floating around out of the tree, > filesystem authors do have a choice between FUSE and being in-kernel. Since > OMFS has been maintained out of tree since 2.6.12 or so, Bob probably has a > very good idea of how much time he has needed to spend updating things for > each release. The recent deprecation of iget was probably the most involved of any. It wasn't that bad, but the #ifdef jungle going back to at least .17 is getting somewhat hairy (I have 19 of them). I would say over the past year or so most of the changes have been <10 liners with kmem_cache_* interface changes. Luckily through review here, that got zapped anyway. In the normal case, I'll grab an -rc3 kernel or so, try to compile it, if it fails, look at minix to see the minimum set of changes I need to make. The challenge for me maintaining it out-of-tree is that sometimes the git logs do not carry enough context to know why XYZ changed and if there's a better, new way to do things. Then it's time to scour the mailing lists. > So, there are two big questions I'd ask: > > * Which setup (kernel or fuse) would Bob find easier to maintain things? > * Is this a first step toward more development and an increased user base? Well, FUSE is easier from the standpoint of having somewhat more control. On the other hand, that also results in an inferior product if it isn't given the many-eyes treatment. For the code itself, it's really not that much different since FUSE is so close to the VFS API anyway. For your second question: More users are always welcome. At present, the FUSE version implements a few things that the kernel module does not - better/different block allocation algorithm, growing truncate, automatic byte-swapping for the ReplayTV model that had a busted block layer. However, the FUSE version is known to be buggy with respect to every day use (I had one MD5 fail among 20G of files in one copy test). I could see adding 1 and 2 to the kernel version, but probably not the byte-swapping bit. I'm not sure what to do from there on. As a user, I use the kernel module because it works, it's faster, and the other bells and whistles aren't that important to me. It's hard to tell what the user community prefers, because the kernel module was first and so far no one has had a reason to try the FUSE implementation (if they have, I don't know about it). -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
