From: RICE,JIM (HP-Cupertino,ex1) (jim_rice@am.exch.hp.com)
Date: 06/07/99-02:47:01 PM Z
Message-ID: <87FB8F5CE210D311B60500A0C9F4871C2379C7@xcup01.cup.hp.com> From: "RICE,JIM (HP-Cupertino,ex1)" <jim_rice@am.exch.hp.com> Subject: RE: Extended attributes Date: Mon, 7 Jun 1999 13:47:01 -0600 Should we be breaking this conversation into two parts, client and server? The requirements for the client side would/should be different than the requirements for processing meta-data on the server side. By nesessity, we would want the definition and the type and handling of the meta-data, on the client side of the transaction, must be uniform and inclusive of the different types of meta data that the servers are able to produce/process. On the server side, we need to make sure that we can handle all of the different types of meta-data that the filesystem and NFS may have to process. But, were the meta-data is stored in the filesystem should be transparent to the NFS server code. ---- Jim Rice (jrice@hp.com) | HP-UX Client+Server File System Architect | Please Hassle Me, Hewlett Packard/ St Paul/ MN/ 55113 | I thrive on Stress PHONE: T(651)603-2945 FAX: (612)997-1203 | > -----Original Message----- > From: Robert Thurlow [mailto:Robert.Thurlow@eng.sun.com] > Sent: Friday, June 04, 1999 6:28 PM > To: Noveck, Dave > Cc: nfsv4-wg@sunroof.eng.sun.com > Subject: Re: Extended attributes > > > > I've been looking at the section on extended attributes and > > I'm a little worried that the concept of a "virtual directory" > > for extended attributes may get out of hand if we don't > > put in place appropriate restrictions. > > I agree - this makes my head spin when I think of attributes having > attributes. However, one of the things prompting this was a group > working on things like security labels, which must have owners so > that you can know who does and does not get to change or remove them. > If you're B2, you can own a file, but may not remove its > security label, > since applications must limit what you can do to the file. That means > that a security label at least needs some access/ACL info of > their own. > > > Starting with the "directory" I get back from OPENATTR: > > > > Can I do a GETATTR on it and if so what are the attributes > > returned? Are they the same (except for size) as of the > > file whose attributes are being described? Does this > > directory, have its own fileid, different from that of > > the file? > > I think that since a likely implementation of this in Unix is to use > a separate inode, that yes, you could examine the regular attributes, > and that the filehandle and fileid could be different from the file > they go with. I don't think this need always be so, but at least the > filehandle should be different. > > > Can I do a SETATTR and what does it mean if I do? > > I think permissions or ACLs should govern whether I can or cannot > add or delete extended attributes, so I should be able to set that. > Perhaps the server won't permit this if the file and the OPENATTR > dir really share regular attributes. > > > Can this directory have its own extended attributes (i.e. > > can I do an OPENATTR on it)? > > I doubt it, but I don't know. I at first thought of how you might > implement an ACL as a structured clump of extended attributes, but > then thought that there was no reason to do that and good reasons > not to (e.g. atomicity). So I would prefer not to see this. > > > Can I do a MKDIR to get extended attributes named a/b, etc? > > > > Can I create anything other than regular files in this > > directory (symlinks, devices)? > > > > Can I create hard links in this directory to other extended > > attrbutes somewhere else or ordinary files (i.e files that > > aren't extended attributes)? > > > > Can someone create a hard link somewhere else to the directory > > for the OPENATTR? > > > > Can this directory appear as the source directory or the target > > directory in a RENAME? > > I hope none of the above things are necessary, since they > make me itch. > > > What do I get back if do a LOOKUPP? > > Some error, since this is not in the regular file namespace. > > > Once I'm dealing with an individual external attribute handle, > > > > Can I create a hard link to it? > > I remember the B2 Security guys talking about hard linking attributes > together to save inodes :-) It's not clear that it is desirable to > have the client aware of this, never mind participate in it. > > > When I do a GETATTR, what do I see? Do I really have > to maintain > > the equivalent of an inode for each attribute or may I just get > > the attributes (except for size) from the file itself? Does > > each attribute have its own fileid? > > I'd be okay with sharing inodes as appropriate in a server > implementation. > > > Can I do a SETATTR (with similar questions)? > > I'd expect an answer as above for the OPENATTR dir. > > > Can this attribute have its own extended attributes (i.e can I > > do an OPENATTR)? > > I'd expect an answer as above for the OPENATTR dir. > > > Can people do OPEN and CLOSE as well as LOOKUP, READ, and WRITE > > with all of the share reservation semantics? > > > > Can you do file locking on extended attributes? > > I guess I would expect that these things would work. The semantics > are not unexpected or inappropriate - saving data against loss seems > just as valid here. > > > What is the relationship between share reservations on the file > > and the extended attributes? If I open a file > DENY=BOTH, is it > > the case that anybody else can do anything they want on any of > > extended attributes? That seems consistent with the > fact that I > > can do a SETATTR while someone else has opened a file > DENY=BOTH, > > but I wonder if this will be a problem for applications? Does > > anybody know what NT streams needs in this regard? > > > > I'm hoping for "No"'s to many of these questions. In particular, > > anything that goes much beyond what is required for NT streams would > > need a pretty strong justification as far as I'm concerned. As I > > understand it, the NT streams model has multiple data forks with a > > single inode (or whatever they call it), and doesn't > support separate > > sets of attributes on each data fork. > > If there are servers out there with underlying data that are more > complex than NT streams, we should not say "Walk to the console to > manage it." We should keep the model simple without crippling it. > However, we can walk before we run by seeing how this works in a > prototype and by using the extensibility of the protocol. > > Rob T >
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:10 AM Z CST