Re: F_NOCACHE vs F_GLOBAL_NOCACHE
Re: F_NOCACHE vs F_GLOBAL_NOCACHE
- Subject: Re: F_NOCACHE vs F_GLOBAL_NOCACHE
- From: Mark Day <email@hidden>
- Date: Thu, 20 Sep 2007 18:28:17 -0700
On Sep 20, 2007, at 4:49 PM, Sam Vaughan wrote:
On 21/09/2007, at 5:04 AM, email@hidden
wrote:
On current systems the F_NOCACHE state is stored per-vnode. This
presents a problem when two programs open two different descriptors
for the same file. The descriptors, by definition, share the same
vnode. So, if program A sets F_NOCACHE on its descriptor, its
setting is reflected in program B's descriptor. Worse yet, if
program A exits without clearing the flag, it remains in effect until
the vnode is recycled. Less than ideal.
Hi Quinn,
That last part is really nasty!
A nice side effect of your current global setting is that you avoid
the cache coherency issue. With per-descriptor flags, a buffered
writer can write data that won't be seen by an unbuffered reader.
Not quite. Both the read and write code will still look in the buffer
cache, and will use (and update, in the case of write) the data that's
in the cache. So no coherency problem.
If the F_NOCACHE flag is set, and some of the blocks being read/
written are not currently in the cache, and they are suitably aligned,
and the entire block is being read/written, then that block will not
(should not) remain in the cache after the read/write completes. In
some cases, it will actually end up in the cache for a brief period of
time, and then be evicted after the read/write. It's just a hint that
says "don't bother caching anything new for this read/write, if you
don't need to".
-Mark
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden