On 2011-09-12 14:10, Trond Myklebust wrote: > On Mon, 2011-09-12 at 13:31 -0700, Benny Halevy wrote: >> On 2011-09-12 07:56, Peng Tao wrote: >>>> The layout segments are not really in use while in LAYOUTCOMMIT. >>>> We only need to get the stateid right with respect to concurrent layout recalls. >>> LAYOUTCOMMIT takes lseg reference to mark them as in use so that >>> layoutrecall cannot free them. >>> >> >> And if layoutrecall would have freed layout segments during layoutcommit, >> what is your specific concern? > > That layoutcommit is supposed to return NFS4ERR_BAD_LAYOUT in that case > according to section 18.42.3 of RFC5661. I can't find anything in the > errata that changes that requirement. > Right. That tells me there no need to strictly serialize LAYOUTCOMMITs with CB_LAYOUTRECALL, as long as the layout stateid sent with LAYOUTCOMMIT atomically represents the state when the operation was prepared. That said, since we do want the LAYOUTCOMMIT to succeed, it would be beneficial for the client to reply to a CB_LAYOUTRECALL received while a conflicting LAYOUTCOMMIT is in progress with NFS4ERR_DELAY. The server, on its side, should prevent a distributed deadlock by avoiding blocking of a LAYOUTCOMMIT on an outstanding CB_LAYOUTRECALL for the same client that sent the LAYOUTCOMMIT. I'm not sure what error would be best to return. Maybe NFS4ERR_RECALL_CONFLICT if it would be allowed (it isn't listed for LAYOUTCOMMIT at the moment). Just returning NFS4ER_DELAY might lead to a live lock situation where neither the LAYOUTCOMMIT not the CB_LAYOUTRECALL complete. Benny -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
