public inbox for virtio-comment@lists.linux.dev
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Keiichi Watanabe <keiichiw@chromium.org>,
	"virtio-comment@lists.linux.dev" <virtio-comment@lists.linux.dev>,
	"uekawa@chromium.org" <uekawa@chromium.org>,
	"takayas@chromium.org" <takayas@chromium.org>,
	"dverkamp@chromium.org" <dverkamp@chromium.org>,
	"tytso@google.com" <tytso@google.com>
Subject: Re: [PATCH 1/1] virito-blk: Support NOSPC error
Date: Tue, 18 Jun 2024 08:18:32 -0400	[thread overview]
Message-ID: <20240618081240-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB54811C1FD9D666D13077E817DCCE2@PH0PR12MB5481.namprd12.prod.outlook.com>

On Tue, Jun 18, 2024 at 11:54:10AM +0000, Parav Pandit wrote:
> Hi Keiichi,
> 
> > From: Keiichi Watanabe <keiichiw@chromium.org>
> > Sent: Tuesday, June 18, 2024 1:49 PM
> > To: virtio-comment@lists.linux.dev
> > Cc: keiichiw@chromium.org; uekawa@chromium.org;
> > takayas@chromium.org; dverkamp@chromium.org; tytso@google.com
> > Subject: [PATCH 1/1] virito-blk: Support NOSPC error
> > 
> > Add a status code to indicate that the storage is full on the virtio-blk device
> > side.
> > 
> > This is useful in scenarios where a virtio-blk disk image is provided on a sparse
> > disk and the host storage is full.
> > In this scenario, the driver cannot create a new file to the disk image because
> > the sparse disk cannot be expanded.
> > However, if the host have a service that clean up host stroage regularly by
> s/stroage/storage
> 
> > wiping cache files, the guest may want to retry the request.
> > For this type of special handling, this error should have a separate error code
> > in virito-blk.
> > 
> > Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
> > ---
> >  device-types/blk/description.tex | 13 ++++++++-----
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/device-types/blk/description.tex b/device-types/blk/description.tex
> > index f04c932..5a34bd5 100644
> > --- a/device-types/blk/description.tex
> > +++ b/device-types/blk/description.tex
> > @@ -532,12 +532,14 @@ \subsection{Device Operation}\label{sec:Device
> > Types / Block Device / Device Ope
> > 
> >  The final \field{status} byte is written by the device: either  VIRTIO_BLK_S_OK
> > for success, VIRTIO_BLK_S_IOERR for device or driver -error or
> > VIRTIO_BLK_S_UNSUPP for a request unsupported by device:
> > +error, VIRTIO_BLK_S_UNSUPP for a request unsupported by device or
> > +VIRTIO_BLK_S_NOSPC for an error that device doesn't have enough space.
> > 
> >  \begin{lstlisting}
> >  #define VIRTIO_BLK_S_OK        0
> >  #define VIRTIO_BLK_S_IOERR     1
> >  #define VIRTIO_BLK_S_UNSUPP    2
> > +#define VIRTIO_BLK_S_NOSPC     7
> >  \end{lstlisting}
> > 
> With recent work from Michael and others in admin command area,
> 
> we try to use existing Linux error codes referenced by the spec [errno] in the "Normative References" section.
> So for this new error code also, it would be good to reuse value 28 (instead of 7) of [2].
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/errno-base.h
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/errno-base.h#n32


The problem with this idea, is that e.g. EIO is 5 which is already used
up by zone flags. And errno values go beyond 127 so with a single byte
status we can't reserve a bit for that, either.


> >  The status of individual segments is indeterminate when a discard or write
> > zero @@ -567,10 +569,11 @@ \subsection{Device
> > Operation}\label{sec:Device Types / Block Device / Device Ope  Requests of
> > type VIRTIO_BLK_T_OUT, VIRTIO_BLK_T_ZONE_OPEN,
> > VIRTIO_BLK_T_ZONE_CLOSE, VIRTIO_BLK_T_ZONE_FINISH,
> > VIRTIO_BLK_T_ZONE_APPEND,  VIRTIO_BLK_T_ZONE_RESET or
> > VIRTIO_BLK_T_ZONE_RESET_ALL may be completed by the -device with
> > VIRTIO_BLK_S_OK, VIRTIO_BLK_S_IOERR or VIRTIO_BLK_S_UNSUPP -
> > \field{status}, or, additionally, with  VIRTIO_BLK_S_ZONE_INVALID_CMD, -
> > VIRTIO_BLK_S_ZONE_UNALIGNED_WP,
> > VIRTIO_BLK_S_ZONE_OPEN_RESOURCE or -
> > VIRTIO_BLK_S_ZONE_ACTIVE_RESOURCE ZBD-specific status codes.
> > +device with VIRTIO_BLK_S_OK, VIRTIO_BLK_S_IOERR,
> > VIRTIO_BLK_S_UNSUPP or
> > +VIRTIO_BLK_S_NOSPC \field{status}, or, additionally, with
> > +VIRTIO_BLK_S_ZONE_INVALID_CMD,
> > VIRTIO_BLK_S_ZONE_UNALIGNED_WP,
> > +VIRTIO_BLK_S_ZONE_OPEN_RESOURCE or
> > VIRTIO_BLK_S_ZONE_ACTIVE_RESOURCE
> > +ZBD-specific status codes.
> > 
> >  Besides the request status, VIRTIO_BLK_T_ZONE_APPEND requests return the
> > starting sector of the appended data back to the driver. For this reason,
> > --
> > 2.45.2.627.g7a2c4fd464-goog
> > 
> 


  reply	other threads:[~2024-06-18 12:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18  8:18 [PATCH 0/1] A new virtio-blk error code for host-side ENOSPC Keiichi Watanabe
2024-06-18  8:18 ` [PATCH 1/1] virito-blk: Support NOSPC error Keiichi Watanabe
2024-06-18 10:58   ` Michael S. Tsirkin
2024-06-18 12:14     ` Michael S. Tsirkin
2024-06-18 11:54   ` Parav Pandit
2024-06-18 12:18     ` Michael S. Tsirkin [this message]
2024-06-19 13:09       ` Keiichi Watanabe
2024-07-03 22:54         ` Michael S. Tsirkin
2024-07-04  9:46           ` Parav Pandit
2024-07-04  8:04         ` Michael S. Tsirkin
2024-07-04  9:52           ` Parav Pandit
2024-07-04 11:19             ` Michael S. Tsirkin
2024-07-04 16:12               ` Parav Pandit
2024-06-18 10:54 ` [PATCH 0/1] A new virtio-blk error code for host-side ENOSPC Michael S. Tsirkin
2024-06-19 13:06   ` Keiichi Watanabe
2024-06-19 14:00 ` Stefan Hajnoczi
2024-07-03 22:55   ` Michael S. Tsirkin
2024-07-09 12:14     ` Stefan Hajnoczi
2024-07-09 13:31       ` Michael S. Tsirkin
2024-07-11  9:16         ` 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=20240618081240-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=dverkamp@chromium.org \
    --cc=keiichiw@chromium.org \
    --cc=parav@nvidia.com \
    --cc=takayas@chromium.org \
    --cc=tytso@google.com \
    --cc=uekawa@chromium.org \
    --cc=virtio-comment@lists.linux.dev \
    /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