linux-kernel - Re: remove exofs, the T10 OSD code and block/scsi bidi support V3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0e8b8d45-cfeb-ba9d-c92f-953cabede1ee@interlog.com>
Date:   Wed, 19 Dec 2018 21:01:53 -0500
From:   Douglas Gilbert <dgilbert@...erlog.com>
To:     Christoph Hellwig <hch@....de>, Boaz Harrosh <ooo@...ctrozaur.com>
Cc:     axboe@...nel.dk, martin.petersen@...cle.com,
        Johannes Thumshirn <jthumshirn@...e.de>,
        Benjamin Block <bblock@...ux.vnet.ibm.com>,
        linux-scsi@...r.kernel.org, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: remove exofs, the T10 OSD code and block/scsi bidi support V3

On 2018-12-19 9:43 a.m., Christoph Hellwig wrote:
> On Mon, Nov 26, 2018 at 07:11:10PM +0200, Boaz Harrosh wrote:
>> On 11/11/18 15:32, Christoph Hellwig wrote:
>>> The only real user of the T10 OSD protocol, the pNFS object layout
>>> driver never went to the point of having shipping products, and we
>>> removed it 1.5 years ago.  Exofs is just a simple example without
>>> real life users.
>>>
>>
>> You have failed to say what is your motivation for this patchset? What
>> is it you are trying to fix/improve.
> 
> Drop basically unused support, which allows us to
> 
>   1) reduce the size of every kernel with block layer support, and
>      even more for every kernel with scsi support

By proposing the removal of bidi support from the block layer, it isn't
just the SCSI subsystem that will be impacted. Those NVMe documents
that you referred me to earlier in the year, in the command tables
in 1.3c and earlier you have noticed the 2 bit direction field and
what 11b means? Even if there aren't any bidi NVMe commands *** yet,
the fact that NVMe's 64 byte command format has provision for 4
(not 2) independent data transfers (data + meta, for each direction).
Surely NVMe will sooner or later take advantage of those ... a
command like READ GATHERED comes to mind.

>   2) reduce the size of the critical struct request structure by
>      128 bits, thus reducing the memory used by every blk-mq driver
>      significantly, never mind the cache effects

Hmm, one pointer (that is null in the non-bidi case) should be enough,
that's 64 or 32 bits.

>   3) stop having the maintainance overhead for this code in the
>      block layer, which has been rather painful at times

You won't get any sympathy from me :-) The sg driver is trying to
inject _SCSI_ commands into the SCSI mid-level for onward processing
by SCSI LLDs. So WTF does it have to deal with the block layer.

While on the subject of bidi, the order of transfers: is the data-out
(to the target) always before the data-in or is it the target device
that decides (depending on the semantics of the command) who is first?

Doug Gilbert

  *** there could already be vendor specific bidi NVMe commands out
     there (ditto for SCSI)