On 17/09/20 18:44, Dmitry Fomichev wrote:
>
> Maxim, looks like you are on top of this problem and your approach sounds
> sensible too me. Just FYI, it is also possible to avoid using
> SG_GET_SG_TABLESIZE
> ioctl and rely entirely on sysfs, but the code gets a bit more complicated
> (see
On 17/09/20 15:16, Max Reitz wrote:
> So is this path ever taken, or can we just replace it all with the ioctl?
>
> (Before 867eccfed84, this function was used for all host devices, which
> might explain why the code even exists.)
Because 867eccfed84 is wrong. If you use /dev/sda* with SG_IO
g; qemu-
> de...@nongnu.org
> Subject: Re: [PATCH 1/2] file-posix: Correctly read max_segments of SG
> nodes
>
> On Thu, 2020-09-17 at 16:22 +0300, Maxim Levitsky wrote:
> > On Thu, 2020-09-17 at 15:16 +0200, Max Reitz wrote:
> > > On 12.08.20 00:51, Dmitry Fomichev wr
On Thu, 2020-09-17 at 16:22 +0300, Maxim Levitsky wrote:
> On Thu, 2020-09-17 at 15:16 +0200, Max Reitz wrote:
> > On 12.08.20 00:51, Dmitry Fomichev wrote:
> > > If scsi-generic driver is in use, an SG node can be specified in
> > > the command line in place of a regular SCSI device. In this
On Thu, 2020-09-17 at 15:16 +0200, Max Reitz wrote:
> On 12.08.20 00:51, Dmitry Fomichev wrote:
> > If scsi-generic driver is in use, an SG node can be specified in
> > the command line in place of a regular SCSI device. In this case,
> > sg_get_max_segments() fails to open max_segments entry in
On 12.08.20 00:51, Dmitry Fomichev wrote:
> If scsi-generic driver is in use, an SG node can be specified in
> the command line in place of a regular SCSI device. In this case,
> sg_get_max_segments() fails to open max_segments entry in sysfs
> because /dev/sgX is a character device. As the
If scsi-generic driver is in use, an SG node can be specified in
the command line in place of a regular SCSI device. In this case,
sg_get_max_segments() fails to open max_segments entry in sysfs
because /dev/sgX is a character device. As the result, the maximum
transfer size for the device may be
