September 6, 20232 yr I accidentally hit the downgrade button from the Tools tab, restarted to allow the downgrade to happen, then upgraded to 6.12.4. Everything seemed fine, so this morning I updated my docker containers which resulted in major issues. One of them had an issue updating which then resulted in all of the containers showing as unavailable. I rebooted the machine and now the docker tab says 'Docker Service failed to start.'. The Fix Common Problems has many issues shown: ERROR: Unable to write to cache. Suggested fix: Drive mounted read-only or completely full. (it is not full) WARNING: Share Applications references non existed pool cache WARNING: Share data references non existing pool cache WARNING: Share Downloads references non existent pool cache WARNING: Share VirtualMachines references non existent pool cache There's no mention of appdata but it seems gone as well. Would welcome any suggestions.
September 6, 20232 yr Community Expert 1 minute ago, exceptional-ant1068 said: restarted to allow the downgrade to happen What version? Attach diagnostics to your NEXT post in this thread.
September 6, 20232 yr Author I was on 6.12.3 before the downgrade but I believe it downgraded to 6.12.1. Diagnostics attached gtower-diagnostics-20230906-1119.zip
September 6, 20232 yr Author I've run the filesystem check (without -n) and it immediately shows this status: 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.
September 6, 20232 yr Author OK - I ran with -L and here's what was displayed: 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 destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata badly aligned inobt rec (starting inode = 3900477132) bad starting inode # (3900477132 (0x2 0xe87c8ecc)) in inobt rec, skipping rec out-of-order ino btree record 167 (17104000) block 2/175330 (repeated about 50 times) inode chunk claims untracked block, finobt block - agno 2, bno 2137984, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 2137985, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 2137986, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 2137987, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 2137988, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 2137989, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 2137990, inopb 8 inode chunk claims untracked block, finobt block - agno 2, bno 2137991, inopb 8 undiscovered finobt record, ino 553974784 (2/17103872) undiscovered finobt record, ino 553974912 (2/17104000) undiscovered finobt record, ino 554076800 (2/17205888) undiscovered finobt record, ino 554079232 (2/17208320) undiscovered finobt record, ino 554401472 (2/17530560) undiscovered finobt record, ino 554429376 (2/17558464) undiscovered finobt record, ino 554438976 (2/17568064) agi_count 421056, counted 421247 in ag 2 agi_freecount 3719, counted 3973 in ag 2 sb_icount 1604928, counted 1605119 sb_ifree 24612, counted 23104 sb_fdblocks 91838485, counted 91510558 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... found inodes not in the inode allocation tree found inodes not in the inode allocation tree - process known inodes and perform inode discovery... - agno = 0 - agno = 1 14e7e46dc680: Badness in key lookup (length) bp=(bno 0x1e212820, len 4096 bytes) key=(bno 0x1e212820, len 16384 bytes) (repeated many times) - agno = 2 correcting imap correcting imap correcting imap correcting imap (repeated about 3200 times) - 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 clearing reflink flag on inodes when possible 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 (1367:20983) is ahead of log (1:2). Format log to cycle 1370. done
September 6, 20232 yr Author Oooh wow, Docker has started up again and I'm seeing the shares. The new diagnostics are attached. Should I be looking into swapping the SSD? gtower-diagnostics-20230906-1245.zip
September 6, 20232 yr Community Expert Filesystem issues don't mean a device problem, keep monitoring but should be resolved.
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.