Hello,

 

i am using the 6.1 server but i hope any of you can help me. as a -nix noob i can tell you that i only know how to use putty and know some very basic linux/unix commands but that's it.

 

my config - 9 x 3 GB wd red 8x data, 1x parity , 3 smaller ssds as cache devicees - asus Z97-C i5 Intel (quad) 32 gigs of ram, a 16port sas/sata3 controller a.s.o.

 

i configured the cache by adding the 3 ssds (256, 128 and 64 GB) and it choose the biggest one to be the master - the other ones don't show up as mounted.

than i added cache support for all user shares - that's where the trouble started - i thought the cache would be something like a fifo buffer rather than a thing one has to flush from time to time aka invoking the mover ... so when i tried to fill my raid smb shares with data strange things started to happen - most of the time i got no more space available errors - in the worst case my network connection crashed and i had to restart my Win10 PC sometimes hard reset the server itself ...

 

then i found out about btrfs scrub - and it found 24 non recoverable errors on my biggest sshd - is there any chance that i can wipe that sshd with dban or something similar without screwing up the system entirely ?

 

for the time being i switched off the cache support completely - at least the file transfers don't crash as often as they did ...

 

any ideas on how to check and wipe the "defective" ssd clean ?

 

now parity - if the parity check finds read/write errors on an HDD - does that mean that this errors will be mapped out ? or do i have to replace the complete hdd ?

any way to speed up the parity check - takes like 24++ hours for only 4 of the 8 3 gig drives ...

 

 

cheers - ahab

now parity - if the parity check finds read/write errors on an HDD - does that mean that this errors will be mapped out ? or do i have to replace the complete hdd ?

Not really sure what you are asking here.    The drives themselves include logic that will attempt to reallocate sectors that appear to be failing regardless of what the host system does.  The SMART attributes for a drive will show whether this has happened or not.  unRAID does include some logic so that if a read fails then as long as all the other drives and parity can be read then unRAID can reconstruct what it should have read.

 

Parity is primarily intended to protect you against a drive really failing.  In such a case you scarp the old drive and parity will rebuild the replacement drive to match the old one.    You can also get scenarios where a drive does not really fail but a write to it fails for some external reason (e.g. loose cable, power fluctuation) but the drive is fine.  If a write fails then unRAID does not know why so in such a case unRAID stops writing to the drive and marks it with a red cross in the GUI.  If you later determine that the physical drive is fine, then unRAID can rebuild the contents of that drive to what it should have been if the write had not failed.

 

any way to speed up the parity check - takes like 24++ hours for only 4 of the 8 3 gig drives ...

The length of time for the parity check is determined by the size of the largest drive involved - not by the number of drives.    Having said that 24++ hours sound too long if the largest drive is 3TB.  It might be worth posting your diagnostics file (Tools->Diagnsotics) to see if anyone can spot anything that might be causing this.

i configured the cache by adding the 3 ssds (256, 128 and 64 GB) and it choose the biggest one to be the master - the other ones don't show up as mounted.

than i added cache support for all user shares - that's where the trouble started - i thought the cache would be something like a fifo buffer rather than a thing one has to flush from time to time aka invoking the mover ... so when i tried to fill my raid smb shares with data strange things started to happen - most of the time i got no more space available errors - in the worst case my network connection crashed and i had to restart my Win10 PC sometimes hard reset the server itself ...

 

then i found out about btrfs scrub - and it found 24 non recoverable errors on my biggest sshd - is there any chance that i can wipe that sshd with dban or something similar without screwing up the system entirely ?

 

for the time being i switched off the cache support completely - at least the file transfers don't crash as often as they did ...

 

any ideas on how to check and wipe the "defective" ssd clean ?

 

This is an interesting problem, one we don't yet have a good handle on.  I've added a procedure within the Check Disk File systems wiki page, Redoing a drive formatted with BTRFS, but it is only for single drives, not pools.  I believe it can be adapted, but how to reset a pool of drives is rather tricky.  I don't have any experience with BTRFS myself, so will have to rely on others.

 

A first attempt at a safe procedure -

- Stop array

- Unassign all but first drive (I think it's best done last to first, but I don't know if that's truly necessary)

- Change the slot count to 1

- Change file system format to ReiserFS (a temporary measure to reset the file system, ReiserFS is chosen because formatting with it is fairly quick)

- Start the array and format the drive

- Stop the array and change the format back to BTRFS

- Start the array and format the drive

- Stop the array

- Change the slot count to the previous count

- Assign the other drives to the pool

- Start the array and let it format and balance them (I'm unsure of the technical details)

 

The problem with the above is that I don't know for sure what it does when it adds the extra drives and sees a BTRFS file system already on them.  If it tries to use it, then it may be using a corrupted system, so we would need to take extra steps to reset the file system on ALL of the drives.

 

I'm hoping someone with a test system can work out all the details to make this a safe method, but it may be hard without a known corrupted pool.

 

Edit: Very likely, others have faced the same problem, and it would be good to hear from them, as to what worked.  Some I know gave up and moved to XFS, but hopefully some have successfully restored their Cache pool.