On 05/08/2012 10:57, Chris Samuel wrote: > On 08/04/2012 08:41 AM, Olivier Bonvalet wrote: > >> Is there something I can do to fix that ? (the mount >> option "recovery" didn't help here) > > I've seen someone (perhaps Marc Merlin) report that the > 3.5.x kernel was able to mount a filesystem that 3.4.x > couldn't, so it might be worth a shot here! > > Best of luck, > Chris Thanks for the idea, but same result : Aug 5 16:10:12 backup2 kernel: [ 58.630481] device fsid a5dfe512-c8a3-46f0-bc8c-6365b8eccdcb devid 1 transid 110425 /dev/mapper/vg--backupplug-backup Aug 5 16:10:12 backup2 kernel: [ 58.631346] btrfs: force zlib compression Aug 5 16:10:12 backup2 kernel: [ 58.631357] btrfs: not using ssd allocation scheme Aug 5 16:10:12 backup2 kernel: [ 58.631366] btrfs: enabling auto recovery Aug 5 16:10:12 backup2 kernel: [ 58.670972] btrfs: no dev_stats entry found for device /dev/mapper/vg--backupplug-backup (devid 1) (OK on first mount after mkfs) Aug 5 16:10:12 backup2 kernel: [ 58.674758] parent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 5 16:10:12 backup2 kernel: [ 58.675090] parent transid verify failed on 615015833600 wanted 110423 found 110424 Aug 5 16:10:12 backup2 kernel: [ 58.675523] btrfs read error corrected: ino 1 off 615015833600 (dev /dev/mapper/vg--backupplug-backup sector 1209083504) Aug 5 16:10:12 backup2 kernel: [ 58.675536] Failed to read block groups: -5 Aug 5 16:10:12 backup2 kernel: [ 58.704720] btrfs: open_ctree failed -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
