On Wed, Dec 4, 2019 at 1:17 PM Gard Vaaler <gardv@xxxxxxxxxxxxx> wrote: > > 4. des. 2019 kl. 20:08 skrev Chris Murphy <lists@xxxxxxxxxxxxxxxxx>: > Why do you think it's complaining about the journal? I'm not seeing > tree log related messages here. > > > Thanks for the reply! That must be a misunderstanding on my part (it's called "transid", which suggested something in the journal to me). Gotcha, yeah transid is just a way Btrfs keeps track of separate commits over time. In effect the file system itself is the journal, there is no separate dedicated journal on Btrfs like you see on ext4 or XFS. For fsync performance enhancement there is a log tree which might be somewhat like a journal, which is what zero log is wiping away. Pretty much on all file systems, it's best to allow log replay to happen before zeroing it, and only zeroing it if there's a problem reported about it, rather than as an early trouble shooting step. > > Is the output provided complete or are > there additional messages? > > > No, that's it. > > What do you get for: > > btrfs insp dump-s /dev/X OK so no log tree, therefore not related. > > > Attached. > > What kernel version was being used at the time of the first problem instance? > > > Fedora's 5.2.8-300 kernel. There's a decent chance this is the cause of the problem. That kernel does not have the fix for this bug: https://www.spinics.net/lists/stable-commits/msg129532.html https://bugzilla.redhat.com/show_bug.cgi?id=1751901 As far as I'm aware the corruption isn't fixable. You might still be able to mount the file system ro to get data out; if not then decent chance you can extract data with btrfs restore, which is an offline scraping tool, but it is a bit tedious to use. https://btrfs.wiki.kernel.org/index.php/Restore The real fix it to make a new Btrfs file system, and don't use kernels 5.2.0-5.2.14. Fedora 29, 30, 31 all are long since on 5.3.x series kernels which do have this fix incorporated. But the fix found it's way into 5.2.15 pretty soon after discovery so I'm gonna guess you've got updates disabled and just got unlucky to get hit by this bug. > > The transid messages above suggest some kind of failure to actually > commit what should have ended up on stable media. Also please provide: > > btrfs-find-root /dev/ > > > Attached (compressed). > > btrfs check --mode=lowmem /dev/ > > > Attached. > > The latter will take a while and since it is an offline check will > need to be done in initramfs, or better from Live media which will > make it easier to capture the output. I recommend btrfs-progs not > older than 5.1.1 if possible. It is only for check, not with --repair, > so the version matters somewhat less if it's not too old. > > > As you can see, it terminates almost immediately with an IO error. However, there's no error in the dmesg on the underlying device, which makes me think there's a bad bounds check or something similar. -- Chris Murphy
