On Mon, Jul 29, 2019 at 8:40 AM Qu Wenruo <quwenruo.bt...@gmx.com> wrote: > > > > On 2019/7/29 下午10:34, Swâmi Petaramesh wrote: > > Le 29/07/2019 à 16:27, Qu Wenruo a écrit : > >> BTW, I'm more interesting in your other corrupted leaf report other than > >> this transid error. > > > > Well I already broke 2 FSes including my most important computer with > > this, took me 2 working days to restore and mostly fix my main computer > > which I couldn't use for a week (because of lack of time for restoring > > it) and now I lose my main backup disk. > > At least from what I see in this transid error, unless you ruled out the > possibility of bad disk firmware and LVM/LUKS, it's hard to say it's > btrfs causing the problem.
I'm using kernel 5.2.x since early rc's on several ystems, nvme, SSD, HDD, half plain partition, half on dmcrypt/LUKS. I can report no problems. None are on LVM. It comes down to: a. workload specific behavior is triggering a new bug in Btrfs or dm or blk layer, or combination b. new hardware issue It seems to me whenever weird stuff pops up with ext4 or XFS, their call traces generally expose the problem, so I wonder if Btrfs devs still have the kernel debug information needed to point the blame; or if there needs to be some debug mode (mount option?) that does extra checks to try and catch the problem. Is this a case for metadata integrity checking of some kind, and have Swâmi run this workload? Either on the problem file system or a new Btrfs file system, just to gather better quality information? But yeah, at least a complete current dmesg is needed. And even possibly helpful is kernel messages for the entire time since switching to 5.2.0: it could be a big file but easy to filter for dm, libata, smartd, and btrfs messages. The filtering I'd leave up to a developer, I always by default provide the entire dmesg, it's not always clear what the instigator is. We've discussed many times how both file system repair, and file system restore from backup, simply are not scalable for big file systems. It takes too long. -- Chris Murphy
