Re: O_DIRECT in freebsd

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: O_DIRECT in freebsd
Date: 2003-06-23 03:00:39
Message-ID: 20030623030039.GL97131@perrin.int.nxad.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > > What about cache coherency problems with other backends not
> > > opening with O_DIRECT?
> >
> > If O_DIRECT introduces cache coherency problems against other
> > processes not using O_DIRECT then the whole idea is a nonstarter,
> > but I can't imagine any kernel hackers would have been stupid
> > enough to allow that to happen ...

Cache coherency isn't an issue, read() called on a fd that has
O_DIRECT set on it will pull data from the FS cache if a write has
occurred to the file pointed to by the reading/writing fd (though the
write of that page gets done immediately and isn't postponed,
rationale for that is still pending).

> Seeing how the buffer exists in user space, I would be interested
> how they prevent coherency problems with good performance --- maybe
> they map the same page into multiple processes --- that would be
> interesting, though it would require some locking.

It's in src/kern/vfs_bio.c, src/ufs/ffs_vnops.c, src/ufs/ffs_rawread.c

http://lists.freebsd.org/pipermail/cvs-all/2003-March/000226.html

phk's likely to revamp some of the FS buffer cache in FreeBSD 6, but
the userland API will remain stable (it'll just get more efficient in
6, not that it's not fast as is).

http://lists.freebsd.org/pipermail/cvs-all/2003-March/000261.html

-sc

--
Sean Chittenden

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-06-23 03:05:52 Re: O_DIRECT in freebsd
Previous Message Bruce Momjian 2003-06-23 02:57:41 Re: Two weeks to feature freeze