[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] Question about the expected behaviour of nbd-server for async ops



On Sun, May 29, 2011 at 11:45:18AM +0100, Alex Bligh wrote:
> Goswin,
> 
> > Wouter: Could we make a decision here about the behaviour of a correct
> > nbd-server in this? Must it logically preserve the order or read/write
> > requests (i.e. return the value you would get if it had been done in
> > order) or can it implement the disordered behaviour that linux seems to
> > allow?
> >
> > The later would be much simpler code wise.
> 
> I think we should probably involve the block layer people in this as
> whilst the ability to disorder a read to go before a write appears
> to be technically allowed, I am under the impression it hadn't
> received a lot of testing. Perhaps the answer is that we simply
> don't specify it in the protocol, but say "you must do what the
> linux block layer expects".

No. Standards which point to one particular implementation as part of
what they define rather than defining it themselves are evil.

Also because there are more client-side implementations of nbd, not just
what's in the Linux kernel (e.g., there's a proxy client in xnbd, and
there's a (possibly long broken, since nobody seems to be working on it
anymore) client in the hurd, too)

I don't mind involving the fsdevel people in this so it makes sense from
their point of view; but saying "do what seems to work for that
particular implementation" is a bad idea, and I don't want to go down
that route.

[...]
> > And turning the device read-only seems like a bad idea. How would
> > badblocks be able to work then?
> 
> The FS going readonly is exactly what happens if you have an error
> on a SCSI disk. I presume you then detach the drive, reattach and
> run badblocks.

NBD is not a file system, it's a block device. Yes, the FS going
readonly is indeed what happens if you have an error on a SCSI disk, but
that doesn't mean the SCSI disk will go readonly.

I don't have a better idea how to handle it either, though. If we've got
the sync option set in the config file or the client has the FUA bit set
in the request, then we can (and should, though I don't think we do
currently) just return the right error code in the response. But beyond
that...

[...]

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a



Reply to: