Ricardo M. Correia wrote: > > On Qui, 2008-02-07 at 09:44 -0700, Mark Shellenbaum wrote: >> I'm not sure we should be using nvlists to store these attributes. >> While it will be quick to implement, I'm concerned about the constant >> packing/unpacking and searching linked lists in the nvlist code. > > That is also one of things that I was concerned about. > > What do you think about providing an alternate interface in the nvlist > code that would do an nvlist_lookup() without having to unpack the > nvlist (ie, by searching the name directly in the encoded format)? > The number of attributes on a file should be very limited so I don't > think a linear search would be a problem. >
Ok, but we don't know how many attributes future consumers may want to store. I hope it will be small, but I wouldn't want to paint ourselves in a corner and then wish we had done it a different way. > We could also provide a similar interface to add/update an attribute > that would manipulate the encoded format directly (the XDR format looks > fairly simple, I think). > I think that would be complicated. You could potentionally have a packed buffer that needs to be expanded in size or compressed depending on how the attribute is changed/added. >> As >> part of this effort I would like to refactor the znode_phys to only >> include what I believe to be the core attributes that must be in the >> znode_phys. Then all of the secondary attributes that aren't needed all >> of the time can use the new EA mechanisms that Lustre and others desire. >> We will need to rev the ZPL version to 4. By refactoring the znode we >> will recover a lot of the bonus space that is in short supply today. > > That sounds reasonable. > >> Section 2.2.4 >> >> Not sure what you mean by storing all xattrs in a single object? Are you >> saying all of the Lustre attributes would be stored in a single Solaris >> extended attribute file? > > Yes. The benefit of this approach is that it would greatly reduce the > number of seeks (which are always in short supply) in a Lustre metadata > server in the case where the xattrs won't fit in the dnode. > >> Section 2.2.5 >> >> This section is not needed. Solaris already has interfaces and >> frameworks in place to expose additional attributes to applications. >> Any attribute that lustre wants to retrieve/set can be retrieved with >> VOP_GETATTR()/VOP_SETATTR() via the xvattr_t. From an application those >> attributes can be manipulated with getattrat()/setattrat(). > > Are you referring to section 2.2.6 as opposed to 2.2.5? > The document that was posted by Girish didn't have a section 2.2.6 > In Lustre, we are not using (nor we have the desire to use) any Solaris > VFS code, so we can't use VOP_*() calls, vnode_t and/or znode_t > structures (although we do manipulate znode_phys_t buffers), ACL code, etc.. > I thought you were going to be running on Solaris? Things would be much simpler if you would be in the kernel. ;-) > Although we don't compile the majority of the ZPL code due to VFS > dependencies, we do compile zfs_znode.c in userspace (without the > _KERNEL definition). > Are you referring to the linux/fuse implementation? If so, then I would probably suggest we add some ioctl interfaces to retrieve the attributes. there is no need for Solaris to add new VOP interfaces for these. > As you may understand, it would be very convenient for us if the core of > this functionality would be free of VFS dependencies so that we could > just implement a thin wrapper in our Lustre code. > However, since this probably belongs more in the ZPL than in the DMU, it > could be implemented in zfs_znode.c. > > Thanks! > > -- > *Ricardo Manuel Correia* > Lustre Engineering > > *Sun Microsystems, Inc.* > Portugal > Phone +351.214134023 / x58723 > Mobile +351.912590825 > Email Ricardo.M.Correia at Sun.COM <mailto:Ricardo.M.Correia at Sun.COM> > > > ------------------------------------------------------------------------ > > _______________________________________________ > zfs-code mailing list > zfs-code at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-code
