On Wed, Jun 03, 2020 at 08:10:50PM +0100, Filipe Manana wrote: > On Wed, Jun 3, 2020 at 8:02 PM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > > On Wed, Jun 03, 2020 at 12:32:15PM +0100, Filipe Manana wrote: > > > On Wed, Jun 3, 2020 at 12:23 PM Filipe Manana <fdmanana@xxxxxxxxx> wrote: > > > > Btw, this is causing a regression in Btrfs now. The problem is that > > > > dio_warn_stale_pagecache() sets an EIO error in the inode's mapping: > > > > > > > > errseq_set(&inode->i_mapping->wb_err, -EIO); > > > > > > > > So the next fsync on the file will return that error, despite the > > > > fsync having completed successfully with any errors. > > > > > > > > Since patchset to make btrfs direct IO use iomap is already in Linus' > > > > tree, we need to fix this somehow. > > > > Y'all /just/ sent the pull request containing that conversion 2 days > > ago. Why did you move forward with that when you knew there were > > unresolved fstests failures? > > > > Now I'm annoyed because I feel like you're trying to strong-arm me into > > making last minute changes to iomap when you could have held off for > > another cycle. > > If you are talking to me, I'm not trying to strong-arm anyone nor > point a fingers. > I'm just reporting a problem that I found earlier today while testing > some work I was doing. I think the correct response to having just found the bug is to back the btrfs-to-iomap conversion out of Linus' tree. I don't think changing the iomap code at this time is the right approach.
