On 05/08/2012 10:57, Chris Samuel wrote:

On 08/04/2012 08:41 AM, Olivier Bonvalet wrote:

quoted

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