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? NeilBrown > > Other things I am interested in: > - new mount API > - Online Filesystem Check > - FS cache shrinking > > [1] https://lwn.net/Articles/710545/ > > > -- > Goldwyn
Attachment:
signature.asc
Description: PGP signature
