New to unraid (still on trial and testing) and would like to get some advice/help. Disk 1, saying 'Unmountable: No file system' in Main.

 

Noticed Sabnzbd plus was spitting out errors and I couldn't view anything on Disk 1 through MC. UI stopped being responsive so restarted. Didn't know to run a diagnostics before restarting is considered best practice.

 

Started the Array in Maintenance Mode by clicking on Disk 1, and clicked on Check spits out a very detailed message along the lines of ...

Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... bad magic number bad on-disk superblock 5 - bad magic number primary/secondary superblock 5 conflict - AG superblock geometry info conflicts with filesystem geometry would zero unused portion of secondary superblock (AG #5) would reset bad sb for ag 5 bad uncorrected agheader 5, skipping ag... sb_icount 901024, counted 765440 sb_ifree 77, counted 189 sb_fdblocks 41542750, counted 29194066 - found root inode chunk Phase 3 - for each AG...

Seems like I either have a bad drive or I can easily have many docker containers somehow corrupting a drive's superblock (i'm not sure which). Seems like the other data on the 6 disk drives are easily mountable in say Ubuntu live drive via reading it through xfs

 

My questions:

I did have a parity drive so should it not keep a record of all the files on the drive?

What would be the best case to recover my data off of Disk 1? I belive its something along the lines of xfs_repair -v /dev/ or just take the drive out and recover from parity onto another drive (not sure how to proceed with this)

 

 

wil-server-diagnostics-20190103-0435.zip

49 minutes ago, wil said:

Didn't know to run a diagnostics before restarting is considered best practice.

Since you rebooted no clue from syslog.

 

49 minutes ago, wil said:

I did have a parity drive so should it not keep a record of all the files on the drive?

Parity doesn't have any of your files. Parity PLUS all other disks allow the data for a missing disk to be calculated.

 

49 minutes ago, wil said:

Seems like I either have a bad drive or I can easily have many docker containers somehow corrupting a drive's superblock (i'm not sure which)

SMART for disk1 looks OK so unlikely the drive is bad. The other possibility you mentioned there is extremely unlikely.

 

49 minutes ago, wil said:

Seems like the other data on the 6 disk drives are easily mountable in say Ubuntu live drive via reading it through xfs

Do you mean you let some other OS besides Unraid mount your data disks? If so you have probably invalidated parity.

 

In any case, rebuilding from parity is not the way to fix filesystem corruption:

 

https://wiki.unraid.net/index.php/Check_Disk_Filesystems

 

But I still question whether or not you have invalidated parity. If so, I'm not sure if you should fix that before or after fixing the filesystem. Might not matter but I can imagine some scenarios where valid parity could still be useful if you have problems during the filesystem fix.

 

So, if you did mount any of your disks in another OS, let's wait and see if anyone ( @johnnie.black ) has an opinion on the best way to proceed.

 

 

First thing is to run xfs_repair without -n, and likely -L will be needed

Do you mean you let some other OS besides Unraid mount your data disks? If so you have probably invalidated parity.

 

I haven't mounted it yet, just saying worst case I can recover my data from at least 6/7 drives. Besides I would mount it only to copy the data off.

 

SMART for disk1 looks OK so unlikely the drive is bad. The other possibility you mentioned there is extremely unlikely.

I tend to agree. However I came across the same earlier (I had 3 drives when I started and Disk 1 became unreadable). But basically when I did was set the appdata folder to 1 drive. Have a mariadb container and other containers such as (Nextcloud, tiny rss, atomix rss) to rely on the mariadb container. Along with maxed 1gbps file transfers and Plex downloading metadata. I ended up just reformatting Disk 1 and rebuilding.

 

You mean run take out the -n and click Check?

Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... 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.

And in doing so would that be safer (not invalidating parity) than just taking out Disk 1 and running the command and rebuilding Disk 1 onto another?

Edited January 3, 20197 yr by wil

As long as you are fixing the md device (which you are if you are doing it in the webUI) parity is maintained. As already mentioned, rebuilding will not fix an unmountable disk.

rebuilding directory inode 651360775 entry "f2620ed8b5b5176d5488ad4e532c559d09d58d6.bundle" in dir ino 651885066 doesn't have a .. entry, will set it in ino 8856337813. entry "c850201d1aac3a603ee33670ad3fb94a8825c25.bundle" in dir ino 651885066 doesn't have a .. entry, will set it in ino 8858439090. entry "5fbd7f14add64ee2b1bd7460abb77a43e72d123.bundle" in dir ino 651885066 doesn't have a .. entry, will set it in ino 8949178026. entry "e7e14d7036dfb83554b6406bfa28a333fba028e.bundle" in dir ino 651885066 doesn't have a .. entry, will set it in ino 9712852261. entry "4a7fffca4481c5b5b354ca186ee48a3ea106af9.bundle" in dir ino 651885066 doesn't have a .. entry, will set it in ino 9847091121. rebuilding directory inode 651885066 xfs_repair: phase6.c:1376: longform_dir2_rebuild: Assertion `done' failed.

"xfs_repair: phase6.c:1376: longform_dir2_rebuild: Assertion `done' failed."

 

I'm lost now. 

xfs_repair should never abort, it should always finish with more or less data loss, best bets are asking for help on the xfs_mailing list and/or waiting for new Unraid which should include a newer xfs_repair that might work with current corruption.

 

 

Do not despair! Seems we got hit by the same bug in xfs_repair, and I did something a bit nasty to get my data back:

Please follow at your own risk, but it looks like xfs_repair has a bug that affects us.

Edited January 3, 20197 yr by spamalam
typo