Does drobo protect erroneous empty space?

I am concerned. After a power outage, I had a problem with my Drobo Pro. I was able to get it online again, but the ext3 superblock was unavailable. I ran e2fsck, and it repaired the superblock, but when it started asking about deleted blocks in groups, I realized I did not know what it meant. The Drobo used capacity went down from 76% to 74% and when I mounted the disk Read Only so that I could copy stuff off, the linux machine claimed only 9GB was used.

All files seem to currently be there with their original data intact.

I got a new Mac Mini server because Drobo is officially supported on it, and was hoping to create a new HFS+ partition and copy the files over using MacFuse. Once I got drobo dashboard installed and the drobo mounted, the capacity lights on the front of the drobo went out, and drobo dashboard is usually telling me only 9GB is used, but occasionally flashes up with the more correct 3.74TB used.

If I create the HFS+ Partition and start copying files, will the drobo write over blocks that may actually have data in them, or will it protect areas where a filesystem has written even if they become “deleted”? Or is this a complete unknown at this point?

Due to the internal block-mapping structure of BeyondRAID, there is no guarantee that anything “deleted” can be undeleted. Or in other words, once something is deleted, that physical block is freed for use, so it may end up being mapped to other data and therefore overwritten.

Do not rely on traditional “just grab the block where it used to be” undelete - it will not always work. It might work sometimes, but there’s no guarantee.

None of the files are deleted. I never deleted a file, but the filesystem does not seem to know how much space is used (says 8.63GB when something like 4.5TB should be used), but the drobo was still showing 7 lights of capacity used until I hooked it up to the drobo dashboard. At that point the drobo seemed to take the filesystem’s word for it and the capacity lights went out. The filesystem is mounted as a standard macfuse ext2 partition (read only) and the files are currently accessable as normal.

I should note that occasionally the Drobo Dashboard will for a few seconds show the 4.5TB used graph before going back to the 8.63GB used graph on the computer. It may be checking drobo status periodically, and the drobo still thinks that it’s using that much space.

The capacity lights “sniff/peek” from the volume bitmap (or whatever it’s called in non-NTFS filesystems). Usually a filesystem check will fix that.

As long as the filesystem was intact before the strange event, the internal block-mapping should be intact as well, and anything that was there is still there and mapped to the correct blocks, even if you can’t see or access it.

You may see differing behavior with Drobo Dashboard running as opposed to without it running. Oh wait, you do…

I would definitely run a filesystem check before writing any new data to the unit.

Alright. I am still a little worried about a disk check damaging data that I can access right now, and while the data can be reproduced, copying it off the drobo while it is accessible will be faster than reproducing it. I will try the disk check, and tell it is automatically correct all errors once I am done (Since it was asking me constantly).

Thank you.

PS: My concern I suppose was that it would be defragmenting data into blocks that the filesystem though was free, but the drobo did not.


I have two options, and I want to know which one is less likely to damage data.

I can create a second volume on the drobo, completely seperate from the damaged volume, and copy the data from the old volume to the new one.

Or I can run the e2fsck on the volume first, then create the second volume and copy the data over.

I really at this point don’t understand whether the Drobo might overwrite the blocks that data is written to or not.

Well, regardless of whether Drobo thinks the block is free or not, if the filesystem says it’s free you wouldn’t be able to access it anyway.

The danger is more that the filesystem has blocks in use that Drobo does not think is in use.

Creating a new volume is writing more data, and writing more data is likely to have Drobo (re)use those blocks that it thinks are not being used, causing corruption of data.

Imagine you go to the post office with a pick-up ticket. The worker looks at your ticket, figures out where your box is in the storage area, retrieves it, and brings it to you.

In this case, your pick-up ticket and postal worker is your filesystem, and the storage area is Drobo.
The pick-up ticket is what you have access to.
The storage area contains all the actual data.

There may be data in the storage area that no pick-up tickets exist for, but you’d never know this because the only visibility you have to what’s in the storage is what pick-up tickets you have.

It’s kind of like going to the store for an item and it’s not on the shelf. You ask the store employee if they have any in the back. Since you yourself can’t get into the back, whether you get the item or not is entirely up to the employee - they may actually be in the back, but the employee may be too lazy to check and they tell you they have none.

When I first remounted the Drobo, and checked the disk to see only 9GB used. I was all ready to open up the mount point and see a random 9GB of files I could not care less about remaining, and everything else gone. Much to my surprise I was able to copy any data off with no issues, nearly 1TB of unique data now. I guess this is a fluke of EXT3 and how it handles free disk space.

I have decided that I will copy the data off the Drobo onto other external hard drives and then wipe the ext3 partition and create a new one. That solves the issue entirely, it will just take several days.

I am so far impressed by the fact that the Drobo has not damaged any data. I am actually feeling a bit safer about using it at a storage system now that I know in some cases the filesystem can be damaged, and the Drobo won’t loose all the data.