Comment 10 for bug 1093385

Raghu,

On Mon, Feb 24 2014 18:13:44 +0400, Raghavendra D. Prabhu wrote:

> In the path of directio, there should be no fadvise/madvise at
> all since these are purely the directives associated with linux
> VM.
>
> a) On a file opened with O_DIRECT, POSIX_FADV_SEQUENTIAL should
> be a no-op but again, it depends on FS/kernel, so undefined, and
> shouldn't be done
>
> b) POSIX_FADV_DONTNEED again shouldn't be used with O_DIRECT.
>

Those hints are defined in a rather generic way by both POSIX and the
Linux man page:

POSIX_FADV_SEQUENTIAL
    The application expects to access the specified data sequentially
    (with lower offsets read before higher ones).
POSIX_FADV_DONTNEED
    The specified data will not be accessed in the near future.

It neither implies nor states explicitly that those hints are
incompatible with O_DIRECT. It is meant to be a way for applications to
explain how data is going to be accessed, so the kernel could
implement optimizations where applicable. If a specific implementation
is, say, incompatible with O_DIRECT, it must also be responsible for
handling it properly.

>
> Out of a) and b), b) is actually bad because a) operates on file
> level, where b) works on mapping level. So, in places you may end
> up flushing the data InnoDB is using (if mysqld is not using
> O_DIRECT). Also, a) operates as directive (it doubles read-ahead

We always access InnoDB files in the same mode as the server. So if
neither server nor XB use O_DIRECT, POSIX_FADV_DONTNEED may (again, up
to specific implementation) indeed stomp on server’s caches. I don’t see
a way around it, but as Sergei pointed out, there shouldn’t be much
impact on InnoDB neither. If both the server and XB use O_DIRECT, then I
don’t see how using POSIX_FADV_DONTNEED may be bad.

> window but doesn't do anything till anyone reads the file) whereas b) actually
> acts (though defined as a directive) immediately.
>
> POSIX_FADV_NOREUSE actually does nothing:
> http://lxr.linux.no/#linux+v3.13.5/mm/fadvise.c#L113 (though without
> POSIX_FADV_NORMAL it actually means no/low readahead)

We could still implement it, as that would provide more info to the
kernel, whether it uses it or not (yet). But OK, thanks for the heads up.