On Thu, 6 Sep 2018 11:17:18 +0200 Rogier Wolff <R.E.Wolff@xxxxxxxxxxxx> wrote: > On Thu, Sep 06, 2018 at 12:57:09PM +1000, Dave Chinner wrote: > > On Wed, Sep 05, 2018 at 02:07:46PM +0200, Rogier Wolff wrote: > > > > And this has worked for years because > > > the kernel caches stuff from inodes and data-blocks. If you suddenly > > > write stuff to harddisk at 10ms for each seek between inode area and > > > data-area.. > > > > You're assuming an awful lot about filesystem implementation here. > > Neither ext4, btrfs or XFS issue physical IO like this when flushing > > data. > > My thinking is: When fsync (implicit or explicit) needs to know > the result of the underlying IO, it needs to wait for it to have > happened. Worse than that. In many cases it needs to wait for the I/O command to have been accepted and confirmed by the drive, then tell the disk to do a commit to physical media, then see if that blows up. A confirmation the disk got the data is not a confirmation that it's stable. Your disk can also reply from its internal cache with data that will fail to hit the media a few seconds later. Given a cache flush on an ATA disk can take 7 seconds I'm not fond of it 8) Fortunately spinning rust is on the way out. It's even uglier in truth. Spinning rust rewrites sectors under you by magic without your knowledge and in freaky cases you can have data turn error that you've not even touched this month. Flash has some similar behaviour although it can at least use a supercap to do real work. You can also issue things like a single 16K write and have only the last 8K succeed and the drive report an error, which freaks out some supposedly robust techniques. Alan
