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-P7bZhjkgW1@https.bugzilla.kernel.org/>
Date:   Sun, 02 Dec 2018 13:43:23 +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

--- Comment #144 from Rainer Fiebig (jrf@...lbox.org) ---
(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.