Re: [LSF/MM ATTEND] memory allocation scope

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]