From: Stefan Hajnoczi <stefanha@redhat.com>
To: Keiichi Watanabe <keiichiw@chromium.org>
Cc: dverkamp@chromium.org, linux-fsdevel@vger.kernel.org,
takayas@chromium.org, tytso@mit.edu, uekawa@chromium.org
Subject: Re: virtio-blk/ext4 error handling for host-side ENOSPC
Date: Wed, 19 Jun 2024 09:57:32 -0400 [thread overview]
Message-ID: <20240619135732.GA57867@fedora.redhat.com> (raw)
In-Reply-To: <CAD90Vcbt-GE6gP3tNZAUEd8-eP4NVUfET51oGA-CVvcH4=EAAA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]
> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-06-19 13:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 3:34 virtio-blk/ext4 error handling for host-side ENOSPC Keiichi Watanabe
2024-06-18 8:33 ` Keiichi Watanabe
2024-06-19 13:57 ` Stefan Hajnoczi [this message]
2024-06-28 3:29 ` Keiichi Watanabe
2024-07-11 6:02 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240619135732.GA57867@fedora.redhat.com \
--to=stefanha@redhat.com \
--cc=dverkamp@chromium.org \
--cc=keiichiw@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=takayas@chromium.org \
--cc=tytso@mit.edu \
--cc=uekawa@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).