On Thu, 2024-08-29 at 17:19 -0700, Rick Macklem wrote: > Hi, > > I have a rather crude patch that does the POSIX draft ACL attributes > that my draft is suggesting for NFSv4.2 for the Linux client. > - It is working ok for small ACLs, but... > > The hassle is that the on-the-wire ACEs have a "who" field that can > be up to 128bytes (IDMAP_NAMESZ). > > I think I have figured out the SETATTR side, which isn't too bad > because > it knows how many ACEs. (It does roughly what the NFSv3 NFSACL code > did, which is allocate some pages for the large ones.) > > However, the getfacl side doesn't know how bug the ACL will be in > the reply. The NFSACL code allocates pages (7 of them) to handle the > largest possible ACL. Unfortunately, for these NFSv4 attributes, they > could be roughly 140Kbytes (140bytes assuming the largest "who" times > 1024 ACEs). > --> Anyone have a better suggestion than just allocating 35pages each > time > (when 99.99% of them will fit in a fraction of a page)? > > Thanks for any suggestions, rick > See the NFSv3 posix acl client code. It allocates the 'pages[]' array of pointers to the page buffers to be of length NFSACL_MAXPAGES, but only allocates the first entry, and leaves the rest NULL. Then in the XDR encoder "nfs3_xdr_enc_getacl3args()" where it declares the length of that array, it sets the flag XDRBUF_SPARSE_PAGES on the reply buffer. That tells the RPC layer that if the incoming RPC reply needs to fill in more data than will fit into that single page, then it should allocate extra pages and add them to the 'pages' array. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
