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;
From:   Naohiro Aota <Naohiro.Aota@wdc.com>
To:     "dsterba@suse.cz" <dsterba@suse.cz>
CC:     "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
        David Sterba <dsterba@suse.com>, Chris Mason <clm@fb.com>,
        Josef Bacik <josef@toxicpanda.com>, Qu Wenruo <wqu@suse.com>,
        Nikolay Borisov <nborisov@suse.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Hannes Reinecke <hare@suse.com>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        Damien Le Moal <Damien.LeMoal@wdc.com>,
        =?iso-8859-1?Q?Matias_Bj=F8rling?= <mb@lightnvm.io>,
        Johannes Thumshirn <jthumshirn@suse.de>,
        Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH v2 00/19] btrfs zoned block device support
Thread-Topic: [PATCH v2 00/19] btrfs zoned block device support
Thread-Index: AQHVHTKAMt+QxADp/024sRBo1BQ8yw==
Date:   Fri, 14 Jun 2019 02:07:15 +0000
Message-ID: <SN6PR04MB5231FF124F9BF2FCB3EDB8F58CEE0@SN6PR04MB5231.namprd04.prod.outlook.com>
References: <20190607131025.31996-1-naohiro.aota@wdc.com>
 <20190612175138.GT3563@twin.jikos.cz>
 <SN6PR04MB5231E2F482B8D794950058FF8CEF0@SN6PR04MB5231.namprd04.prod.outlook.com>
 <20190613134612.GU3563@suse.cz>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ae409566-791f-4d7d-59aa-08d6f06d05d8
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2019 02:07:15.8550
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Naohiro.Aota1@wdc.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR04MB5263
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2019/06/13 22:45, David Sterba wrote:> On Thu, Jun 13, 2019 at 04:59:23A=
M +0000, Naohiro Aota wrote:=0A=
>> On 2019/06/13 2:50, David Sterba wrote:=0A=
>>> On Fri, Jun 07, 2019 at 10:10:06PM +0900, Naohiro Aota wrote:=0A=
>>> How can I test the zoned devices backed by files (or regular disks)? I=
=0A=
>>> searched for some concrete example eg. for qemu or dm-zoned, but closes=
t=0A=
>>> match was a text description in libzbc README that it's possible to=0A=
>>> implement. All other howtos expect a real zoned device.=0A=
>>=0A=
>> You can use tcmu-runer [1] to create an emulated zoned device backed by=
=0A=
>> a regular file. Here is a setup how-to:=0A=
>> http://zonedstorage.io/projects/tcmu-runner/#compilation-and-installatio=
n>> That looks great, thanks. I wonder why there's no way to find that, all=
=0A=
> I got were dead links to linux-iscsi.org or tutorials of targetcli that=
=0A=
> were years old and not working.=0A=
=0A=
Actually, this is quite new site. ;-)=0A=
=0A=
> Feeding the textual commands to targetcli is not exactly what I'd=0A=
> expect for scripting, but at least it seems to work.=0A=
=0A=
You can use "targetcli <directory> <command> [<args> ...]" format, so=0A=
you can call e.g.=0A=
=0A=
targetcli /backstores/user:zbc create name=3Dfoo size=3D10G cfgstring=3Dmod=
el-HM/zsize-256/conv-1@/mnt/nvme/disk0.raw=0A=
=0A=
> I tried to pass an emulated ZBC device on host to KVM guest (as a scsi=0A=
> device) but lsscsi does not recognize that it as a zonde device (just a=
=0A=
> QEMU harddisk). So this seems the emulation must be done inside the VM.=
=0A=
=0A=
Oops, QEMU hide the detail.=0A=
=0A=
In this case, you can try exposing the ZBC device via iSCSI.=0A=
=0A=
On the host:=0A=
(after creating the ZBC backstores)=0A=
# sudo targetcli /iscsi create=0A=
Created target iqn.2003-01.org.linux-iscsi.naota-devel.x8664:sn.f4f308e4892=
c.=0A=
Created TPG 1.=0A=
Global pref auto_add_default_portal=3Dtrue=0A=
Created default portal listening on all IPs (0.0.0.0), port 3260.=0A=
# TARGET=3D"iqn.2003-01.org.linux-iscsi.naota-devel.x8664:sn.f4f308e4892c"=
=0A=
=0A=
(WARN: Allow any node to connect without any auth)=0A=
# targetcli /iscsi/${TARGET}/tpg1 set attribute generate_node_acls=3D1=0A=
Parameter generate_node_acls is now '1'.=0A=
( or you can explicitly allow an initiator)=0A=
# TCMU_INITIATOR=3Diqn.2018-07....=0A=
# targecli /iscsi/${TARGET}/tpg1/acls create ${TCMU_INITIATOR}=0A=
=0A=
(for each backend)=0A=
# targetcli /iscsi/${TARGET}/tpg1/luns create /backstores/user:zbc/foo=0A=
Created LUN 0.=0A=
=0A=
Then, you can login to the iSCSI on the KVM guest like:=0A=
=0A=
# iscsiadm -m discovery -t st -p $HOST_IP=0A=
127.0.0.1:3260,1 iqn.2003-01.org.linux-iscsi.naota-devel.x8664:sn.f4f308e48=
92c=0A=
# iscsiadm -m node -l -T ${TARGET}=0A=
Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.naota-de=
vel.x8664:sn.f4f308e4892c, portal: 127.0.0.1,3260]=0A=
Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.naota-devel.x=
8664:sn.f4f308e4892c, portal: 127.0.0.1,3260] successful.=0A=