From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34178 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZfNe-0005VL-98 for qemu-devel@nongnu.org; Fri, 16 Jul 2010 03:32:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZfNR-0005KL-Py for qemu-devel@nongnu.org; Fri, 16 Jul 2010 03:30:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45147) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZfNR-0005K8-I8 for qemu-devel@nongnu.org; Fri, 16 Jul 2010 03:30:33 -0400 Message-ID: <4C400A8F.609@redhat.com> Date: Fri, 16 Jul 2010 09:30:23 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Make default invocation of block drivers safer References: <1279123952-1576-1-git-send-email-aliguori@us.ibm.com> <20100714184311.GA9383@lst.de> <4C3E06DA.8080302@codemonkey.ws> <4C3F355E.3020800@codemonkey.ws> <4C3F4101.8070005@redhat.com> <4C3F4A89.6040909@codemonkey.ws> In-Reply-To: <4C3F4A89.6040909@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi , Christoph Hellwig Am 15.07.2010 19:51, schrieb Anthony Liguori: > On 07/15/2010 12:10 PM, Kevin Wolf wrote: >> Am 15.07.2010 18:20, schrieb Anthony Liguori: >> >>> I have another idea that I hope will solve the problem in a more >>> complete way. The fundamental issue is that it's impossible to probe >>> raw images reliably. We can probe qcow2, vmdk, etc but not raw. >>> >>> So, let's do the following: have raw_probe() always fail. Probing >>> shouldn't be a heuristic, it should be an absolute. We can't prove it's >>> a raw image, so we should always fail. >>> >>> To accomodate current use-cases with raw, let's introduce a new format >>> called "probed_raw". probed_raw's semantics will be the following: >>> >>> The signature of a probed_raw will be ~{'QFI\xfb', 'VMDK', 'COWD', >>> 'OOOM', ...}. If the signature is 'QRAW', then instead of reading the >>> first sector at offset 0, we read the first sector at offset LENGTH. If >>> the signature is 'QRAW', LENGTH is computed by calculating FILE_SIZE - 512. >>> >>> For probed_raw, write requests to sector 0 are checked. If the first >>> four bytes is an invalid probed_raw signature or QRAW, we write a QRAW >>> signature to file offset 0 and copy the first sector to the end of the >>> file redirecting reads and writes to the end of file. >>> >>> An approach like this has the following properties: >>> >>> 1) We can make the bdrv_probe check 100% reliable and return a boolean. >>> 2) In the cases where we known format=raw, none of this code is ever >>> invoked. >>> 3) probed_raw images usually look exactly like raw images in most cases >>> 4) In the degenerate cases, probe_raw images are still mountable in the >>> normal way. >>> 5) Even after the QRAW signature is applied, if the guest writes a valid >>> signature, we can truncate the file and make it appear as a normal raw >>> image. >>> >>> Christoph/Markus/Stefan, does this seem like a more reasonable approach? >>> >> I hope I may answer even though you didn't ask me. ;-) >> > > Heh, you just seemed more agreeable to the overall concept but obviously > I value your input :-) > >> This qraw format you introduce is a weird thing, mainly because >> depending on a signature the first sectors moves to somewhere completely >> else. >> >> If we want to introduce something, that's _almost_ raw and that we can >> use by default, what about doing something similar to what statically >> sized VHD images look like: take a raw image and attach a footer? > > I guess this could work provided that the image size was not a multiple > of 512 and that all other image formats guaranteed that they were a > multiple of 512 or they also had a footer. > > Makes me a little nervous though because it's easy to confuse an image > with a magic id and data at the end from an image with a special footer. Yeah, I guess you're right. It would be hard to tell apart a qcow2 image with a qraw footer in its data and a qraw image with a qcow2 header in it's data. Was just a thought... Kevin