On Thu, Feb 14, 2019 at 11:10 PM Christoph Anton Mitterer <cales...@scientia.net> wrote: > > On Thu, 2019-02-14 at 01:22 +0000, Filipe Manana wrote: > > The following one liner fixes it: > > https://friendpaste.com/22t4OdktHQTl0aMGxcWLj3 > > Great to see that fixed... is there any advise that can be given for > users/admins?
Upgrade to a kernel with the patch (none yet) or build it from source? Not sure what kind of advice you are looking for. > > > Like whether and how any occurred corruptions can be detected (right > now, people may still have backups)? > > > Or under which exact circumstances did the corruption happen? And under > which was one safe? > E.g. only on specific compression algos (I've been using -o compress > (which should be zlib) for quite a while but never found any > compression),... or only when specific file operations were done (I did > e.g. cp with refcopy, but I think none of the standard tools does hole- > punching)? As I said in the previous reply, and in the patch's changelog [1], the corruption happens at read time. That means nothing stored on disk is corrupted. It's not the end of the world. [1] https://lore.kernel.org/linux-btrfs/20190214151720.23563-1-fdman...@kernel.org/ > > > Cheers, > Chris. > -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.”
