The problem is right there. Always has been. People who think that
userspace filesystems are realistic for anything but toys are just
misguided." --LT[1]
Nice appeal to authority you've got there. I'd hate to see anything happen to it . . . like realizing that when it comes to storage Linus is no expert. He hasn't worked on non-trivial storage systems, and some of the world's largest systems make good use of user-space filesystems like PVFS. Is Intrepid a toy? Nope. He's simply wrong, as he usually is about storage. On to the facts.
The fact is that without being in the I/O path you can't detect and propagate updates as they happen - even with inotify, which doesn't scale well to very large filesystems anyway. There will always be some lag, and some reordering. Whether those matter to you depends a lot on your specific needs, but I for one don't like to rely on storage software that don't even try to guarantee correct behavior and might fail me at the most inopportune moment.
FUSE is the way to get in the I/O path without having to become a kernel developer (which I am BTW, since before Linus, since you happen to like appeals to authority). A FUSE-based result will give better functional guarantees and better performance than a hacked rsync. Whether it might have some disadvantages compared to kernel code isn't even the right question. Compared to what this thread is about, FUSE actually is a better answer.
The kernel module is essentially an interceptor, much like FUSE; the serious logic is still all in user space. When I talked to the developers about four years ago, they had considered using FUSE on several occasions but it had never performed as well - for them - as what they had already developed themselves.
When Linus says that user-space filesystems are just toys, he's simply wrong. If he were to say the same thing about FUSE in particular he'd be closer to mark, but a large part of the reason FUSE has lagged is Linus. You don't get credit for predicting an outcome you control, in my book. It's worse than it needs to be because Al Viro and others actively resist any changes that would make it better. Linus, who delegated this part of the kernel to others nearly twenty years ago, backs them up. Making the VFS layer look more exactly like what XFS or even NFS needs is par for the course. Making the smallest concession to what FUSE needs is verboten. I guess some folks are afraid of losing their niche if those artificial obstacles were removed so that more people could build filesystems without begging for keys from the gatekeepers.
Git is not a storage system at all. I was talking about actual physical storage systems that drive requirements for storage software, and there don't seem to be many petabyte-level git repositories. Git doesn't even qualify as storage software, as it delegates all of the real storage tasks to filesystems and such. It's an application that uses storage, much like every other application from emacs to Excel.
Also, have you noticed that git is in user space? Must be a toy, then. Just ask Linus.
Wow -- did you read even a single paragraph beyond that line? Immediately after that he goes on to say:
> fuse works fine if the thing being exported is some random low-use interface to a fundamentally slow device. But for something like your root filesystem? Nope. Not going to happen.
"Random low-use interface to a fundamentally slow device" (like say a remote server in some faraway "cloud") sounds exactly like the situation at hand. Compared to a "real" filesystem (like something you'd mount on /), GDrive is very much a toy, and seems to me like an ideal candidate for a FUSE filesystem.
In this context, yes, for exactly the same reasons as GDrive. No one with any sense is going to be running a relational database or MapReduce out of either one.
Note that when I say "toy" in this context it's not really anything pejorative -- I use such "toy" filesystems all the time (sshfs most often, but also encfs and s3ql), and they're awesome and highly useful. But they're the kind of thing where, say, lock contention (or hell, even being single-threaded) isn't much of a big deal because they're not performance-critical.
