Deprecating xfs_check

[Chandra Seetharaman]

Hello All,

While trying to replace xfs_check with xfs_repair -n in xfstests, I
found that xfs_check is quiet if all is well, and prints information
only if something is wrong. But, xfs_repair -n always prints information
on different phases etc.,

What should be our approach ?
 1. add a -q option to xfs_repair, which prints no message at all
 2. add a -q option, and it will be quiet, but is valid only if -n 
    is specified.
 3. Leave it as is. Since users have to change their scripts anyways to 
    replace xfs_check, they can as well change the logic around the 
    output.

Please suggest.

Regards,

Chandra 


On Fri, 2013-04-12 at 11:04 +1000, Dave Chinner wrote:
> [compendium reply]
> 
> On Thu, Apr 11, 2013 at 06:01:12PM -0500, Troy McCorkell wrote:
> > On 04/11/2013 05:17 PM, Ben Myers wrote:
> > >Hey Chandra,
> > >
> > >On Thu, Apr 11, 2013 at 04:45:08PM -0500, Chandra Seetharaman wrote:
> > >>Hello All,
> > >>
> > >>Alex Elder mentioned about deprecating xfs_check, and he suggested is to
> > >>replace xfs_check command with a script, that says xfs_check is
> > >>deprecated, use "xfs_repair -n".
> > >>
> > >>Sounds ok ?
> 
> Yes. I'd suggest that you also put a removal date in the output,
> such as:
> 
> "xfs_check is deprecated and scheduled for removal in June 2014.
>  Please use xfs_repair -n <dev> instead."
> 
> The same information needs to go into the xfs_check man page.
> 
> xfstests also still needs to run xfs_check. That means we also need
> either an override flag an make $XFS_CHECK_PROG have it set
> appropriately or add an internal xfs_db wrapper that runs the
> xfs_check functionality appropriately. The second is probably the
> better option...
> 
> > >>Let me know if it is not the right approach.
> > >That sounds ok to me.  You might also consider making xfs_check a hardlink to
> > >xfs_repair and varying the behavior based on program name.  Then xfs_check ==
> > >xfs_repair -n.
> 
> xfs_check is a shell script wrapper around xfs_db, so modifying the
> shell script is the right thing to do at this point in time.
> 
> > Does "xfs_repair -n" need to provide all of the functionality that xfs_check
> > provides before it is replaced?
> 
> It already does.
> 
> > xfs_check can be run on a filesystem mounted read-only.  xfs_repair
> > -n can not.
> 
>        -d     Repair  dangerously.  Allow  xfs_repair  to  repair an XFS filesystem mounted read only. This is typically done on a root fileystem from single user
>               mode, immediately followed by a reboot.
> 
> 
> $ sudo mount -o remount,ro /mnt/scratch
> $ grep scratch /proc/mounts
> /dev/vdc /mnt/scratch xfs ro,relatime,attr2,nobarrier,inode64,logbsize=256k,noquota 0 0
> $ sudo xfs_repair -dn /dev/vdc
> Phase 1 - find and verify superblock...
> Version 5 superblock detected. xfsprogs has EXPERIMENTAL support enabled!
> Use of these features is at your own risk!
> Not enough RAM available for repair to enable prefetching.
> This will be _slow_.
> You need at least 16061MB RAM to run with prefetching enabled.
> Phase 2 - using internal log
>         - scan filesystem freespace and inode maps...
> ....
>         - agno = 98
>         - agno = 99
> 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...
> No modify flag set, skipping filesystem flush and exiting.
> $
> 
> So it works just fine on read-only filesystems...
> 
> (Oh, yeah, that's a 100TB metadata crc enabled filesystem with 50
> million inodes in it ;)
> 
> > xfs_check has two options:
> >     -i ino   Specifies  verbose  behavior  for  the specified inode ino.
> >     -b bno   Specifies  verbose behavior for the specific filesystem
> > block at bno.
> > which are not available with xfs_repair.
> 
> I've never used either of them in 10 years. If they are needed, you
> can still use xfs_db to get that information directly:
> 
> # xfs_db -F -i -p xfs_check -c "check -i ino" <dev>
> 
> So, really, we are not losing any xfs_check functionality at all -
> all we are doing is deprecating the user facing interface to it.
> 
> Cheers,
> 
> Dave.