[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v6 03/22] blockdev: Add and parse "lock-mode" op
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-block] [PATCH v6 03/22] blockdev: Add and parse "lock-mode" option for image locking |
Date: |
Tue, 6 Sep 2016 19:15:45 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 06.09.2016 um 18:51 hat Daniel P. Berrange geschrieben:
> On Tue, Sep 06, 2016 at 06:45:55PM +0200, Kevin Wolf wrote:
> > Am 08.07.2016 um 15:05 hat Max Reitz geschrieben:
> > > I think whether to lock a BDS chain is a host-side property and has not
> > > a lot to do with the guest, thus it should be a BDS property. I can
> > > imagine that a guest may say that sharing should be disallowed under all
> > > circumstances, but a guest is never able to decide to allow sharing.
> >
> > Well, yes and no. The decision which lock mode to use is at the node
> > level, no doubt. But it's not something that a user can configure.
> > Non-raw images simply can't be shared and the user can't do anything
> > about it. Why should they have an option to specify a lock mode when
> > there is only one correct setting?
>
> I'm not sure that's true for all non-raw images. I understand things like
> qcow2 won't work, because of cached metadata which can be updated by QEMU
> during writes, but I think the luks format ought to be safe as the cached
> metadata is never changed.
Yes, I guess I've been overgeneralising. Doesn't really make a
difference for my point, though, the luks driver still knows what it
needs to request from the lower layer without user intervention.
Kevin