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  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]
Date:   Thu, 12 Apr 2018 17:57:56 -0400
From:   "Theodore Y. Ts'o" <>
To:     Andres Freund <>
Cc:     Jeff Layton <>,
        Matthew Wilcox <>,
        Andreas Dilger <>,,
        Ext4 Developers List <>,
        Linux FS Devel <>,
        "Joshua D. Drake" <>
Subject: Re: fsync() errors is unsafe and risks data loss

On Thu, Apr 12, 2018 at 02:53:19PM -0700, Andres Freund wrote:
> > > 
> > > Isn't beautiful to script, but it's also not absolutely terrible.
> ext4 seems to have something roughly like that
> (/sys/fs/ext4/$dev/errors_count), and by my reading it already seems to
> be incremented from the necessary places.

This is only for file system inconsistencies noticed by the kernel.
We don't bump that count for data block I/O errors.

The same idea could be used on a block device level.  It would be
pretty simple to maintain a counter for I/O errors, and when the last
error was detected on a particular device.  You could evne break out
and track read errors and write errors eparately if that would be

If you don't care what block was bad, but just that _some_ I/O error
had happened, a counter is definitely the simplest approach, and less
hair to implemnet and use than something like a netlink channel or
scraping dmesg....

						- Ted

Powered by blists - more mailing lists