From: Boaz Harrosh <ooo@electrozaur.com>
To: dgilbert@interlog.com, Christoph Hellwig <hch@lst.de>,
Jens Axboe <axboe@kernel.dk>,
martin.petersen@oracle.com,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Nathan Chancellor <natechancellor@gmail.com>,
osd-dev@open-osd.org, linux-scsi@vger.kernel.org,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: remove exofs and the T10 OSD code V2
Date: Thu, 1 Nov 2018 02:03:41 +0200 [thread overview]
Message-ID: <a711a25d-e866-aabe-95c8-53bcd212a173@electrozaur.com> (raw)
In-Reply-To: <57a73f2b-29be-6301-2f4b-df582b7d23ff@interlog.com>
On 31/10/18 23:10, Douglas Gilbert wrote:
> On 2018-10-31 4:57 p.m., Boaz Harrosh wrote:
>> On 30/10/18 09:45, Christoph Hellwig wrote:
>>> On Mon, Oct 29, 2018 at 02:42:12PM -0600, Jens Axboe wrote:
>>>> LGTM, for both:
>>>
>>> I also have this one on top as requested by Martin. The core block
>>> bidi support is unfortunately also used by bsg-lib, although it is
>>> not anywhere near as invasive. But that is another argument for
>>> looking into moving bsg-lib away from using block queues..
>>>
>>
>> BUT this patch is very very wrong.
>>
>> Totally apart from T10-OSD and its use in the field. Support for scsi BIDI
>> commands is not exclusive to T10-OSD at all. Even the simple scsi-array
>> command-set has BIDI operations defined. for example the write-return-xor
>> and so on.
>>
>> Also some private administrative CDBs of some vendor devices uses SCSI-BIDI.
>> So this patch just broke some drivers. (User-mode apps use bsg pass through)
>>
>> Also you might (try hard and) remove all usage of scsi-bidi as an initiator
>> from the Linux Kernel. But what about target mode. As a target we have supported
>> on the wire bidi protocols like write-return-xor and others for a long time.
>> Are you willing to silently break all these setups in the field on the next update?
>> Are you so sure these are never used?
>>
>> PLEASE, I beg of you guys. Do not remove SCSI-BIDI. It is a cry of generations.
>>
>> And I think by the rules of Linus, as far as target mode. You are not allowed
>> to break users in this way.
>
> Hi,
> I'm in the process of rebuilding the sg driver with the following goals:
>
> - undo 20 years of road wear, some of which is caused by literally
> hundreds of "laparoscopic" patches that gradually ruin a driver,
> at least from the maintainer's viewpoint. Comments that once made
> sense become cryptic or just nonsense; naming schemes that
> obliterate variable names to the extent that a random name
> generator would be easier to follow; and just plain broken code.
> For example, why sort out the existing locking at a particular
> level when you can add a new lock in a completely non-orthogonal
> way? [Yes, I looking at you, google.] Anyway, my first cut at this
> is out there (on the linux-scsi list, see: "[PATCH v3 0/8] sg:
> major cleanup, remove max_queue limit"). Not much new there,
> unless you look very closely
>
> - the next step is to add to the sg driver async SCSI command
> capability based on the sg_io_v4 structure previously only used
> by the bsg driver and now removed from bsg. The main advantage
> of the sg_io_v4 structure over previous pass-through interface
> attempts is the support of SCSI bidi commands
>
> - as part of this effort introduce two new ioctls: SG_IOSUBMIT and
> SG_IORECEIVE to replace the write()/read() technique currently
> in use (since Linux 1.0 in 1992). The write()/read() technique
> seems to be responsible for various security folks losing clumps
> of their hair. One advantage of ioctls, as Alan Cox pointed out,
> is the ability to write to and read back from the kernel in a way
> that is naturally synchronized. [Actually, those security folks
> shouldn't look too closely at sg_read() in that respect.]
>
> In discussions with several folks who are on the T10 committee, I
> wondered why there was no READ GATHERED command (there has been a
> WRITE SCATTERED for 2 years). The answer was lack of interest ***,
> plus the difficultly of implementation. You see, READ GATHERED needs
> to send a scatter gather list to the device and get the corresponding
> data back (as a linear array). And that requires either:
> a) bidi commands (scatter gather list in the data-out, corresponding
> "read" data in the data-in), or
> b) loooong SCSI commands, up to around 256 bytes long in which the
> sgat list is the latter part of that command
>
> And the T10 folks say neither of those options is well supported or
> is expensive.
It is supported in Linux scsi/osd driver is a proof of that. And expensive
it is not. I have demonstrated the ability to saturate a 10G link over
a raid of devices from a single writer. In OSD everything is bidi.
> I'm guessing they are referring to Linux and Windows.
> I haven't argued much beyond that point, but it looks like a bit of
> a chicken and egg situation.
>
>
> Don't know too much about the T10 OSD stuff. But I can see that it
> uses both long SCSI commands and a lot of bidi. IMO it seems to be
> 10 or 20 years before its time. Maybe ibm/redhat need to
> (re-)discover it for it to catch on.
>
>
> Plus there are proprietary SCSI bidi commands out there. People contact
> me and ask me how to issue them with sg3_utils package. Easy, I tell them,
> just use sg_raw with a bsg device. Typically, in my experience, "no news
> is good news" after suggestions like that. When I give bad advice, I
> usually hear back relatively quickly. Anyone who wants SCSI bidi _async_
> support is currently out of luck.
>
Thank you Doug
> Enough already
> Doug Gilbert
>
>
> *** example: loading all or most kernel modules in a few READ SCATTERED
> commands might speed up boot time ...
>
next prev parent reply other threads:[~2018-11-01 0:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-27 8:20 remove exofs and the T10 OSD code V2 Christoph Hellwig
2018-10-27 8:20 ` [PATCH 1/2] fs: remove exofs Christoph Hellwig
2018-10-29 20:41 ` Bart Van Assche
2018-10-27 8:20 ` [PATCH 2/2] scsi: remove the SCSI OSD library Christoph Hellwig
2018-10-29 20:43 ` Bart Van Assche
2018-10-27 20:32 ` remove exofs and the T10 OSD code V2 Nick Desaulniers
2018-10-29 20:42 ` Jens Axboe
2018-10-30 7:45 ` Christoph Hellwig
2018-10-31 15:57 ` Boaz Harrosh
2018-10-31 21:10 ` Douglas Gilbert
2018-11-01 0:03 ` Boaz Harrosh [this message]
2018-11-01 11:13 ` Douglas Gilbert
2018-10-31 15:59 ` Jens Axboe
2018-10-31 16:34 ` Boaz Harrosh
2018-10-31 17:29 ` Bart Van Assche
2018-10-31 17:47 ` Boaz Harrosh
2018-10-31 22:07 ` Finn Thain
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=a711a25d-e866-aabe-95c8-53bcd212a173@electrozaur.com \
--to=ooo@electrozaur.com \
--cc=axboe@kernel.dk \
--cc=dgilbert@interlog.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=osd-dev@open-osd.org \
--cc=torvalds@linux-foundation.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).