> On 6 Oct 2016, at 11:15, Wouter Verhelst <w@xxxxxxx> wrote: > >> >> >> .... but I still think it would be helpful if the protocol helped out >> the end user of the client and refused to negotiate multichannel >> connections when they are unsafe. How is the end client meant to know >> whether the back end is not on Linux, not on a block device, done >> via a Ceph driver etc? > > Well, it isn't. The server, if it provides certain functionality, should > also provide particular guarantees. If it can't provide those > guarantees, it should not provide that functionality. > > e.g., if a server runs on a backend with cache coherency issues, it > should not allow multiple connections to the same device, etc. Sure. I'm simply saying that the connection flags should say "I can't support multiple connections to this device" (available at NBD_OPT_INFO time) rather than errorring out. This is a userspace protocol issue. >> I still think it's pretty damn awkward that with a ceph back end >> (for instance) which would be one of the backends to benefit the >> most from multichannel connections (as it's inherently parallel), >> no one has explained how flush could be done safely. > > If ceph doesn't have any way to guarantee that a write is available to > all readers of a particular device, then it *cannot* be used to map > block device semantics with multiple channels. Thinking about it I believe Ceph actually may be able to do that, it's just harder than a straightforward flush. > Therefore, it should not > allow writing to the device from multiple clients, period, unless the > filesystem (or other thing) making use of the nbd device above the ceph > layer actually understands how things may go wrong and can take care of > it. > > As such, I don't think that the problems inherent in using multiple > connections to a ceph device (which I do not deny) have any place in a > discussion on how NBD should work in the face of multiple channels with > a sane/regular backend. On which note, I am still not convinced that fsync() provides such semantics on all operating systems and on Linux on non-block devices. I'm not sure all those backends are 'insane'! However, if the server could signal lack of support for multiple connections (see above) my concerns would be significantly reduced. Note his requires no kernel change (as you pointed out). -- Alex Bligh -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
