Greetings

 

My home server has been running flawlessly for some 2 years now. Over this time the data storage needs increased so I started adding some drives to it. Initially I got the server from Limetech with Seagate 4TB drives, but later on I opted for the 6TB Western Digital NAS ones.

 

The first one I swapped was the parity drive. Everything worked fine on that. Then I got another two drives which I attached to the server. Everything worked like a dream.

 

I ordered a new 6TB drive (which arrived 2 days ago) and lucky that I did since one of the 4TB drives started giving out warnings on SMART. I had a power failure the same day and the server did come back up but when I started the array Disk 5 (the 4TB one) came up as Unmountable. Panic ensued, I stopped the array and powered down the server through the UI.

 

When the drive (luckily) came the same day, I chose to replace the 4TB one and let the parity rebuild it. So I powered it up again, marked the slot (Disk E) and then powered it back down. I swapped the drives putting the 6TB one in and perhaps my mistake was not to preclear it.

 

When I booted the server up and assigned the new drive to the Drive E slot, the message came up that the drive was being rebuild.

 

A day later the rebuild was done but I am seeing the unmountable again on the screen. Parity is OK and nothing else seems to be wrong (the data is there).

 

I run some tests on the drives. I started the array on maintenance mode and all drives were ok except the one in question. That one brings out the following message:

 

root@TITANIUM:~# xfs_repair -v /dev/md5 
Phase 1 - find and verify superblock...
        - block cache size set to 3020680 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 2692754 tail block 2692375
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

 

At this point I stopped the array and started it again normally (not maintenance mode). I let it sit for 30 mins or so in case it flushes the metadata changes in the log as the message above reports.

 

Stopped the array again, started it in maintenance mode and run xfs_repair again. The same message appeared again.

 

Any pointers are more than welcome.

 

= Running the 6.2 unraid

Model: Custom
M/B: Supermicro - X9SCL/X9SCM
CPU: Intel® Xeon® CPU E3-1230 V2 @ 3.30GHz
HVM: Enabled
IOMMU: Disabled
Cache: 256 kB, 1024 kB, 8192 kB
Memory: 32.0078125 GB (max. installable capacity 64 GB)*
Network: eth0: 1000 Mb/s, full duplex, mtu 1500 
Kernel: Linux 4.4.19-unRAID x86_64

 

Screenshot here:

Since the disk is not mountable you will need to run xfs_repair with the -L option.  Normally this does not affect the data recovered, but in the worst case it can mean that the last update or two are lost.

 

Note that if a disk is uncountable due to file system corruption then a rebuild never clears this - the rebuilt disk has the same corruption.  Only running the repair tool can clear this.

Note that if a disk is uncountable due to file system corruption then a rebuild never clears this - the rebuilt disk has the same corruption.  Only running the repair tool can clear this.

 

Do you mean the raid being corrupted or the parity itself?

Note that if a disk is uncountable due to file system corruption then a rebuild never clears this - the rebuilt disk has the same corruption.  Only running the repair tool can clear this.

 

Do you mean the raid being corrupted or the parity itself?

Parity doesn't have a filesystem so it can't have filesystem corruption, but if parity is in sync then any filesystem corruption on a data disk will be reflected in parity. Don't think of filesystem corruption as a bad disk, it is just bad data (filesystem metadata).

Got it thanks for the explanation.

 

Well good news! the -L seems to have fixed this.

 

Just to be on the safe side, I will venture in moving all my data from the array and rebuilding it from scratch. It will be a long task but one can never be careful when memories are preserved in electronic formats (pictures/videos and such).

 

Thank you again!

Just to be on the safe side, I will venture in moving all my data from the array and rebuilding it from scratch. It will be a long task but one can never be careful when memories are preserved in electronic formats (pictures/videos and such).

And even if you do all this, you still need to have backups. unRAID or any RAID is not a backup. Anything you consider irreplaceable must have multiple copies, preferably on independent systems.