https://bugzilla.kernel.org/show_bug.cgi?id=201685 Daniel Harding (dharding@xxxxxxxxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dharding@xxxxxxxxxxxxx --- Comment #143 from Daniel Harding (dharding@xxxxxxxxxxxxx) --- 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. -- You are receiving this mail because: You are watching the assignee of the bug.
