On 02/14/2018 09:53 PM, NeilBrown wrote: > On Wed, Feb 14 2018, Goldwyn Rodrigues wrote: > >> Discussion with the memory folks towards scope based allocation >> I am working on converting some of the GFP_NOFS memory allocation calls >> to new scope API [1]. While other allocation types (noio, nofs, >> noreclaim) are covered. Are there plans for identifying scope of >> GFP_ATOMIC allocations? This should cover most (if not all) of the >> allocation scope. >> >> Transient Errors with direct I/O >> In a large enough direct I/O, bios are split. If any of these bios get >> an error, the whole I/O is marked as erroneous. What this means at the >> application level is that part of your direct I/O data may be written >> while part may not be. In the end, you can have an inconsistent write >> with some parts of it written and some not. Currently the applications >> need to overwrite the whole write() again. > > So? > If that is a problem for the application, maybe it should use smaller > writes. If smaller writes cause higher latency, then use aio to submit > them. > > I doubt that splitting bios is the only thing that can cause a write > that reported as EIO to have partially completed. An application should > *always* assume that EIO from a write means that the data on the device > is indistinguishable from garbage - shouldn't it? > Yes, and that is what I got from others as well. The scenario is not deterministic of the contents of the file in case of overwriting a file. And no, splitting bios is not the only reason you can have partial write. This is different from what buffered I/O would result in, where a partial write may not be an error and returns the bytes written. Perhaps this needs to be documented in the man pages. I will put in one shortly. -- Goldwyn
