On Thu, Aug 29, 2024 at 5:33 PM Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > 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. Oh, ok thanks for the explanation. It doesn't sound like a problem then. I'll just code things the same way. Maybe I can ask one more question?? There are a large # of XXX_decode_XXX functions. Are there any that should/should not be used for the above case? For example, there are: - Ones that take a "struct xdr_stream *xdr" (usually with _stream_ in the name) vs - Ones that take a "struct xdr_buf *buf" argument. (I ended up using these for the encode side and this looks like what nfsacl_decode() uses, as well.) (I'll admit I have been wading around in the code, but haven't really gotten to the point of understanding which ones should be used.) Thanks, rick > > -- > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust@xxxxxxxxxxxxxxx > >
