From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36208 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZSaM-0008SZ-6S for qemu-devel@nongnu.org; Thu, 15 Jul 2010 13:51:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZSaK-0002Cv-0B for qemu-devel@nongnu.org; Thu, 15 Jul 2010 13:51:02 -0400 Received: from mail-ew0-f45.google.com ([209.85.215.45]:40670) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZSaJ-0002Co-PV for qemu-devel@nongnu.org; Thu, 15 Jul 2010 13:50:59 -0400 Received: by ewy5 with SMTP id 5so417847ewy.4 for ; Thu, 15 Jul 2010 10:50:58 -0700 (PDT) Message-ID: <4C3F4A89.6040909@codemonkey.ws> Date: Thu, 15 Jul 2010 12:51:05 -0500 From: Anthony Liguori 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> In-Reply-To: <4C3F4101.8070005@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi , Christoph Hellwig 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. Regards, Anthony Liguori > With > this approach you should still be able to mount it in the host etc. We > could automatically append this footer when opening a probed qraw image r/w. > D > Kevin >