I’ve noticed a very consistent issue on my DroboFS. This occurs when using AFP mounts to Mac OS X (since it specifically involves Finder metadata, no other combination is valid). I’ll have a copy to the Drobo blazing along at full speed (several MB/sec for small files, 20-30MB/sec for large files) when all of a sudden it will stop dead. For minutes. And every time, it’s when it hits a custom folder icon (the kind that are stored as “Icon\r” on disk). During these minutes the disks on the Drobo are thrashing like mad, but there’s relatively low CPU load - it’s clearly waiting on some I/O process to finish. And after a few minutes, it does, and the copy continues as if nothing was the matter. Until it hits the next icon. Repeat.
I’m assuming this is an issue with netatalk, and I’m guessing further it has to do with how it tracks custom Mac OS X metadata and filesystem semantics not supported by ext3 - perhaps in a data store somewhere. If I mount via SMB/CIFS, I don’t get custom metadata at all (heck, I don’t even get long file names reliably, which is extremely disappointing). There are probably a few hundred thousand files on this share, so if there is some type of “metadata datastore” as I theorize, I wouldn’t be too surprised that it’s getting hammered. But still - minutes to write an icon?
Top shows that the following is about the only thing taking (mild) CPU time:
/sbin/cnid_dbd /mnt/DroboFS/Shares/Dante/.AppleDB 15 1
Said “.AppleDB” file? 600MB.
It effectively makes my Drobo a read-only device, since any time I write files (including rsync backups to an AFP mount - haven’t configured daemon-to-daemon yet) I take the chance of it dying randomly.
Any ideas how to resolve this?