It is safe to execute a fallocate on a opened and in-use file?

It is safe to execute a fallocate on a opened and in-use file?

[Gionatan Danti]

Hi all,
I would like to understand if it is safe, or not, to execute a fallocate 
on a opened an possibly in-use file.

Scenario: a running Qemu/KVM virtual machine that need its RAW-image 
vdisk to be expanded.

I normally stop the virtual machine and issue "fallocate -l <newsize> 
<filename>", then I restart it. I wonder if I can skip the stop/start 
phases, going directly for the fallocate.

Reasoning on the question, I naively think that fallocating when the VM 
is writing on the file has the potential to cause corruption, due to 
this racing condition:
- I execute fallocate;
- the filesystem begins searching for to-be-allocated chunks, and finds 
one;
- the VM suddenly writes to the very same block found on the previous 
step;
- the filesystem continue allocating the previos block, accidentally 
discarding the just-written data.

This scenario can be avoided if the relevant critical path are protected 
with mutex (or equivalent structures). Is it the case?

In general, how to consider concurrent metadata updates for the same 
file/block? Should I expect file corruption, similar to concurrently 
writing data to the same file/block?

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

Re: It is safe to execute a fallocate on a opened and in-use file?

[Darrick J. Wong]

On Sat, Jun 10, 2017 at 08:09:40PM +0200, Gionatan Danti wrote:
> Hi all,
> I would like to understand if it is safe, or not, to execute a fallocate on
> a opened an possibly in-use file.
> 
> Scenario: a running Qemu/KVM virtual machine that need its RAW-image vdisk
> to be expanded.
> 
> I normally stop the virtual machine and issue "fallocate -l <newsize>
> <filename>", then I restart it. I wonder if I can skip the stop/start
> phases, going directly for the fallocate.
> 
> Reasoning on the question, I naively think that fallocating when the VM is
> writing on the file has the potential to cause corruption, due to this
> racing condition:
> - I execute fallocate;
> - the filesystem begins searching for to-be-allocated chunks, and finds one;
> - the VM suddenly writes to the very same block found on the previous step;
> - the filesystem continue allocating the previos block, accidentally
> discarding the just-written data.
> 
> This scenario can be avoided if the relevant critical path are protected
> with mutex (or equivalent structures). Is it the case?

Yes, writes and fallocates are serialized with each other to avoid corruption.

How do you get qemu to announce the disk size change the guest?

--D

> In general, how to consider concurrent metadata updates for the same
> file/block? Should I expect file corruption, similar to concurrently writing
> data to the same file/block?
> 
> Thanks.
> 
> -- 
> Danti Gionatan
> Supporto Tecnico
> Assyoma S.r.l. - www.assyoma.it
> email: g.danti@assyoma.it - info@assyoma.it
> GPG public key ID: FF5F32A8
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: It is safe to execute a fallocate on a opened and in-use file?

[Gionatan Danti]

Il 10-06-2017 23:18 Darrick J. Wong ha scritto:
> 
> Yes, writes and fallocates are serialized with each other to avoid 
> corruption.
> 

Great. Is this behavior valid for all filesystem (ie: it is implemented 
on the VFS layer) or is it filesystem-specific?

> 
> How do you get qemu to announce the disk size change the guest?
> 

You can do that via virsh blockresize which, in turn, taps on qemu 
monitor (which can even be used directly, without libvirt intervention). 
 From virsh man page:

"blockresize domain path size
Resize a block device of domain while the domain is running, path 
specifies the absolute path of the block device; it corresponds to a 
unique target name (<target dev='name'/>) or source file (<source 
file='name'/>) for one of the disk devices attached to domain (see also 
domblklist for listing these names)."

Thanks.

> --D
> 
>> In general, how to consider concurrent metadata updates for the same
>> file/block? Should I expect file corruption, similar to concurrently 
>> writing
>> data to the same file/block?
>> 
>> Thanks.
>> 
>> --
>> Danti Gionatan
>> Supporto Tecnico
>> Assyoma S.r.l. - www.assyoma.it
>> email: g.danti@assyoma.it - info@assyoma.it
>> GPG public key ID: FF5F32A8
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-xfs" 
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8