Crap…

Well, the port multiplier replacement came in and all installed just fine.  Good news is that it was the PMP that had failed.  Bad news is that when I got everything configured as it was before the failure, unRAID decided that those three drives were all new and started clearing them!

I hit the reset button on the unRAID box after only a few seconds…it never budged past 0%, but damage was done.  All drives subsequently showed back up as unformatted when unRAID resumed operation.  I had lost roughly 750GB of TV episodes and my entire NAS drive.

Fortunately, I started a recovery process that, so far, appears to be promising.  I performed it first on the NAS drive.  It involves using reiserfsck commands that are not for the faint-hearted.  However, considering my predicament, I had no choice.

I started out with the following commands that basically just rebuilds the resierfs directory structure.  That’s probably dumbing it down a lot since I’m about the farthest thing from a linux guru.  

root@MEDIASVR:/# /root/samba stop

root@MEDIASVR:/# reiserfsck –scan-whole-partition –rebuild-tree /dev/md4

unRAID has to have the array started, but samba sharing has to be stopped in order for it to begin the rebuild.  After about 5 hours, I had a single lost+found folder that contained many more folders named with seemingly random numbers and over 100 randomly numbered files with no file extension.  After perusing a few of those folders, it appeared as all of my old directories were in them.  I have no idea what the no-extension files are, however.  I’m hoping they’re just old deleted files that were recovered after the fact.

I was a bit more at ease until trying the next drive.  This was the one that contained the bulk of my TV episodes and after starting the rebuild, it ended shortly after upon hitting a bad block.  I now had to do a 

root@MEDIASVR:/# /sbin/badblocks -b 4096 -o badblocks.lst /dev/sde

to generate a list of all the bad blocks that the drive could discover.  This lasted about 5 hours - the same length as a recover.   Once finished, I had to make reiserfsck aware of this list and modify my rebuild command like so,

root@MEDIASVR:/# reiserfsck –scan-whole-partition –rebuild-tree -B badblocks.lst /dev/md5

This allows the bad blocks to be skipped or reallocated - I’m not really sure…I just know that reiserfsck knows when and what to do at bad block.  As I write this I have about 35 minutes to go on the rebuild before I’ll see what the damage is.  Considering my TV show folders begin at three levels deep, I think I should be in pretty good shape at retaining the directory structure I had.  I’ll be doing an RMA on this drive once I get everything moved.  Seagates have 5-year warranties and this one is not even two yet.

After spending a few minutes checking that drive when it’s done, I’ll immediately begin with the third drive.  It was, at most, about 2/3 capacity remaining and was a spillover for the other TV episode drive.  I can only hope for no more bad blocks there so I can get this done tonight and spend tomorrow getting it all back in order to use, while finding out what I’m missing.  I’ll be sure to update tomorrow.

In other news, I received a P3 Kill-A-WATT P4400 device that I had ordered yesterday.  The Kill-A-WATT plugs into a standard 3-prong electrical outlet and allows you to monitor all the characteristics of what is coming out of that outlet to the device that plugs into the Kill-A-WATT.  I can get KWh, line condition, voltage, etc.  I plan on using this on the most used electrical devices in the house to see where we can cut some corners.  Computers, applicances, stereo equipment, etc. will eventually all be tested.  I may start a small index so that others can compare to it and see what their devices are drawing while on.  More on that later.

Recent Entries

4 Responses to “Crap…”

  1. havix Says:

    Did you ever find out why these were detected as new drives? This scares me as I’ve had some drive failures lately with WHS and just got UNRAID up and running to avoid issues like this.

  2. Jon Says:

    I never did, but I have to take some blame as I should have taken notice that they were detected as new drives to begin with. I could have at least gone to the unRAID forum to find out what I needed to do before hitting that Restore button.
    Port multipliers with unRAID is quite new and I’m pretty sure I’m only one of a handful that are even doing it right now (I only know of two others from the forums that use them). I still find unRAID to be much more reliable and useful as a pure NAS than WHS.

  3. havix Says:

    Thanks for the response. It sounds like a fluke. I’ve been enjoying unRaid so far but it’s a little slow to move over my old data. I am happy I’m not running WHS anymore though. unRAID appears to be rock solid, quick to boot, and easy to manage. It’s fun to read your experiences with this product. Keep up the good work!

  4. Jon Says:

    It’s probably too late for you, but a quicker way to move data to an unRAID server is to NOT activate a parity drive prior to moving. This will disable the parity check process during copying data and will result in at least double the transfer rate. Typically, I get around 11MB/s with parity enabled. With it disabled, expect whatever the true transfer rate of the drive is, minus overhead for SMB (you can expect anywhere from 25MB/s all the way into the 50-60MB/s range). After your copy is complete (make sure you don’t cut and paste, eliminating an existing copy if anything goes wrong), simply enable parity, let it calculate and enjoy your new protected data store :)

Leave a Reply