Skip site navigation (1) Skip section navigation (2)

Re: O_DIRECT use

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: O_DIRECT use
Date: 2002-01-04 23:12:44
Message-ID: 200201042312.g04NCir06014@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> 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.
> 
> > I am told on FreeBSD it does not disable read-ahead, just caching;
> > something that needs more research.
> 
> Hmm.  I always thought of read-ahead as preloading buffer cache entries.
> 
> It'd be interesting to get a description of *exactly* what this flag
> does, rather than handwavy approximations.  Time to start reading the
> kernel code, I suppose.

I found this before adding the item:

	http://www.pairlist.net/pipermail/flow-tools/2001-October/000058.html

And this for FreeBSD 4.4:

2.1 Kernel Changes

   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.


I also found:

	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.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-01-04 23:13:23
Subject: Re: O_DIRECT use
Previous:From: Brent VernerDate: 2002-01-04 21:59:50
Subject: Re: More problem with scripts

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group