https://bugzilla.kernel.org/show_bug.cgi?id=201685 --- Comment #144 from Rainer Fiebig (jrf@xxxxxxxxxxx) --- (In reply to Daniel Harding from comment #143) > Another datapoint: I have observed Ext4 metadata corruption under both > 4.19.1 and 4.19.4. I'm using LVM (but no RAID); the underlying drive is a > 1GB SATA-attached Samsung 850 PRO SSD. I've not been able to reliably > reproduce, but an rsync-based backup of my home partition runs once an hour > and it usually starts reporting corruption errors within a day or two of > booting a 4.19.x kernel. So far the corruption has only happened in > directories that I am not actively using - as far as I know they are only > being accessed by the rsync process. Since I started seeing the corruption > under 4.19.x, I've run 4.18.16 for two stretches, one of which was twelve > days, without any problems, so I'm quite confident it is not an issue of > defective hardware. I have a weekly cron job which runs fstrim, but at > least once I booted into 4.19.4 (previous boot was 4.18.16), and started > seeing metadata corruption after about 36 hours, but fstrim had not run > during that time. > > Some (possibly) relevant kernel configs: > CONFIG_SCSI_MQ_DEFAULT=y > # CONFIG_DM_MQ_DEFAULT is not set > # CONFIG_MQ_IOSCHED_DEADLINE is not set > # CONFIG_MQ_IOSCHED_KYBER is not set > CONFIG_DAX_DRIVER=y > CONFIG_DAX=y > # CONFIG_DEV_DAX is not set > # CONFIG_FS_DAX is not set > > $ cat /sys/block/sda/queue/scheduler > [none] bfq > > I'm happy to report any more info about my kernel/system if it would be > helpful, but unfortunately I don't have the bandwidth to do any bisection > right now. Bisecting just fs/ext4 (comment 79) wouldn't cost much time. Just 32 commits, 5 steps. It won't get much cheaper than that. -- You are receiving this mail because: You are watching the assignee of the bug.
