> What do you think of this idea? Also, has anything similar been attempted yet? Hi Keiichi, Yes, there is an existing approach that is related but not identical to what you are exploring: QEMU has an option to pause the guest and raise a notification to the management tool that ENOSPC has been reached. The guest is unable to resolve ENOSPC itself and guest applications are likely to fail the disk becomes unavailable, hence the guest is simply paused. In systems that expect to hit this condition, this pause behavior can be combined with an early notification when a free space watermark is hit. This way guest are almost never paused because free space can be added before ENOSPC is reached. QEMU has a write watermark feature that works well on top of qcow2 images (they grow incrementally so it's trivial to monitor how much space is being consumed). I wanted to share this existing approach in case you think it would work nicely for your use case. The other thought I had was: how does the new ENOSPC error fit into the block device model? Hopefully this behavior is not virtio-blk-specific behavior but rather something general that other storage protocols like NVMe and SCSI support too. That way file systems can handle this in a generic fashion. The place I would check is Logical Block Provisioning in SCSI and NVMe. Perhaps there are features in these protocols for reporting low resources? (Sorry, I didn't have time to check.) Stefan
Attachment:
signature.asc
Description: PGP signature
