Why does fsck.xfs not do what xfs_repair -n does?

Why does fsck.xfs not do what xfs_repair -n does?

[Marcel Partap]

Dear XFS dev crew,
> fsck.xfs(8)
>         fsck.xfs - do nothing, successfully
>         If you wish to check the consistency of an XFS filesystem, or repair a damaged or corrupt XFS filesystem, see xfs_repair(8).

So there's a FS check command that does not work as with all the other filesystems. Instead of checking the FS, it tells you to use xfs_repair both for - XFS repair.. and XFS check. Whereas in the man page of
> xfs_repair - repair an XFS filesystem
it doesn't tell you right at the top that xfs_repair can check XFS. Instead
> *       -n     No modify mode. Specifies that xfs_repair should […]  *scan  the  filesystem*

Is this imperative? It does not make any sense to me apart from the quirk.

#Best Regards!MPartap

Re: Why does fsck.xfs not do what xfs_repair -n does?

[Carlos Maiolino]

On Fri, Feb 24, 2017 at 09:49:17PM +0100, Marcel Partap wrote:
> Dear XFS dev crew,
> > fsck.xfs(8)
> >         fsck.xfs - do nothing, successfully
> >         If you wish to check the consistency of an XFS filesystem, or repair a damaged or corrupt XFS filesystem, see xfs_repair(8).
> 
> So there's a FS check command that does not work as with all the other filesystems. Instead of checking the FS, it tells you to use xfs_repair both for - XFS repair.. and XFS check. Whereas in the man page of
> > xfs_repair - repair an XFS filesystem
> it doesn't tell you right at the top that xfs_repair can check XFS. Instead
> > *       -n     No modify mode. Specifies that xfs_repair should […]  *scan  the  filesystem*

Xfs used to have two different tools for that. xfs_check and xfs_repair. This
required one more tool, several more lines of code to be maintained, while
xfs_repair does the check job with '-n' option, so, it was decided to deprecate
xfs_check and keep efforts only in xfs_repair.

> 
> Is this imperative? It does not make any sense to me apart from the quirk.
> 
I am not quite sure what you mean by "imperative" here, but most (if not all)
repair tools, have a dry-run mode with -n, as so, xfs_repair also does. The name
of xfs tool is also kept due historical reasons, once, AFAIK, xfs_repair is the
name for the tool since its beginning.

If you believe that the first description of xfs_repair's man page, should say
something like "check and repair an XFS filesystem", feel free to send a patch
for that, IMHO I really don't see any reason for that, giving that the main goal
of such tools are to fix filesystem inconsistencies.

Cheers

-- 
Carlos

Re: Why does fsck.xfs not do what xfs_repair -n does?

[Eric Sandeen]

On 2/27/17 2:16 AM, Carlos Maiolino wrote:
> On Fri, Feb 24, 2017 at 09:49:17PM +0100, Marcel Partap wrote:
>> Dear XFS dev crew,
>>> fsck.xfs(8)
>>>         fsck.xfs - do nothing, successfully
>>>         If you wish to check the consistency of an XFS filesystem, or repair a damaged or corrupt XFS filesystem, see xfs_repair(8).
>>
>> So there's a FS check command that does not work as with all the other filesystems. Instead of checking the FS, it tells you to use xfs_repair both for - XFS repair.. and XFS check. Whereas in the man page of
>>> xfs_repair - repair an XFS filesystem
>> it doesn't tell you right at the top that xfs_repair can check XFS. Instead
>>> *       -n     No modify mode. Specifies that xfs_repair should […]  *scan  the  filesystem*
> 
> Xfs used to have two different tools for that. xfs_check and xfs_repair. This
> required one more tool, several more lines of code to be maintained, while
> xfs_repair does the check job with '-n' option, so, it was decided to deprecate
> xfs_check and keep efforts only in xfs_repair.
> 
>>
>> Is this imperative? It does not make any sense to me apart from the quirk.
>>
> I am not quite sure what you mean by "imperative" here, but most (if not all)
> repair tools, have a dry-run mode with -n, as so, xfs_repair also does. The name
> of xfs tool is also kept due historical reasons, once, AFAIK, xfs_repair is the
> name for the tool since its beginning.

Yep. TBH, fsck.xfs was added only to satisfy initscripts which expect a fsck.$FS
for every filesystem at boot time.

But as a journaling filesystem, xfs has no need for a boot-time fsck.  xfs_repair
is for exceptional circumstances, not for a normal reboot with a log replay.

So there is no reason to execute a potentially long xfs_repair -n via fsck.xfs
on every boot; that would completely defeat the purpose of the metadata
journaling.

Like Carlos, I am also confused about what change you'd actually like to see
here.

Thanks,
-Eric

> If you believe that the first description of xfs_repair's man page, should say
> something like "check and repair an XFS filesystem", feel free to send a patch
> for that, IMHO I really don't see any reason for that, giving that the main goal
> of such tools are to fix filesystem inconsistencies.
> 
> Cheers
> 

Re: Why does fsck.xfs not do what xfs_repair -n does?

[Luis R. Rodriguez]

