• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
F_NOCACHE vs F_GLOBAL_NOCACHE
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

F_NOCACHE vs F_GLOBAL_NOCACHE


  • Subject: F_NOCACHE vs F_GLOBAL_NOCACHE
  • From: Quinn <email@hidden>
  • Date: Thu, 20 Sep 2007 15:04:20 +0100

Greetings All

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.

Over the past couple of years Apple has been laying the groundwork for fixing this. Specifically, with the Mac OS X 10.4u SDK, we've added a new fcntl selector, F_GLOBAL_NOCACHE, whose defined semantics is the current behaviour (it turns off caching globally) and we've decided that the semantics of F_NOCACHE will be per-descriptor (which is what we generally want folks to use). However, in all versions of Mac OS X 10.4.x these flags have the same effect: they both effect the vnode.

In future systems we expect to implement the defined semantics correctly: that is, F_NOCACHE will only disable caching for accesses via that descriptor and F_GLOBAL_NOCACHE will disabling caching for accesses via all descriptors.

If you're a file system client, there's really not much change. Most folks want the per-descriptor functionality, and that's what you'll get by default. However, if you're developing a VFS plug-in, you have to do some things for this to work properly. Specifically:

A. If you're using the cluster layer (cluster_read, cluster_write, and so on), pass the ioflag parameter for your read/write nop entry point through to the flags parameter of the corresponding cluster routine (the last parameter).

B. If you're not using the cluster layer, you should disabling caching if either IO_NOCACHE is set in the ioflags parameter or vnode_isnocache returns true.

It turns out that my MFSLives sample code doesn't do the properly. Check out my VNOPRead routine in "MFSLives.c".

<http://developer.apple.com/samplecode/MFSLives/listing5.html>

Rather than passing ioflag through to the last parameter of cluster_read, I just pass in zero. That's a bug that I'm going to have to fix <rdar://problem/5494259>.

Share and Enjoy
--
Quinn "The Eskimo!"                    <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
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


  • Prev by Date: Re: Creating Plists / How is the <data> value generated?
  • Next by Date: Re: F_NOCACHE vs F_GLOBAL_NOCACHE
  • Previous by thread: Re: Creating Plists / How is the <data> value generated?
  • Next by thread: Re: F_NOCACHE vs F_GLOBAL_NOCACHE
  • Index(es):
    • Date
    • Thread