I have 2 vaults configured in Aperture. One is on a 7200rpm drive in a Firewire 800 enclosure - this one works fine and is very fast to update.

The other is on a sparse image which I mount over a gigE network from a smb share on a Linux server. Network transfers to this server are generally as fast as they could be (25 to 30MB a second from my laptops 5400rpm hard drive).

When I update the vault on the sparse image it takes much longer to update than the one on the firewire drive. Yesterday I shot about 5GB worth of photos and after processing them it took ages (at least an hour) to update the vault on the sparse image. Updating the vault on the FW drive took a few minutes in comparison.

I ran nload to measure bandwidth usage on the Linux server and it was jumping up and down between 3MB/s and no network transfer while the vault was updating...

Any ideas what could cause this to behave so slowly?

I wouldn't bother trying to investigate this, but set up an NFS share on linux instead, and use NFS manager to mount it on your Mac. A lot faster than using a Windows protocol to sync a Mac and Linux box.

I'd still have to use a sparse image on the NFS mount then wouldn't I?

I will try this later with a new vault and see how fast it updates.

OK I am pretty sure there is still some problem. I created a single export on the Linux box then used the NFS manager software to mount it. Then I created a single sparse image on that NFS export and mounted it. I just created a new vault on there to test and have started updating it. It is transferring data to the vault at about 0.65MB/s...

I just tested transferring some files in Path Finder from my local hard drive to both the old smb mounted sparse image, and then to the NFS mounted sparse image. In both cases the transfer showed speeds between 500 and 700KB/s.

Transferring to the share where the sparse image is directly (ie, not ONTO the sparse image itself) goes at 20+MB/s.

What could be wrong with my sparse images?

They're sparse images that are not working on an original Mac filing system, that's why. Sparse images are annoying to use on Macs at the best of times, and an absolute pain to use on any other filing system, purely because of the way it handles the dynamic allocation of space.

If you add to a .sparse on HFS+, the volume manager can simply tell to add extra blocks to the .sparse as it writes -- the filesystem is geared for that. Try the same trick on a non HFS+ filesystem, and with every block that's written to the .sparse, it has to send the entire block map, wait for the foreign filesystem to translate that, check and allocate the newly-demanded space, send back an okay, then MacOS can send it the data for those blocks, then wait for confirmation which won't hapen until the foreign filesystem has done its own block-allocation check and confirmation.

What you're trying to do is akin to writing a novel in English one sentence at a time, by sending each word to someone who speaks English, Chinese and Dutch, but the only writing medium handy is a clay tablet and stylus

Try and use a normal, fixed size image on your non-HFS filesystem and see how that goes.


Brains

Thanks for the explanation Brains. I've just tested creating and mounting a standard disk image on the SMB volume and the disk performance is much much faster (it's not slower than writing directly to the SMB share).

Of course the only minor disadvantage in this case is that all the disk space needs to be pre-allocated - but that doesn't matter in my case.

Thanks for your help guys.