From: Mike Eisler (mre@eng.sun.com)
Date: 11/04/99-07:22:40 PM Z
Date: Thu, 4 Nov 1999 17:22:40 -0800 (PST) From: Mike Eisler <mre@eng.sun.com> Subject: Re: change of persistent_fh attribute (attempt 2) Message-ID: <Roam.SIMC.2.0.6.941764960.10004.mre@eng.sun.com> > > > > FH4_VOL_MIGRATION - fh may expire during file system migration. May > > only be set if FH4_VOLATILE_ANY is not set. > > > > FH4_VOL_RENAME - fh may expire due to a rename. This includes a > > rename by the requesting client or a rename by another client. May > > only be set if FH4_VOLATILE_ANY is not set. > Could there be some explanation about how the client could make use of > the last two. I cannot seem them being, from the clients > perspective, functionally different from FH4_VOLATILE_ANY (as rename > and migration could happen at any time). We should call these the Linux bits. :-) The notion behind FH4_VOL_RENAME is that I can cache file handles as long as I don't rename my files. if I do rename my files then I should tack a LOOKUP/GETFH onto the end of RENAME compound. Of course, another client could rename files from under me, if I'm concered about that, then I'll treat FH4_VOL_RENAME as FH4_VOLATILE_ANY, i.e. cache path names in my fh caches. If FH4_VOL_MIGRATION on, the client will cache the path name of every file is caches an fh for, but if FH4_VOL_RENAME is off it need not append a LOOKUP/GETFH to the RENAME. If the client doesn't support migration, then it need not do anything special at all. FH4_VOLATILE_ANY simply makes it very clear how tenuous things are. I'd use FH4_VOLATILE_ANY when doing file transfer to a DOS floppy, but unless FH4_NOEXPIRE_WITH_OPEN, is also set I'd think twice about writable file access. > On that note, Mike, your minor versioning proposal says: > > Note that this rule doesn't mean we can't add bits to > flag fields, such as new attributes to GETATTR's bitmap4 data > > This seems to imply that any bit field, such as persistent_fh and the > various bit fields to do with ACLs, may be extended by a minor > version. Is this true? Should it be explicit? I'll make it explicit. Any other feedback? -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:50 AM Z CST