my drobo started to slow down at 80% space usage even though the knowledge base said 85% but its extremely slow and it doesnt even make sense to say it slowed down because it will take about a hour to transfer a 300mb file at that time. While I know this is a precaution I dont plan on fulling it to 99% before adding a new drive but i would like to disable that feature.
The short answer to your question: No.
The long answer to your question: Nooooooooooooooooooooooooooooooo.
Sorry, but thats it
Drives in general get slower as they get fuller due to the mechanics and physicalities of how the data is laid out.
but you can defrag drives
mi not sure if drobo optimises its layout in the background, but i would imagine so
No, they don’t At least, not that noticeable. Said behaviour is described in the knowledge base and implemented in Drobo to let you know it’s time to add/replace the drive. In “thin provisioning” solution, there isn’t really a better way as the OS “thinks” it copes with huge partition with still plenty of space on it so you won’t get “disk full” message from the OS. And you wouldn’t want the Drobo to suddenly throw write error or another scary error condition while you reach 100%.[hr]
That is described in the knowledge base too There’s no point in running OS-based defrag utility as the virtualization mechanism hides the real physical data layout from the operating system. Sure, it will move things around, but not necessarily in the optimal way. I wouldn’t be surprised if it makes things worse, even. And no - the sudden slowdown while reaching full capacity isn’t due to fragmentation - it’s intentional.
thank you for the replies, I wish drobo would change the slow down rate at 90%, I was trying to empty a drive so I could add it to the drobo for more space, Guess i’ll have to put the files somewhere else then add the drive to drobo
Zbig, thats exactly what i said??? real drives you can defrag, drobo you cant (well you can but its futile and pointless)?
does it describe in the knowledge base whether drobo do internal optimisation or not? i would amazed if it does since DRI are so secretive about what their black box does
Plus its blindingly obvious that the original poster knows that drobo’s slowdown is due to design and not fragmentation - that’s why he is asking if he can turn it off!
Well… no… First you said that you can defragment the drive (as if you were supporting the idea that this is the cause of the slowdown) and then, that you wonder if Drobo does it by itself. If you wanted to say something else, I just didn’t get that, sorry.[hr]
I’m sure it is. But I’ve replyed to the bhiga’s false statement - not the original poster’s, right? There’s even a proper quote, ekhm…
Furthermore, if it’s that blindlingly obvious, why do you seem to support bhiga’s untrue fragmentation theory by speculating whether Drobo does defragment its data or not?
Anyway, there’s no need to be nervous and for overusing the exclamations and triple question marks. I’m trying to help - just like you
fragmentation does slow down drives, in many cases noticeably, that’s why defrag product are and continue to be popular.
Also, as drives get fuller, it becomes harder to find continuous space, so fragmentation will naturally increase.
while defrag products wont work on drobo since it virtualises its storage, i’m sure the layout of data on its multiple drives will have a significant impact on its performance - and you haven’t answered whether drobo optimises itself or not - which is a perfectly valid question in its own right, and probably would have an impact on performance when drobo is below 85% full.
What I meant was that in most typical real-world situations, the slowdown caused by the fragmentation won’t be anything near as noticeable and steep as the rapid, firmware-induced slowdown in Drobo. I think you’re right I should have phrased it otherwise.
Right, but this effect has been quite sucessfully mitigated for most typical usage scenarios in most modern file systems (better than FAT)
Right, that’s the case even with “classic” RAID5 although theoreticaly, distribution of the data between multiple drives could lead to read performance improvements. But there are several other factors associated with data management and redundancy, like parity calculation, I think. And I could only guess how much more complicated Drobo data structure is compared to the “old-school” RAID5. Furthermore, Drobo is data-aware and it has to actually “know and understand” how NTFS/HPFS/EXT works as compared to “dumb”, block-level RAID, which I think doesn’t serve as a performance benefit, either. As I figured out, here for example, are several zones - one part of the drive could act like a part of RAID1 array equivalent while another as RAID5 and so on… Anyway, as I found by observing my own unit in action, it already “trashes” its disks much more than in case of stand-alone fixed drive so I guess that filesystem fragmentation would have even less noticeable effect here.
And I won’t as I don’t know I could only guess it does as I’m pretty sure I’ve found some information about several cluster relocations in the logfile.
According to Drobo documentation I read somewhere (might even have been the manual that comes in the box), Drobo is supposed to automatically do its own “housekeeping” so host-based defragmentation is not necessary.
As far as drive data throughput, the write data throughput for an individual drive does get slower as the drive gets fuller regardless of filesystem, at least for video use (which tends to be fewer, large files).
Drobo’s management of the drives adds another layer of complexity to the problem, so I see your point on maybe Drobo’s internal housekeeping process gets slower as the volumes fill up. That makes a good amount of sense.
A Drobo knowledgebase article says that the slowdown is now at 95%. Not at 85%.[hr]
Here’s the article:
well that article is misleading because my transfers were going fine till 85%, so i ran a test and tried to move a 200mb file and it was gonna take about 2hrs, wasnt even worth it to make it go to 86%
Interesting. Did you try to temporarily remove some files to make it less than 85% used and then try to copy a file to it to see if it performs the way it used to at less than 85%?
I didn’t try that so i just add a new hard drive and the transfer speed immediately went back to normal
What is the conclusion here? Is it that feeding Drobo mores drives when it asks for them is the right thing to do? All the speculation about how Drobo works vs single drives when getting full is … uninformed speculation?
I think that DRI’s thinking on this is flawed … it’s okay to slow down a drive on a system with no good indicators (like some barely supported Linux flavor) to let the user know that he’s reaching capacity, but on a well supported system where the Drobo software is informing the user via Growl and sending emails to the user explaining the situation and the Dashboard’s turned the drive yellow - it’s superfluous and tortures the customer for no good reason.
I mean, alright already. I ordered a new drive from Amazon and it’s in the mail. Let me get this thing copied already and stop trying to tell me what you’ve already told me.
Anyone else feel this way?
Seems the conclusion is that Drobo gets significantly slower (ie, more than what would be expected just from drive physicalities) when it gets somewhere between 85% and 95% full, and that’s a sign to add more space, if you haven’t received another indicator.
I agree with varase though… in situations where there are other methods of notification, or in times when the user is quite aware that the volume is near-limit, but accepts that, reducing performance seems like a very unwelcome notification method. At the very least it’d be nice to be able to turn this function off.
Syslogs, broadcast message (bad form and often disabled though), blinking lights, email… lots of different ways to get the user’s attention, though I suspect most of them would require the Drobo Dashboard, and that in and of itself isn’t necessarily a good assumption as Drobo can be used without Drobo Dashboard installed.
How about in the Drobo Dashboard a warning that you’re reaching capacity and a “Yes, I know - please stop slowing down my drive” checkbox? You’ve got a way to send the Drobo out-of-band messages, right?
You can even reenable the slowdown when I’ve reached 1000 MB free. Or better yet, change the drive over to read-only status and leave it full speed.
100%-85%=15% of 3 TB is 450 GB - which is almost as much storage as my entire laptop’s drive. At an average of 20MB/sec, at full bore it would take the Drobo 6.25 HOURS of non-stop copying to fill up the drive. And it’ll get worse with higher capacity drives.
A slow drive doesn’t intuitively tell me the drive’s getting full - it tells me something else - the driver? - isn’t working. That something’s broke. And it’s incredibly annoying (especially with no way to turn it off).
I understand that DRI never wants to let the drive get full - after all, the storage is overcommitted and how do you return a clean “drive full” when you’ve allowed the user to overcommit the space available.
I posted a feature request in this thread in the Feature Requests section.