firrae Posted November 20, 2020 Share Posted November 20, 2020 Hi there, I'm in a weird issue. the UnRAID disk check says my drive has filesystem corruption, but I find it interesting that the system is fine until I've written 1 or 2 GBs of data to it. At that point it becomes I/O errors galore. So clearly it's messed up. When I went through the wiki article here on repairing drives with issues: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui. It returns the following through both the UI and through a SSH session: xfs_repair -v /dev/md6 Phase 1 - find and verify superblock... - block cache size set to 1507224 entries Phase 2 - using internal log - zero log... zero_log: head block 2248359 tail block 2247490 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. So now I'm not sure what that means for me. I don't think there's anything awfully important on the drive and am about to boot it up as normal to double check, but like I said I can read off it perfectly fine, even after writes start to fail, so if there is anything important on it I can presumably recover it. Now though is the crux of my question, what is the best method? I have a spare 4TB drive sitting here if replacing it 1:1 will work and letting the parity re-build (there's maybe 20GB on the drive so far as I can remember) so not much, otherwise do I drop that `-L` flag on it and hope it fixes things (from the wiki the tool seems unreliable for positive outcomes at best)? I'm going to check what's on the drive now aby spinning it back up and hopefully someone can help me go from there. If you need anything else to help out let me know. tower-smart-20201119-2112.zip tower-diagnostics-20201119-2112.zip Quote Link to comment
firrae Posted November 20, 2020 Author Share Posted November 20, 2020 OK, what I care about on it is being backed up again. So it's good to die if it needs to. Quote Link to comment
itimpi Posted November 20, 2020 Share Posted November 20, 2020 That message is quite normal and very rarely leads to data loss - and despite its ominous wording even when it does it only affects the last file written. You need to try again but add the -L option. Quote Link to comment
firrae Posted November 20, 2020 Author Share Posted November 20, 2020 13 minutes ago, itimpi said: That message is quite normal and very rarely leads to data loss - and despite its ominous wording even when it does it only affects the last file written. You need to try again but add the -L option. Cool, thanks. Will do tomorrow after work. With its ominous wording I figured I'd make sure before doing it ha. Sometimes it actually means something. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.