* Deprecating xfs_check @ 2013-04-11 21:45 Chandra Seetharaman 2013-04-11 22:17 ` Ben Myers 0 siblings, 1 reply; 7+ messages in thread From: Chandra Seetharaman @ 2013-04-11 21:45 UTC (permalink / raw) To: XFS mailing list 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating xfs_check 2013-04-11 21:45 Deprecating xfs_check Chandra Seetharaman @ 2013-04-11 22:17 ` Ben Myers 2013-04-11 23:01 ` Troy McCorkell 0 siblings, 1 reply; 7+ messages in thread From: Ben Myers @ 2013-04-11 22:17 UTC (permalink / raw) To: Chandra Seetharaman; +Cc: XFS mailing list 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating xfs_check 2013-04-11 22:17 ` Ben Myers @ 2013-04-11 23:01 ` Troy McCorkell 2013-04-12 1:04 ` Dave Chinner 0 siblings, 1 reply; 7+ messages in thread From: Troy McCorkell @ 2013-04-11 23:01 UTC (permalink / raw) To: xfs, Chandra Seetharaman, Ben Myers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating xfs_check 2013-04-11 23:01 ` Troy McCorkell @ 2013-04-12 1:04 ` Dave Chinner 2013-04-12 14:41 ` Troy McCorkell 2013-04-16 17:27 ` Chandra Seetharaman 0 siblings, 2 replies; 7+ messages in thread From: Dave Chinner @ 2013-04-12 1:04 UTC (permalink / raw) To: Troy McCorkell; +Cc: Ben Myers, Chandra Seetharaman, xfs [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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating xfs_check 2013-04-12 1:04 ` Dave Chinner @ 2013-04-12 14:41 ` Troy McCorkell 2013-04-16 17:27 ` Chandra Seetharaman 1 sibling, 0 replies; 7+ messages in thread From: Troy McCorkell @ 2013-04-12 14:41 UTC (permalink / raw) To: Dave Chinner, xfs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating xfs_check 2013-04-12 1:04 ` Dave Chinner 2013-04-12 14:41 ` Troy McCorkell @ 2013-04-16 17:27 ` Chandra Seetharaman 2013-04-20 19:14 ` Alex Elder 1 sibling, 1 reply; 7+ messages in thread From: Chandra Seetharaman @ 2013-04-16 17:27 UTC (permalink / raw) To: XFS mailing list 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Deprecating xfs_check 2013-04-16 17:27 ` Chandra Seetharaman @ 2013-04-20 19:14 ` Alex Elder 0 siblings, 0 replies; 7+ messages in thread From: Alex Elder @ 2013-04-20 19:14 UTC (permalink / raw) To: xfs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-04-20 19:14 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-04-11 21:45 Deprecating xfs_check Chandra Seetharaman 2013-04-11 22:17 ` Ben Myers 2013-04-11 23:01 ` Troy McCorkell 2013-04-12 1:04 ` Dave Chinner 2013-04-12 14:41 ` Troy McCorkell 2013-04-16 17:27 ` Chandra Seetharaman 2013-04-20 19:14 ` Alex Elder
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox