Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp1471632imd; Thu, 1 Nov 2018 16:33:39 -0700 (PDT) X-Google-Smtp-Source: AJdET5fywZCLOU/rTxrBvfiZJEwgENUDNi5sYGvF45rJW/WauVEJSQI4+x13HgV2T1gHtpBHd+lH X-Received: by 2002:a17:902:145:: with SMTP id 63-v6mr254633plb.276.1541115219614; Thu, 01 Nov 2018 16:33:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541115219; cv=none; d=google.com; s=arc-20160816; b=Jd1Q9mRh+MidFP4er63t8NL+292T0aF7cttdu2S0BAtQ0aAmdqUzOsQo4tfMowpEDq 12SEVGXIhh3moV2jUrQYnOf6LHhY1/a/P09V3BzNLQVyl3OcG0ObdEAnldLskZYfwwN2 i0T3F9biJXO+xjBQurHryK7pVa4c36gTpNSf22yJ1lMGel1S6MQxn41uwYiF1g7MkgbP TpiqBRmSgwLhEQwUhZH75/r+VOZ4j5xMAnDPiVa36xivI2/qAfvMFljd9IlRMAgklK3m BiUtvdVuMrKENk5E6aJXwhAedEvHiLBVne/lji4Z+GHhIkXiD7dOnj7HFnIiL93uxLPc Bsqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=T52sfm9vxP9PVe8zroacA5EZCHyTwJp4ZmRr6MI2A7Q=; b=zdzPKhR84c/PG+rsyKeD3XRvGNGdMZL/z2y2dDJ29FXBy8geIUxeReii4piAPjzCF7 P6FKzF5u6llKJNjwVdq28UygcaIY7HSXaEHNMCBd/DhhBkk9775ZySxgy+VQgXKpM4VX /8ZKzILb6FUJkA3xTY0pCXWA0IiMYQy+E5sHgFGFLeBCfwZKcQQBO8xilzMAjdc5hjWC q2hjMZD/iiErBuVVhurwLcgbBP8ytnmyP56Wse6JEiXEzxjmxX0mo38eerqZGeIqDAzf 9ah5nbQYB7Q3oCKlaBPLhsx/JvWL2YUAWR4VyElVBRVoL+Z9vlcNnm6zeIot16ZkFvA+ rq3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w61-v6si33598297plb.95.2018.11.01.16.33.24; Thu, 01 Nov 2018 16:33:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728269AbeKBIgy (ORCPT + 99 others); Fri, 2 Nov 2018 04:36:54 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:59419 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728100AbeKBIgy (ORCPT ); Fri, 2 Nov 2018 04:36:54 -0400 Received: from 1.general.cascardo.us.vpn ([10.172.70.58] helo=calabresa) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1gIMR5-00057z-V3; Thu, 01 Nov 2018 23:31:36 +0000 Date: Thu, 1 Nov 2018 20:31:30 -0300 From: Thadeu Lima de Souza Cascardo To: Christoph Hellwig Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Sagi Grimberg , Jens Axboe , Potnuri Bharat Teja , Keith Busch , Hannes Reinecke , "Martin K . Petersen" Subject: Re: [PATCH] nvme: create 'paths' entries for hidden controllers Message-ID: <20181101233129.GB4249@calabresa> References: <20180928191720.3461-1-cascardo@canonical.com> <20181005073245.GA24224@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181005073245.GA24224@lst.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 05, 2018 at 09:32:45AM +0200, Christoph Hellwig wrote: > On Fri, Sep 28, 2018 at 04:17:20PM -0300, Thadeu Lima de Souza Cascardo wrote: > > When using initramfs-tools with only the necessary dependencies to mount > > the root filesystem, it will fail to include nvme drivers for a root on a > > multipath nvme. That happens because the slaves relationship is not > > present. > > > > As discussed in [1], using slaves will break lsblk, because the slaves are > > hidden from userspace, that is, they have no real block device, just an > > entry under sysfs. > > > > Introducing the paths subdir and using that on initramfs-tools makes it > > possible to now boot a system with nvme multipath as root. > > Do we need documentation how these paths links are supposed to work? > Who is going to parse them? Hi, Christoph. I have just sent a v2 against block/for-next with a Documentation file describing it. The first intended user is initramfs-tools, documented there as well. Thanks. Cascardo.