From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: nsoffer@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org,
mlevitsk@redhat.com
Subject: Re: [PATCH v2 2/6] file-posix: try BLKSECTGET on block devices too, do not round to power of 2
Date: Thu, 27 May 2021 17:51:32 +0200 [thread overview]
Message-ID: <YK/ABCylKztcARUz@merkur.fritz.box> (raw)
In-Reply-To: <20210524163645.382940-3-pbonzini@redhat.com>
Am 24.05.2021 um 18:36 hat Paolo Bonzini geschrieben:
> bs->sg is only true for character devices, but block devices can also
> be used with scsi-block and scsi-generic. Unfortunately BLKSECTGET
> returns bytes in an int for /dev/sgN devices, and sectors in a short
> for block devices, so account for that in the code.
>
> The maximum transfer also need not be a power of 2 (for example I have
> seen disks with 1280 KiB maximum transfer) so there's no need to pass
> the result through pow2floor.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Looks like this is more or less a revert of Maxim's commit 867eccfe. If
this is what we want, should this old commit be mentioned in one way or
another in the commit message?
Apparently the motivation for Maxim's patch was, if I'm reading the
description correctly, that it affected non-sg cases by imposing
unnecessary restrictions. I see that patch 1 changed the max_iov part so
that it won't affect non-sg cases any more, but max_transfer could still
be more restricted than necessary, no?
For convenience, the bug report fixed with that patch is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1647104
Are we really trying to describe different things (limits for SG_IO and
for normal I/O) in one value with max_transfer, even though it could be
two different numbers for the same block device?
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 59c889d5a7..e5ef006aee 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -1149,22 +1149,27 @@ static void raw_reopen_abort(BDRVReopenState *state)
> s->reopen_state = NULL;
> }
>
> -static int sg_get_max_transfer_length(int fd)
> +static int sg_get_max_transfer_length(int fd, struct stat *st)
This is now a misnomer. Should we revert to the pre-867eccfe name
hdev_get_max_transfer_length()?
> {
> #ifdef BLKSECTGET
> - int max_bytes = 0;
> -
> - if (ioctl(fd, BLKSECTGET, &max_bytes) == 0) {
> - return max_bytes;
> + if (S_ISBLK(st->st_mode)) {
> + unsigned short max_sectors = 0;
> + if (ioctl(fd, BLKSECTGET, &max_sectors) == 0) {
> + return max_sectors * 512;
> + }
> } else {
> - return -errno;
> + int max_bytes = 0;
> + if (ioctl(fd, BLKSECTGET, &max_bytes) == 0) {
> + return max_bytes;
> + }
> }
> + return -errno;
> #else
> return -ENOSYS;
> #endif
> }
>
> -static int sg_get_max_segments(int fd)
> +static int sg_get_max_segments(int fd, struct stat *st)
Same for this one.
> {
> #ifdef CONFIG_LINUX
> char buf[32];
> @@ -1173,15 +1178,9 @@ static int sg_get_max_segments(int fd)
> int ret;
> int sysfd = -1;
> long max_segments;
> - struct stat st;
> -
> - if (fstat(fd, &st)) {
> - ret = -errno;
> - goto out;
> - }
>
> sysfspath = g_strdup_printf("/sys/dev/block/%u:%u/queue/max_segments",
> - major(st.st_rdev), minor(st.st_rdev));
> + major(st->st_rdev), minor(st->st_rdev));
> sysfd = open(sysfspath, O_RDONLY);
> if (sysfd == -1) {
> ret = -errno;
> @@ -1218,15 +1217,20 @@ out:
> static void raw_refresh_limits(BlockDriverState *bs, Error **errp)
> {
> BDRVRawState *s = bs->opaque;
> + struct stat st;
> +
> + if (fstat(s->fd, &st)) {
> + return;
Don't we want to set errp? Or do you intentionally ignore the error?
> + }
>
> - if (bs->sg) {
> - int ret = sg_get_max_transfer_length(s->fd);
> + if (bs->sg || S_ISBLK(st.st_mode)) {
> + int ret = sg_get_max_transfer_length(s->fd, &st);
>
> if (ret > 0 && ret <= BDRV_REQUEST_MAX_BYTES) {
> - bs->bl.max_transfer = pow2floor(ret);
> + bs->bl.max_transfer = ret;
> }
>
> - ret = sg_get_max_segments(s->fd);
> + ret = sg_get_max_segments(s->fd, &st);
> if (ret > 0) {
> bs->bl.max_iov = ret;
> }
Kevin
next prev parent reply other threads:[~2021-05-27 15:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-24 16:36 [PATCH v2 0/6] block: file-posix queue Paolo Bonzini
2021-05-24 16:36 ` [PATCH v2 1/6] scsi-generic: pass max_segments via max_iov field in BlockLimits Paolo Bonzini
2021-05-24 16:36 ` [PATCH v2 2/6] file-posix: try BLKSECTGET on block devices too, do not round to power of 2 Paolo Bonzini
2021-05-27 15:51 ` Kevin Wolf [this message]
2021-05-27 20:14 ` Paolo Bonzini
2021-05-31 13:59 ` Kevin Wolf
2021-05-31 16:36 ` Paolo Bonzini
2021-05-24 16:36 ` [PATCH v2 3/6] file-posix: fix max_iov for /dev/sg devices Paolo Bonzini
2021-05-24 16:36 ` [PATCH v2 4/6] block: feature detection for host block support Paolo Bonzini
2021-05-24 16:36 ` [PATCH v2 5/6] block: check for sys/disk.h Paolo Bonzini
2021-05-24 16:36 ` [PATCH v2 6/6] block: detect DKIOCGETBLOCKCOUNT/SIZE before use Paolo Bonzini
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=YK/ABCylKztcARUz@merkur.fritz.box \
--to=kwolf@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=nsoffer@redhat.com \
--cc=pbonzini@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 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).