Strange volume behavior from same Drobo/disk pack

I’ve got an odd problem, which seems to correlate to the addition of Mac OS X 10.9.

I have a Drobo connected via fw800, which has two volumes on the disk pack. The first volume contains a handful of files, but is mostly my iTunes library. The second volume contains more files/folders, and is also a Time Machine volume. Lately, the Finder treats volume 1 oddly. iTunes sees it, as items play just fine, but I cannot add any files to the volume. Additionally, it doesn’t show on the desktop or a Finder window sidebar, but volume 2 does. Disk Utility sees both and shows both as mounted. I can browse volume 1, but cannot change the name of any file, move them, etc. If I reboot the Drobo, everything comes back fine. If I then reboot the Mac, I’m back to just volume 2. Getting info shows the same permissions for both, even when volume 1 isn’t on the desktop.

I hope these symptoms make sense.

Has anyone seen anything like this before?

Do you have the same problem when connected via USB?
If you have another system, does it occur there as well? If so, is it the same OS version?

Good questions, which I will try to answer. I prefer FW because the port is otherwise unpopulated, and I can use it as a hub when necessary to plug in other drives.

I’ll try the USB switch around and see if that causes a change in behavior. I’m all 10.9 here, except a 10.5 legacy machine.

hi key, it sounds like you upgraded to mac Mavericks?

I did, yes (I noted 10.9 above). Is there known issue?

Various users on various forums for various products have been reporting various issues.
It’s not just a Drobo thing, unfortunately.

This happens often after a major update/upgrade to an OS is released… Despite developer previews and betas, the fact of the matter is software changes just prior to release are common. So even if you’ve been following the progress (which sometimes causes wasted efforts when there’s a bit direction-change midstream), it’s not unlikely that some unexpected change sneaks in, or there’s some previously-unknown interaction between pieces (software or hardware) that causes problems.

Unfortunately as more and more systems move toward automatic unattended upgrades, this will likely pop up more often. In the systems I work with, we intentionally removed automatic update notifications in our software (it’s available for the lower-end versions) because in a mission-critical scenario the last thing you want is something to literally change overnight or without you being aware.

-10 for automatic unattended upgrades
(sorry, that was my vote, similar to the +1 we usually use) :slight_smile:

There are always pros and cons to automating things, but i think there are more cons than pros for that.

btw key, did you have any luck with trying out the same things via usb in the meantime?

Nothing was “unattended” or automatic on my system.

No luck switching to USB. The only thing that gets it going again it is a Drobo reboot. Also, oddly, I unmounted the one volume I could see, then put the Drobo into standby, then unplugged the power to Drobo. Upon doing so, the computer complained of having the drive removed without being unmounted. I couldn’t see it to unmount it!!

hmm, what happens if you shutdown and turn everything off (from power)
and then only power on the drobo (until it completes its startup sequence etc)
and then power on the mac?[hr]
(also when you mentioned your “10.5 legacy machine”, is that still available for testing?)

If I reboot the Drobo, I get everything back. By everything, I mean, both volumes mount as expected. Once Drobo is up and running, and the Mac is running with it, a restart on the Mac side yields only one volume being mounted upon computer reboot. That, in turn, necessitates a Drobo reboot to get everything back to normal.

These other threads may be helpful…

Those are for networked Drobos. Mine is direct attached via firewire.

Ack sorry, you’re right…
On Windows a drive can be attached but not given a drive letter, not sure if the same applies to Mac OS.

No letters on the Mac. They are assigned a disk number, but that is invisible the regular user.

I’ve somehow managed to get the 2nd volume mounted without a Drobo reboot. I ten verify disk from DU and then it appeared; not sure if it caused it, or if it is a coincidence.

Yeah, was aware there are no letters on Mac, was wondering how it handled “make this visible to the user” (essentially how it handles a unix mount), so sounds like the drive number is how it handles that behind the scenes. Thanks. :slight_smile:

Most folks have 16TB volume size so they only have one volume unless they have an 8 or 12 bay Drobo.

So, keep an eye on it, run it through a few more shutdown/restart test and unmount/mount tests.
Filesystem inconsistencies can cause slow/no mount on both Windows and Mac OS, so likely that did the trick though.

[quote=“bhiga, post:15, topic:136553”]
Yeah, was aware there are no letters on Mac, was wondering how it handled “make this visible to the user” (essentially how it handles a unix mount), so sounds like the drive number is how it handles that behind the scenes.[/quote]

You’re correct: OS X mounts exactly as UNIX. UNIX assigns a device ID like /dev/sd0a or /dev/disk0s1, which is then mounted as some arbitrary name. OS X mounts it as the volume name, e.g. /Volumes/Drobo2, then creates an icon named Drobo2 on the desktop.

In this case, it sounds like the second Drobo volume was disconnected instead of gracefully being closed out and unmounted. The next time the OS tried to mount the volume, it noticed the “dirty flag” for that filesystem, reported improper unmounting, and checked for filesystem problems. The “dirty flag” is written when the volume is properly mounted for read/write and is cleared when it is properly unmounted. It’s the computer version of those orange “REMOVE BEFORE FLIGHT” banners on aircraft maintenance tools. :slight_smile:

its good that you got it working again keytohwy,
(if your process keeps working, maybe you can write up a “how-tohwy” for others to use :slight_smile:

speaking of “dirty flags”, i had a lot (and i mean a lot) of attempts on my xp machine to try and get Chkdsk to run at next startup (on the windows C drive)

It simply would not run it… and i had to reboot the machine around 12 times in safe mode, safe command prompt mode, and even use a Recovery Console bootdisk before finally being able to get it to self-scan on startup.

Unfortunately i cant seem to get rid of the Ntfs Volume bitmap error’s that chkdsk keeps reporting, so might have to rip that drive out of the host machine, and plug it as a secondary ‘dumb’ ntfs drive to run chkdsk on it via another o/s boot drive?

Not so fast, I guess. I rebooted today and neither volume mounted on my desktop, but both are visible to the OS. DU sees both, and shows one as mounted. That volume contains my iTunes library. And in fact, if I launch iTunes, I can play files. Further use Finder window toolbar shortcuts to see the files on the drive, but again, it is not mounted on the desktop or the sidebar.

The other volume shows as unmounted in DU. I’m currently running a Verify Disk operation from DU, and it says it will take another 16 hours to finish (already a couple of hours in). This volume is 4TB, with 2.12TB currently occupying space there. I’ll let the process run. Perhaps it will finish by morning. Mind you, this is a Verify, not a Repair.

I’m curious if you can mount the second volume manually in Disk Utility.
There might also be something in your OS logs. The most relevant one is probably /var/log/kernel.log

So, after a couple of weeks playing with it, here is what I can re-produce.

• Upon computer reboot, only the “1st” Drobo volume is visible on the desktop, in the sideboard, and in open/save dialog boxes
• In the above situation, Disk Utility reports that both volumes are mounted
• DU rips through verify on the first volume, but the second volume takes so long that I’ve never let it finish.
• If I unmount the 2nd volume, then initiate a verify disk, the volume mounts. I then cancel the verify action.
• Once the 2nd volume mounts, it behaves as expected
• No difference between USB and FW.