> On Oct 28, 2024, at 3:45 AM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: > > 1. How should this be tested? You are adding a random element to the > test matrix, without an option to manually set a fixed value, or > disable it. At least there should be a hook in /proc to set the number > of DRC slots, so CI can simulate changes. Neil suggested exposing session parameters via /proc. I think I would prefer /sys instead. But perhaps we could make (some of) them writable as well as readable; Neil will have to let us know if that is feasible. pynfs already has some unit testing of SEQUENCE and CREATE_SESSION, but we don't (yet) have a lot of testing around server memory exhaustion. > 2. How do you provide backwards compatibility to clients which do not > implement the number of slots adjustments per SEQUENCE op, or > implement it wrong? Just claim "its the NFSv4.1 standard, and legacy > clients should burn&die" is not an option, otherwise AWS&co will try a > Jeanne d'Arc-style punishment on those responsible That's what a standard is for. Either a client implementation complies to the standard, and thus has interoperability guarantees; or it doesn't, and all bets are off. This isn't something unique to the NFS world, it's actually a very common approach to such issues. Do you know of any specific client implementation that would have difficulty with dynamic session resizing? Find an example and we can work through it. > 3. How do you handle changes in memory, e.g. memory hotplug, or > changes in mem assigned to the VM running the nfsd? It's certainly possible to add but has it been demonstrated that it is necessary on day zero? These are the corneriest of corner cases; I would prefer to avoid heroic interventions in this code until it just can't be avoided. I also note that a shrinker could signal NFSD when system memory conditions have changed. A shrinker callback does not have to release any memory, and can be used to opportunistically reduce future memory needs. > Is swap space counted too? It isn't currently. I can't think of a reason NFSD would need to do that. What were you thinking of? > 4. Windows until Windows Server 2003 (leaked source code can be > googled) had this kind of memory autoscaling for SMB. Each Windows > release before Server 2003 had increasingly more complex code, with > increasingly unpleasant curses in the source comments about unexpected > and unwanted side effects. After Windows Server 2003 this whole > machinery was yanked out, because it was much more harmful to > customers than any savings in memory consumptions could ever bring. > > Why do you want to try to bring the same nightmarish experiment to the > NFSv4 world, after Microsoft failed so horribly? You might be comparing apples and oranges, but I can't tell because there is so very little detail here that would enable us to say whether we are implementing anything remotely similar to what Microsoft might have done 20 years ago, nor do we know any specifics about the implementation issues they faced. We do have one or two former SMB folks on list who could provide some facts. But, suffice to say, other NFSD server implementations already implement dynamic session slot resizing, and there have been only minor issues with those. I do expect that ours will have to be tuned and tweaked over time. -- Chuck Lever
