On 2015-11-28 11:52, Jeff Mahoney wrote:
The bit about ext* is debatable, the code doesn't appear to do any automatic repairs on an online filesystem like XFS does (and BTRFS does when you scrub it), which would indicate to me that it should be run, but not forced on boot for ext3/4, assuming the FS is configured sanely (which means on the systems I manage, it only gets run at most once every 24 hours unless I break into the boot sequence and force it manually).On 11/23/15 11:02 PM, Christoph Anton Mitterer wrote: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)?Running fsck on boot is a holdover from an era where non-journaling file systems were the norm. It persists in the ext* world mostly due to inertia, but it shouldn't be run on boot with ext3 or ext4 either. As Eric noted, fsck.xfs is a no-op. We have something similar for btrfs and have no intention of ever running fsck on boot with btrfs except in the case of a mount failure of the root file system.
I agree with Qu here, if this is the case, it's a bug that needs to be fixed.Plus... is btrfs check (without any arguments) non-desctructive, or are there corner-cases where it may lead to any changes on the devices?I haven't reviewed it in detail, but a quick glance makes it look like it will, minimally, create transactions even in check-only mode.
smime.p7s
Description: S/MIME Cryptographic Signature
