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.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
