> On Oct 12, 2022, at 5:18 PM, NeilBrown <neilb@xxxxxxx> wrote: > > On Thu, 13 Oct 2022, Chuck Lever III wrote: >> >> I think I stopped at the non-list variant of rhashtable because >> using rhl was more complex, and the non-list variant seemed to >> work fine. There's no architectural reason either file_hashtbl >> or the filecache must use the non-list variant. >> >> In any event, it's worth taking the trouble now to change the >> nfs4_file implementation proposed here as you suggest. > > If you like you could leave it as-is for now and I can provide a patch > to convert to rhl-tables later (won't be until late October). > There is one thing I would need to understand though: why are the > nfsd_files per-filehandle instead of per-inode? There is probably a > good reason, but I cannot think of one. I'm not clear on your offer: do you mean converting the nfsd_file cache from rhashtable to rhl, or converting the proposed nfs4_file rework? I had planned to do the latter myself and post a refresh. The nfsd_file_acquire API is the only place that seems to want a filehandle, and it's just to lookup the underlying inode. Perhaps I don't understand your question? -- Chuck Lever
