On 10/6/18 8:03 AM, Dave Howorth wrote: > We had a very brief power-glitch last night, but it was enough to cause > my PC to reboot. But the reboot didn't come up cleanly. > > It was complaining about not being able to mount an XFS filesystem > that I use for storing recorded TV programmes. In fact mount claims > 'wrong fs type': > > # mount -v /srv/live-tv/ > mount: /srv/live-tv: wrong fs type, bad option, bad superblock > on /dev/mapper/mint_vg-live--tv_lv, missing codepage or helper program, > or other error. You need to look to the kernel logs to know what actually went wrong with the mount. > The mount is being tried against fstab: > > # grep live-tv /etc/fstab > #LABEL=LiveTV /srv/live-tv xfs noatime,noacl 0 2 > /dev/mint_vg/live-tv_lv /srv/live-tv xfs noatime,noacl 0 2 > > I normally mount this filesystem by label but I commented that out to > get the system to boot and I added the /dev line as a more basic method > to see if it helped, but it gives the same error. > > # l /dev/mint_vg/live-tv_lv > lrwxrwxrwx 1 root root 7 Oct 6 09:45 /dev/mint_vg/live-tv_lv -> ../dm-3 > > The XFS filesystem is in an LV. lv/pv/vgscan all report everything > normal; I don't think there's a problem at the LVM level. > > I tried xfs_repair -n: > > # xfs_repair -n /dev/dm-3 > 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. The log is dirty as expected. But at least xfs_repair thinks it is an xfs filesystem, and it looks intact. Try # mount /dev/dm-3 /srv/live-tv and if that fails, type "dmesg" to show the kernel message, look towards the end to see what it thinks went wrong. > - scan filesystem freespace and inode maps... > sb_ifree 81, counted 80 > sb_fdblocks 12504226, counted 12276402 > - 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 > imap claims a free inode 135 is in use, would correct imap and clear > inode > - 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 > entry "Coronation Street Omnibus.ts" at block 0 offset 3848 in > directory inode 96 references free inode 135 would clear inode number > in entry at offset 3848... > - agno = 3 > - agno = 2 > No modify flag set, skipping phase 5 > Phase 6 - check inode connectivity... > - traversing filesystem ... > entry "Coronation Street Omnibus.ts" in directory inode 96 points to > free inode 135, would junk entry bad hash table for directory inode 96 > (no data entry): would rebuild > - traversal finished ... > - moving disconnected inodes to lost+found ... > Phase 7 - verify link counts... > No modify flag set, skipping filesystem flush and exiting. > > > This is openSUSE Leap 15.0 > > I'm a bit stuck now; my XFS foo is not strong today, it seems. Can > anybody suggest what my next steps should be? I'll keep googling but I > hope somebody may have more informed ideas :) Look at the end of "dmesg" output when mount fails. -Eric
