I recently had one of my 1.5TB drives failed. After replacement and during rebuild I had to stop the rebuild process as we lost power, the box went down hard when my UPS choked (I know things couldn't have gone much worse).  When I brought it back up one of my other 1.5TB drives showed up missing, cache and recently replaced drive showed unformatted. Brought the box down and back up, missing 1.5TB drive was back, started rebuild, seemed to go alright, but somehow I've lost 300G or so worth of data...but I can replace it in time.

 

The only outstanding issue now is that my cache drive shows unformatted, and I'm unable to get it formatted.

 

I click format in the web interface, it says formatting, upon refresh I'm back at the main status page and it still displays unformatted.

 

syslog contains the following entries:

Dec 19 23:22:42 storage emhttp: writing mbr on disk 16 (/dev/hda)

Dec 19 23:22:42 storage kernel:  hda: unknown partition table

Dec 19 23:22:43 storage emhttp: shcmd (27): mkreiserfs -q /dev/hda1 >/dev/null 2>&1

 

I've looked at the partition tables on some of the other drives and noticed they start at cylinder 2 and attempted to manually build the partition table with fdisk, same message.

I even went as far as to dd the whole drive with zero's.

 

any suggestions? If you need anymore info please let me know.

Try the Preclear Disk procedure, might make a difference.  I can't guarantee it, because I don't know what is wrong either.  It's possible that electrical spikes have corrupted the firmware.  Get a SMART report and check it for anything unusual.  Post it here if you aren't sure.

 

Those syslog lines look correct for an unformatted drive.  If you could post the full syslog, then perhaps we would see something else suspicious.  Make sure it covers an attempt to format it.

 

Changes to the MBR or partition table usually require a reboot.  unRAID has never required it, so I don't know how the Linux kernel gets around that.

Changes to the MBR or partition table usually require a reboot.  unRAID has never required it, so I don't know how the Linux kernel gets around that.

The preclear_disk.sh process requests that the kernel re-read the partition table once it configures the MBR and partition table.  It also re-starts the "udev" daemon so the proper /dev/disk/by-* entries are made.

 

You should not have to reboot if you use it.

 

Joe L.

Ran preclear_disk.sh without luck. We once again lost power over night, this ice in the midwest is killing me.

 

This time after start up a parity check ran, once completed I hit the format button and it successfully created the filesystem and partition table so all is well. I did get slightly different syslog results so it appears it may have been an issue with the kernel rereading the partition table...

 

Dec 24 13:56:57 storage emhttp: writing mbr on disk 16 (/dev/hda)

Dec 24 13:57:00 storage kernel:  hda: hda1

Dec 24 13:57:01 storage emhttp: shcmd (26): mkreiserfs -q /dev/hda1 >/dev/null 2>&1

 

 

*edit* A little googling goes a long way

JoeL: question for you on preclear, very neat utility. I looked through but didn't see exactly where it was being done, so how do you display the current progress of dd like that? I work in a shop with around 3500 AIX, HPUX, Linux and Solaris boxes, displaying current dd progress like that would be really helpful in doing full reads of "failing" internal drives.

JoeL: question for you on preclear, very neat utility. I looked through but didn't see exactly where it was being done, so how do you display the current progress of dd like that? I work in a shop with around 3500 AIX, HPUX, Linux and Solaris boxes, displaying current dd progress like that would be really helpful in doing full reads of "failing" internal drives.

 

The progress marks during "reading" the drive are easy, as I only read 2000 "blocks" at a time.

 

The progress marks when writing to the drive are a tiny bit harder.

 

I put the "dd" command in the background, capture its process ID, and then send it a USR1 signal every 10 seconds.  "dd" will output its current progress when signaled in that way.

 

Now, you don't need a loop, if you have a running "dd" on a box, and are at the terminal where it was started, you can just type "kill -USR1 ProcessID"

 

In preclear_disk.sh (zeroing a drive) is done like this:

  dd if=/dev/zero bs=2048k of=$theDisk &

  dd_pid=$!

 

  # if we are interrupted, kill the background zero of the disk.

  trap 'kill $dd_pid 2>/dev/null;exit' 2

  while kill -0 $dd_pid >/dev/null 2>&1

  do

      sleep 10

    kill -0 $dd_pid >/dev/null 2>&1 && kill -USR1 $dd_pid

  done

the "kill -0 $dd_pid" returns 0 if the process still exists, and 1 if it does not.  It is used to get out of the while loop when the "dd" is done, and also to test if the "dd" is still running before sending it the USR1 signal.

 

Sorry to hear of your power outages.  We had two long outages here several years ago, both from ice storms, one for 7 days, and the other for 4 days.  Not a lot of fun when the house is entirely dependent upon electricity (well pump for water, heat-pump for heat)

 

Joe L.