Drobo

Orphaned/non-deletable files - know a solution?

Hi everyone,

I have been using my DroboShare and Drobo for a while now. Now that I’ve finished a clean migration over to Windows 7 (64 bit), I’m trying to clean house on some of my other computer problems - one of them is orphaned/non-deletable files on my Drobo…

The problem seems to occur from time-to-time when I do a large directory delete on my Drobo (connected through DroboShare). During the delete, I get a warning message on some of the files saying they no longer can be found with a skip/try again dialogue. After the folder delete operation finishes (I have to choose skip), the folder is still there and the files that were complained about remain in a strange state -> when I try to delete them, they look deleted, but when I refresh, they are still there. Now I have 3 old directories that I can’t seem to get rid of because of these orphaned files.

I have tried a few things (such as connecting the Drobo directly to my PC and tried using Ubuntu to delete them), but can’t find a solution that works.

Has anyone encountered this and has a solution?

Thank you!

I dont think this is a drobo issue, more of a filesystem error, I would try “Chkdsk [volume] /F” from cmd. You might also want to add the /X switch if just /F doesnt want to cooperate with you.

Caver, I hate to tell you this, but this is an endemic issue reported before and not addressed. This may be the ‘secret’ & proprietary way Drobo stores the information in its non standard FAT.

Often I delete a file, and it shows deleted (e.g. no longer visible), yet if I try to copy a file with the same name, it asks if I want to overwrite the ‘ghost file’. I also cannot delete emptied directories, as the file manager tells me the directory is not empty. I was told by Drobo that I may have file corruption due to some mis manipulation on my part. Ummmmmm trust me (famous last word), I’ve been with PCs since the original IBM dual floppy, and Altair machines.

We have an issue here, in denial. Fact is, that after a relatively long time, Drobo cleans up its act, and does fix the FAT. Who knows what goes on behind the scene. Fact is we have a reliabilty issue, and now my Drobo is a great music & video server. I would NEVER store any valuable info on the system, pending transparency on it’s file management and error correction disclosure. Now we know why it’s a black box, with no useful inforamtion displays. Nuff said.

Well, I’ve deleted files and replaced files on both local connection and DroboShare on my Drobo (gen 2), so I’m not sure what you’re encountering there (I’ve been with PCs since the PCjr, so not quite as long as you, but close)…

it was just a suggestion not a defenetive 100% proof solution, ive seen this kind of problems before with the FAT and usaly chkdsk fixed it for me. AND IVE BEEN AROUND SINCE 6502! :wink:

Interesting… Mark F said Drobo is a block-level device, and derives its “fill meter” from the volume bitmap so in theory you’d be able to format a Drobo with any arbitrary filesystem, but it wouldn’t know how full it is unless the filesystem is “known to Drobo.”

In the case of DroboShare, it’s a different story though, because the DroboShare’s OS handles the filesystem.

Back @Effortless, I’ve seen similar “delayed reaction” happen when using network shares, especially when there’s network latency or otherwise high load on the system. If you’re still seeing this type of problem, I definitely recommend what caver suggests - run Chkdsk on the volume. If Chkdsk finds no errors, then try a different USB port or USB cable (Firewire port or Firewire cable, if you’re hooked up that way), marginal cables can also cause delay problems.

This worked! I’ve been able to clear out the orphaned files and folders. Thank you…[hr]

Thanks for the pointers. Yeah, the chkdisk worked although I switched from my droboshare over ethernet to a USB cable for the repair process. I’ve only encountered the orphaning problem using my home network an have never really used any direct connections to my PC via USB or firewire.[hr]
Equifoto, I totally agree. It is both a Drobo issue and a filesystem issue - they are not independent, and finger pointing won’t solve it. This is a reliability issue that needs to be addressed as a priority by Drobo.

I didn’t encounter this type of issue with my old Iomega NAS - of course, they didn’t offer the storage expansion ease nor apps configuration options which drew me to the Drobo. That said, the fewer connection types and customization options of my old NAS (Ethernet only, no file system type choices, etc) most likely decreased the complexity needed to deliver a reliable solution.

I definitely love the Drobo flexibilty and wouldn’t want to go back to another solution (severely rationing disk space just has too many side effects and being able to expand without copying all your data somewhere else is magic). However, offering workarounds (like chkdsk) is “necessary”, but acknowledging and fixing the problems is the actual path to provide a “sufficient” Drobo solution in terms of trust and reliability.

bhiga:

In the case of DroboShare, it’s a different story though, because the DroboShare’s OS handles the filesystem.

Interesting comment. Are you implying that an accidental format and recovery would be different if the format occured on a Droboshare vs one connected to the USB due to the file handling? The file handling is network traffic only -right? The actual internal and layout will be the same by the black box - USB / Firewire / Droboshare has no bearing?

I would say yes. Because when you format a Drobo from a DroboShare, the DroboShare is the “computer” formatting the Drobo.

It’s just like having a shared drive on another PC. System A can write to System B’s drive, but System B is really doing all the filesystem work. It’s just getting a network request from System A that says “Hey, store this file for me, will ya?” Then System B stores the file using whatever means it has to.

This is why you can have a DroboShare format a drive as EXT3 and still access the contents from Windows PC (which doesn’t understand EXT3) over the network. Hooking up the same Drobo directly to the Windows PC will put the burden of knowing how to “speak” EXT3 on the Windows PC, and it’ll come up as an unknown volume type.

This is very much different from iSCSI, which is used on DroboPro. In iSCSI, it’s just like having a pure storage connection, just happens over Ethernet instead of a USB or Firewire cable.