On Oct 10, 2014, at 6:53 AM, Bob Marley <bobmar...@shiftmail.org> wrote:
> On 10/10/2014 03:58, Chris Murphy wrote: >> >>> * mount -o recovery >>> "Enable autorecovery attempts if a bad tree root is found at mount >>> time." >> I'm confused why it's not the default yet. Maybe it's continuing to evolve >> at a pace that suggests something could sneak in that makes things worse? It >> is almost an oxymoron in that I'm manually enabling an autorecovery >> >> 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. For a general purpose file system, losing 30 seconds (or less) of questionably committed data, likely corrupt, is a file system that won't mount without user intervention, which requires a secret decoder ring to get it to mount at all. And may require the use of specialized tools to retrieve that data in any case. The fail safe behavior is to treat the known good tree root as the default tree root, and bypass the bad tree root if it cannot be repaired, so that the volume can be mounted with default mount options (i.e. the ones in fstab). Otherwise it's a filesystem that isn't well suited for general purpose use as rootfs let alone for boot. Chris Murphy -- 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
