Disk 6 Becomes Unwritable


4 posts in this topic Last Reply

Recommended Posts

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

Link to post
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.

Link to post

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.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.