The only way I can think of to check the DroboFS filesystem is to enable SSH, connect, and then run “fsck -y”. You can’t repair a remote filesystem, so none of your desktop utilities are going to work.
Perhaps there’s a more elegant way of proceeding, but that’s my best suggestion.
-A Walk /etc/fstab and check all filesystems
-N Don’t execute, just show what would be done
-P With -A, check filesystems in parallel
-R With -A, skip the root filesystem
-T Don’t show title on startup
-C n Write status information to specified filedescriptor
-t type List of filesystem types to check
Funnily enough, when I run fsck on mine, I get this strange error message:
root@DroboFS:~# fsck /dev/sda1
fsck (busybox 1.14.2, 2009-07-29 17:47:47 PDT)
fsck: fsck.auto: No such file or directory
This is probably happening because /dev/sda1 (which is the FS storage pool at /mnt/DroboFS) is mounted as read-write, and you probably need to mount it read-only. I’m not sure what would happen if you did remount the partition while DroboApps are running (such as SSH), or even if you can remount that partition from the shell (there could be some strange mojo from DRI inside the NASD process to mount it, I’m not brave enough to try on mine ).
I’m getting less thrilled with BusyBox by the day. I completely understand why it’s the solution DRI used - it’s made for embedded systems like that, but it doesn’t make the bare-bones design of it any more pleasant.
Agreed on your assessment - and also not something I’d like to attempt. I assume fsck is run during boot, so the best I can say is reboot the DroboFS and let it check the filesystem.
We’ll probably never get to a stock distro - there’s simply too much to test and certify. Busybox is the best we’re likely to see, as limited and buggy as it may be.
Rant mode: activated.
However, I’d settle for a Linux install that wasn’t fundamentally broken (/etc/passwd issue - yes, I’m beating a dead horse). My wishlist would include better diagnostic tools, whether that’s more complete disk check tools, SMART status tools, or something to more easily get drive health, status, capacity, etc information out of nasd. And for God’s sake, get rid of Dashboard for NAS devices. It’s a hacked together solution that doesn’t work very well, and network-attached devices are expected to have web administration interfaces. They can be used from anywhere, tunneled across VPN’s easily, don’t take ages to respond (ages being >1 second) and don’t require desktop installs consisting of multiple startup items, iSCSI kexts that aren’t needed, background services, etc. Cheap Linksys routers have had better admin interfaces for years.
hi from simplistic way of thinking…
there “must” be a way to be able to check and fix the FS in case of filesystem corruption
Ricardo, when you mention that only certain fsck commands would work… do you know which ones need to be run?
eg on my windows, (direct attached), i type chkdsk driveletter: /x for example
do you know what would be the equivalent command for an FS?
if not, then we need someone to help clarify it (ideally DRI)
how do other tools like norton disk doctor etc run on certain servers?
There is, and the FS (as any Linux machine) should do it automatically at boot time. Now, between “should” and “does” there is a lot of ground.
The command would be simply “fsck /dev/sda1” from an SSH session. However, as I indicated above this does not work because under Linux it is not wise (and in fact may be dangerous to your data) to run a filesystem check on an active filesystem (i.e., a filesystem that can be used to read and write data). Therefore the command fails as a safety measure.
Since the FS runs a variant of Linux, it should be possible to take the data filesystem (/dev/sda1) down, and run that command. However, since all the user “interface” (i.e., SSH server) relies on that same filesystem that is going to be checked, I’m not sure whether or not it is a good idea. Think of it as trying to trim the grass under your feet while you are standing on it.
And even if that worked (i.e., take the filesystem down, and check it while running programs that are located on that filesystem), I’m not quite sure that we could bring it back online afterwards. While nosing around in the system files on the FS, I have not seen where or how the data filesystem is mounted. I have this bad feeling that some weird voodoo is needed to bring the data filesystem online, and that it only happens inside the NASD process. In other words, you might get yourself in a situation where you cannot bring the data filesystem back online.
This is why I’m very uncomfortable with giving you any more specific details. I have a pretty good idea on which commands to use, but I am quite afraid that one wrong step will make you lose all your data irreversibly.
Yes. An answer from DRI would be most appreciated. Specially about the mounting/unmounting of the data filesystem.
Because their filesystem is NTFS. NTFS allows for some tricks that are not supported by EXT3, such as on-the-fly checking. Although if you want to check the boot partition even Windows is going to tell you to reboot.
if the drobo hardware is the main controller of enabling / disabling (unmounting etc) the active volumes… maybe the way forward is the the dashboard to have an extra feature/tab that shows when the last internal filesystem check took place, (along with its findings) and an option to invoke it at some (safe) point in time?
(it might need some firmware upgrades but thats probably the safer way to force invoke it, assuming the drobo otherwise does it itself in some way after inactivit, and/or if it thinks there is a need for it etc)
Yeah, the most you’re going to get is “Open a support ticket”, or instructions on how to reload firmware. Kind of odd, given how in-depth their phone support is in my experience. Of course, you can only get phone support past 90 days by paying a large chunk of change, so…
DRI’s entire support model and philosophy just leaves a very sour taste in my mouth, and it’s gone a long way toward ensuring I don’t purchase or recommend their products in the future. Private boards so you don’t know what you’re getting into. Limited support even there, with no feedback or response beyond the most basic level 1 support. Distancing it from DRI Inc by not even hosting it on “drobo.com”. And of course the 90 day limited phone support. None of this says they stand behind their products.
I’m starting to realize that every disappointed and ranting blog against Drobo products started with a enthusiastic user who was completely let down by the company post-sale. It’s quickly become a product I tolerate - barely - rather than gush about, which is how I went into it.
I was thinking that it would be possible to compile a version of OpenSSH (or dropbear, for that matter) that would install itself in /dev/shm.
/dev/shm is a ramdisk automatically created on the DroboFS at boot time. It is about 30 MB, and should be plenty enough to have a self-contained environment to stop all apps, unmount the disk pack, run fsck and restore everything.
I managed to find the exact parameters used to mount the disk pack:
That does suck. It’s not like DRI ever gave much support, but of the few DRI employees that would post here, Jennifer would spend a few posts to understand an issue, and it felt like she was at least trying to take concerns up to corporate.
Now all we get is “open a support ticket”.
I may be stuck with my DroboFS for a long time, but DRI will never get another solitary penny out of me. Or anyone I know. It’s enough to make me look at what eBay rates on a DroboFS are, and how much I’d have to spend to get a Synology DS1511+ today.
(Yeah, I harp on this. It’s not like anything has gotten better.)
Long story short: best thing I’ve ever done. Although it is pretty old, it is quite silent and works as a wonderful secondary backup device. I leave it on my desk at the university, and use it to replicate important data from the FS (family pics and videos, etc) remotely. I also managed to set it up as a Time Machine disk for my Mac.
Anyway, my point is that I hope that in the (near) future someone will hack the FS to install some full-fledged Linux distro without losing the support for BeyondRAID. Once that happens I’ll be a happy camper.