[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 02:30:51PM +0100, Alex Bligh wrote:
> Goswin,
> 
> --On 29 May 2011 14:53:01 +0200 Goswin von Brederlow <goswin-v-b@...186...> 
> wrote:
> 
> > That really sucks documentation wise. Because then you have to start a
> > hunt for further documentation which probably doesn't even exist other
> > than the source.
> >
> > It is ok to say we implement what the linux block layer expects but it
> > should be spelled out in the text or at least name a file to look at for
> > the details. It should not be left this vague.
> 
> Point taken. However, it does mean we would end up documenting
> in practice how the linux block layer behaves. Which itself is
> not static.

No, we need to define how nbd behaves. This may or may not be the same
thing as how the Linux block layer behaves, and it may change at some
point in the future if we add additional messages to the protocol.
I'm *not* going to be adding negotiation messages of the likes of "use
2.6.42-style semantics".

[...]
> Consider a normal SATA disk with a write-behind cache (forget nbd
> for a minute). From memory mkfs just does normal block writes. It
> may do an fsync() on the block device which results in a sync
> at the end. It has no way of knowing where bad blocks are anyway.

it doesn't even try to figure out, unless you set a particular option,
which will cause it to run badblocks. And badblocks doesn't try to find
bad blocks by checking for write errors, it tries to find them by
writing more blocks than would fit in the drive's cache and then reading
them out again; if one or more gives bad results, they're marked as bad.
Additionally, badblocks is not as useful as it used to be.

I'm also not going to care about marking the particular write that
failed. If you're writing to a broken disk, your filesystem is going to
lock up anyway, and then all writes will fail. If write() returns an
error condition, I'd return that to the client. If fsync() returns an
error condition, I'd return that to the client too. Beyond that, I'm not
going to care much about assigning failures to the correct write.

It's code, not AI.

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

pi zz a



Reply to: