All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org,
	"Markus Armbruster" <armbru@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Max Reitz" <mreitz@redhat.com>
Subject: Re: [PATCH v3 4/4] block: switch to use qemu_open/qemu_create for improved errors
Date: Fri, 24 Jul 2020 15:26:18 +0100	[thread overview]
Message-ID: <20200724142618.GE3146350@redhat.com> (raw)
In-Reply-To: <18b793fa-bb7f-f2a2-62de-f6b396f5e93f@redhat.com>

On Fri, Jul 24, 2020 at 09:10:00AM -0500, Eric Blake wrote:
> On 7/24/20 8:25 AM, Daniel P. Berrangé wrote:
> > Currently at startup if using cache=none on a filesystem lacking
> > O_DIRECT such as tmpfs, at startup QEMU prints
> > 
> > qemu-system-x86_64: -drive file=/tmp/foo.img,cache=none: file system may not support O_DIRECT
> > qemu-system-x86_64: -drive file=/tmp/foo.img,cache=none: Could not open '/tmp/foo.img': Invalid argument
> 
> Are we trying to get this in 5.1?

It is probably verging on too late to justify for the rc

> 
> > 
> > while at QMP level the hint is missing, so QEMU reports just
> > 
> >    "error": {
> >        "class": "GenericError",
> >        "desc": "Could not open '/tmp/foo.img': Invalid argument"
> >    }
> > 
> > which is close to useless for the end user trying to figure out what
> > they did wrong.
> > 
> > With this change at startup QEMU prints
> > 
> > qemu-system-x86_64: -drive file=/tmp/foo.img,cache=none: Unable to open '/tmp/foo.img' flags 0x4000: filesystem does not support O_DIRECT
> > 
> > while at the QMP level QEMU reports a massively more informative
> > 
> >    "error": {
> >       "class": "GenericError",
> >       "desc": "Unable to open '/tmp/foo.img' flags 0x4002: filesystem does not support O_DIRECT"
> >    }
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> 
> > @@ -3335,7 +3331,7 @@ static bool setup_cdrom(char *bsd_path, Error **errp)
> >       for (index = 0; index < num_of_test_partitions; index++) {
> >           snprintf(test_partition, sizeof(test_partition), "%ss%d", bsd_path,
> >                    index);
> > -        fd = qemu_open_old(test_partition, O_RDONLY | O_BINARY | O_LARGEFILE);
> > +        fd = qemu_open(test_partition, O_RDONLY | O_BINARY | O_LARGEFILE, NULL);
> 
> Should qemu_open() always be setting O_BINARY|O_LARGEFILE, without us having
> to worry about them at each caller?  But that's a separate cleanup.

Hmm, I think both of these are dead code.

IIUC, O_BINARY  is a no-op on any platform except Windows, and this is
file-posix.c, and O_LARGEFILE is a no-op, if you have _FILE_OFFSET_BITS=64,
which we hardcode.

> Reviewed-by: Eric Blake <eblake@redhat.com>

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2020-07-24 14:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24 13:25 [PATCH v3 0/4] block: improve error reporting for unsupported O_DIRECT Daniel P. Berrangé
2020-07-24 13:25 ` [PATCH v3 1/4] util: rename qemu_open() to qemu_open_old() Daniel P. Berrangé
2020-07-24 13:54   ` Eric Blake
2020-07-24 14:24   ` Philippe Mathieu-Daudé
2020-07-24 13:25 ` [PATCH v3 2/4] util: introduce qemu_open and qemu_create with error reporting Daniel P. Berrangé
2020-07-24 14:02   ` Eric Blake
2020-07-24 14:33   ` Philippe Mathieu-Daudé
2020-07-27  7:37   ` Markus Armbruster
2020-07-24 13:25 ` [PATCH v3 3/4] util: give a specific error message when O_DIRECT doesn't work Daniel P. Berrangé
2020-07-24 14:05   ` Eric Blake
2020-07-24 13:25 ` [PATCH v3 4/4] block: switch to use qemu_open/qemu_create for improved errors Daniel P. Berrangé
2020-07-24 14:10   ` Eric Blake
2020-07-24 14:26     ` Daniel P. Berrangé [this message]
2020-07-24 14:37   ` Philippe Mathieu-Daudé
2020-07-27  7:43   ` Markus Armbruster

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=20200724142618.GE3146350@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.