XFS mount problem

XFS mount problem

[Dave Howorth]

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.

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.
        - 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 :)

Re: XFS mount problem

[Eric Sandeen]

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

Re: XFS mount problem

[Dave Howorth]

On Sat, 6 Oct 2018 09:22:37 -0500
Eric Sandeen <sandeen@sandeen.net> wrote:

Thanks for your reply, Eric.

> 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 

Hmm, that worked. Thanks. I'm not sure why that worked when my attempt
failed, although I do see in dmesg:

 [  467.743699] SGI XFS with ACLs, security attributes, no debug enabled
 [  467.744733] XFS (dm-3): unknown mount option [noacl].

So is that also the reason it failed at boot? I'm surprised because
that would seem to imply it's never been mounted using the information
in /etc/fstab before. I suppose it is possible because I only created
the filesystem a little while ago. Good news if so, since I can resume
mounting by label.

> and if that fails, type "dmesg" to show the kernel message, look
> towards the end to see what it thinks went wrong.

> Look at the end of "dmesg" output when mount fails.
> 
> -Eric

Thanks again, Dave

PS What's the list etiquette here about replies? I use claws and both
Reply and Reply-List would send my reply just to Eric, so I did
Reply-All. I just did a quick search for list etiquette for the list
but didn't see anything obvious.

Re: XFS mount problem

[Eric Sandeen]

On 10/6/18 10:28 AM, Dave Howorth wrote:
> On Sat, 6 Oct 2018 09:22:37 -0500
> Eric Sandeen <sandeen@sandeen.net> wrote:
> 
> Thanks for your reply, Eric.
> 
>> 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 
> 
> Hmm, that worked. Thanks. I'm not sure why that worked when my attempt
> failed, although I do see in dmesg:
> 
>  [  467.743699] SGI XFS with ACLs, security attributes, no debug enabled
>  [  467.744733] XFS (dm-3): unknown mount option [noacl].
> 
> So is that also the reason it failed at boot? I'm surprised because
> that would seem to imply it's never been mounted using the information
> in /etc/fstab before. I suppose it is possible because I only created
> the filesystem a little while ago. Good news if so, since I can resume
> mounting by label.

Oh, yep, I didn't see the "noacl" in fstab.  That's not a valid xfs 
mount option.  Don't know why its' in fstab or how things were working
before.

>> and if that fails, type "dmesg" to show the kernel message, look
>> towards the end to see what it thinks went wrong.
> 
>> Look at the end of "dmesg" output when mount fails.
>>
>> -Eric
> 
> Thanks again, Dave
> 
> PS What's the list etiquette here about replies? I use claws and both
> Reply and Reply-List would send my reply just to Eric, so I did
> Reply-All. I just did a quick search for list etiquette for the list
> but didn't see anything obvious.


Reply all is fine as far as I'm concerned.

-Eric