On Mon, Jul 08, 2013 at 10:25:21PM +0000, Myklebust, Trond wrote: > On Mon, 2013-07-08 at 17:17 -0400, Bruce Fields wrote: > > Is your argument that this will require breaking delegations too > > frequently to make write delegations practical, hence that clients and > > server will still have to depend on clients doing some minimal update of > > the file on close? > > Yes. Right now, our client does relax the rules to not send the COMMIT; > the write delegation ensures that we can recover safely in case of a > server reboot. However we do still actively flush out the WRITEs to > reduce the burden of delegation recalls, and also to ensure that we > don't have to worry about the whole delegation writeback quota > business... OK, so: we should assume that a client will do what's necessary to update the server attributes on close, such that the server won't need to do something new on stat to prevent a regression in consistency semantics when we implement write delegations. That makes sense to me. But (unless I'm totally misreading) the RFC authors clearly expected clients to delay that stuff on close. Specs aren't manuals for how to write a good implementation, I understand that, but--here you're asking me to assume client implementors will all do something that the spec goes out of its way to tell them they don't have to do. So I'd be more comfortable if I'd seen some ietf discussion of that. I'll go start it if need be. (Or maybe there already was some and I missed it.) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
