Hey. Well the consensus over at linux-btrfs list seems to be: 1) right now it's not yet stable enough (has false positives, etc.) 2) it's very slow 3) btrfs should detect errors by itsel
and thus the suggestion tends towards "don't run it at boot". (1) should hopefulle be resolved sooner or later (2) Obviously, as it is now, btrfs check checks always (i.e. no mount count or last check time as in ext*)... this is of course overkill. But it shouldn't be impossible to have something similar for btrfs. And apart from that... I really maintain a lot of storage (>2PiB) and even though it takes quite a while to run e2fsck at boot, I'm rather happy to spend that time every half a year or so, than possibly running into data loss (and we regularly see small errors on our ext4 filesystems, even though there were no crashes, or the journal should have corrected them). (3) Apparently btrfsck does much more in depth checks than the kernel driver would do itself... and I'm sure many admin will rather require the extra time a full check could require at boot to find at least the slightest hints of problems, before such would pile up and may later cause serious problems. That being said... I still agree that one shouldn't include unnecessary stuff in the initramfs image, and ideally even not to run dummy- wrappers. But how much time is lost for running that? I doubt it's half a second. That may be important to get rid of when one wants to tune the desktop to the fastest boot ever (which I think is pretty pointless either),... but is completely irrelevant for every server system. I don't think one should remove facilities to have e.g. btrfs checked at boot, in the expectation that sooner or later btrfsck will be stable and that there are people wo rather want to have it run than not. Cheers, Chris
smime.p7s
Description: S/MIME cryptographic signature
