Parity check makes server slow or unresponsive?

[CaptainSpalding]

Hi,

 

I just upgrated to 5.0 final the first boot was fine. Then I powered it down from the webgui and at the next start-up it started parity check that did not allow me to use webgui and the telnet was REALLY slow or did not respond at all.

 

I powered it down again and rebooted and now was fine, but the time of the last parity check referred to the time of the earlier boot.

 

I have experienced this a few times with the earlier versions too. What causes this? Usually during parity check I can refresh the webgui and there seems not to be any problems.

 

This is very annoying as I cannot connect my graphics card to monitor after it has booted.

 

EDIT: Hmmm... could be the same as http://lime-technology.com/forum/index.php?topic=29408.0

 

I have not had time to run parity check with 5.0 final, but will do in a couple of days.

 

[dgaschk]

Attach a syslog that includes the problem event.

[BobPhoenix]

I just upgrated to 5.0 final the first boot was fine. Then I powered it down from the webgui and at the next start-up it started parity check that did not allow me to use webgui and the telnet was REALLY slow or did not respond at all.

This would indicate that you had an unclean shutdown.  You may have had a plugin that was accessing a drive so unRAID wasn't able to properly stop.  Also likely is that the drive that was in use when you shut down had to replay journal transactions while doing the parity sync when it booted and that is why you noticed a slow down.  As dgaschk posted a system log would confirm or deny this speculation on my part but dgaschk would have to interpret the log as I wouldn't know what to look for.

[CaptainSpalding]

Thanks for your input!

 

I'm going home tonight to run parity check, but I think with the server powered down there's no useful syslog to post?

 

Is there a script that would take syslog automatically on power-up and save it to flash?

 

And another question: If the flash drive fails how can it be replaced with the same data? I know some use a usb card readers GUID, but how about the data, does the data change a lot on the flash on use?

[CaptainSpalding]

Thanks Patilan!

 

 

 

[BobPhoenix]

And another question: If the flash drive fails how can it be replaced with the same data? I know some use a usb card readers GUID, but how about the data, does the data change a lot on the flash on use?

I have some reader's on two of my unRAID boxes but flash drives on two others with a spare registered flash drive in reserve.  I also do a daily backup of the flash drive contents to catch any changes.  But that is definately overkill as nothing really changes on my flash unless I make configuration changes.  I don't use any plugins that write to the flash drive so mine never changes except when I add/remove/replace drives or change a configuration setting.  I just do the daily backups so that I don't have to think about taking a backup of the flash drive before I make the change.  If I make multiple changes on the same day I won't have anything backed up between changes but I don't usually make many changes anyway so it is more than enough.

 

I do this backup from a Windows PC with a scheduled task executing a batch file that calls WinRAR to archive and compress the entire USB drive (\\"unraid servername"\flash) on each unRAID server.

[CaptainSpalding]

Should there had been journal transactions as I did not do anything else than just boot the server and shut down after?

[BobPhoenix]

Should there had been journal transactions as I did not do anything else than just boot the server and shut down after?

This would probably be best if answered by someone else but here is my take - but if I'm wrong and it is pointed out then ignore the following:

 

ReiserFS is a Jounaling file system.  Any time you write to the array (this would include any writes that unRAID does when it is unmounting the drives) it will have some journal transactions.  They would then be written when you start the system back up again.  If you just start up the system and then shut it down there should not be very many.  The only way you might have allot is if the last boot did not get finished processing them before you shut down again.

[dgaschk]

Should there had been journal transactions as I did not do anything else than just boot the server and shut down after?

This would probably be best if answered by someone else but here is my take - but if I'm wrong and it is pointed out then ignore the following:

 

ReiserFS is a Jounaling file system.  Any time you write to the array (this would include any writes that unRAID does when it is unmounting the drives) it will have some journal transactions.  They would then be written when you start the system back up again.  If you just start up the system and then shut it down there should not be very many.  The only way you might have allot is if the last boot did not get finished processing them before you shut down again.

 

This is correct. Mounting and un-mounting the drive causes writes to the drive. But there should be no journal transactions to replay if the disk has been unmounted cleanly.

[twg]

do you have a swap file ? try disabling the swap file and see if that helps ?