Hi Rick - > On Aug 4, 2023, at 6:18 PM, Rick Macklem <rick.macklem@xxxxxxxxx> wrote: > > Hi, > > I wrote an IETF draft proposing a few new attributes for NFSv4.2. > Since there did not seem to be interest in them, I just > let the draft expire. However, David Noveck pinged > me w.r.t. it, so I thought I'd ask here about it. > > All the attributes are meant to be "read only, per server file system": > supported_ops - A bitmap of the operations supported. > The motivation was that NFS4ERR_NOTSUPP is supposed to > be "per server", although the rumour was that the Linux knfsd > uses it "per server file system". Before crafting new protocol, we should have a look at server implementation behavior to see if it can be improved in this area. Is Linux the only problematic implementation? Send email, bug reports, or patches... we'll consider them. > dir_cookie_rising - Only useful for directory delegations, which no > one seems to be implementing. We've been talking privately and informally about implementing directory delegation in the Linux NFS server, so this one could be interesting. But there aren't enough details here to know whether this new attribute would be useful to us. > seek_granularity - The smallest size of unallocated region reported > be the Seek operation. FreeBSD has a pathconf(2) variable called > _PC_MIN_HOLE_SIZE that an application can use to decide if > lseek(SEEK_DATA/SEEK_HOLE) is useful. I'm not aware of a scenario where the Linux server would provide a value not equal to 1, so it would be easy for us to implement. What would clients do with this information, aside from filling in a pathconf field? Might this value be of benefit for READ_PLUS? > mandatory_br_locks - Byte range locks are mandatory. No one > seems to be implementing these, but a client needs to know > that mandatory locking is being enforced so that it can cache > data correctly. I don't have much exposure to mandatory locking, maybe Jeff could chime in on this one. > max_xattr_len - Allows the client to avoid attempting to Setxattr an > attribute that is larger than the server file system supports. Can you elaborate on the problem you are trying to solve? Why isn't the current situation adequate? Again, I don't think this would be difficult for the Linux server to implement, but I'd like to know why it's needed. -- Chuck Lever
