October 1, 20169 yr Hi all, I am recently having file system issues that are preventing mnt/disk1 from mounting (and the array from starting). I attempted an xfs_repair, after diagnosing with -n, but I see the following message: xfs_repair -v /dev/md1 Phase 1 - find and verify superblock... - block cache size set to 343376 entries Phase 2 - using internal log - zero log... zero_log: head block 542166 tail block 541726 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 am unable to start the array outside of maintenance mode. My plan is to simply replace this (fairly old) drive to solve this issue (and expand the size a bit). I understand that an xfs_repair -L could result in data loss, so this seems like the approach if I dont want to risk data loss on /mnt/disk1. 2 questions: [*]Am I correct that simply swapping out the drive, formatting and restoring with a new drive should solve this issue? [*]Am I correct that filesystem errors aren't written to parity (meaning, by restoring, I'm not restoring the errors too)? Anything else I should know? Thanks in advance! M
October 1, 20169 yr Author Ahh, glad I asked then... Thank you Johnnie Is my only option to xfs_repair -nvL and hope for no data loss? Any other suggestions are very much welcome. M
October 1, 20169 yr Community Expert It's you best option, remove the n or it won't attempt a repair.
October 1, 20169 yr Author The repair appears to have worked, and the array is now able to start. I don't see any data loss and only 2 files in the lost+found folder. Many thanks!
Archived
This topic is now archived and is closed to further replies.