qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-block] [PATCH 0/3] block/file-posix: File locking


From: Max Reitz
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 0/3] block/file-posix: File locking during creation
Date: Mon, 23 Apr 2018 17:56:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 2018-04-23 15:19, Alberto Garcia wrote:
> On Sat 21 Apr 2018 12:09:10 AM CEST, Max Reitz wrote:
>> Currently we do not take permissions on a file while it is being
>> created.  That is a bit sad.  The simplest way to test this is the
>> following:
>>
>>     $ qemu-img create -f qcow2 foo.qcow2 64M
>>     Formatting 'foo.qcow2', fmt=qcow2 size=67108864 cluster_size=65536 
>> lazy_refcounts=off refcount_bits=16
>>     $ qemu-img convert -f qcow2 -O qcow2 foo.qcow2 foo.qcow2
>>     qemu-img: foo.qcow2: error while converting qcow2: Failed to get "write" 
>> lock
>>     Is another process using the image?
>>     $ qemu-img info foo.qcow2
>>     image: foo.qcow2
>>     file format: raw
>>     virtual size: 0 (0 bytes)
>>     disk size: 0
> 
> Not quite the same problem, but here's another example of QEMU creating
> an image before checking if it can be created:
> 
> $ qemu-img create -o cluster_size=2M -f qcow2 img.qcow2 7E
> Formatting 'img.qcow2', fmt=qcow2 size=8070450532247928832 encryption=off 
> cluster_size=2097152 lazy_refcounts=off refcount_bits=16
> qemu-img: img.qcow2: The image size is too large for file format 'qcow2' (try 
> using a larger cluster size)
> 
> $ qemu-img info img.qcow2 
> image: img.qcow2
> file format: qcow2
> virtual size: 0 (0 bytes)
> disk size: 6.0M
> cluster_size: 2097152
> Format specific information:
>     compat: 1.1
>     lazy refcounts: false
>     refcount bits: 16
>     corrupt: false
> 
> Berto

Actually a very different problem, and I think we are not going to
change this behavior -- especially considering the direction
blockdev-create is taking (that is, separating protocol file creation
and formatting).

The main reason why it's a different problem, though, is because it
doesn't mean any data loss.  You just get a stale file lying around.

(You could argue that in any case the file should at least be a raw file
of size 0, because the qcow2 driver should not start formatting until it
has checked all options, but, well...  I don't know how that would help
anyone.)

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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