In order to help with verifying the layout-related algorithms presented in RFC5661 I've built a simple simulator that generates random layout operations, implements them on the server side and applies the results on the client side. The simulator then verifies the resulting layout on both sides of the wire to make sure they agree on the layout stateid and on the contents of the layout, so that the client does not hold layout it is not supposed to. So far, I've checked combinations of LAYOUTGET and LAYOUTRETURN and the only addition to the protocol that was required was the serialization of the initial LAYOUTGET carrying a non-layout stateid. The reason for that, even without a forgetful client, is that in case the client sent multiple layoutgets with the initial stateid and a layoutreturn that returns everything (and thus resetting the layout stateid), without waiting for all the initial layoutgets, then there will be a mixture of layout stateids before and after the layoutreturn with colliding seqids. I've implemented a simple synchronization scheme allowing a single layoutget with the initial stateid although in theory we could allow multiple such layoutgets in parallel, just fully serialized against a conflicting layoutreturn. If we allow forgetful clients to send a layoutget with the initial stateid to signal a "reset" of the layout (e.g., an implicit layoutreturn for the whole file), it should be a singular operation as well. The simulator is freely available (under GPLv2) here: git://linux-nfs.org/~bhalevy/layout-sim.git Next on my list are: - CB_LAYOUTRECALL - forgetful client - return_on_close Please feel free to use and improve it! 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
