linux-ext4 - [Bug 201685] ext4 file system corruption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bug-201685-13602-FrXBraUxsN@https.bugzilla.kernel.org/>
Date:   Sun, 02 Dec 2018 13:35:42 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 201685] ext4 file system corruption

https://bugzilla.kernel.org/show_bug.cgi?id=201685

Daniel Harding (dharding@...ing180.net) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dharding@...ing180.net

--- Comment #143 from Daniel Harding (dharding@...ing180.net) ---
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.