In a recent thread, Miklos Szeredi provided some usage statistics for FUSE [1], the "Filesystem in Userspace". FUSE is an API that was originally developed for the AVFS [2] project, and has since been utilized by a growing range of userland filesystems. It was merged into Andrew Morton's -mm kernel in mid January of 2005 [story [3]], and nearly made it into the mainline 2.6.12 kernel in early March [story [4]]. Miklos pointed out that the code has been downloaded around 7,000 times in the past three months, is successfully utilized by 27 known userland filesystems, and provides bindings in 7 different programming languages.
2.6 Linux kernel maintainer Andrew Morton replied, "the main sticking point with FUSE remains the permission tricks around fuse_allow_task(). AFAIK it remains the case that nobody has come up with any better idea, so I'm inclined to merge the thing." He went on to note, "what others think matters. But at this stage, objections would need to be substantial, IMO. We're rather deadlocked on the permission thing, but if we can't come up with anything better then I'm inclined to say what-the-hell." In a later email [story [5]], Andrew had made up his mind noting that he was, "fed up with arguing - any remaining problems can be fixed up in-tree if anyone can think of how to fix them."
From: Miklos Szeredi [email blocked] To: akpm Subject: FUSE merging? Date: Sat, 03 Sep 2005 00:02:18 +0200 Hi Andrew! Do you plan to send FUSE to Linus for 2.6.14? I know you have some doubts about usefulness, etc. Here are a couple of facts, that I hope show that Linux should benefit from having FUSE: - total number of downloads from SF: ~25000 - number of downloads of last release (during 3 months): ~7000 - number of distros carrying official packages: 2 (debian, gentoo) - number of publicly available filesystems known: 27 - of which at least 2 are carried by debian (and maybe others) - number of language bindings: 7 (native: C, java, python, perl, C#, sh, TCL) - biggest known commercial user: ~110TB exported, total bandwidth: 1.5TB/s - mailing list traffic 100-200 messages/month - have been in -mm since 2005 january Miklos
From: Andrew Morton [6] [email blocked] Subject: Re: FUSE merging? Date: Fri, 2 Sep 2005 15:34:40 -0700 Miklos Szeredi [email blocked] wrote: > > Hi Andrew! > > Do you plan to send FUSE to Linus for 2.6.14? Haven't thought about it all much. Have spent most of my time in the last month admiring the contents of kernel bugzilla, and the ongoing attempts to increase them. > I know you have some doubts about usefulness, etc. Here are a couple > of facts, that I hope show that Linux should benefit from having FUSE: > > - total number of downloads from SF: ~25000 > > - number of downloads of last release (during 3 months): ~7000 > > - number of distros carrying official packages: 2 (debian, gentoo) > > - number of publicly available filesystems known: 27 > > - of which at least 2 are carried by debian (and maybe others) > > - number of language bindings: 7 (native: C, java, python, perl, C#, sh, TCL) > > - biggest known commercial user: ~110TB exported, total bandwidth: 1.5TB/s > > - mailing list traffic 100-200 messages/month > > - have been in -mm since 2005 january > I agree that lots of people would like the functionality. I regret that although it appears that v9fs could provide it, there seems to be no interest in working on that. The main sticking point with FUSE remains the permission tricks around fuse_allow_task(). AFAIK it remains the case that nobody has come up with any better idea, so I'm inclined to merge the thing.
From: Miklos Szeredi [email blocked] Subject: Re: FUSE merging? Date: Sat, 03 Sep 2005 07:31:34 +0200 > Haven't thought about it all much. Have spent most of my time in the last > month admiring the contents of kernel bugzilla, and the ongoing attempts to > increase them. A penal system could be created, for example if someone is caught introducing a bug, he will have to choose three additional reports from bugzilla and analyze/fix them ;) > > - number of language bindings: 7 (native: C, java, python, perl, > > - C#, sh, TCL) 8 now, someone just sent a private mail about bindings for the Pliant (never heard of it) language. > I agree that lots of people would like the functionality. I regret that > although it appears that v9fs could provide it, I think you are wrong there. You don't appreciate all the complexity FUSE _lacks_ by not being network transparent. Just look at the error text to errno conversion muck that v9fs has. And their problems with trying to do generic uid/gid mappings. > there seems to be no interest in working on that. It would mean adding a plethora of extensions to the 9P protocol, that would take away all it's beauty. I think you should realize that these are different interfaces for different purposes. There may be some overlap, but not enough to warrant trying to massage them into one big ball. > The main sticking point with FUSE remains the permission tricks around > fuse_allow_task(). AFAIK it remains the case that nobody has come up with > any better idea, so I'm inclined to merge the thing. Do you promise? I can do a resplit and submit to Linus, if that takes some load off you. Thanks, Miklos
From: Andrew Morton [7] [email blocked] Subject: Re: FUSE merging? Date: Fri, 2 Sep 2005 23:40:42 -0700 Miklos Szeredi [email blocked] wrote: > > > The main sticking point with FUSE remains the permission tricks around > > fuse_allow_task(). AFAIK it remains the case that nobody has come up with > > any better idea, so I'm inclined to merge the thing. > > Do you promise? I troll. What others think matters. But at this stage, objections would need to be substantial, IMO. We're rather deadlocked on the permission thing, but if we can't come up with anything better then I'm inclined to say what-the-hell. > I can do a resplit and submit to Linus, if that takes > some load off you. Nah, then I'd just have to check that everything is the same.
From: Miklos Szeredi [email blocked] Subject: Re: FUSE merging? Date: Sat, 03 Sep 2005 09:23:31 +0200 > > > The main sticking point with FUSE remains the permission tricks around > > > fuse_allow_task(). AFAIK it remains the case that nobody has come up with > > > any better idea, so I'm inclined to merge the thing. > > > > Do you promise? > > I troll. What others think matters. But at this stage, objections would > need to be substantial, IMO. Fair enough. > We're rather deadlocked on the permission thing, but if we can't > come up with anything better then I'm inclined to say what-the-hell. There's no disadvantage IMO. It adds nearly zero complexity. If someone doesn't like it, it can be configured out in userspace. And it leaves no legacy interfaces to support if later a better method is found. > > I can do a resplit and submit to Linus, if that takes > > some load off you. > > Nah, then I'd just have to check that everything is the same. OK. Thanks, Miklos
Related Links:
- Archive of above thread [8]
- KernelTrap interview with Andrew Morton [9]