How slow should this Drobo FS be?

[Farquaon]

Hey guys, I am busy copying 21GB worth of data from one drobo shared folder to another shared drobo folder and at this same time I am watching a 183MB SD video with is jerky like hell, at least every 10 seconds it stutters for about 1-2 seconds.

My connections are all GB.

Should it be this slow or is there something I can check/change to optimize the performance?

thanks for the help.

[diamondsw]

You’re running into what’s called I/O contention. Duplicating data (simultaneous read/write) on a RAID array is a quick way to bring it to its knees. I had a traditional RAID-5 server array that dropped to <1MB/sec in I/O performance while duplicating. It doesn’t surprise me that the Drobo would suffer the same thing.

What happens is internally the drives seek to one location to read data, then seek to another location to write (seeking is the physical movement of the drive heads to be positioned above the right spot on the platter to access the data). If this is brief (as it is with normal access) it can batch certain operations and avoid any real contention and thrashing. If you’re duplicating data, however, this becomes unavoidable. Since seeking takes much more time than the actual reading and writing of the data and you’re seeking constantly, you spend most of your time moving the heads across the disk rather than reading/writing data, and performance plummets. Add to that all of the housekeeping the DroboFS has to do, and while I don’t know if it hurts, it certainly can’t help matters.

As to your current problem, if you need to move data between shares it’s MUCH easier and faster to SSH into the DroboFS and just move the data. Shares are an illusion - on the underlying filesystem they’re just different folders, so you can move data between them without copying - instantaneous.

[Farquaon]

You’re running into what’s called I/O contention. Duplicating data (simultaneous read/write) on a RAID array is a quick way to bring it to its knees. I had a traditional RAID-5 server array that dropped to <1MB/sec in I/O performance while duplicating. It doesn’t surprise me that the Drobo would suffer the same thing.

What happens is internally the drives seek to one location to read data, then seek to another location to write (seeking is the physical movement of the drive heads to be positioned above the right spot on the platter to access the data). If this is brief (as it is with normal access) it can batch certain operations and avoid any real contention and thrashing. If you’re duplicating data, however, this becomes unavoidable. Since seeking takes much more time than the actual reading and writing of the data and you’re seeking constantly, you spend most of your time moving the heads across the disk rather than reading/writing data, and performance plummets. Add to that all of the housekeeping the DroboFS has to do, and while I don’t know if it hurts, it certainly can’t help matters.

As to your current problem, if you need to move data between shares it’s MUCH easier and faster to SSH into the DroboFS and just move the data. Shares are an illusion - on the underlying filesystem they’re just different folders, so you can move data between them without copying - instantaneous.

Thanks for that. Seems like i need to learn some ssh speak then.

[matthijs]

Not sure if this is appropriate to post here, but it might help others who search for speed drobo fs.

I found that using the mutil tool which comes with mac os dramatically improves the write speed for time machine to the drobofs. I had to start allover with my backup, but hey… it wasn’t backing up anymore, so that’s not much of a loss.

i used the following code

sudo mutil setdestination afp://username:password@/

using the ip instead of the name seems to have improved the transfer speeds a lot. It’s still not absolutely top of the line, but i have backup upped approximately 225GB in 15 hours… so that is way better than it was before.