Subject: Re: direct I/O
To: Darrin B.Jewell <dbj@netbsd.org>
From: Stephan Uphoff <ups@tree.com>
List: tech-kern
Date: 03/03/2005 23:37:48
On Thu, 2005-03-03 at 23:09, Darrin B.Jewell wrote:
> Chuck Silvers <chuq@chuq.com> writes:
> > POSIX requires that for regular files, read() and write() be atomic with
> > respect to each other (and write()s with respect to other write()s),
> > so we do need to keep enough locking to provide that. however, there no
> > requirement that non-overlapping write()s be serialized, so tracking
> > the ranges are being read or written allows greater concurrency than
> > the current scheme of just tracking read vs. write.
>
> Thanks for pointing this out. I was not aware of a requirement in this
> area. However, after your assertion, and yamt's comment, I looked it
> up in the online opengroup spec 6. I found this in the rationale to the
> read() call found at:
> http://www.opengroup.org/onlinepubs/009695399/functions/read.html
>
> I/O is intended to be atomic to ordinary files and pipes and
> FIFOs. Atomic means that all the bytes from a single operation that
> started out together end up together, without interleaving from
> other I/O operations. It is a known attribute of terminals that this
> is not honored, and terminals are explicitly (and implicitly
> permanently) excepted, making the behavior unspecified. The behavior
> for other device types is also left unspecified, but the wording is
> intended to imply that future standards might choose to specify
> atomicity (or not)
>
> Darrin
I know that some implementations of B (link) trees depend on this
feature to avoid locking the tree for read operations.
Stephan