Drobo

Very slow file access performance

Hello,

I have a Drobo FS with 5 2-TB drives and I’m seeing very slow file access performance. Once a read or write begins, the transfer rate is fine, but “statting” files (doing a directory listing, calculating directory size, etc.) is very, very slow. Getting Finder to display a medium-size directory can take 30 seconds or more, with the spinning beach ball throughout.

Also, mounting a volume can take forever. From the time that I click on the server name in Finder to when I see the list of available shares can be 30-60 seconds.

And deleting files is pretty much a non-starter. I just SSH in and use rm.

I’m running AFS, 1 GB networking with a Dell enterprise-grade switch, and 1 or 2 Mac computers running OS X 10.6.5. My MTU is 1500, since that seems to be all that the MacBook Pro supports.

Any suggestions?

Thanks,
Jeremy

Buy something else?
The Drobos are slow…

not sure if this relates to you or no, i was getting very slow reads (1-2 MB/s) on some files, my problem was rtorrent related, not able to check numbers on the drobo, but an external hooked to the machine it was running on had a 1.4GB file that was in 1500 pieces. so i’m assuming that the drobo files look about the same, also anything that was written at the same time is probably chunked up in there too.
any time it had to look at those files the whole thing would grind to a halt. by copying them off, deleting, and then copying back on, it cleared up a lot of my problems, now getting 40-50MB/s reads.
the tech i was dealing with said he would put in a request for a manual defragment tool, instead of having to wait for down for it to start on it’s own. (also you need to give it downtime so it can work).

since you seem somewhat comfortable with ssh, try rm-ing the .AppleDB folder in each share, this is the file that AFP uses to index the drive, it may not help, but won’t hurt, it may take a bit longer the first time you re-access the drive, but after that it should be fine.

hi, i dont know about the other models, but with my v1 and v2 (4-slot drobos) i recently got 30MB/s read - i also use it for video editing, and for live music creating and no problems so far.

(sometimes after heavy use, or when something has changed like new drive, re-layout, or upgrade etc it needs a day to re-jig itself, and maybe an occasional reboot but once back in synch etc its very good here) - i even have backups using 1 drobo through to the other and have seen about 12mb -15mb writes - its directly attached via usb2

Hi Paul,

Thanks a lot for the suggestion… I gave it a shot, but it doesn’t seem to have improved things greatly.

In looking at the system load, it seems like the afpd processes (AFP protocol implementation) are working pretty hard. As an example, here one process (of about 10 afpd processes) showing 24% CPU utilization, and an “uptime”-reported load of 4.

1271 372 root D 7720 4.0 0 24.6 /sbin/afpd -F /mnt/DroboFS/System/netatalk/conf/afpd.conf -P /mnt/DroboFS/System/netatalk/security/afpd.pid

Does anyone know if this is normal?

Is there a way to turn of AFP and just use SMB instead?

Thanks again,
Jeremy

i did a trial, copying at 35-40 MB/s was getting > 50% usage
22591 344 root R 7720 4.0 0 58.0 /sbin/afpd -F /mnt/DroboFS/System/netatalk/conf/afpd.conf -P /mnt/DroboFS/System/netatalk/security/afpd.pid
using uptime, the 1 minute load was 1.25 (copying the whole time)

to access via samba from your mac…
cmd-K then “smb://0.0.0.0” where 0.0.0.0 is the ip of the drobo.

also did you try letting it rebuild the afp database like i suggested earlier, i’ve found that cleans up lots of problems, been running afp from my linux server for years.