What makes you think the FUSE approach is better?
FUSE is a natural choice if you want fully integrated and transparent access to so-called "cloud storage" services. Performance overhead isn't so much of an issue, you'll probably manage to max out most home broadband services even with the several layers of syscalls.
You'll have less to remember, throw a line in fstab (or mount it in your shell's rc) and it's all just there, no sync commands to remember, just grab your favourite application and start hammering away at your files.
'userspace filesystem'?
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]
[1] http://www.spinics.net/lists/linux-fsdevel/msg46078.html
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.
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.
Also, have you noticed that git is in user space? Must be a toy, then. Just ask Linus.
> 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.