From: Keiichi Watanabe <keiichiw@chromium.org>
To: linux-fsdevel@vger.kernel.org
Cc: Junichi Uekawa <uekawa@chromium.org>,
Takaya Saeki <takayas@chromium.org>,
tytso@mit.edu, Daniel Verkamp <dverkamp@chromium.org>
Subject: virtio-blk/ext4 error handling for host-side ENOSPC
Date: Mon, 17 Jun 2024 12:34:27 +0900 [thread overview]
Message-ID: <CAD90VcZybb0ZOVrhE-MqDPwEya8878uzA1RBwd68U7x4CufkTQ@mail.gmail.com> (raw)
Hi,
I'm using ext4 over virtio-blk for VMs, and I'd like to discuss the
situation where the host storage gets full.
Let's say you create a disk image file formatted with ext4 on the host
side as a sparse file and share it with the guest using virtio-blk.
When the host storage is full and the sparse file cannot be expanded
any further, the guest will know the error when it flushes disk
caches.
In the current implementation, the VMM's virtio-blk device returns
VIRTIO_BLK_S_IOERR, and the virtio-blk driver converts it to
BLK_STS_IOERR. Then, the ext4 module calls mapping_set_error for that
area.
However, the host's ENOSPC may be recoverable. For example, if a host
service periodically deletes cache files, it'd be nice if the guest
kernel can wait a while and then retry flushing.
So, I wonder if we can't have a special handling for host-side's
ENOSPC in virtio-blk and ext4.
My idea is like this:
First, (1) define a new error code, VIRTIO_BLK_S_ENOSPC, in
virtio-blk. Then, (2) if the guest file system receives this error
code, periodically retry flushing. We may want to make the retry limit
via a mount option or something.
What do you think of this idea? Also, has anything similar been attempted yet?
Thanks in advance.
Best,
Keiichi
next reply other threads:[~2024-06-17 3:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 3:34 Keiichi Watanabe [this message]
2024-06-18 8:33 ` virtio-blk/ext4 error handling for host-side ENOSPC Keiichi Watanabe
2024-06-19 13:57 ` Stefan Hajnoczi
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=CAD90VcZybb0ZOVrhE-MqDPwEya8878uzA1RBwd68U7x4CufkTQ@mail.gmail.com \
--to=keiichiw@chromium.org \
--cc=dverkamp@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).