Jump to content

[SOLVED] "Stalled" Disk Formatting process even post Pre Clear


Recommended Posts

Hi folks,

 

I am creating a brand new unRAID system with unRAID 4.7 and 7 WD20EARX hard disks (2TB) and am noticing that the formatting process is taking forever.

 

All the hard disks are empty, and the unRAID main screen process has created the Parity drive over about 10 hours but it now appears that the other 6 hard drives are just 'sitting' there in "Formatting..." mode, but they don't appear to be doing anything.

 

I had already precleared the drives using the -A argument with the 4K alignment option selected without the jumper on the drives, but for some reason unRAID has not detected that these drives have been pre-cleared, and the formatting process seems to be taking forever.

 

Just wondering if anyone else has had this problem and what to do about it. Should I force stop the array, restart unRAID and then try to have the drives formatted again?

 

unRAID Menu shows all drives as "OK" status and the parity drive being valid, but the drives are still perpetually in "Formatting" mode without actually doing anything.

 

Advice appreciated.

 

Cheers

Mike.

Link to comment

Hi folks,

 

Attached is my complete SysLog as of this moment.

 

System Specs:

 

Gigabyte GA-Z68XP-UD3R Motherboard

Intel Core i3 2120

7 x Western Digital 2TB Caviar Green - WD20EARX

 

Using unRAID 4.7 Pro (registered)

 

I am concerned with some of the log entries particularly around 13:18:32 29 January where it says that there is "wrong FS type" - assuming FS = file system.

 

Also screengrabbed is my settings screen on the unRAID terminal, the main unRAID screen and the unMENU screen as well.

 

The hard disks are completely empty and don't have the jumper on them as per factory settings. They have also been pre-cleared with the 4K MBR option on.

 

Thanks for your assistance.

Cheers

Mike.

 

Welcome any advice.

 

unRAID_Main_Screen.GIF.c1a4feef553696d873041d66221a37b3.GIF

unRAID_Menu_screen.GIF.9a0207963b89467be9796fe0cc353188.GIF

unRAID_Main_Screen_Settings.GIF.62b2039329a1a28366810859d8610498.GIF

Complete_UnRAID_SysLog.txt

Link to comment

Everything in your syslog looks perfectly normal.

 

The lines you are concerned about are normal, as the FS (file-system) has not yet been created on the disks, therefore they cannot be mounted. 

 

The actual commands to create the file systems are here in the syslog, a few seconds later:

Jan 29 13:20:03 BargeTower emhttp: shcmd (69): mkreiserfs -q /dev/md1 2>&1 | logger

Jan 29 13:20:03 BargeTower emhttp: shcmd (69): mkreiserfs -q /dev/md2 2>&1 | logger

Jan 29 13:20:03 BargeTower emhttp: shcmd (69): mkreiserfs -q /dev/md5 2>&1 | logger

Jan 29 13:20:03 BargeTower emhttp: shcmd (69): mkreiserfs -q /dev/md3 2>&1 | logger

Jan 29 13:20:03 BargeTower emhttp: shcmd (69): mkreiserfs -q /dev/md6 2>&1 | logger

Jan 29 13:20:03 BargeTower emhttp: shcmd (69): mkreiserfs -q /dev/md4 2>&1 | logger

Jan 29 13:20:03 BargeTower logger: mkreiserfs 3.6.21 (2009 www.namesys.com)

Jan 29 13:20:03 BargeTower logger:

Jan 29 13:20:03 BargeTower logger: mkreiserfs 3.6.21 (2009 www.namesys.com)

Jan 29 13:20:03 BargeTower logger:

Jan 29 13:20:03 BargeTower logger: mkreiserfs 3.6.21 (2009 www.namesys.com)

Jan 29 13:20:03 BargeTower logger:

Jan 29 13:20:03 BargeTower logger: mkreiserfs 3.6.21 (2009 www.namesys.com)

Jan 29 13:20:03 BargeTower logger:

Jan 29 13:20:03 BargeTower logger: mkreiserfs 3.6.21 (2009 www.namesys.com)

Jan 29 13:20:03 BargeTower logger:

Jan 29 13:20:03 BargeTower logger: mkreiserfs 3.6.21 (2009 www.namesys.com)

 

Apparently, the array was ALSO attempting to initially calculate parity at that same time.  That would have slowed things down considerably as the disk heads would have had to have been seeking like mad.

 

