Thank you for the answer, reg 1, in which cases the server should increase the seqid in the delegation stateid then? Another question regarding locks, in case the client has only write delegation stateid (for example while using WANT_DELEGATION or OPEN4_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION), which means he can cache opens and locks, in case of a recall - the stateid of the opens and the locks will be the stateid of the delegation ? On Wed, Aug 14, 2024 at 4:14 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Wed, 2024-08-14 at 08:46 +0300, Roi Azarzar wrote: > > scenario 1 that I tested - 2 opens from the same client different > > owners (pcap attached). > > I'm wondering what should be the behavior in case the server received > > 2 opens with access read with want_read_deleg. > > I thought the server should give the same delegation state in the 2nd > > open and increase the seqid but I see the server doesn't grant > > delegation at all, can you explain it please? > > > > An open stateid can only have one owner, so when you issue the OPEN > request with a different owner, the server has to issue you a new > stateid. > > Delegations are a bit different, since they are issued to the client, > and not to a specific openowner. The server will not issue more than > one delegation to a client at a time, which is why it didn't issue one > here. > > > Another behavior that I'm trying to understand is size,change attrs > > in cb_getattr, I tested the following scenario: > > > > client 1 open for write > > client 1 write > > client 2 do stat on file > > client 1 write again > > client 2 do stat on file again > > > > Each stat caused the serv to send cb_geattr but in the response from > > the client I saw the same change and size values, can you explain it? > > > > both serv and client versions > > > > > > ]$ uname -r > > > 6.10.3-custom > > > > That sounds like a client bug. > -- > Jeff Layton <jlayton@xxxxxxxxxx>
