The Guru College

Aperture, Referenced Masters and Distributed File Systems

I’m a long time Aperture user. I’ve been in the habit of saving my Master images (be them .NEF, .TIFF, .PSD or .JPG) to secondary disks or NAS devices for years. This lets me keep my Aperture library, containing the metadata about the images, the preview thumbnails, and the project organization relatively small. (1.4 TB of images, 97 GB library). However, I’ve been running without a secondary file server for months now, which I was using for a backup of the primary image collection, and I’m not terribly comfortable without a reliable backup. CrashPlan is running on my machines at home, but literally 8 months remain until all my images are backed up to the cloud. I would also prefer to have backups at home.

This has lead me to do a bunch of research on distributed and replicated network file systems. The idea being that you buy a number of relatively cheap computers to be used as file server nodes, you join them in some sort of namespace, and then you let the servers act as redundant copies of each other in case one is down with hardware issues or needs to be patched, or whatever. The popular options seem to be the RedHat backed GlusterFS, the network file system side of Hadoop, and Lustre, the somewhat failed distributed file system that Sun purchased and Oracle seems to have killed off. In the developmental space, there is Ceph, which looks promising but really isn’t ready for prime time.

Of course, none of these support OS X natively, and have lots of their own internal problems. Hadoop can only be accessed over it’s JSON/REST calls, or via a FUSE plugin; Lustre development is dying and similarly needs to be shared via FUSE; GlusterFS is modern and supported, but you have to re-share the namespace via SMB or NFS if you want to use it on your Mac, and the syntax for growing pools of storage seem archaic. Ceph is dynamic, POSIX compliant, and apparently awesome, but it’s not done, and there’s again no native OS X support, so it’s FUSE or SMB/NFS time.

I don’t want to set up a cluster of nodes just to have the one that is serving over SMB die, and have all my connections get reset. I want to access the file systems natively, and in a way that Aperture can actually use the space in the way the file system designers intended. And, much to my surprise, it seems that all roads are pointing me to OpenAFS, which I just so happen to use at work.

To start, it doesn’t do some of what I want, which is the automatic server-to-server replication that you see in Ceph or GlusterFS. But apart from that, it seems to rock along nicely. Volumes can be moved between servers, or even partitions on servers, while they are in active use by clients. All authentication is done over Kerberos or IP ACLs. Backups are automatically run nightly, and with a little scripting, volumes can be balanced between nodes without much effort. But the best of all is that it’s “native” to OSX – there’s a kernel-level driver to install, sure, but once that’s done, the global AFS namespace shows up under /afs – and by global, it covers every publicly available AFS installation in the world, if you want it to. It’s been around for 25+ years, and it just works. There are robust clients for OSX, Windows, Linux and Solaris, which are all the machines I’ll ever run it on.

Even better is the idea that if I were to partition my photo repository properly, I could move lesser used volumes to nodes with larger, slower disks, and move recently used files to faster ones – perhaps SSDs. With a working knowledge of the AFS command set, perl and find, this could even be done somewhat automatically, where every 30 minutes or so “hot” volumes could be moved to faster storage.

A lot of this is still a pipe dream – I need to replace my desktop before I turn my eye to storage solutions – but planning is King, right? Comments or questions, please sound off in the comments.

PhotoStream vs Camera Roll | Home | Keep The User In The App