Aviv Posted June 3, 2020 Posted June 3, 2020 (edited) Hi, My cache drive is suddenly saying: "Unmountable: No file system" Im using XFS (Encrypted). I run Extended offline smart test on the cache and it pass. I have data on the cache drive (vms, plex , and some data) so i cant just reformat it.  Any tips? 😞 Thank you 🙂  --- 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... sb_fdblocks 79152746, counted 80012186 - 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 = 1 - agno = 0 - 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 ... Phase 7 - verify link counts... Maximum metadata LSN (51:10362) is ahead of log (51:9849). Would format log to cycle 54. No modify flag set, skipping filesystem flush and exiting. fatty-diagnostics-20200603-1543.zip Edited June 3, 2020 by Aviv Quote
JorgeB Posted June 3, 2020 Posted June 3, 2020 Run xfs_repair without -n or nothing will be done. Quote
Aviv Posted June 3, 2020 Author Posted June 3, 2020 2 minutes ago, johnnie.black said: Run xfs_repair without -n or nothing will be done. Thank you, is it dangerous? Quote
JorgeB Posted June 3, 2020 Posted June 3, 2020 There's always same data loss risk when repairing a filesystem, but usually nothing major with XFS. Quote
Aviv Posted June 3, 2020 Author Posted June 3, 2020 (edited) 4 hours ago, johnnie.black said: There's always same data loss risk when repairing a filesystem, but usually nothing major with XFS. Thank you, I tried to run it with no 'n' param and receive this error: Â "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." Just to make sure, should I run it now with the -L option or there is a better option? Thank you again for your kind help. Â Edited June 3, 2020 by Aviv Quote
JorgeB Posted June 3, 2020 Posted June 3, 2020 4 minutes ago, Aviv said: should I run it now with the -L option Yes. Quote
Aviv Posted June 3, 2020 Author Posted June 3, 2020 (edited) 6 minutes ago, johnnie.black said: Yes. Tried. Â Now im receiving this error: "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. Invalid block length (0x0) for buffer Log inconsistent (didn't find previous header) empty log check failed fatal error -- failed to clear log" I did a second try and receive this: hase 1 - find and verify superblock... Phase 2 - using internal log - zero log... Invalid block length (0x0) for buffer Log inconsistent (didn't find previous header) empty log check failed zero_log: cannot find log head/tail (xlog_find_tail=5) - scan filesystem freespace and inode maps... sb_fdblocks 79152746, counted 80012186 - 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 = 1 - agno = 2 - agno = 0 - 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 ... Phase 7 - verify and correct link counts... Maximum metadata LSN (51:10387) is ahead of log (1:2). Format log to cycle 54. done. Now im able to mount. I dont see any folder called "Lost+found". what does that mean? Â Â Â Edited June 3, 2020 by Aviv Quote
JorgeB Posted June 3, 2020 Posted June 3, 2020 10 minutes ago, Aviv said: I dont see any folder called "Lost+found". what does that mean? That's good, usually means all data should be there, without lost/partial files. Quote
Aviv Posted June 3, 2020 Author Posted June 3, 2020 (edited) Ok, so it seems the cache drive is now undetectable 😞 Trying to replace cable. wish me luck. Edited June 3, 2020 by Aviv Quote
Aviv Posted June 3, 2020 Author Posted June 3, 2020 i unplug and re-plug the sata + power cable and it seems good now. will take a close look on this one for few days 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.