Jeff Darcy <jdarcy@xxxxxxxxxx> writes: > However, I’d be even more comfortable with an even simpler approach that > avoids the need to solve what the database folks (who have dealt with > complex transactions for years) would tell us is a really hard problem. > Instead of designing for every case we can imagine, let’s design for the > cases that we know would be useful for improving performance. Open plus > read/write plus close is an obvious one. Raghavendra mentions > create+inodelk as well. For each of those, we can easily define a > structure that contains the necessary fields, we don’t need a > client-side translator, and the server-side translator can take care of > “forwarding” results from one sub-operation to the next. We could even > use GF_FOP_IPC to prototype this. If we later find that the number of > “one-off” compound requests is growing too large, then at least we’ll > have some experience to guide our design of a more general alternative. > Right now, I think we’re trying to look further ahead than we can see > clearly. Actually, I'm taking the design, I've seen another network protocol use, SMB2, and proposing it here, I'd be shocked if NFS doesn't behave in the same way. Interestingly, all the cases, really deal with a single file, and a single lock, and a single... There's a reason I talked about a single sentinel value, and not multiple ones. Because I wanted to keep it simple. Yes, the extensions you mention are obvious, but they lead to a giant mess, that we may not want initially. (But that we CAN extend into if we want them. I made the choice not to go there because honestly, I found the complexity too much for me.) A simple "abort on failure" and let the higher levels clean it up is probably right for the type of compounding I propose. It is what SMB2 does. So, if you get an error return value, cancel the rest of the request, and have it return ECOMPOUND as the errno. Note: How you keep the list to be compounded doesn't matter much to me. the semantics matter, because those are what I can ask for later, and allow us to create ops the original desginers hadn't thought of, which is usually the hallmark of a good design. I think you should look for a simple design you can "grow into" instead of creating one off ops, to satisfy a demand today. My thoughts, -Ira _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
