Re: O_DIRECT use
От | Matthew Kirkwood |
---|---|
Тема | Re: O_DIRECT use |
Дата | |
Msg-id | Pine.LNX.4.33.0201050011500.16532-100000@sphinx.mythic-beasts.com обсуждение исходный текст |
Ответ на | Re: O_DIRECT use (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
On Fri, 4 Jan 2002, Bruce Momjian wrote: > > >> For that matter, I would expect that O_DIRECT also defeats readahead, > > >> so I'd fully expect it to be a loser for seqscans too. > And this for FreeBSD 4.4: > The O_DIRECT flag has been added to open(2) and fcntl(2). Specifying this > flag for open files will attempt to minimize the cache effects of reading > and writing. This seems rather vague. Can any FreeBSD person here say whether the semantics are any stronger? > http://www.ukuug.org/events/linux2001/papers/html/AArcangeli-o_direct.html > > These later ones seem to indicate there isn't read-ahead, meaning we > would have to do our own prefetches. Eck. I am unclear if that is > true on all OS's. The Linux O_DIRECT semantics are intended to be harder. In essence, the kernel _will not cache_ data read from or written to such a file or device. The point of this, incidentally, was to be able to run things like Oracle Parallel Server and other shared- disk setups. It's use as an "I don't need this cached" mechanism is secondary, and rather sub-optimal, as seen here; you disable software read-ahead and introduce coherence issues with non-O_DIRECT openers of the file. (I'm not sure of the precise Linux semantics of this, but it's probably fair to say that you may as well consider them undefined.) Linux 2.4 has "madvise", but unfortunately no matching "fadvise". A quick Google implied that FreeBSD is in the same boat. Matthew.
В списке pgsql-hackers по дате отправления: