January 7, 20179 yr Author Got it, doing it now, looks grim already. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... Metadata corruption detected at xfs_agf block 0xaea86661/0x200 flfirst 118 in agf 3 too large (max = 118) agf 118 freelist blocks bad, skipping freelist scan agi unlinked bucket 59 is 45568827 in ag 3 (inode=3266794299) sb_ifree 127, counted 128 sb_fdblocks 295550266, counted 295568757 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0
January 7, 20179 yr Author So do I now run it without the -n to repair? Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... Metadata corruption detected at xfs_agf block 0xaea86661/0x200 flfirst 118 in agf 3 too large (max = 118) agf 118 freelist blocks bad, skipping freelist scan agi unlinked bucket 59 is 45568827 in ag 3 (inode=3266794299) sb_ifree 127, counted 128 sb_fdblocks 295550266, counted 295568757 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 3266794299, would move to lost+found Phase 7 - verify link counts... would have reset inode 3266794299 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting.
January 7, 20179 yr Author Ok, when I leave the option blank and run the check I get this 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. So, I guess I have to sue the -L option? As I cannot successfully mount disk2.
January 7, 20179 yr Yes, use the -L option. That output might look scary but the file system doesn't look very badly damaged, as far as I can see.
January 7, 20179 yr Author I have nerves of steel.... It's running, disk read counter is going up, so looking good.
January 7, 20179 yr It has found uncommitted journal entries. In order to commit them the file system needs to be mounted. But we already know that it can't be mounted. So you have to tell it to wipe the journal entries. So you'll lose whatever it was doing when the crash happened and hopefully not much else.
January 7, 20179 yr Author It's was nothing important. After the repair completes I'll do the same for disk1 as disk 1 and 2 are used for that mapped drive.
January 7, 20179 yr If I tell you that the XFS repair tools in unRAID 6.2 are generally thought to be better than in previous versions, does that help? Disk 1 was mountable in your last diagnostics but it does no harm to run with the -n option on any disk you have suspicions about.
January 7, 20179 yr Author I've read that the XFS toolset (repair) wasn't that mature, well when compared with EXT3/4 et-al, but from where I'm sitting now it seems pretty good!! Ok, the repair on disk2 didn't take long 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 destroyed because the -L option was used. - scan filesystem freespace and inode maps... Metadata corruption detected at xfs_agf block 0xaea86661/0x200 flfirst 118 in agf 3 too large (max = 118) agi unlinked bucket 59 is 45568827 in ag 3 (inode=3266794299) sb_ifree 127, counted 128 sb_fdblocks 295550266, counted 295568763 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 3266794299, moving to lost+found Phase 7 - verify and correct link counts... Maximum metadata LSN (1:984885) is ahead of log (1:2). Format log to cycle 4. done And you were quite right, it found no errors on disk1. So now bring the array online and commence the parity check? I'm hoping this fixed the original copy issue.
January 8, 20179 yr Author Ok, I think I'm good to go now. The parity check completed without error, I also copied 1GB, 2GB and 20GB files back and forth without issue, and several torrents as well, so it's looking good. John_M, I really appreciate your help with this, it's people like you and others in the community that makes unRAID really special. It's been a great learning experience as well, so a heart felt thank you.
January 8, 20179 yr My pleasure. It was unfortunate that what should have been a simple upgrade resulted you having three different issues to deal with. It's all good fun though
Archived
This topic is now archived and is closed to further replies.