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