Re: O_DIRECT fails in some kernel and FS

From: Steve Lord (lord@sgi.com)
Date: Mon Feb 04 2002 - 10:15:30 EST


On Sun, 2002-02-03 at 16:44, Chris Wedgwood wrote:
> On Sun, Feb 03, 2002 at 09:05:04AM -0600, Stephen Lord wrote:
>
> but page faults are not blocked out for the duration of the I/O so
> the coherency is weak.
>
> I was thinking this would also be goof, basically invalidate those
> pages and remove them from the VMAs, marking them as unusable pending
> IO completion --- the logic her being if you were to fault on an
> invalidated page during IO you deserve to block indefinitely until the
> IO completes.
>
> However, if an application is doing a combination of mmapped and
> direct I/O to a file at the same time, then it should generally
> have some form of user space synchronization anyway.
>
> I hadn't considered that. I imagined an application doing either but
> not both, and the kernel enforcing this. However, in the case when
> you want to mmap a large file, you may want to manipulate some pages
> using mmap whilst writing others with O_DIRECT. Although, in such
> cases arguably you could using multiple mapping's.
>
>

If an application is single threaded then it cannot be doing both at
the same time - so all we need to do is flush and invalidate mappings
at the start of I/O. This is really only needed for the range covered by
the direct read/write.

If an application is multithreaded and is doing mmap and direct I/O
from different threads without doing its own synchronization, then it
is broken, there is no ordering guarantee provided by the kernel as
to what happens first.

>
> --cw

Steve

-- 

Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:34 EST