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

Re: [Nbd] [PATCH] Only send one reply on oversize writes



On Sat, May 28, 2011 at 08:36:33PM +0100, Alex Bligh wrote:
> Wouter,
> 
> --On 28 May 2011 13:53:30 +0100 Alex Bligh <alex@...872...> wrote:
> 
> >>There's nothing to say that the seek offset won't be duplicated, either.
> >>Probably best to create our own handles, indeed.
> >
> >I meant the seek offset into the transaction log (which is monotonic)
> >but given we'll have a hash there anyway, yes, probably just creating
> >random ones is best.
> 
> I did this, and produced a test for oversize reads & writes. This was
> clearly worth doing as I found 3 bugs in our handling of oversize
> transactions. Given these all have disk corruption potential, I hope
> you can get them into your weekend release.

Will be.

> I reintroduced the duplicate reply bug, and integrityhuge caught
> it immediately.
> 
> Out of interest, I also fixed the speed calculation in integritytest()
> (stupid error on my part). This now shows the integrity test with normal
> data (even full of flushes and FUAs) runs far faster than the throughput
> test, and the huge integrity test runs even faster! I'm getting
> (to an SSD on a Macbook Air via VMWare) about 10MB/s for throughput
> test, and 67MB/s for integrity and 130 for integrityhuge. I can only
> explain this by the fact that using even slightly large read/write
> sizes than 1K seems to be far more efficient.

Right. That would make sense.

> I'm now reasonably confident that between the 2 integrity test instances,
> we are comprehensively testing the server.
> 
> You will be pleased to hear I don't plan to do anything more for
> this weekend's release, unless you find some bugs in my code of
> course.

I didn't see anything suspicious in your code, so I've merged it. I'm
working on the release right now.

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

pi zz a



Reply to: