Re: O_DIRECT! or O_DIRECT?

Miquel van Smoorenburg
2001-07-04T20:23:37Z

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.