On 5:17 17/02, Christoph Hellwig wrote: > On Thu, Feb 13, 2020 at 01:25:03PM -0600, Goldwyn Rodrigues wrote: > > From: Goldwyn Rodrigues <rgoldwyn@xxxxxxxx> > > > > In case of a block device error, iomap code returns 0 as opposed to > > the amount of submitted I/O, which may have completed before the > > error occurred. Return the count of submitted I/O for correct > > accounting. > > Haven't we traditionally failed direct I/O syscalls that don't fully > complete and never supported short writes (or reads)? Yes, but I think that decision should be with the filesystem what to do with it and not the iomap layer. The reason we need this patch for btrfs is that we need to account for updating the allocations. iomap_end() returns written as zero while iomap_dio_rw loop has submitted part of the I/O. So btrfs has no idea as to how much has been submitted before the failure and how much of the allocation to update. This was exhibited by generic/250 in some of the runs where it fails the underlying storage. -- Goldwyn
