From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vyhyv-0006kx-4e for qemu-devel@nongnu.org; Thu, 02 Jan 2014 08:06:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vyhyo-0007ae-LO for qemu-devel@nongnu.org; Thu, 02 Jan 2014 08:06:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vyhyo-0007aT-DX for qemu-devel@nongnu.org; Thu, 02 Jan 2014 08:06:30 -0500 Message-ID: <52C56452.10901@redhat.com> Date: Thu, 02 Jan 2014 06:06:26 -0700 From: Eric Blake MIME-Version: 1.0 References: <52864C79.20800@gmail.com> <52864EEE.3000900@redhat.com> <52865824.7070600@redhat.com> <20131118133133.GB31173@stefanha-thinkpad.hitronhub.home> <20131209121729.GA9611@stefanha-thinkpad.redhat.com> <52A71E14.6060907@gmail.com> <20140102085501.GA4922@stefanha-thinkpad.redhat.com> In-Reply-To: <20140102085501.GA4922@stefanha-thinkpad.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UwI9xQtGFL1HxnSXU03KXBxvReVCF0edN" Subject: Re: [Qemu-devel] [PATCH] HMP: snapshot_blkdev can not consider //root/sn1 and /root/sn1 as the same file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , lijun Cc: lcapitulino@redhat.com, qemu-devel@nongnu.org, Max Reitz This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UwI9xQtGFL1HxnSXU03KXBxvReVCF0edN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/02/2014 01:55 AM, Stefan Hajnoczi wrote: > Okay, I think we got side-tracked worrying about identifying identical > files. The problem in your example is more fundamental. >=20 > Here is what should have happened: >=20 > (qemu) snapshot_blkdev drive-scsi0-0-0 /mnt/dir2/sn1 > Could not create '/mnt/dir2/sn1': File exists >=20 > The file was previously created with the name /mnt/dir1/sn1. Running > snapshot_blkdev with /mnt/dir2/sn1 clobbers the file in your example. > This is bad because it corrupts the backing chain. >=20 > If QEMU uses O_CREAT | O_EXCL open(2) flags then creating the snapshot > file fails and the user will not mistakingly overwrite sn1. >=20 > However, QEMU does not use O_EXCL to create image files anywhere today > (qemu-img or QEMU monitor commands). Returning an error is not > backwards-compatible since existing users might rely on clobbering file= s > (there are safe cases where it can be useful). In fact, libvirt _requires_ that you clobber existing image files - when libvirt drives qemu with SELinux labelling enabled, then qemu cannot create files, but can only open already existing files that have already been labelled. So libvirt would need a way to avoid O_EXCL, even if you add it and make it default (and if you change the default to O_EXCL, you also need to provide a way to probe for the new switch that can bypass that new default). >=20 > We could add an option to commands that create files but I'm not sure i= f > it's worth the effort since human users who are most at risk probably > won't provide this new option... Changing to be safe by default and requiring a new option to allow reuse of existing files might be okay; but it will be backwards incompatible. Keeping existing behavior and requiring a new option to turn on O_EXCL for safety is back-compat friendly, but is the very situation where users aren't going to know they need to use the new option, so you've gained no safety. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --UwI9xQtGFL1HxnSXU03KXBxvReVCF0edN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSxWRSAAoJEKeha0olJ0NqnmsH/RTL0aemtAMYozSmMOACta6f +zMcMbf64onSbv8tnIBz5BTWQm7S1V163NjLhtc+yX7xjo02hO58hOcwgMh6suuX 4r9z5Mtcpya85F/lbo8Ioo1ocrA4LamtJWtNIJ33adTkYa5lUOUJyn4Jotuxugvx RgXmjjmC4R88xF8AdjiARFCFj0i5TqFwOzmZdZSU/sWt3U1zOpB7y2uMa3/OzJmj y8ebhOdI6n/qsjM4m/HtBxzIl7jYWQ60mkjLw8Wov9oC1qyqRDI9J7oPeVODME5l NOgqfJ95z3A7a11ETmb5V2f+fJ2rRplAdXfbsFKFvPSbpeIIMpGEjFcis+ngzZc= =ONmt -----END PGP SIGNATURE----- --UwI9xQtGFL1HxnSXU03KXBxvReVCF0edN--