Did you try typing powerdown or reboot on the console?

Didn't work. 

 

I have had to do a hard reset now I have a quandary. If I start a parity check it is going to build parity using all the drives inc the "swap" drive I was using, isnt it? Should I take the Swap drive offline and then let it do the parity check?

Don't understand the question, if the "swap" drive is part of the array and parity was valid it won't change anything.

I am in the process of changing the file system on my drives from ReiserFS to XFS. To do this I have added a "swap" drive to transfer the data from a ReiserFS drive to the "Swap" drive as per the instructions here http://lime-technology.com/wiki/index.php/File_System_Conversion#Mirroring_procedure_to_convert_drives 

 

Unfortunately the server became unresponsive during the transfer of the data, which I believe completed successfully, but I could not powerdown the server at this point or access the GUI just user telnet or the console. So I have had to hard reboot the server which of course now wants to rebuild parity with all my data drives PLUS the swap drive. I had hoped to complete the file system changes without affecting parity.

 

I may be wrong here but when my system locks like this it seems to be an out of memory error associated with SMB, is there anything I can do to try and prevent this happening?

The swap drive is just an empty array drive, it's still part of the protected array.

I think we are talking at cross purposes.

 

I have 17 drives, 16 data plus parity. All but two are on reiserfs. So I add an 18th drive, names by UNRAID as drive 17, and this is formated as xfs. Drive 14 is reiserfs and similar size to XFS drive 17 I have just added. I now use rsync to clone the data on drive 14 to the the new xfs drive ie drive 17.

 

Whilst the cloning is taking place the GUI becomes unresponsive. The console shows process 1620 SMBD is out of memory and I cannot powerdown or reboot via telnet or the console. However it does appear that the cloning has finished successfully. 

 

Now I have to hard reboot but drive 17 the new drive is still there and so a parity rebuild would include a parity built from the 16 data drives PLUS the 17th "swap" drive I have added, this isnt ideal as I had wanted to preserve parity throughout changing the file system on the drives.

 

Is that any cleared or have I muddied the waters more?

Drive 17 is still part of the array, parity doesn't care about file system.

I had 16 data drives with parity checked, but the 17th was blank.

 

Now I have 17 data drives, but with drive 14 and 17 now having the same data. This must affect the parity. 

8 minutes ago, ridley said:

Now I have 17 data drives, but with drive 14 and 17 now having the same data. This must affect the parity. 

 

It doesn't.

 

https://lime-technology.com/wiki/index.php/Parity#How_parity_works

Parity was built with the 17th drive being empty. 

 

Now the 17th drive isn't empty, are you trying to say that adding data to the 17th drive will not affect the parity? I really cannot see how that works. (unless parity is preserved during the rsync)

Parity is real-time, any change on any disk automatically updates parity, including rsync naturally.