On Thu, 2010-12-23 at 00:49 +0100, Alexander Graf wrote:
>
> Congratulations for finding lots of Linux bugs :). Look at it from
> that way: You'll most likely be the very first person actually using
> sg properly. So after you're done, others won't have to fix it :).
Hahah, I doubt it :-) Makes m
On 23.12.2010, at 00:44, Benjamin Herrenschmidt wrote:
> On Thu, 2010-12-23 at 00:39 +0100, Alexander Graf wrote:
>> This all belongs in the block layer. If you create a call back
>> function or property in the block struct, windows can implement its
>> own limits when someone sits down to implem
On Thu, 2010-12-23 at 00:39 +0100, Alexander Graf wrote:
> This all belongs in the block layer. If you create a call back
> function or property in the block struct, windows can implement its
> own limits when someone sits down to implement SG_IO on Windows.
Right and we do have "generic" ways it
On 23.12.2010, at 00:35, Benjamin Herrenschmidt wrote:
> On Thu, 2010-12-23 at 00:23 +0100, Alexander Graf wrote:
>>> The non working compat ioctl is one, the fact that "sg" has
>>> no /sys/class/block (or /sys/block) entries is another, etc... Ie,
>> we
>>> are faced with a problem with Linux no
On Thu, 2010-12-23 at 00:23 +0100, Alexander Graf wrote:
> > The non working compat ioctl is one, the fact that "sg" has
> > no /sys/class/block (or /sys/block) entries is another, etc... Ie,
> we
> > are faced with a problem with Linux not exposing those informations
> in
> > an easy to retrieve w
On 22.12.2010, at 22:59, Benjamin Herrenschmidt wrote:
> On Wed, 2010-12-22 at 14:54 +0100, Hannes Reinecke wrote:
>
>> Well, sort of. 'sg' doesn't have any block queue limits directly as the
>> block queue is attached to the block device (surprise, surprise :-).
>> But nevertheless any commands
On 22.12.2010, at 14:27, Christoph Hellwig wrote:
> On Wed, Dec 22, 2010 at 02:54:54PM +0100, Hannes Reinecke wrote:
>> Most modern HBAs are using separate codepaths for streaming/block I/O
>> anyway,
>
> That's not true at all. Every normal HBA justs passes normal SCSI
> commands to the SCSI t
On Wed, 2010-12-22 at 14:27 +0100, Christoph Hellwig wrote:
> On Wed, Dec 22, 2010 at 02:54:54PM +0100, Hannes Reinecke wrote:
> > Most modern HBAs are using separate codepaths for streaming/block I/O
> > anyway,
>
> That's not true at all. Every normal HBA justs passes normal SCSI
> commands to
On Wed, 2010-12-22 at 14:54 +0100, Hannes Reinecke wrote:
> Well, sort of. 'sg' doesn't have any block queue limits directly as the
> block queue is attached to the block device (surprise, surprise :-).
> But nevertheless any commands send via SG_IO are being placed on the
> block queue, hence the
On Wed, Dec 22, 2010 at 02:54:54PM +0100, Hannes Reinecke wrote:
> Most modern HBAs are using separate codepaths for streaming/block I/O
> anyway,
That's not true at all. Every normal HBA justs passes normal SCSI
commands to the SCSI targets. It's just raid adapters that take special
commands, a
On 12/21/2010 11:05 PM, Benjamin Herrenschmidt wrote:
>>> So back to square 1 ... my vscsi (and virtio-blk too btw) can
>>> technically pass a max size to the guest, but we don't have a way to
>>> interrogate scsi-generic (and the underlying block driver) which is the
>>> main issue (that plus the
> > So back to square 1 ... my vscsi (and virtio-blk too btw) can
> > technically pass a max size to the guest, but we don't have a way to
> > interrogate scsi-generic (and the underlying block driver) which is the
> > main issue (that plus the fact that the ioctl seems to be broken in
> > "compat"
On 12/21/2010 04:52 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2010-12-21 at 14:38 +1100, ronnie sahlberg wrote:
>> Ben,
>>
>> Since it is a scsi device you can try the Inquiry command with
>> pagecode 0xb0 : Block Limit VPD Page.
>> That pages show optimal and maximum request sizes.
>>
>> This
On Tue, 2010-12-21 at 14:38 +1100, ronnie sahlberg wrote:
> Ben,
>
> Since it is a scsi device you can try the Inquiry command with
> pagecode 0xb0 : Block Limit VPD Page.
> That pages show optimal and maximum request sizes.
>
> This is for SBC, in the Vital Product Data chapter.
>
> Unfortuna
Ben,
Since it is a scsi device you can try the Inquiry command with
pagecode 0xb0 : Block Limit VPD Page.
That pages show optimal and maximum request sizes.
This is for SBC, in the Vital Product Data chapter.
Unfortunately this page is not mandatory so some devices might not
understand it. :-(
Hi folks !
There's an odd problem I've encountered with my scsi host (basically an
powerpc "vscsi" compatible with IBM PAPR).
When using /dev/sg (ie, scsi-generic), there seem to be no way I can
find to retrieve the underlying driver's max request transfer size.
This can normally be obtained wit
16 matches
Mail list logo
