Jorgo Posted September 9 Posted September 9 Sorry to bother you again, the troubles with my system won't end.... Now one of my drives in the array shows as unmountable. The file check shows some errors but overall doesn't look that bad... but xfs_repair doesn't offer to fix the file system. How do I go about this now (manually?)? Repair log follows: Quote 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... agf_freeblks 32896671, counted 33731680 in ag 2 agi unlinked bucket 41 is 569399081 in ag 3 (inode=7011850025) agi_freecount 37, counted 61 in ag 2 agi_freecount 37, counted 61 in ag 2 finobt sb_ifree 399, counted 386 sb_fdblocks 290730776, counted 310931492 - 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 Metadata CRC error detected at 0x4627c8, xfs_dir3_block block 0x12586c220/0x1000 bad directory block magic # 0x3c657069 in block 0 for directory inode 4924555877 corrupt block 0 in directory inode 4924555877 would junk block no . entry for directory 4924555877 no .. entry for directory 4924555877 problem with directory contents in inode 4924555877 would have cleared inode 4924555877 - agno = 3 data fork in ino 7011850006 claims free block 876481246 imap claims a free inode 7011850017 is in use, would correct imap and clear inode imap claims a free inode 7011850018 is in use, would correct imap and clear inode imap claims a free inode 7011850019 is in use, would correct imap and clear inode imap claims a free inode 7011850020 is in use, would correct imap and clear inode imap claims a free inode 7011850021 is in use, would correct imap and clear inode imap claims a free inode 7011850022 is in use, would correct imap and clear inode imap claims a free inode 7011850023 is in use, would correct imap and clear inode data fork in ino 7011850024 claims free block 1063027389 data fork in ino 7011850026 claims free block 876483605 data fork in ino 7011850027 claims free block 876483707 data fork in ino 7011850028 claims free block 876483772 data fork in ino 7011850029 claims free block 876483822 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... free space (2,229440923-230273633) only seen by one free space btree free space (3,71176818-71177236) only seen by one free space btree - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 3 - agno = 5 - agno = 8 - agno = 10 - agno = 1 - agno = 7 - agno = 9 - agno = 4 - agno = 6 entry "Akira (1988a)" at block 0 offset 96 in directory inode 17252377121 references free inode 4924555877 would clear inode number in entry at offset 96... entry "Ancien and the Magic Tablet (2017) 720p.BRRip-banner.jpg" at block 0 offset 176 in directory inode 7011850006 references free inode 7011850017 would clear inode number in entry at offset 176... entry "Ancien and the Magic Tablet (2017) 720p.BRRip-clearlogo.png" at block 0 offset 328 in directory inode 7011850006 references free inode 7011850018 would clear inode number in entry at offset 328... entry "Ancien and the Magic Tablet (2017) 720p.BRRip-fanart.jpg" at block 0 offset 480 in directory inode 7011850006 references free inode 7011850019 would clear inode number in entry at offset 480... entry "Ancien and the Magic Tablet (2017) 720p.BRRip-keyart.jpg" at block 0 offset 632 in directory inode 7011850006 references free inode 7011850020 would clear inode number in entry at offset 632... entry "Ancien and the Magic Tablet (2017) 720p.BRRip-landscape.jpg" at block 0 offset 784 in directory inode 7011850006 references free inode 7011850021 would clear inode number in entry at offset 784... entry "Ancien and the Magic Tablet (2017) 720p.BRRip-poster.jpg" at block 0 offset 936 in directory inode 7011850006 references free inode 7011850022 would clear inode number in entry at offset 936... entry "Ancien and the Magic Tablet (2017) 720p.BRRip.ass" at block 0 offset 1080 in directory inode 7011850006 references free inode 7011850023 would clear inode number in entry at offset 1080... bad directory block magic # 0x3c657069 in block 0 for directory inode 4924555877 corrupt block 0 in directory inode 4924555877 would junk block no . entry for directory 4924555877 no .. entry for directory 4924555877 problem with directory contents in inode 4924555877 would have cleared inode 4924555877 Missing reference count record for (2/78698566) len 1 count 2 xfs_repair: rmap.c:1278: fix_inode_reflink_flags: Assertion `(irec->ino_is_rl & irec->ir_free) == 0' failed tower-diagnostics-20240909-1245.zip Quote
Jorgo Posted September 9 Author Posted September 9 OK, while still in maintenance mode I ran xfs_repair from command prompt on the drive without any arguments but in verbose mode. Here the output is Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... .found candidate secondary superblock... unable to verify superblock, continuing... and now it just prints dots, presumably searching the whole drive.... argh. Quote
JorgeB Posted September 9 Posted September 9 44 minutes ago, Jorgo said: xfs_repair from command prompt You are likely using the incorrect device here, but if xfs_repair cannot fix it, options are contact the xfs mailing list to see if they can help or reformat and restore from a backup, if one is not available, try a file recovery app, like UFS explorer. Quote
Jorgo Posted September 9 Author Posted September 9 I can see from the read operations that it seems to be the correct drive. I am asking myself, though, why the disk checker returns different messages in GUI mode and command line mode? Also, in previous Unraid versions there existed the possibility to add/change flags in a text field after the button - how can I get that back in 7 beta 2? In case manual repair will fail because of superblock problems... would I be able to unassign that disk, assign a new one and get the contents back from parity? And/or should I rather run repair on the emulated drive after unassigning it? Quote
JorgeB Posted September 9 Posted September 9 1 hour ago, Jorgo said: I can see from the read operations that it seems to be the correct drive. What was the command used? Quote
JorgeB Posted September 9 Posted September 9 That won't work, you need to specify the parition /dev/sdb1, but the correct way is using the md device, or parity won't be updated, so disk1 foe example would be /dev/md1p1 Quote
Jorgo Posted September 9 Author Posted September 9 Thanks, that was a life-saver... repaired with minimal damage (lost+found 0 byte). Quote
Jorgo Posted September 9 Author Posted September 9 I took your advice and used md3p1 so parity would be updated. Quote
JorgeB Posted September 10 Posted September 10 That is the same as using the webGUI, so possibly it worked because it was a new try. Quote
Jorgo Posted September 10 Author Posted September 10 webGUI refused to work without -n and there was no text field to change that option. Quote
JorgeB Posted September 10 Posted September 10 OK, I see, with v7 xfs repair is supposed to detect the corruption and then offer the repair option automatically, not sure why it was aborting with -n, will keep an eye to see if it happens again to other users. Quote
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.