On Sep 17, 2014, at 3:06 AM, Tovo Rabemanantsoa <tovo.rabemanant...@bordeaux.inra.fr> wrote: > > Sep 17 11:05:55 sdeeph1 kernel: [85381.548215] parent transid verify > failed on 24562568384512 wanted 255444 found 255446 > Sep 17 11:05:55 sdeeph1 kernel: [85381.548229] parent transid verify > failed on 24562568384512 wanted 255444 found 255446 > Sep 17 11:05:55 sdeeph1 kernel: [85381.548237] parent transid verify > failed on 24562568384512 wanted 255444 found 255446 > Sep 17 11:05:55 sdeeph1 kernel: [85381.548243] parent transid verify > failed on 24562568384512 wanted 255444 found 255446 > Sep 17 11:05:55 sdeeph1 kernel: [85381.548249] parent transid verify > failed on 24562568384512 wanted 255444 found 255446 > Sep 17 11:05:55 sdeeph1 kernel: [85381.670344] btrfs: open_ctree failed > > /var/log/syslog adds this line : > Sep 17 11:05:55 sdeeph1 kernel: [85381.548255] Failed to read block > groups: -5
This isn't what I expect as a candidate for btrfs-zero-log, I don't know what the last message means. You could run a btrfs check <btrfsdev> and then ask about both the failure to read block groups -5 and also the btrfs check (without --repair) results Or take a leap of faith, take an image of the file system first as it might make recovery more difficult. If there are things you really need off this file system first you should look at https://btrfs.wiki.kernel.org/index.php/Restore before zeroing the log. btrfs-image -c 9 -t 8 <btrfsdev> /path/to/file btrfs-zero-log <btrfsdev> 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
