-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/11/2014 3:29 AM, Goffredo Baroncelli wrote: > On 10/10/2014 12:53 PM, Bob Marley wrote: >>> >>> If true, maybe the closest indication we'd get of btrfs >>> stablity is the default enabling of autorecovery. >> >> No way! I wouldn't want a default like that. >> >> If you think at distributed transactions: suppose a sync was >> issued on both sides of a distributed transaction, then power was >> lost on one side, than btrfs had corruption. When I remount it, >> definitely the worst thing that can happen is that it >> auto-rolls-back to a previous known-good state. > > I cannot agree. I consider a sane default to have a consistent > state with "the recently data written lost", instead of "require > the user intervention to not lost anything". > > To address your requirement, we need a "super sync" command which > ensure that the data are in the filesystem and not only in the log > (as sync should ensure).
I have to agree. There is a reason we have fsck -p and why that is what is run at boot time. Some repairs involve a tradeoff that will result in permanent data loss that maybe could be avoided by going the other way, or performing manual recovery. Such repairs should never be done automatically by default. For that matter I'm not even sure this sort of thing should be there as a mount option at all. It really should require a manual fsck run with a big warning that *THIS WILL THROW OUT SOME DATA*. Now if the data is saved to a snapshot or something so you can manually try to recover it later rather than being thrown out wholesale, I can see that being done automatically at boot time. Of course, if btrfs is that damaged then wouldn't grub be unable to load your kernel in the first place? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUamDQAAoJEI5FoCIzSKrwaYAIAKXgkGBbBZj6yUuLC1+euim6 6Xqer1DiGywEiO4UPaxmq3rHDOlZlyIamDpUi7nIvbfK+TgBWfEVtLvdd6shjfqA FvFv7t+X2mlAyk+iGffSK1w9/qgEhE55M35exba95Cdsn0ezos4LpvTsL1128nkx uGzYQcoYj1irkmDp133JuHYAxhrAp0Q6PB+5gIgWfRsVbGezcxg5FvqzotEq1J/d 7MT1FvdoUo5qt2j/KzTUfD5AlFhsXE5beykakMdFmoHlTCQAxEeUU21z6APclkxF /b/ppLt603Vpb6rpKvNUyBy1TuPr6FJEx5O2qWUWlhRxkOUB98M86KHyWVBHtMM= =uG+h -----END PGP SIGNATURE----- -- 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
