On 06/07/2016 04:08 AM, Kevin Wolf wrote: >> Found it; squash this in (or use it as an argument why we don't want >> request_alignment in bs->bl after all): > > This hunk doesn't make sense to me. For the correctness of the code it > shouldn't make a difference whether the alignment happens before passing > the request to file/raw-posix or already in the raw format layer. > > The cause for the hang you're seeing is probably that the request is > already aligned before the blkdebug layer and therefore the blkdebug > events aren't generated any more. That's a problem with the test (I'm > considering the blkdebug events part of the test infrastructure), > however, and not with the code. >
Yes, it's definitely a hang caused by the test expecting an unalignment
event, but the inheritance chain now causes things to be aligned to
begin with and nothing unaligned happens after all.
> Kevin
>
>> diff --git i/block/raw_bsd.c w/block/raw_bsd.c
>> index b1d5237..c3c2246 100644
>> --- i/block/raw_bsd.c
>> +++ w/block/raw_bsd.c
>> @@ -152,7 +152,11 @@ static int raw_get_info(BlockDriverState *bs,
>> BlockDriverInfo *bdi)
>>
>> static void raw_refresh_limits(BlockDriverState *bs, Error **errp)
>> {
>> + /* Inherit all limits except for request_alignment */
>> + int request_alignment = bs->bl.request_alignment;
>> +
>> bs->bl = bs->file->bs->bl;
>> + bs->bl.request_alignment = request_alignment;
Any ideas on how to fix the test, then? Have two blkdebug devices
nested atop one another, since those are the devices where we can
explicitly override alignment? (normally, you'd _expect_ the chain to
inherit the worst-case alignment of all BDS in the chain, so blkdebug is
the way around it).
That's the only thing left before I repost the series, so I may just
post the last patch as RFC and play with it a bit more...
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
