Le dimanche 07 septembre 2014 à 17:48 +0000, Holger Hoffstätte a écrit : > On Sun, 07 Sep 2014 18:39:40 +0200, Olivier Bonvalet wrote: > > I cannot really offer much assistance, but that particular area of code > looks suspiciously like something fixed later and *not* yet backported > to 3.14.8: > > "Btrfs: fix leaf corruption caused by ENOSPC while hole punching" > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/btrfs?id=fc19c5e73645f95d3eca12b4e91e7b56faf1e4a4 > > The symptoms described in the patch sound like they might be your OOPS. > Unfortunately (I think) that would mean that just installing different > kernels will not fix the problem, since the problem is on disk. :/ > > So to me it seems your best course of action is to backup/mkfs/restore > the affected partition and stick with 3.17-rc3, since that has tons > more fixes. > > If you really need/want 3.14.x and are not afraid of building your > own kernel, you can try applying my btrfs-* patches from: > https://github.com/hhoffstaette/kernel-patches/tree/master/3.14 > which apply cleanly to the latest 3.14.18-stable. > > However even that will not fix a bungled tree on disk. > > -h > > --
Ok, so the cause is probably solved, this is a very good news, thanks. And yes, I can easily use 3.17-rc3 kernel. So the problem is with current data : I don't know an easy way to export/restore subvolumes & snapshots thought network, and I don't have physical access to this rent servers. Any hope that btrfsck be updated to fix that ? Olivier -- 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
