I submitted a case to Drobo Support about my drobo rebooting during heavy disk access. I have a yellow warning on bay 2, and when I access large amounts of data, the drobo reboots, then comes back with the exact same amount of capacity used/free, but no longer has the yellow warning. At this point, I can no longer access the drobo and have to reboot it. Support recommended I do a disk check on the volumes, but they told me to do it in windows. I have the drobo connected to the network via droboshare with the drives formatted to EXT3, so check disk in windows is not an option. Support told me they do not provide support for EXT3, and I should post here to see if anyone knows how to run a disk check with this sort of file system. I tried fsk from a Ubuntu live cd with no success and was wondering if I can ssh into the drobo and run a disk check from there.
Also, slightly off topic but may be related…when browsing around here, I saw someone mention “the 80% capacity thing”. I’m currently sitting a 1.8TB used and 222.63 GB free, which is about 90% of capacity. I plan to replace the yellow drive soon, but need to fix this problem first. I don’t want to just throw money at a problem hoping it gets resolved. Does anyone have a better reference for the 80% thing mentioned? Are errors inevitable at this percentage of capacity?
80% capacity is when it lights up yellow - that is ALL that happens, it should not produce any errors, or cause any other effects, 80% capacity is when it prompts you that it will be needing more space soon.
(it may be 85% - i forget)
at 90% or 95% (again i forget which) the light goes red - this means it NEEDs more capacity - again this should not produce any errors or any effect which could threaten your data integrity. HOWEVER past this point, if you continue adding data - drobo will intentionally get slower (to avoid you ever actually hitting the buffers and filling it up totally.
rebooting under heavy load sounds more like an issue with your power supply - does it have a “revision” written on the bottom?
It does not specifically say “revision”, but there is a white sticker near the bottom of the text that says “A50”. Power is something I considered, since the supply runs both the drobo and the droboshare in parallel. Do I need to request a more powerful supply from data robotics?
Also, forgot to mention that my first thought was heat, but I put a thermometer on the exhaust and happened to catch it as it was rebooting. The thermometer was at 85 degrees, and they claim drobo doesn’t have heat issues until 95, so I doubt it’s heat.
To run fsck from a live CD, you have to connect the Drobo to the PC via USB, not droboshare.
boot the PC, get into a shell window,
plug Drobo in via USB.
sudo bash
dmesg | tail -40
see the device (should say something like sdz is connected.)
fsck /dev/sdz
or…
To do it without changing any hardware, download the droboshare SDK. Instructions there tell you how
to get a root shell on the ds, where you can run fsck.
The first time I did connect the drobo via usb and attempted to fsck as you described, but received several errors about not being able to fsck the volume. I read somewhere that drives could not be fsck’ed while mounted, so I unmounted them and received errors about the magic number on the volume being incorrect (sorry I’m being vague…I’ll post any errors I get the next time I try it). I also already have Dropbear loaded, so I’ll probably try this way first.
On a side note, the next volume upgrade I do on the drobo will give me an opportunity to remove all data and reformat the file system if necessary. The plan is to have the drobo (via droboshare) connected to the home network where it will serve as file storage for a Win7 machine, a macbook pro for time machine, and possibly a linux machine. Is NTFS a good idea since Drobo support will help me with it? Should I stick with EXT3 even though Drobo support has told me they don’t provide support for the EXT3 file system? Is it even possible to connect to NTFS via Mac OSX through the Droboshare?
Using Drobo through DroboShare is just like using it through a computer sharing it. If you don’t have a specific reason to use EXT3, then I’d definitely use either HFS or NTFS, at both are fully and officially supported.
DroboShare can use any of the three and shares the volume via SMB, so your Mac OS machine should be able to connect to it too.
When a drive is connected to a computer and shared, the filesystem type is abstracted away and the systems accessing the shared volume only need to be compatible with the sharing protocol (AFP, SMB, etc) in order to access the volume. You can run into issues where you might try to do something the underlying filesystem doesn’t support, but generally the system doing the sharing will stop you.
Good to know, thanks. As far as the power supply having an “A50” sticker on the bottom…do I need to request a new supply to power both the droboV2 and the droboshare via the Y cable? I’m probably still a few days away from doing a fsck, but I’ll post the results when I do. I am hearing a bit of clicking coming from one of my drives (they’re all Seagates, but the next one probably won’t be).
I’ll have to wait until I get home to check the part number, but I know for certain that there is no sticker with “REV” of any kind, only the one that says “A50”
On the power brick I have: Model: EA11003A, P/N: EA11003A(50)[hr]
Ok, I just tried to fsck the drobo via the linux live cd, and it wouldn’t let me while it was mounted. I unmounted the volume, and it says:
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (2-Jan-2009)
fsck.ext2: Superblock invalid, trying backup blocks…
fsck.ext2: Bad magic number in super-block while trying to open /dev/sde
The superbock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193
aj, you were right. Thanks for pointing that out, just something I overlooked. fsck is currently running at home on my first volume. I’ll post the results after my second volume completes
Ok, here’s the results for both partitions from fsck:
sde1 - Drobo: ***** FILE SYSTEM WAS MODIFIED *****
Drobo: 13/8388608 files (0.0% non-contiguous), 330301/536870202 blocks
sdd1 - fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
Drobo primary superblock features different from backup, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 3015336, i_blocks is 358976, should be 357952. Fix? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(275428858–275428863) -(275429249–275429254) -275430095 -(275430205–275430207) -(275430339–275430414) -(275430417–275430424) -(275430858–275430863) -(275430924–275430927) -(275431100–275431103) -(275431242–275431247) -(275431320–275431327)
Fix? yes
Free blocks count wrong for group #8405 (15, counted=143).
Fix? yes
Free blocks count wrong (71437574, counted=71437702).
Fix? yes
Drobo: ***** FILE SYSTEM WAS MODIFIED *****
Drobo: 44766/8388608 files (27.4% non-contiguous), 465432500/536870202 blocks
I can tell that errors were found, and I hope they were fixed, but I’m not entirely sure how to read everything. Is there anything here that indicates something seriously wrong with the disks?
Been quite a while since I have seen an fsck output with errors. Journaling filesystems usually keep themselves consistent.
So from that it looks like fsck has found an inconsistency and marked some blocks free. I think this kind of problem can be caused if a file was being written to the Drobo and there was a problem - such as a power failure or reboot.
Not really a surprise as your first post describes the Drobo spontaneously rebooting. So the question is did the file system inconsistency cause the Drobo to reboot; or did the reboots cause the filesystem inconsistency
ext2/3 is native to the system it is droboshare is ARM based, is 32bit, big-endian. Your live-cd should be 32-bit.
perhap try -s (swap endianness) and see if the results are better.
Since I posted those results, I haven’t had an issue with the Drobo, but I’m being a little more gentle to it now in terms of disk access than I was before. I’m going to coddle it until I have the new disk in hand to add storage, since I’m going to pull the data, scan each disk, reformat to NTFS and change the allocation size from 2TB probably to 16TB, then move the data back.
