Re: O_DIRECT! or O_DIRECT?

[miquels@cistron-office.nl (Miquel van Smoorenburg)]

In article <20010704193402.A6403@redhat.com>,
Stephen C. Tweedie <sct@redhat.com> wrote:
>Hi,
>
>On Wed, Jul 04, 2001 at 06:27:13PM +0000, Miquel van Smoorenburg wrote:
>> 
>> Any chance of something like O_SEQUENTIAL (like madvise(MADV_SEQUENTIAL))
>
>What for?  The kernel already optimises readahead and writebehind for
>sequential files.

Yes, but I really do mean like in madvise().

>If you want to provide specific extra hints to the kernel, then things
>like O_UNCACHE might be more appropriate to instruct the kernel to
>explicitly remove the cached page after IO completes (to avoid the VM
>overhead of maintaining useless cache).  That would provide a definite
>improvement over normal IO for large multimedia-style files or for
>huge copies.  But what part of the normal handling of sequential files
>would O_SEQUENTIAL change?  Good handling of sequential files should
>be the default, not an explicitly-requested feature.

exactly what I meant, since that is what MADV_SEQUENTIAL seems to do:

linux/mm/filemap.c:

 *  MADV_SEQUENTIAL - pages in the given range will probably be accessed
 *              once, so they can be aggressively read ahead, and
 *              can be freed soon after they are accessed.

/*
 * Read-ahead and flush behind for MADV_SEQUENTIAL areas.  Since we are
 * sure this is sequential access, we don't need a flexible read-ahead
 * window size -- we can always use a large fixed size window.
 */
static void nopage_sequential_readahead(struct vm_area_struct * vma,

O_SEQUENTIAL perhaps is the wrong name.

I'd like to see this so I can run tar to backup a machine during the
day (if tar used this flag, ofcourse) without performance going
down the drain because of cache pollution.

Mike.