Girish Shilamkar wrote: > Hi, > With reference to my previous mail ([zfs-code] Nvpair for storing EAs > in dnode) which had expressed our intent to use libnvpair for EAs in > dnode. I am now sending a high level design document for the same. > > Any suggestions/comments are most welcome. > > Thanks & Regards, > Girish > >
General comment: 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. 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. 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? 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(). -Mark