The initial parity calc finished here:

Jan 29 23:03:25 BargeTower kernel: md: sync done. time=35094sec rate=55665K/sec

 

Have you refreshed the browser window since then? 

(Have you tried pressing the "Refresh" button on the web-management console? )

 

One more thing... the pre-clear has nothing to do with this when initially starting a new array and initially calculating parity.  It does verify the disks are basically sound and weeds out those destined to fail in their first few hours of life. 

 

Joe L.

Link to comment

Hi Joe,

 

Thanks for your help.

 

I have refreshed many times, used several browsers etc so it's definitely just sitting there in 'formatting...' mode.

 

What do you suggest I do here? I have checked all my pre clear logs from the other day and they report no errors yet the whole system is in limbo.

 

Is it worth force shutting it down, rebooting an trying to restart the array?

 

If so, how do I do that? If there's another option, what do you suggest?

 

Thanks mate,

Mike

Link to comment

Hi Joe,

 

Thanks for your help.

 

I have refreshed many times, used several browsers etc so it's definitely just sitting there in 'formatting...' mode.

 

What do you suggest I do here? I have checked all my pre clear logs from the other day and they report no errors yet the whole system is in limbo.

 

Is it worth force shutting it down, rebooting an trying to restart the array?

 

If so, how do I do that? If there's another option, what do you suggest?

 

Thanks mate,

Mike

Since the disks are not mounted, you should be able to log in via telnet, or on the system console and type:

/root/mdcmd stop

 

which should cleanly stop the array.  (normally you would have to terminate SAMBA and un-mount the disks, but since they are not mounted, you can skip those steps)

 

Then, you can refresh the unMENU screen and it should show the array as stopped.  (The unRAID screen should show the same)

 

Then... you can use the "Start" button on the unRAID screen if it is visible.  If not, since the array is stopped, you can reboot and it should all come up cleanly.

 

You can reboot from the command line by typing:

reboot

 

Normally you would not want to use the "reboot" command if the array was started, since it would force a parity check on reboot as the array would not be stopped cleanly.  Since the array will be stopped (if you use the above command to stop it first) it should not do a parity check on reboot.

 

Joe L.

Link to comment

Hi Joe - sorry to keep coming back to you.

 

I cannot invoke the MDCMD STOP command from the command prompt after telnetting into the Tower.

 

It gives me the "Write Error : Device or resource busy"

 

Do I need to unmount or do something else in order to safely stop the system and then restart as per your other suggestions?

 

Thanks,

Mike.

mdcmd_not_working.GIF.0ec473b0f683abbcab91859c4612b20c.GIF

Link to comment

Folks,

 

Problem was resolved with the advice given - however the reset of the Tower was tricky - for some reason no matter what I did, the drives were always "busy" - but given there was nothing on the drives I took the risk and executed the "Reboot" command.

 

Full power down of the Tower and then boot up again gave me the main unRAID screen - aborted the Parity check as one had completed a day before only, executed the Format function which only took about 10 minutes for the 6 remaining drives, and before you knew it, all drives were functioning!

 

Commencing creating Shares and then will copy my data over.

 

Thanks to all, especially Joe for assisting!

 

best wishes,

Mike.

Link to comment

Folks,

 

Problem was resolved with the advice given - however the reset of the Tower was tricky - for some reason no matter what I did, the drives were always "busy" - but given there was nothing on the drives I took the risk and executed the "Reboot" command.

 

Full power down of the Tower and then boot up again gave me the main unRAID screen - aborted the Parity check as one had completed a day before only, executed the Format function which only took about 10 minutes for the 6 remaining drives, and before you knew it, all drives were functioning!

 

Commencing creating Shares and then will copy my data over.

 

Thanks to all, especially Joe for assisting!

 

best wishes,

Mike.

Before going too far I'd perform a full parity check by pressing the "Check" button.  Since you have unMENU installed, perform the NOCORRECT version available from its web-page.  (easiest to recover from if there is any issue, as it does not overwrite parity if a data disks is un-readable and returns zeros instead of correct data.)

 

So far you've written the parity disk, but until you perform a check, you have no idea if what you've written is readable.

 

I've no idea what had the disks "busy" as they sure were not mounted...  Glad you are up and running.

Yours is not the first time I've heard of what appears to be a deadlock when formatting multiple drives at the same time. 

 

Joe L.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...