On 2/27/17 2:16 AM, Carlos Maiolino wrote: > On Fri, Feb 24, 2017 at 09:49:17PM +0100, Marcel Partap wrote: >> Dear XFS dev crew, >>> fsck.xfs(8) >>> fsck.xfs - do nothing, successfully >>> If you wish to check the consistency of an XFS filesystem, or repair a damaged or corrupt XFS filesystem, see xfs_repair(8). >> >> So there's a FS check command that does not work as with all the other filesystems. Instead of checking the FS, it tells you to use xfs_repair both for - XFS repair.. and XFS check. Whereas in the man page of >>> xfs_repair - repair an XFS filesystem >> it doesn't tell you right at the top that xfs_repair can check XFS. Instead >>> * -n No modify mode. Specifies that xfs_repair should […] *scan the filesystem* > > Xfs used to have two different tools for that. xfs_check and xfs_repair. This > required one more tool, several more lines of code to be maintained, while > xfs_repair does the check job with '-n' option, so, it was decided to deprecate > xfs_check and keep efforts only in xfs_repair. > >> >> Is this imperative? It does not make any sense to me apart from the quirk. >> > I am not quite sure what you mean by "imperative" here, but most (if not all) > repair tools, have a dry-run mode with -n, as so, xfs_repair also does. The name > of xfs tool is also kept due historical reasons, once, AFAIK, xfs_repair is the > name for the tool since its beginning. Yep. TBH, fsck.xfs was added only to satisfy initscripts which expect a fsck.$FS for every filesystem at boot time. But as a journaling filesystem, xfs has no need for a boot-time fsck. xfs_repair is for exceptional circumstances, not for a normal reboot with a log replay. So there is no reason to execute a potentially long xfs_repair -n via fsck.xfs on every boot; that would completely defeat the purpose of the metadata journaling. Like Carlos, I am also confused about what change you'd actually like to see here. Thanks, -Eric > If you believe that the first description of xfs_repair's man page, should say > something like "check and repair an XFS filesystem", feel free to send a patch > for that, IMHO I really don't see any reason for that, giving that the main goal > of such tools are to fix filesystem inconsistencies. > > Cheers > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
