« Kerberos 'n Shit | Main | TeX Shit »
October 21, 2004
The Pain of Filesystems
Dammit, right after my Mac comes back, the monitor on my box starts going again. Now I’ve got dark horizontal lines wherever something dark is. I’m ready to slay Sylvania, this is the second time this monitor has died on me in three years.
So, here I am thinking about what a fucking disaster networked filesystems are currently, when I get this weird idea.
You see, I just tried to install Coda on FreeBSD. There is apparently a kernel module for Coda, though I’m not sure what version. Coda version 6 builds and installs on FreeBSD, both client and server. Setting it up is such a nightmare, they’ve included a helpful script to get you going with it. You discover during this set up that it wants partitions to hold log files and “RVM” data, that it hates changing any of these configuration parameters after being installed, that it needs about 6 servers to be running, and that it’s very picky about the values in the configuration file. So fuck it.
Then I thought, all I really care about is that people be able to get at certain files in a securely authenticated, encrypted tunnel kind of way. I’d like it to look like it’s in the local filesystem, but I can’t actually say that I care. So maybe what I really want is Subversion. That way, the nimrods get access to the files, they don’t get to write unless I want them to, plus we have all this handy-dandy distribution. I could rig some sort of replication into it, too, have some other damn server just pull the changes every few hours and set up failover to it.
So the question is, can Subversion be the next distributed filesystem? Is it possible that all I really want is some way of “mounting” a Subversion server locally and then notifying the remote server a la COMMIT and ROLLBACK from a database?
It looks like others have had this thought too but nothing seems to have come of it. Plus I don’t really want it backending into shitty WebDAV or messy Coda, if it could backend into (say) FTP or NFS.
This of course brings us up to the state-of-the-art of VMS in the mid-70’s, with a correctly versioning filesystem. Except not, because the transaction concept is still manual. I’d like to be able to copy a file, make a bunch of changes to it (saving between each one) and then say “actually, roll those uncommented commits into a single commented commit with this text.” Of course, the system would preserve the original transactions, but would by default show me the named ones for convenience. Or something.
I think this bears scrutiny. Kerberos is based on the concept of having a single auth server and then a bunch of app servers, with the user being at home on their own box. It doesn’t really fit with this model to have this huge monolithic file service running on a shit-ton of iron in the back room just to serve me my Nethack high scores, not when I could just check out the stuff I intend to modify, work on it, commit it, and then have a transactional, fully versioned FS on top of it. I mean, consider it—99% of the time, when I access a file on the networked server, it’s either some fucking binary, or something that’s just mine. In the cases where it’s some fucking binary, we might as well use goddamn NFS, or just have fucking copies and use rsync to update ‘em. For that matter, if speed were to become an issue with the initial checkout, use rsync to make every client a peer for it’s own files, and then when the original server comes back, synchronize. The beauty of Subversion is all the mystical merging it can do anyway, right?
So what do we wind up needing? Some sort of hierarchical failover for Subversion, and a few scripts to checkout and checkin on login and logout. Kerberos support for Subversion, but we could just as well use subversion over SSH, and have Kerberos auth it to that.
What do yall think?
Posted by FusionGyro at October 21, 2004 10:32 PM
Trackback Pings
TrackBack URL for this entry:
http://www.clanspum.net/~fusion/blog/admin/mt-tb.cgi/38
Comments
That’s how I found your page: googling for a versioning filesystem with the features you mentioned. Although having read some stuff about Arch and Monotone, it sounds more like I’d want one of those as my filesystem backend with Rendezvous support for it (letting my notebooks and the desktop machines sync with each other whenever they meet on the WLAN).
Now I am wondering whether anyone will read this, half a year after the original post … heck, will I see any answers?
Posted by: Harald at April 27, 2005 01:49 PM