On Mon, Feb 27, 2017 at 09:16:36AM +0100, Carlos Maiolino wrote:
> On Fri, Feb 24, 2017 at 09:49:17PM +0100, Marcel Partap wrote:
> > Dear XFS dev crew,
> > > fsck.xfs(8)
> > >         fsck.xfs - do nothing, successfully
> > >         If you wish to check the consistency of an XFS filesystem, or repair a damaged or corrupt XFS filesystem, see xfs_repair(8).
> > 
> > So there's a FS check command that does not work as with all the other
> > filesystems. Instead of checking the FS, it tells you to use xfs_repair
> > both for - XFS repair.. and XFS check. Whereas in the man page of
> > > xfs_repair - repair an XFS filesystem
> > it doesn't tell you right at the top that xfs_repair can check XFS. Instead
> > > *       -n     No modify mode. Specifies that xfs_repair should […]  *scan  the  filesystem*
> 
> Xfs used to have two different tools for that. xfs_check and xfs_repair. This
> required one more tool, several more lines of code to be maintained, while
> xfs_repair does the check job with '-n' option, so, it was decided to deprecate
> xfs_check and keep efforts only in xfs_repair.

A symlink to xfs_check and a check for the alias would have sufficed to keep the
old interface while sharing code. That can be considered should folks agree this
desirable and should be a few lines of code.

  Luis

Re: Why does fsck.xfs not do what xfs_repair -n does?

[Eric Sandeen]

On 2/27/17 12:26 PM, Luis R. Rodriguez wrote:
> On Mon, Feb 27, 2017 at 09:16:36AM +0100, Carlos Maiolino wrote:
>> On Fri, Feb 24, 2017 at 09:49:17PM +0100, Marcel Partap wrote:
>>> Dear XFS dev crew,
>>>> fsck.xfs(8)
>>>>         fsck.xfs - do nothing, successfully
>>>>         If you wish to check the consistency of an XFS filesystem, or repair a damaged or corrupt XFS filesystem, see xfs_repair(8).
>>>
>>> So there's a FS check command that does not work as with all the other
>>> filesystems. Instead of checking the FS, it tells you to use xfs_repair
>>> both for - XFS repair.. and XFS check. Whereas in the man page of
>>>> xfs_repair - repair an XFS filesystem
>>> it doesn't tell you right at the top that xfs_repair can check XFS. Instead
>>>> *       -n     No modify mode. Specifies that xfs_repair should […]  *scan  the  filesystem*
>>
>> Xfs used to have two different tools for that. xfs_check and xfs_repair. This
>> required one more tool, several more lines of code to be maintained, while
>> xfs_repair does the check job with '-n' option, so, it was decided to deprecate
>> xfs_check and keep efforts only in xfs_repair.
> 
> A symlink to xfs_check and a check for the alias would have sufficed to keep the
> old interface while sharing code. That can be considered should folks agree this
> desirable and should be a few lines of code.

Actually, it was deprecated because it doesn't scale on large filesystems.

I think I'm losing the thread here.  What's the problem with how things are
today? :)

-Eric

>   Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Why does fsck.xfs not do what xfs_repair -n does?

[Darrick J. Wong]

On Mon, Feb 27, 2017 at 07:26:46PM +0100, Luis R. Rodriguez wrote:
> On Mon, Feb 27, 2017 at 09:16:36AM +0100, Carlos Maiolino wrote:
> > On Fri, Feb 24, 2017 at 09:49:17PM +0100, Marcel Partap wrote:
> > > Dear XFS dev crew,
> > > > fsck.xfs(8)
> > > >         fsck.xfs - do nothing, successfully
> > > >         If you wish to check the consistency of an XFS filesystem, or repair a damaged or corrupt XFS filesystem, see xfs_repair(8).
> > > 
> > > So there's a FS check command that does not work as with all the other
> > > filesystems. Instead of checking the FS, it tells you to use xfs_repair
> > > both for - XFS repair.. and XFS check. Whereas in the man page of
> > > > xfs_repair - repair an XFS filesystem
> > > it doesn't tell you right at the top that xfs_repair can check XFS. Instead
> > > > *       -n     No modify mode. Specifies that xfs_repair should […]  *scan  the  filesystem*
> > 
> > Xfs used to have two different tools for that. xfs_check and xfs_repair. This
> > required one more tool, several more lines of code to be maintained, while
> > xfs_repair does the check job with '-n' option, so, it was decided to deprecate
> > xfs_check and keep efforts only in xfs_repair.
> 
> A symlink to xfs_check and a check for the alias would have sufficed to keep the
> old interface while sharing code. That can be considered should folks agree this
> desirable and should be a few lines of code.

Yuck.

xfs_check does not (and has never had) the ability to repair anything.
so fsck.xfs should /never/ point to it.

Furthermore, xfs_repair was designed to work around the scalability
problems that exist in the bitrotting xfs_check codebase.  In other
words, _repair superseded _check long ago.  These days _check implements
the bare minimum it needs to get by on a v5 filesystem without blowing
up xfstests, which is afaict the sole remaining _check user.

As for boot time checking, XFS stores logical in-core updates in its
journal (unlike ext[34]|ocfs2 which store physical blocks in their
journal), which means that the log replay only works in-kernel on the
same type of machine that wrote the journal.  Therefore, running fsck at
boot time because we crashed is pointless because xfs_repair cannot
replay the journal.  Nor can xfs_check.

I admit that fsck.xfs doing essentially nothing is weird, but it /does/
tell you to go run xfs_repair if you really mean it.  It's unfortunate
that there really are two use-cases here -- boot scripts running
fsck.xfs (in which case we really do want to do nothing) and the admin
running fsck.xfs (in which case the current behavior is clunky).

This may become even less important once online fsck stabilizes,
though I'm putting the cart way ahead of the horse on that one. :)

--D

> 
>   Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html