Re: F_NOCACHE vs F_GLOBAL_NOCACHE
Re: F_NOCACHE vs F_GLOBAL_NOCACHE
- Subject: Re: F_NOCACHE vs F_GLOBAL_NOCACHE
- From: Sam Vaughan <email@hidden>
- Date: Fri, 21 Sep 2007 14:21:08 +1000
On 21/09/2007, at 11:28 AM, Mark Day wrote:
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.
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".
Hi Mark,
I forgot about the cluster layer's F_NOCACHE support. Of course
you're right, there are lots of good tricks being performed in there,
including special consideration for I/O to non-main memory such as
video capture cards.
Unfortunately when we ported CXFS we couldn't use all that code
because the cross-platform volume manager didn't really allow us to
drag high level information such as the vnode all the way down to the
layer that issues I/Os to the underlying disk devices.
It's interesting that you mention the alignment checks in the cluster
layer. We had the headache of trying to support all the Mac
applications that issue F_NOCACHE I/Os to offsets that aren't on
basic block boundaries, or aren't multiples of a basic block in
length. On all the other UNIX platforms we supported, unaligned
direct I/O simply wasn't permitted.
I wonder how the Leopard ZFS port is handling direct I/O using
F_NOCACHE. Given that they're also bringing volume management code
to the platform, they could well be encountering similar issues.
Sam
_______________________________________________
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