On Fri, May 08, 2015 at 12:16:16PM +0200, Paolo Bonzini wrote: > There are two problems: > > 1) A literal reading of the specification could imply that the server could > not send a reply if fsync() fails, because in that case previous writes > have not reached the disk. Of course, this part of the specification only > applies to successful replies. > > 2) Flush does not apply to outstanding writes. It applies to _completed_ > writes, ensuring that they also hit the disk.
Er, I always thought it was supposed to imply ordering as well. If you send write request A, then write request B, then receive a reply message for B, and then (before receiving reply for A) send a flush request, the flush reply message should not be sent before A *and* B are finished; that was my understanding. Of course, this nbd server doesn't actually care either way, because it "just" does fsync(), without disordering writes. So I suppose what matters is the Linux kernel's semantics in this regard for flush messages; does it care? If not, an asynchronous implementation of nbd-server would be much simpler (because no synchronisation is necessary); but if it does, we shouldn't change that part of the protocol--and if we're not sure we should probably not change it either, just to be on the safe side. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
