The tower had a bad power failure (short circuit on 12v power output), the system was busy reading, and maybe writing (I'm not alone here).

Just after the time of the power supply automatic fuse, unraid restart, ouffff

 

Stangely, after reboot, all drive were physically present on the main menu of unraid, but some drives (6) were unmounted (...Mounting...)

And the writes counter of those drives were continuously incremented, so does the parity drive also. WTF? Writing?

 

A little frightened, I stopped the system (first by pressing the power button, and, after a while - time to hurry a screen and a keyboard - by then typing "reboot" on the console).

After this reboot, there was no more unmounted drive on the main menu, no strange writing, but a lot of strange repeated errors on sdk - the usb boot key.

Then I stopped the array again, and after a reformat of the usb key, everything seems ok, and, of course, the system is currently on a parity checking.

 

Question :

What was the matter, with those unmounted disks busy writing?

Is there anything I have to do now to verify, to fix something, or to avoid a future issue?

 

Is there a process to have a -REAL- power off button, that really stop the machine? I hate to have to install a keyboard, a screen, just and everytime to correctly stop -asap- the system. If it's possible by a command line, it will be possible by the press of the button made for (and, of course, the only button that is on every machine, for sure).

Last, is there a process to have an idea of the current health of the disks, a script or something to launch smartctl on all the disks automatically, which write the results somewhere?

 

Thanks for all/everyone.

642

The drives were busy replaying transactions on the filesystem. This was caused by your power failure. The drives use ReiserFS which is a journalled filesystem. In the event of power failures then certain transactions need to be replayed so the filesystem consistency is guaranteed. Everything was going as expected and by design until your interrupted the process.

 

As for real power control, I highly suggest you install the community addon "powerdown".

The drive would have mounted once the transactions had been replayed.

 

I've seen that take as long as 15 minutes if there were a lot of transactions in the journal when the disk was spun down in a power failure.

 

You should not have interrupted it.  Just be patient.

BRiT is right.  After a power fault, unRAID has to write journaled transactions.  I think this should happen very fast, but unRAID does a jack rabbit start of the parity check, which slows down the writes tremendously.  I don't know what the world's record for journal playback is, but think I've seen close to 30 minutes.  I've requested that Tom delay the automatic parity check start until after the journaled writes complete, but never pushed it and its not on the Roadmap.  If you feel strongly about it, might want to request that.  

 

It is not a good idea to interrupt this process, although I expect RFS will still do okay once you reboot.  Just don't stop it again.  Also Let the parity check run to completion.  It is possible you'll need to run reiserfsck - in fact it might be a good idea to run a check (not repair) with it just to make sure all is well after the disks finally mount and your parity check finishes.

Thanks everybody.

 

Finally, those writing operation were correct, but it's something I don't know.

I've never made a forced power down, so I think hope there is nothing to be really worried about.

 

Of course I understand the system would perform a parity check after a power failure, even if it's questionnable if it should be by default or after a choice. And in this instance, parity check more cache_dirs process will slow down another process like the filesystem consistency.

 

 It is possible you'll need to run reiserfsck - in fact it might be a good idea to run a check (not repair) with it just to make sure all is well after the disks finally mount and your parity check finishes.

 

A "check"? A reiserfsck?  Is it the "File System Check" I can found in the Disk management of the unmenu?

 

 

OK, parity check without problem.

Will try a "file system check" now.

 

I hope it's not a long process.

 

 

Help

I've tried the "file system check" on the first drive, and now it appears as unformatted!

WTF?

 

No access to unmenu!

Have I to power down, and restart a parity checking again (just a 26hours job...)?

 

No more access to tower now! 

 

Help

I've tried the "file system check" on the first drive, and now it appears as unformatted!

WTF?

 

No access to unmenu!

Have I to power down, and restart a parity checking again (just a 26hours job...)?

 

No more access to tower now!   

 

To do any file system check it must be un-mounted.  An un-mounted drive will show as unformatted to unRAID, especially on the older versions of unRAID.  Just do not press the format button.

 

Joe L.

 

To do any file system check it must be un-mounted.  An un-mounted drive will show as unformatted to unRAID, especially on the older versions of unRAID.  Just do not press the format button.

Joe L.

 

Thanks for your answer.

 

But how do I know the job is done (no more acces to tower by http or nfs, to unmenu, even by telnet), and where do I find the result of the file check if I have to reboot at the end (when) ?

 

"older versions of unraid" : I currently have the 4.5.6, and the last stable 4.6 is not available anymore! What should I do?