Re: Deprecating xfs_check

[Dave Chinner <david@fromorbit.com>]

[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.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs