After a system failure (due to a faulty disk that failed to pre-clear) and reboot, I can no longer enable the cache disk for my single user share. I also am unable to re-configure the split level back to its previously-configured value. The Settings screen allows the changes to be entered, but then returns to the defaults (split level = blank, use cache disk = no) after clicking apply.

 

I have a couple of other disks still in the middle of a pre-clearing cycle, might this be the cause?

 

If the same issue persists after the pre-clear completes and the array is expanded, what then to do?

 

Thanks in advance for any pointers.

After a system failure (due to a faulty disk that failed to pre-clear) and reboot, I can no longer enable the cache disk for my single user share. I also am unable to re-configure the split level back to its previously-configured value. The Settings screen allows the changes to be entered, but then returns to the defaults (split level = blank, use cache disk = no) after clicking apply.

settings are saved to the flash drive.  Perhaps the system failure resulted in its file system being corrupted to where it is now mounted as read-only?

I have a couple of other disks still in the middle of a pre-clearing cycle, might this be the cause?

unlikely.  should have absolutely nothing to do with the disks in the assigned array.

If the same issue persists after the pre-clear completes and the array is expanded, what then to do?

Same as almost any issue you desire assistance in resolving.  Attach a copy of your syslog to your next post.  It might have the clues needed to identify what is happening.  (You can do that now, before you reboot, before the pre-clear of the other disks is complete) Instructions for how to get a copy of the syslog for attachment are in the wiki under troubleshooting.

 

If the flash drive is not writable I'd not attempt to expand the array just yet, as the change in configuration would not be writable to the flash drive.

Get this issue resolved first.

 

Once the pre-clears are complete you can stop the array, power down, and move the flash drive to a PC where you can run scandisk/checkdisk on it and repair any file system corruption.

Thanks in advance for any pointers.

You are welcome.

 

Joe L.

Thanks for the response Joe. Unfortunately events have proceeded somewhat since last night’s original posted query so I'm not able to follow your recommended process completely. The system is now to all appearances back to nomal with one still puzzling anomaly, relating to the pre-clear process on which more in a moment.

 

First though to expand on the remarks in the original post, the original system failure did appear to be related to the inability of a disk to complete the pre-clear process properly. Briefly, a pre-clear was initiated on two disks – both brand-new 2TB Seagate Barracuda LP – one disk completed successfully in a typical time of 33 hours, the second was exhibiting much slower read rates (35 vs 80 MB) and took 57 hours to start the post-read phase.

 

I left it for the night but on checking next day around 9 am found the system had crashed, without http, console or telnet access (although it would respond to a ping). There seemed no alternative but to cold start which brought the system up in its ‘normal’ state, with the array started and all 15 disks (incl parity and cache) present and correct. At that point I did capture the syslog, which is included here as syslog-1. I wonder if Joe or another expert could have a look at this and point out what if anything might indicate the cause of the crash

 

 

To be on the safe side I removed the ‘bad’ disk from the rack before adding the one new pre-cleared disk to the array, which occurred without drama. After several hours, I started a second pre-clear operation, this time involving two 2TB WD-EADS disks that had several hundred hours earlier use in another NAS. Everything seemed to progressing OK, with good read rates (over 80 MB) and after several more hours I transferred some DVD files to the cache for moving to the array in the early hours. The transfer rate was somewhat slow (15 MB vs the usual 40 plus) but I put this down to the pre-clear process still underway. It wasn’t until several hours later that I took a look at the cache and found it empty, the transferred files being in the share, but the Settings fields locked as detailed above. In addition around half of the movie folders in the user share were m.i.a. and NFS had been turned off.

 

At this stage the two pre-clears were at around 90% through the post-read so I left them for the night. In the morning, emails confirming completion of the post-read arrived around 2 am, but even 8 hours later no emails confirming final status had been received. I should have captured a syslog at this point but it slipped my mind.

 

I got a bit flustered at this point and decided to try and add one of ‘pre-cleared’ disks thinking that if they were not really pre-cleared the system would recognize this and either flag the issue or start off on the standard zeroing process for non-cleared disks. But instead the system reacted by de-assigning all but two of the disks in the array. I quickly unassigned the new disk and rebooted (Again a syslog would have been useful here).

 

After the reboot the system returned as normal with all disks present, the user share had recovered its proper settings. The system initiated a parity check which is still in progress, with around 5 hours to go.

Here is another syslog-2 captured after the restart.

 

 

At this stage I don’t intend to touch anything until the parity check is completed, but I would be grateful for expert comments on the state of play. In particular, the circumstances under which a ‘dead disk’ could cause the system to fail so drastically, and what could have prevented the second pair of disks from finishing their pre-clear particularly when both were so far through the process and apparently doing well. Is there any way to examine the progress of the pre-clear process after the fact?

 

Thanks in advance.

syslog-1.zip

syslog-2.zip