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