Re: RFC: Adding a UF_DONTCACHE flag
Robert Clausecker <[email protected]> Mon, 13 Jul 2026 03:28:03 +0200
| Newsgroups | gmane.os.freebsd.devel.file-systems |
|---|---|
| Message-ID | <[email protected]> |
Hi Rick, As requested, my thoughts on this one. We already have several flags where negation is expressed through the word NO, so using DONT seems inconsistent. Maybe UF_NOCACHE? As for fflagstostr(), maybe do it like with nodump/dump where the flag is turned on by specifying noucache and off by specifying ucache? This seems much less klunky and more intuitive than the udontcache and noudontcache (double negation?!) you propose. Yours, Robert Clausecker Am Thu, Jul 09, 2026 at 05:54:53PM -0700 schrieb Rick Macklem: > Hi, > > This internet draft (which is close to being an RFC) > specifies a new NFSv4.2 attribute which tells the NFSv4.2 > client to not cache file data. (Similar to O_DIRECT, but > triggered by this attribute set on the file on the NFSv4.2 > server and not by the application's open(2).) > > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-uncacheable-files/ > > I am thinking that this can be implemented as a > new UF_xxx va_flags bit. I called it UF_DONTCACHE, > but anyone can suggest a better name. > (The alternative would be to define an extended attribute, > but that involves extra overhead, since GETATTR will probably > ask for it for every file when open'd on a client.) > > Does this sound reasonable or is there a better approach? > > Thanks in advance for any comments, rick > ps: I don't know if this flag would be useful for other types > of file systems? > -- () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachments