qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 05/18] ide: Turn debug messages into assertions


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 05/18] ide: Turn debug messages into assertions
Date: Mon, 06 Jun 2011 14:56:12 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10

Am 06.06.2011 13:57, schrieb Markus Armbruster:
>>>> Not sure what's the best way of fixing this. Maybe just ignoring
>>>> -snapshot for read-only block devices?
>>>
>>> Why not, the combination is pointless.
>>
>> It could start making a difference in some obscure combinations. Imagine
>> a read-only image with a backing file, -snapshot and the 'commit'
>> monitor command.
>>
>> Sounds pretty insane, but I wouldn't bet that people aren't using it...
> 
> People try all kinds of insane things.  The question is whether we can
> change it anyway.

We have a backing file chain like base <- cow [<- tmp], and the drive is
read-only.

Currently, 'commit' means that tmp is committed to cow (i.e. nothing
happens because it's read-only). After changing it, we would commit the
content of cow to base and possibly corrupt other images that are based
on base.

We can hope that nobody would be hit by it in practice, but it's not a
change I'd feel very comfortable about.

>>>>                                        Or we could try and forward the
>>>> eject request to the backing file if the format driver doesn't handle it.
>>>
>>> For what it's worth, the "raw" driver forwards manually.
>>
>> Yeah, but copying that into each driver probably isn't the right thing
>> to do.
> 
> I didn't mean to hold up the "raw" driver as a shining example of how to
> do stuff.
> 
>>        For a generic implementation we could probably first try the
>> driver itself, if it returns -ENOTSUP we try the protocol, and if that
>> returns -ENOTSUP, too, we ask the backing file driver.
> 
> I don't want to start another "format vs. protocol" semantic war, just
> point out that the general case is a tree of block drivers, and a
> general rule for passing eject up the tree better covers that.
> 
> The current block.c provides for binary trees (bs->file and
> bs->backing_hd).  When we discussed blockdev_add, we came up with much
> wilder trees.

I didn't mean to imply that you suggested raw was a shining example.
However, if we're going for the wild trees (or even graphs), there's no
simple option of doing it in generic code any more. Backing files and
protocols (for lack of a better term) are special in the tree because
they are a concept that the block layer knows. For everything else the
least we need is a hint from the block driver.

In any case passing up the tree means that you need to decide which
child is the one to try first, or if there are children to which it
shouldn't be passed at all.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]