From mboxrd@z Thu Jan 1 00:00:00 1970 From: hch@lst.de (Christoph Hellwig) Date: Tue, 14 Jun 2016 16:52:43 +0200 Subject: [RFC-v2 00/11] nvmet: Add support for multi-tenant configfs In-Reply-To: <1465878946-26556-1-git-send-email-nab@linux-iscsi.org> References: <1465878946-26556-1-git-send-email-nab@linux-iscsi.org> Message-ID: <20160614145243.GA29949@lst.de> On Tue, Jun 14, 2016@04:35:35AM +0000, Nicholas A. Bellinger wrote: > Comments..? Still no good reason for doing anything like this. On a conceptual level: The NVMe target is front end implementing a simple protocol to export block devices to a remove host. The SCSI target is larger front end to expose a more complex protocol to remote hosts. None of them should actually implement any real protocol independent behavior, and except for persistent reservations in the SCSI neither of them does. On a practical level it means we drag in over 25.000 lines of code as a dependency, without actually dropping any code in the nvmet module, and vastly more complicated object hierarchies that don't make any sense for the tight-knit NVMe standard. We'd also get dragged into into the nightmare of diverging an incompatible user space tooling, and we'd lose all the test coverage we've built up. We'd also have to deal with tons of tunables that neither fit the protocol we implement nor the philosophy of the project. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [RFC-v2 00/11] nvmet: Add support for multi-tenant configfs Date: Tue, 14 Jun 2016 16:52:43 +0200 Message-ID: <20160614145243.GA29949@lst.de> References: <1465878946-26556-1-git-send-email-nab@linux-iscsi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from verein.lst.de ([213.95.11.211]:46032 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751119AbcFNOwq (ORCPT ); Tue, 14 Jun 2016 10:52:46 -0400 Content-Disposition: inline In-Reply-To: <1465878946-26556-1-git-send-email-nab@linux-iscsi.org> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: "Nicholas A. Bellinger" Cc: target-devel , linux-scsi , linux-nvme , Jens Axboe , Christoph Hellwig , Keith Busch , Jay Freyensee , Martin Petersen , Sagi Grimberg , Hannes Reinecke , Mike Christie , Dave B Minturn On Tue, Jun 14, 2016 at 04:35:35AM +0000, Nicholas A. Bellinger wrote: > Comments..? Still no good reason for doing anything like this. On a conceptual level: The NVMe target is front end implementing a simple protocol to export block devices to a remove host. The SCSI target is larger front end to expose a more complex protocol to remote hosts. None of them should actually implement any real protocol independent behavior, and except for persistent reservations in the SCSI neither of them does. On a practical level it means we drag in over 25.000 lines of code as a dependency, without actually dropping any code in the nvmet module, and vastly more complicated object hierarchies that don't make any sense for the tight-knit NVMe standard. We'd also get dragged into into the nightmare of diverging an incompatible user space tooling, and we'd lose all the test coverage we've built up. We'd also have to deal with tons of tunables that neither fit the protocol we implement nor the philosophy of the project.