It is safe to execute a fallocate on a opened and in-use file?
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.
Signature · 5 lines
Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: [email protected] - [email protected] GPG public key ID: FF5F32A8
Quoted 20 lines · 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.
Quoted 2 lines
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
Quoted 16 lines
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.
Signature · 9 lines
Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: [email protected] - [email protected] GPG public key ID: FF5F32A8 -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Il 10-06-2017 23:18 Darrick J. Wong ha scritto:
Quoted 3 lines
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?
Quoted 3 lines
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.
Quoted 18 lines
--D
Quoted 16 lines
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: [email protected] - [email protected]
GPG public key ID: FF5F32A8
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 5 lines
Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: [email protected] - [email protected] GPG public key ID: FF5F32A8