Christoph Anton Mitterer posted on Tue, 24 Nov 2015 05:02:34 +0100 as excerpted:
> Hey. > > Short question since that came up on debian-devel. > > Now that btrfs check get's more and more useful, are the developers > going to recommend running it periodically on boot (of course that > wouldn't work right now, as it would *always* check)? I'm a list regular and btrfs user, not a dev, but all the indications continue to point to _not_ running it automatically at boot, nobody even _suggesting_ otherwise. The btrfs kernel code itself detects and often corrects many problems, and btrfs check is simply not recommended for automatic at-boot scheduling -- if the kernel code can't fix it without intervention, then the problem is too serious to be fixed without intervention by some scheduled btrfs check run, as well. In fact, take a look at the shipped fsck.btrfs shell-script, based upon the xfs one. As both the code and the comments suggest, it's specifically designed to simply return success (well, if the given device exists, if not it does error out on that), without actually checking anything (beyond simple device existence). If it's run in auto mode, as it would be with an on-boot run, it does nothing else. If it's not run in auto mode, suggesting that a misinformed user attempted to run it, it prints a message redirecting them to btrfs check. That's pretty clear as to intent -- btrfs check is simply not designed or intended to ever be run at boot. > Plus... is btrfs check (without any arguments) non-desctructive, or are > there corner-cases where it may lead to any changes on the devices? Btrfs check, without arguments, is designed to be read-only. AFAIK, the only way it wouldn't be would be if there was a serious bug. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
