Deprecating xfs_check

Deprecating xfs_check

[Chandra Seetharaman]

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 ?

Let me know if it is not the right approach.

Regards,

Chandra

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

Re: Deprecating xfs_check

[Ben Myers]

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 ?
> 
> 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.

Regards,
	Ben

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

Re: Deprecating xfs_check

[Troy McCorkell]

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

Does "xfs_repair -n" need to provide all of the functionality that xfs_check
provides before it is replaced?

xfs_check can be run on a filesystem mounted read-only.  xfs_repair -n 
can not.

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.

-Troy

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

Re: Deprecating xfs_check

[Dave Chinner]

[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

Re: Deprecating xfs_check

[Troy McCorkell]

On 04/11/2013 08:04 PM, 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.
>    

Dave,

Thanks for the thorough explanation!   I agree, time to deprecate xfs_check.

Thanks,
Troy

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

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


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

Re: Deprecating xfs_check

[Alex Elder]

On 04/16/2013 12:27 PM, Chandra Seetharaman wrote:
> 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.

I like option 1 the best.  But any of them is reasonable.	-Alex

> Please suggest.
> 
> Regards,
> 
> Chandra 

. . .

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