Subject: RE: direct I/O again
To: Chuck Silvers <email@example.com>
From: Gordon Waidhofer <firstname.lastname@example.org>
Date: 03/31/2006 11:35:27
> POSIX defines "the right thing". the last version of SUS is apparently
> different, but previous versions did specify atomicity requirements for
> read() and write().
Oh, yes. The atomicity, where read() won't be exposed to
partial write()s, is important. Good point.
> > If the application layer isn't taking care of such races, arbitrary
> > rules in the kernel or (the|a) file system won't save them.
> > Consider stat(2). ...
> > There is non-zero probability that the struct st in userland is
> > stale before control is returned to the application, let alone
> > whether it's accurate when acted upon (like ls(1) printing).
> the issue we're discussing is read() and write() serialization.
> yes, the info returned by stat() can become stale before an application
> gets a chance to look at it, but that's not relevant for the
> topic at hand.
In terms of atomicity, I agree.
Most system interfaces observe volatile state. The scenario
for stat() could just as easily be a scenario for read().
Introduce something like NFS into the mix and the probability
What I was driving at is that over aggressive serialization can't
ever overcome the volatility, but could be counterproductive
to the motivations of something like O_DIRECT.
> > These races simply can't be overcome below the syscall level.
> > In short, nobody should worry about serializing intersecting
> > direct reads/writes (or non-direct for that matter) too much.
> > Don't worry, be happy.
> some applications rely on this serialization, so it does seem
> appropriate to worry about it.
I think what you mean to say is some applications rely on
the atomicity guarantees rather than serialization. Or am
I missing something?