From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Mike Snitzer <snitzer@redhat.com>,
"Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: "hare@suse.de" <hare@suse.de>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"jaegeuk@kernel.org" <jaegeuk@kernel.org>,
"yuchao0@huawei.com" <yuchao0@huawei.com>,
"ghe@suse.com" <ghe@suse.com>,
"mwilck@suse.com" <mwilck@suse.com>,
"tchvatal@suse.com" <tchvatal@suse.com>,
"zren@suse.com" <zren@suse.com>,
"agk@redhat.com" <agk@redhat.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: dm-zoned-tools: add zoned disk udev rules for scheduler / dmsetup
Date: Fri, 15 Jun 2018 09:59:33 +0000 [thread overview]
Message-ID: <3dca87db-d8ce-5229-0fd9-939501bc6b3a@wdc.com> (raw)
In-Reply-To: <20180614175852.GA1034@redhat.com>
TWlrZSwNCg0KT24gNi8xNS8xOCAwMjo1OCwgTWlrZSBTbml0emVyIHdyb3RlOg0KPiBPbiBUaHUs
IEp1biAxNCAyMDE4IGF0ICAxOjM3cG0gLTA0MDAsDQo+IEx1aXMgUi4gUm9kcmlndWV6IDxtY2dy
b2ZAa2VybmVsLm9yZz4gd3JvdGU6DQo+IA0KPj4gT24gVGh1LCBKdW4gMTQsIDIwMTggYXQgMDg6
Mzg6MDZBTSAtMDQwMCwgTWlrZSBTbml0emVyIHdyb3RlOg0KPj4+IE9uIFdlZCwgSnVuIDEzIDIw
MTggYXQgIDg6MTFwbSAtMDQwMCwNCj4+PiBMdWlzIFIuIFJvZHJpZ3VleiA8bWNncm9mQGtlcm5l
bC5vcmc+IHdyb3RlOg0KPj4+DQo+Pj4+IFNldHRpbmcgdXAgYSB6b25lZCBkaXNrcyBpbiBhIGdl
bmVyaWMgZm9ybSBpcyBub3Qgc28gdHJpdmlhbC4gVGhlcmUNCj4+Pj4gaXMgYWxzbyBxdWl0ZSBh
IGJpdCBvZiB0cmliYWwga25vd2xlZGdlIHdpdGggdGhlc2UgZGV2aWNlcyB3aGljaCBpcyBub3QN
Cj4+Pj4gZWFzeSB0byBmaW5kLg0KPj4+Pg0KPj4+PiBUaGUgY3VycmVudGx5IHN1cHBsaWVkIGRl
bW8gc2NyaXB0IHdvcmtzIGJ1dCBpdCBpcyBub3QgZ2VuZXJpYyBlbm91Z2ggdG8gYmUNCj4+Pj4g
cHJhY3RpY2FsIGZvciBMaW51eCBkaXN0cmlidXRpb25zIG9yIGV2ZW4gZGV2ZWxvcGVycyB3aGlj
aCBvZnRlbiBtb3ZlDQo+Pj4+IGZyb20gb25lIGtlcm5lbCB0byBhbm90aGVyLg0KPj4+Pg0KPj4+
PiBUaGlzIHRyaWVzIHRvIHB1dCBhIGJpdCBvZiB0aGlzIHRyaWJhbCBrbm93bGVkZ2UgaW50byBh
biBpbml0aWFsIHVkZXYNCj4+Pj4gcnVsZSBmb3IgZGV2ZWxvcG1lbnQgd2l0aCB0aGUgaG9wZXMg
TGludXggZGlzdHJpYnV0aW9ucyBjYW4gbGF0ZXINCj4+Pj4gZGVwbG95LiBUaHJlZSBydWxlIGFy
ZSBhZGRlZC4gT25lIHJ1bGUgaXMgb3B0aW9uYWwgZm9yIG5vdywgaXQgc2hvdWxkIGJlDQo+Pj4+
IGV4dGVuZGVkIGxhdGVyIHRvIGJlIG1vcmUgZGlzdHJpYnV0aW9uLWZyaWVuZGx5IGFuZCB0aGVu
IEkgdGhpbmsgdGhpcw0KPj4+PiBtYXkgYmUgcmVhZHkgZm9yIGNvbnNpZGVyYXRpb24gZm9yIGlu
dGVncmF0aW9uIG9uIGRpc3RyaWJ1dGlvbnMuDQo+Pj4+DQo+Pj4+IDEpIHNjaGVkdWxlciBzZXR1
cA0KPj4+DQo+Pj4gVGhpcyBpcyB3cm9uZy4uIGlmIHpvbmVkIGRldmljZXMgYXJlIHNvIGRlcGVu
ZGVudCBvbiBkZWFkbGluZSBvcg0KPj4+IG1xLWRlYWRsaW5lIHRoZW4gdGhlIGtlcm5lbCBzaG91
bGQgYWxsb3cgdGhlbSB0byBiZSBoYXJkY29kZWQuICBJIGtub3cNCj4+PiBKZW5zIHJlbW92ZWQg
dGhlIEFQSSB0byBkbyBzbyBidXQgdGhlIGZhY3QgdGhhdCBkcml2ZXJzIG5lZWQgdG8gcmVseSBv
bg0KPj4+IGhhY2tzIGxpa2UgdGhpcyB1ZGV2IHJ1bGUgdG8gZ2V0IGEgZnVuY3Rpb25hbCBkZXZp
Y2UgaXMgcHJvb2Ygd2UgbmVlZCB0bw0KPj4+IGFsbG93IGRyaXZlcnMgdG8gaW1wb3NlIHRoZSBz
Y2hlZHVsZXIgdXNlZC4NCj4+DQo+PiBUaGlzIGlzIHRoZSBwb2ludCB0byB0aGUgcGF0Y2ggYXMg
d2VsbCwgSSBhY3R1YWxseSB0ZW5kIHRvIGFncmVlIHdpdGggeW91LA0KPj4gYW5kIEkgaGFkIHRy
aWVkIHRvIGRyYXcgdXAgYSBwYXRjaCB0byBkbyBqdXN0IHRoYXQsIGhvd2V2ZXIgaXRzICpub3Qq
IHBvc3NpYmxlDQo+PiB0b2RheSB0byBkbyB0aGlzIGFuZCB3b3VsZCByZXF1aXJlIHNvbWUgY29u
c2Vuc3VzLiBTbyBmcm9tIHdoYXQgSSBjYW4gdGVsbA0KPj4gd2UgKmhhdmUqIHRvIGxpdmUgd2l0
aCB0aGlzIG9uZSBvciBhIGZvcm0gb2YgaXQuIEllIGEgZmlsZSBkZXNjcmliaW5nIHdoaWNoDQo+
PiBkaXNrIHNlcmlhbCBnZXRzIGRlYWRsaW5lIGFuZCB3aGljaCBvbmUgZ2V0cyBtcS1kZWFkbGlu
ZS4NCj4+DQo+PiBKZW5zPw0KPj4NCj4+IEFueXdheSwgbGV0J3MgYXNzdW1lIHRoaXMgaXMgZG9u
ZSBpbiB0aGUga2VybmVsLCB3aGljaCBvbmUgd291bGQgdXNlIGRlYWRsaW5lLA0KPj4gd2hpY2gg
b25lIHdvdWxkIHVzZSBtcS1kZWFkbGluZT8NCj4gDQo+IFRoZSB6b25lZCBzdG9yYWdlIGRyaXZl
ciBuZWVkcyB0byBtYWtlIHRoYXQgY2FsbCBiYXNlZCBvbiB3aGF0IG1vZGUgaXQNCj4gaXMgaW4u
ICBJZiBpdCBpcyB1c2luZyBibGstbXEgdGhlbiBpdCBzZWxlY3RzIG1xLWRlYWRsaW5lLCBvdGhl
cndpc2UNCj4gZGVhZGxpbmUuDQoNCkFzIEJhcnQgcG9pbnRlZCBvdXQsIGRlYWRsaW5lIGlzIGFu
IGFsaWFzIG9mIG1xLWRlYWRsaW5lLiBTbyB1c2luZw0KImRlYWRsaW5lIiBhcyB0aGUgc2NoZWR1
bGVyIG5hbWUgd29ya3MgaW4gYm90aCBsZWdhY3kgYW5kIG1xIGNhc2VzLg0KDQo+Pj4+IDIpIGJh
Y2tsaXN0IGYyZnMgZGV2aWNlcw0KPj4+DQo+Pj4gVGhlcmUgc2hvdWxkIHBvcmJhYmx5IGJlIHN1
cHBvcnQgaW4gZG0tem9uZWQgZm9yIGRldGVjdGluZyB3aGV0aGVyIGENCj4+PiB6b25lZCBkZXZp
Y2Ugd2FzIGZvcm1hdHRlZCB3aXRoIGYyZnMgKGFzc3VtaW5nIHRoZXJlIGlzIGEga25vd24gZjJm
cw0KPj4+IHN1cGVyYmxvY2spPw0KPj4NCj4+IE5vdCBzdXJlIHdoYXQgeW91IG1lYW4uIEFyZSB5
b3Ugc3VnZ2VzdGluZyB3ZSBhbHdheXMgc2V0dXAgZG0tem9uZWQgZm9yDQo+PiBhbGwgem9uZWQg
ZGlza3MgYW5kIGp1c3QgbWFrZSBhbiBleGNlbXB0aW9uIG9uIGRtLXpvbmUgY29kZSB0byBzb21l
aG93DQo+PiB1c2UgdGhlIGRpc2sgZGlyZWN0bHkgaWYgYSBmaWxlc3lzdGVtIHN1cHBvcnRzIHpv
bmVkIGRpc2tzIGRpcmVjdGx5IHNvbWVob3c/DQo+IA0KPiBObywgSSdtIHNheWluZyB0aGF0IGEg
dWRldiBydWxlIHdvdWxkbid0IGJlIG5lZWRlZCBpZiBkbS16b25lZCBqdXN0DQo+IGVycm9yZWQg
b3V0IGlmIGFza2VkIHRvIGNvbnN1bWUgZGlza3MgdGhhdCBhbHJlYWR5IGhhdmUgYW4gZjJmcw0K
PiBzdXBlcmJsb2NrLiAgQW5kIGV4aXN0aW5nIGZpbGVzeXN0ZW1zIHNob3VsZCBnZXQgY29uZmxp
Y3Rpbmcgc3VwZXJibG9jaw0KPiBhd2FyZW5lc3MgImZvciBmcmVlIiBpZiBibGtpZCBvciB3aGF0
ZXZlciBpcyB0cmFpbmVkIHRvIGJlIGF3YXJlIG9mDQo+IGYyZnMncyBzdXBlcmJsb2NrLg0KDQpX
ZWxsIHRoYXQgaXMgdGhlIGNhc2UgYWxyZWFkeTogb24gc3RhcnR1cCwgZG0tem9uZWQgd2lsbCBy
ZWFkIGl0cyBvd24NCm1ldGFkYXRhIGZyb20gc2VjdG9yIDAsIHNhbWUgYXMgZjJmcyB3b3VsZCBk
byB3aXRoIGl0cyBzdXBlci1ibG9jay4gSWYNCnRoZSBmb3JtYXQvbWFnaWMgZG9lcyBub3QgbWF0
Y2ggZXhwZWN0ZWQgdmFsdWVzLCBkbS16b25lZCB3aWxsIGJhaWwgb3V0DQphbmQgcmV0dXJuIGFu
IGVycm9yLiBkbS16b25lZCBtZXRhZGF0YSBhbmQgZjJmcyBtZXRhZGF0YSByZXNpZGUgaW4gdGhl
DQpzYW1lIHBsYWNlIGFuZCBvdmVyd3JpdGUgZWFjaCBvdGhlci4gVGhlcmUgaXMgbm8gd2F5IHRv
IGdldCBvbmUgd29ya2luZw0Kb24gdG9wIG9mIHRoZSBvdGhlci4gSSBkbyBub3Qgc2VlIGFueSBw
b3NzaWJpbGl0eSBvZiBhIHByb2JsZW0gb24gc3RhcnR1cC4NCg0KQnV0IGRlZmluaXRlbHksIHRo
ZSB1c2VyIGxhbmQgZm9ybWF0IHRvb2xzIGNhbiBzdGVwIG9uIGVhY2ggb3RoZXIgdG9lcy4NClRo
YXQgbmVlZHMgZml4aW5nLg0KDQo+PiBmMmZzIGRvZXMgbm90IHJlcXVpcmUgZG0tem9uZWQuIFdo
YXQgd291bGQgYmUgcmVxdWlyZWQgaXMgYSBiaXQgbW9yZSBjb21wbGV4DQo+PiBnaXZlbiBvbmUg
Y291bGQgZGVkaWNhdGUgcG9ydGlvbnMgb2YgdGhlIGRpc2sgdG8gZjJmcyBhbmQgb3RoZXIgcG9y
dGlvbnMgdG8NCj4+IGFub3RoZXIgZmlsZXN5c3RlbSwgd2hpY2ggd291bGQgcmVxdWlyZSBkbS16
b25lZC4NCj4+DQo+PiBBbHNvIGZpbGVzeXN0ZW1zIHdoaWNoICpkbyBub3QqIHN1cHBvcnQgem9u
ZWQgZGlza3Mgc2hvdWxkICpub3QqIGJlIGFsbG93aW5nDQo+PiBkaXJlY3Qgc2V0dXAuIFRvZGF5
IHRoYXQncyBhbGwgZmlsZXN5c3RlbXMgb3RoZXIgdGhhbiBmMmZzLCBpbiB0aGUgZnV0dXJlDQo+
PiB0aGF0IG1heSBjaGFuZ2UuIFRob3NlIGFyZSBidWxsZXRzIHdlIGFyZSBhbGxvd2luZyB0byB0
cmlnZ2VyIGZvciB1c2Vycw0KPj4ganVzdCB3YWl0aW5nIHRvIHNob3QgdGhlbXNlbHZlcyBvbiB0
aGUgZm9vdCB3aXRoLg0KPj4NCj4+IFNvIHdobydzIGdvaW5nIHRvIHdvcmsgb24gYWxsIHRoZSBh
Ym92ZT8NCj4gDQo+IEl0IHNob3VsZCB0YWtlIGNhcmUgb2YgaXRzZWxmIGlmIGV4aXN0aW5nIHRv
b2xzIGFyZSB0cmFpbmVkIHRvIGJlIGF3YXJlDQo+IG9mIG5ldyBzaWduYXR1cmVzLiAgRS5nLiBl
eHQ0IGFuZCB4ZnMgYWxyZWFkeSBhcmUgYXdhcmUgb2Ygb25lIGFub3RoZXINCj4gc28gdGhhdCB5
b3UgY2Fubm90IHJlZm9ybWF0IGEgZGV2aWNlIHdpdGggdGhlIG90aGVyIHVubGVzcyBmb3JjZSBp
cw0KPiBnaXZlbi4NCj4gDQo+IFNhbWUga2luZCBvZiBtdXR1YWwgZXhjbHVzc2lvbiBuZWVkcyB0
byBoYXBwZW4gZm9yIHpvbmVkIGRldmljZXMuDQoNClllcy4NCg0KPiBTbyB0aGUgem9uZWQgZGV2
aWNlIHRvb2xzLCBkbS16b25lZCwgZjJmcywgd2hhdGV2ZXIuLiB0aGV5IG5lZWQgdG8gYmUNCj4g
dXBkYXRlZCB0byBub3Qgc3RlcCBvbiBlYWNoIG90aGVycyB0b2VzLiAgQW5kIG90aGVyIGZpbGVz
eXN0ZW1zJyB0b29scw0KPiBuZWVkIHRvIGJlIHVwZGF0ZWQgdG8gYmUgem9uZWQgZGV2aWNlIGF3
YXJlLg0KDQpJIHdpbGwgdXBkYXRlIGRtLXpvbmVkIHRvb2xzIHRvIGNoZWNrIGZvciBrbm93biBG
UyBzdXBlcmJsb2NrcywNCnNpbWlsYXJseSB0byB3aGF0IG1rZnMuZXh0NCBhbmQgbWtmcy54ZnMg
ZG8uDQoNCj4+Pj4gMykgcnVuIGRtc2V0dXAgZm9yIHRoZSByZXN0IG9mIGRldmljZXMNCj4+Pg0K
Pj4+IGF1dG9tYWdpY2FsbHkgcnVubmluZyBkbXNldHVwIGRpcmVjdGx5IGZyb20gdWRldiB0byBj
cmVhdGUgYSBkbS16b25lZA0KPj4+IHRhcmdldCBpcyB2ZXJ5IG11Y2ggd3JvbmcuICBJdCBqdXN0
IGdldHMgaW4gdGhlIHdheSBvZiBwcm9wZXIgc3VwcG9ydA0KPj4+IHRoYXQgc2hvdWxkIGJlIGFk
ZCB0byBhcHByb3ByaWF0ZSB0b29scyB0aGF0IGFkbWlucyB1c2UgdG8gc2V0dXAgdGhlaXINCj4+
PiB6b25lZCBkZXZpY2VzLiAgRm9yIGluc3RhbmNlLCBwZXJzaXN0ZW50IHVzZSBvZiBkbS16b25l
ZCB0YXJnZXQgc2hvdWxkDQo+Pj4gYmUgbWFkZSByZWxpYWJsZSB3aXRoIGEgdm9sdW1lIG1hbmFn
ZXIuLg0KPj4NCj4+IEFoIHllcywgYnV0IHdobydzIHdvcmtpbmcgb24gdGhhdD8gSG93IGxvbmcg
d2lsbCBpdCB0YWtlPw0KPiANCj4gTm8gaWRlYSwgYXMgaXMgKGZyb20gbXkgdmFudGFnZSBwb2lu
dCkgdGhlcmUgaXMgY2xvc2UgdG8gemVybyBkZW1hbmQgZm9yDQo+IHpvbmVkIGRldmljZXMuICBJ
dCB3b24ndCBiZSBhIHByaW9yaXR5IHVudGlsIGVub3VnaCBjdXN0b21lcnMgYXJlIGFza2luZw0K
PiBmb3IgaXQuDQoNCkZyb20gbXkgcG9pbnQgb2YgdmlldyAoZHJpdmUgdmVuZG9yKSwgdGhpbmdz
IGFyZSBkaWZmZXJlbnQuIFdlIGRvIHNlZSBhbg0KaW5jcmVhc2luZyBpbnRlcmVzdCBmb3IgdGhl
c2UgZHJpdmVzLiBIb3dldmVyLCBtb3N0IHVzZSBjYXNlcyBhcmUgc3RpbGwNCmxpbWl0ZWQgdG8g
YXBwbGljYXRpb24gYmFzZWQgZGlyZWN0IGRpc2sgYWNjZXNzIHdpdGggbWluaW1hbCBpbnZvbHZl
bWVudA0KZnJvbSB0aGUga2VybmVsIGFuZCBzbyBmZXcgInN1cHBvcnQiIHJlcXVlc3RzLiBNYW55
IHJlYXNvbnMgdG8gdGhpcywgYnV0DQpvbmUgaXMgdG8gc29tZSBleHRlbnQgdGhlIGN1cnJlbnQg
bGFjayBvZiBleHRlbmRlZCBzdXBwb3J0IGJ5IHRoZQ0Ka2VybmVsLiBEZXNwaXRlIGFsbCB0aGUg
cmVjZW50IHdvcmsgZG9uZSwgYXMgTHVpcyBleHBlcmllbmNlZCwgem9uZWQNCmRyaXZlcyBhcmUg
c3RpbGwgZmFyIGhhcmRlciB0byBlYXNpbHkgc2V0dXAgdGhhbiByZWd1bGFyIGRpc2tzLiBDaGlj
a2VuDQphbmQgZWdnIHNpdHVhdGlvbi4uLg0KDQo+PiBJIGFncmVlIGl0IGlzIG9kZCB0byBleHBl
Y3Qgb25lIHRvIHVzZSBkbXNldHVwIGFuZCB0aGVuIHVzZSBhIHZvbHVtZSBtYW5hZ2VyIG9uDQo+
PiB0b3Agb2YgaXQsIGlmIHdlIGNhbiBqdXN0IGFkZCBwcm9wZXIgc3VwcG9ydCBvbnRvIHRoZSB2
b2x1bWUgbWFuYWdlci4uLiB0aGVuDQo+PiB0aGF0J3MgYSByZWFzb25hYmxlIHdheSB0byBnby4N
Cj4+DQo+PiBCdXQgKndlJ3JlIG5vdCB0aGVyZSogeWV0LCBhbmQgYXMtaXMgdG9kYXksIHdoYXQg
aXMgZGVzY3JpYmVkIGluIHRoZSB1ZGV2DQo+PiBzY3JpcHQgaXMgdGhlIGJlc3Qgd2UgY2FuIGRv
IGZvciBhIGdlbmVyaWMgc2V0dXAuDQo+IA0KPiBKdXN0IGJlY2F1c2UgZG9pbmcgdGhpbmdzIHJp
Z2h0IHRha2VzIHdvcmsgZG9lc24ndCBtZWFuIGl0IG1ha2VzIHNlbnNlDQo+IHRvIGVsZXZhdGUg
dGhpcyB1ZGV2IHNjcmlwdCB0byBiZSBwYWNrYWdlZCBpbiBzb21lIHVwc3RyZWFtIHByb2plY3Qg
bGlrZQ0KPiB1ZGV2IG9yIHdoYXRldmVyLg0KDQpBZ3JlZS4gV2lsbCBzdGFydCBsb29raW5nIGlu
dG8gYmV0dGVyIHNvbHV0aW9ucyBub3cgdGhhdCBhdCBsZWFzdCBvbmUNCnVzZXIgKEx1aXMpIGNv
bXBsYWluZWQuIFRoZSBjdXN0b21lciBpcyBraW5nLg0KDQo+Pj4gSW4gZ2VuZXJhbCB0aGlzIHVk
ZXYgc2NyaXB0IGlzIHVud2VsY29tZSBhbmQgbWFrZXMgdGhpbmdzIHdheSB3b3JzZSBmb3INCj4+
PiB0aGUgbG9uZy10ZXJtIHN1Y2Nlc3Mgb2Ygem9uZWQgZGV2aWNlcy4NCj4+DQo+PiBkbS16b25l
ZC10b29scyBkb2VzIG5vdCBhY2tub3dsZWRnZSBpbiBhbnkgd2F5IGEgcm9hZG1hcCwgYW5kIGp1
c3QgcHJvdmlkZXMNCj4+IGEgc2NyaXB0LCB3aGljaCBJTUhPIGlzIGxlc3MgZ2VuZXJpYyBhbmQg
bGVzcyBkaXN0cmlidXRpb24gZnJpZW5kbHkuIEhhdmluZw0KPj4gYSB1ZGV2IHJ1bGUgaW4gcGxh
Y2UgdG8gZGVtb25zdHJhdGUgdGhlIGN1cnJlbnQgc3RhdGUgb2YgYWZmYWlycyBJTUhPIGlzDQo+
PiBtb3JlIHNjYWxhYmxlIGRlbW9uc3RyYXRlcyB0aGUgaXNzdWVzIGJldHRlciB0aGFuIHRoZSBz
Y3JpcHQuDQo+Pg0KPj4gSWYgd2UgaGF2ZSBhbiBhZ3JlZWQgdXBvbiBsb25nIHRlcm0gc3RyYXRl
Z3kgbGV0cyBkb2N1bWVudCB0aGF0LiBCdXQgZnJvbQ0KPj4gd2hhdCBJIGdhdGhlciB3ZSBhcmUg
bm90IGV2ZW4gaW4gY29uc2Vuc3VzIHdpdGggcmVnYXJkcyB0byB0aGUgc2NoZWR1bGVyDQo+PiBz
dHVmZi4gSWYgd2UgaGF2ZSBjb25zZW5zdXMgb24gdGhlIG90aGVyIHN0dWZmIGxldHMgZG9jdW1l
bnQgdGhhdCBhcw0KPj4gZG0tem9uZWQtdG9vbHMgaXMgdGhlIG9ubHkgcGxhY2UgSSB0aGluayBm
b2xrcyBjb3VsZCBmaW5kIHRvIHJlYXNvbmFibHkNCj4+IGRlcGxveSB0aGVzZSB0aGluZ3MuDQo+
IA0KPiBJJ20gc3VyZSBEYW1pZW4gYW5kIG90aGVycyB3aWxsIGhhdmUgc29tZXRoaW5nIHRvIHNh
eSBoZXJlLg0KDQpZZXMuIFRoZSBzY2hlZHVsZXIgc2V0dXAgcGFpbiBpcyByZWFsLiBKZW5zIG1h
ZGUgaXQgY2xlYXIgdGhhdCBoZQ0KcHJlZmVycyBhIHVkZXYgcnVsZS4gSSBmdWxseSB1bmRlcnN0
YW5kIGhpcyBwb2ludCBvZiB2aWV3LCB5ZXQsIEkgdGhpbmsNCmFuIGF1dG9tYXRpYyBzd2l0Y2gg
aW4gdGhlIGJsb2NrIGxheWVyIHdvdWxkIGJlIGZhciBlYXNpZXIgYW5kIGdlbmVyYXRlDQphIGxv
dCBsZXNzIHByb2JsZW0gZm9yIHVzZXJzLCBhbmQgbGlrZWx5IGxlc3MgImJ1ZyByZXBvcnQiIHRv
DQpkaXN0cmlidXRpb25zIHZlbmRvcnMgKGFuZCB0byBteXNlbGYgdG9vKS4NCg0KVGhhdCBzYWlk
LCBJIGFsc28gbGlrZSB0byBzZWUgdGhlIGN1cnJlbnQgZGVwZW5kZW5jeSBvZiB6b25lZCBkZXZp
Y2VzIG9uDQp0aGUgZGVhZGxpbmUgc2NoZWR1bGVyIGFzIHRlbXBvcmFyeSB1bnRpbCBhIGJldHRl
ciBzb2x1dGlvbiBmb3IgZW5zdXJpbmcNCndyaXRlIG9yZGVyaW5nIGlzIGZvdW5kLiBBZnRlciBh
bGwsIHJlcXVpcmluZyBkZWFkbGluZSBhcyB0aGUgZGlzaw0Kc2NoZWR1bGVyIGRvZXMgaW1wb3Nl
IG90aGVyIGxpbWl0YXRpb25zIG9uIHRoZSB1c2VyLiBMYWNrIG9mIEkvTw0KcHJpb3JpdHkgc3Vw
cG9ydCBhbmQgbm8gY2dyb3VwIGJhc2VkIGZhaXJuZXNzIGFyZSB0d28gZXhhbXBsZXMgb2Ygd2hh
dA0Kb3RoZXIgc2NoZWR1bGVycyBwcm92aWRlIGJ1dCBpcyBsb3N0IHdpdGggZm9yY2luZyBkZWFk
bGluZS4NCg0KVGhlIG9idmlvdXMgZml4IGlzIG9mIGNvdXJzZSB0byBtYWtlIGFsbCBkaXNrIHNj
aGVkdWxlcnMgem9uZSBkZXZpY2UNCmF3YXJlLiBBIGxpdHRsZSBoZWF2eSBoYW5kZWQsIHByb2Jh
Ymx5IGxvdHMgb2YgZHVwbGljYXRlZC9zaW1pbGFyIGNvZGUsDQphbmQgbWFueSBtb3JlIHRlc3Qg
Y2FzZXMgdG8gY292ZXIuIFRoaXMgYXBwcm9hY2ggZG9lcyBub3Qgc2VlbQ0Kc3VzdGFpbmFibGUg
dG8gbWUuDQoNCldlIGRpc2N1c3NlZCBvdGhlciBwb3NzaWJpbGl0aWVzIGF0IExTRi9NTSAoc3Bl
Y2lhbGl6ZWQgd3JpdGUgcXVldWUgaW4NCm11bHRpLXF1ZXVlIHBhdGgpLiBPbmUgY291bGQgYWxz
byB0aGluayBvZiBtb3JlIGludmFzaXZlIGNoYW5nZXMgdG8gdGhlDQpibG9jayBsYXllciAoZS5n
LiBhZGRpbmcgYW4gb3B0aW9uYWwgImRpc3BhdGNoZXIiIGxheWVyIHRvIHRpZ2h0bHkNCmNvbnRy
b2wgY29tbWFuZCBvcmRlcmluZyA/KS4gQW5kIHByb2JhYmx5IGEgbG90IG1vcmUgb3B0aW9ucywg
QnV0IEkgYW0NCm5vdCB5ZXQgc3VyZSB3aGF0IGFuIGFwcHJvcHJpYXRlIHJlcGxhY2VtZW50IHRv
IGRlYWRsaW5lIHdvdWxkIGJlLg0KDQpFdmVudHVhbGx5LCB0aGUgcmVtb3ZhbCBvZiB0aGUgbGVn
YWN5IEkvTyBwYXRoIG1heSBhbHNvIGJlIHRoZSB0cmlnZ2VyDQp0byBpbnRyb2R1Y2Ugc29tZSBk
ZWVwZXIgZGVzaWduIGNoYW5nZXMgdG8gYmxrLW1xIHRvIGFjY29tbW9kYXRlIG1vcmUNCmVhc2ls
eSB6b25lZCBibG9jayBkZXZpY2VzIG9yIG90aGVyIG5vbi1zdGFuZGFyZCBibG9jayBkZXZpY2Vz
IChvcGVuDQpjaGFubmVsIFNTRHMgZm9yIGluc3RhbmNlKS4NCg0KQXMgeW91IGNhbiBzZWUgZnJv
bSB0aGUgYWJvdmUsIHdvcmtpbmcgd2l0aCB0aGVzZSBkcml2ZXMgYWxsIGRheSBsb25nDQpkb2Vz
IG5vdCBtYWtlIGZvciBhIGNsZWFyIHN0cmF0ZWd5LiBJbnB1dHMgZnJvbSBvdGhlciBoZXJlIGFy
ZSBtb3JlIHRoYW4NCndlbGNvbWUuIEkgd291bGQgYmUgaGFwcHkgdG8gd3JpdGUgdXAgYWxsIHRo
ZSBpZGVhcyBJIGhhdmUgdG8gc3RhcnQgYQ0KZGlzY3Vzc2lvbiBzbyB0aGF0IHdlIGNhbiBjb21l
IHRvIGEgY29uc2Vuc3VzIGFuZCBoYXZlIGEgcGxhbi4NCg0KPj4+IEkgZG9uJ3QgZGlzcHV0ZSB0
aGVyZSBpcyBhbiBvYnZpb3VzIHZvaWQgZm9yIGhvdyB0byBwcm9wZXJseSBzZXR1cCB6b25lZA0K
Pj4+IGRldmljZXMsIGJ1dCB0aGlzIHNjcmlwdCBpcyBfbm90XyB3aGF0IHNob3VsZCBmaWxsIHRo
YXQgdm9pZC4NCj4+DQo+PiBHb29kIHRvIGtub3chIEFnYWluLCBjb25zaWRlciBpdCBhcyBhbiBh
bHRlcm5hdGl2ZSB0byB0aGUgc2NyaXB0Lg0KPj4NCj4+IEknbSBoYXBweSB0byBhZGFwdCB0aGUg
bGFuZ3VhZ2UgYW5kIHN1cHBseSBpdCBvbmx5IGFzIGFuIGV4YW1wbGUgc2NyaXB0DQo+PiBkZXZl
bG9wZXJzIGNhbiB1c2UsIGJ1dCB3ZSBjYW4ndCBsZWF2ZSB1c2VycyBoYW5naW5nIGFzIHdlbGwu
IExldCdzIGF0DQo+PiBsZWFzdCBjb21lIHVwIHdpdGggYSBwbGFuIHdoaWNoIHdlIHNlZW0gdG8g
YWdyZWUgb24gYW5kIGRvY3VtZW50IHRoYXQuDQo+IA0KPiBCZXN0IHRvIHRyeSB0byBnZXQgRGFt
aWVuIGFuZCBvdGhlcnMgbW9yZSBpbnZlc3RlZCBpbiB6b25lZCBkZXZpY2VzIHRvDQo+IGhlbHAg
eW91IHRha2UgdXAgeW91ciBjYXVzZS4gIEkgdGhpbmsgaXQgaXMgd29ydGh3aGlsZSB0byBkZXZl
bG9wIGENCj4gc3RyYXRlZ3kuICBCdXQgaXQgbmVlZHMgdG8gYmUgZG9uZSBpbiB0ZXJtcyBvZiB0
aGUgbm9ybXMgb2YgdGhlIGV4aXN0aW5nDQo+IGluZnJhc3RydWN0dXJlIHdlIGFsbCBtYWtlIHVz
ZSBvZiB0b2RheS4gIFNvIGZpcnN0IHN0ZXAgaXMgbWFraW5nDQo+IGV4aXN0aW5nIHRvb2xzIHpv
bmVkIGRldmljZSBhd2FyZSAoZXZlbiBpZiB0byByZWplY3Qgc3VjaCBkZXZpY2VzKS4NCg0KUmVz
dCBhc3N1cmVkIHRoYXQgSSBhbSBmdWxseSBpbnZlc3RlZCBpbiBpbXByb3ZpbmcgdGhlIGV4aXN0
aW5nDQppbmZyYXN0cnVjdHVyZSBmb3Igem9uZWQgYmxvY2sgZGV2aWNlcy4gQXMgbWVudGlvbmVk
IGFib3ZlLCBhcHBsaWNhdGlvbnMNCmJhc2VkIHVzZSBvZiB6b25lZCBibG9jayBkZXZpY2VzIHN0
aWxsIHByZXZhaWxzIHRvZGF5LiBTbyBJIGRvIHRlbmQgdG8NCndvcmsgbW9yZSBvbiB0aGF0IHNp
ZGUgb2YgdGhpbmdzIChsaWJ6YmMsIHRjbXUsIHN5c3V0aWxzIGZvciBpbnN0YW5jZSkNCnJhdGhl
ciB0aGFuIG9uIGEgYmV0dGVyIGludGVncmF0aW9uIHdpdGggbW9yZSBhZHZhbmNlZCB0b29scyAo
c3VjaCBhcw0KTFZNKSByZWx5aW5nIG9uIGtlcm5lbCBmZWF0dXJlcy4gSSBhbSBob3dldmVyIHNl
ZWluZyByaXNpbmcgaW50ZXJlc3QgaW4NCmZpbGUgc3lzdGVtcyBhbmQgYWxzbyBpbiBkbS16b25l
ZC4gU28gZGVmaW5pdGVseSBpdCBpcyB0aW1lIHRvIHN0ZXAgdXANCndvcmsgaW4gdGhhdCBhcmVh
IHRvIGZ1cnRoZXIgc2ltcGxpZnkgdXNpbmcgdGhlc2UgZHJpdmVzLg0KDQpUaGFuayB5b3UgZm9y
IHRoZSBmZWVkYmFjay4NCg0KQmVzdCByZWdhcmRzLg0KDQotLSANCkRhbWllbiBMZSBNb2FsLA0K
V2VzdGVybiBEaWdpdGFs
WARNING: multiple messages have this Message-ID (diff)
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Mike Snitzer <snitzer@redhat.com>,
"Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: "hare@suse.de" <hare@suse.de>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"jaegeuk@kernel.org" <jaegeuk@kernel.org>,
"yuchao0@huawei.com" <yuchao0@huawei.com>,
"ghe@suse.com" <ghe@suse.com>,
"mwilck@suse.com" <mwilck@suse.com>,
"tchvatal@suse.com" <tchvatal@suse.com>,
"zren@suse.com" <zren@suse.com>,
"agk@redhat.com" <agk@redhat.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: dm-zoned-tools: add zoned disk udev rules for scheduler / dmsetup
Date: Fri, 15 Jun 2018 09:59:33 +0000 [thread overview]
Message-ID: <3dca87db-d8ce-5229-0fd9-939501bc6b3a@wdc.com> (raw)
In-Reply-To: <20180614175852.GA1034@redhat.com>
Mike,
On 6/15/18 02:58, Mike Snitzer wrote:
> On Thu, Jun 14 2018 at 1:37pm -0400,
> Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>
>> On Thu, Jun 14, 2018 at 08:38:06AM -0400, Mike Snitzer wrote:
>>> On Wed, Jun 13 2018 at 8:11pm -0400,
>>> Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>>>
>>>> Setting up a zoned disks in a generic form is not so trivial. There
>>>> is also quite a bit of tribal knowledge with these devices which is not
>>>> easy to find.
>>>>
>>>> The currently supplied demo script works but it is not generic enough to be
>>>> practical for Linux distributions or even developers which often move
>>>> from one kernel to another.
>>>>
>>>> This tries to put a bit of this tribal knowledge into an initial udev
>>>> rule for development with the hopes Linux distributions can later
>>>> deploy. Three rule are added. One rule is optional for now, it should be
>>>> extended later to be more distribution-friendly and then I think this
>>>> may be ready for consideration for integration on distributions.
>>>>
>>>> 1) scheduler setup
>>>
>>> This is wrong.. if zoned devices are so dependent on deadline or
>>> mq-deadline then the kernel should allow them to be hardcoded. I know
>>> Jens removed the API to do so but the fact that drivers need to rely on
>>> hacks like this udev rule to get a functional device is proof we need to
>>> allow drivers to impose the scheduler used.
>>
>> This is the point to the patch as well, I actually tend to agree with you,
>> and I had tried to draw up a patch to do just that, however its *not* possible
>> today to do this and would require some consensus. So from what I can tell
>> we *have* to live with this one or a form of it. Ie a file describing which
>> disk serial gets deadline and which one gets mq-deadline.
>>
>> Jens?
>>
>> Anyway, let's assume this is done in the kernel, which one would use deadline,
>> which one would use mq-deadline?
>
> The zoned storage driver needs to make that call based on what mode it
> is in. If it is using blk-mq then it selects mq-deadline, otherwise
> deadline.
As Bart pointed out, deadline is an alias of mq-deadline. So using
"deadline" as the scheduler name works in both legacy and mq cases.
>>>> 2) backlist f2fs devices
>>>
>>> There should porbably be support in dm-zoned for detecting whether a
>>> zoned device was formatted with f2fs (assuming there is a known f2fs
>>> superblock)?
>>
>> Not sure what you mean. Are you suggesting we always setup dm-zoned for
>> all zoned disks and just make an excemption on dm-zone code to somehow
>> use the disk directly if a filesystem supports zoned disks directly somehow?
>
> No, I'm saying that a udev rule wouldn't be needed if dm-zoned just
> errored out if asked to consume disks that already have an f2fs
> superblock. And existing filesystems should get conflicting superblock
> awareness "for free" if blkid or whatever is trained to be aware of
> f2fs's superblock.
Well that is the case already: on startup, dm-zoned will read its own
metadata from sector 0, same as f2fs would do with its super-block. If
the format/magic does not match expected values, dm-zoned will bail out
and return an error. dm-zoned metadata and f2fs metadata reside in the
same place and overwrite each other. There is no way to get one working
on top of the other. I do not see any possibility of a problem on startup.
But definitely, the user land format tools can step on each other toes.
That needs fixing.
>> f2fs does not require dm-zoned. What would be required is a bit more complex
>> given one could dedicate portions of the disk to f2fs and other portions to
>> another filesystem, which would require dm-zoned.
>>
>> Also filesystems which *do not* support zoned disks should *not* be allowing
>> direct setup. Today that's all filesystems other than f2fs, in the future
>> that may change. Those are bullets we are allowing to trigger for users
>> just waiting to shot themselves on the foot with.
>>
>> So who's going to work on all the above?
>
> It should take care of itself if existing tools are trained to be aware
> of new signatures. E.g. ext4 and xfs already are aware of one another
> so that you cannot reformat a device with the other unless force is
> given.
>
> Same kind of mutual exclussion needs to happen for zoned devices.
Yes.
> So the zoned device tools, dm-zoned, f2fs, whatever.. they need to be
> updated to not step on each others toes. And other filesystems' tools
> need to be updated to be zoned device aware.
I will update dm-zoned tools to check for known FS superblocks,
similarly to what mkfs.ext4 and mkfs.xfs do.
>>>> 3) run dmsetup for the rest of devices
>>>
>>> automagically running dmsetup directly from udev to create a dm-zoned
>>> target is very much wrong. It just gets in the way of proper support
>>> that should be add to appropriate tools that admins use to setup their
>>> zoned devices. For instance, persistent use of dm-zoned target should
>>> be made reliable with a volume manager..
>>
>> Ah yes, but who's working on that? How long will it take?
>
> No idea, as is (from my vantage point) there is close to zero demand for
> zoned devices. It won't be a priority until enough customers are asking
> for it.
From my point of view (drive vendor), things are different. We do see an
increasing interest for these drives. However, most use cases are still
limited to application based direct disk access with minimal involvement
from the kernel and so few "support" requests. Many reasons to this, but
one is to some extent the current lack of extended support by the
kernel. Despite all the recent work done, as Luis experienced, zoned
drives are still far harder to easily setup than regular disks. Chicken
and egg situation...
>> I agree it is odd to expect one to use dmsetup and then use a volume manager on
>> top of it, if we can just add proper support onto the volume manager... then
>> that's a reasonable way to go.
>>
>> But *we're not there* yet, and as-is today, what is described in the udev
>> script is the best we can do for a generic setup.
>
> Just because doing things right takes work doesn't mean it makes sense
> to elevate this udev script to be packaged in some upstream project like
> udev or whatever.
Agree. Will start looking into better solutions now that at least one
user (Luis) complained. The customer is king.
>>> In general this udev script is unwelcome and makes things way worse for
>>> the long-term success of zoned devices.
>>
>> dm-zoned-tools does not acknowledge in any way a roadmap, and just provides
>> a script, which IMHO is less generic and less distribution friendly. Having
>> a udev rule in place to demonstrate the current state of affairs IMHO is
>> more scalable demonstrates the issues better than the script.
>>
>> If we have an agreed upon long term strategy lets document that. But from
>> what I gather we are not even in consensus with regards to the scheduler
>> stuff. If we have consensus on the other stuff lets document that as
>> dm-zoned-tools is the only place I think folks could find to reasonably
>> deploy these things.
>
> I'm sure Damien and others will have something to say here.
Yes. The scheduler setup pain is real. Jens made it clear that he
prefers a udev rule. I fully understand his point of view, yet, I think
an automatic switch in the block layer would be far easier and generate
a lot less problem for users, and likely less "bug report" to
distributions vendors (and to myself too).
That said, I also like to see the current dependency of zoned devices on
the deadline scheduler as temporary until a better solution for ensuring
write ordering is found. After all, requiring deadline as the disk
scheduler does impose other limitations on the user. Lack of I/O
priority support and no cgroup based fairness are two examples of what
other schedulers provide but is lost with forcing deadline.
The obvious fix is of course to make all disk schedulers zone device
aware. A little heavy handed, probably lots of duplicated/similar code,
and many more test cases to cover. This approach does not seem
sustainable to me.
We discussed other possibilities at LSF/MM (specialized write queue in
multi-queue path). One could also think of more invasive changes to the
block layer (e.g. adding an optional "dispatcher" layer to tightly
control command ordering ?). And probably a lot more options, But I am
not yet sure what an appropriate replacement to deadline would be.
Eventually, the removal of the legacy I/O path may also be the trigger
to introduce some deeper design changes to blk-mq to accommodate more
easily zoned block devices or other non-standard block devices (open
channel SSDs for instance).
As you can see from the above, working with these drives all day long
does not make for a clear strategy. Inputs from other here are more than
welcome. I would be happy to write up all the ideas I have to start a
discussion so that we can come to a consensus and have a plan.
>>> I don't dispute there is an obvious void for how to properly setup zoned
>>> devices, but this script is _not_ what should fill that void.
>>
>> Good to know! Again, consider it as an alternative to the script.
>>
>> I'm happy to adapt the language and supply it only as an example script
>> developers can use, but we can't leave users hanging as well. Let's at
>> least come up with a plan which we seem to agree on and document that.
>
> Best to try to get Damien and others more invested in zoned devices to
> help you take up your cause. I think it is worthwhile to develop a
> strategy. But it needs to be done in terms of the norms of the existing
> infrastructure we all make use of today. So first step is making
> existing tools zoned device aware (even if to reject such devices).
Rest assured that I am fully invested in improving the existing
infrastructure for zoned block devices. As mentioned above, applications
based use of zoned block devices still prevails today. So I do tend to
work more on that side of things (libzbc, tcmu, sysutils for instance)
rather than on a better integration with more advanced tools (such as
LVM) relying on kernel features. I am however seeing rising interest in
file systems and also in dm-zoned. So definitely it is time to step up
work in that area to further simplify using these drives.
Thank you for the feedback.
Best regards.
--
Damien Le Moal,
Western Digital
next prev parent reply other threads:[~2018-06-15 9:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-14 0:11 [PATCH] dm-zoned-tools: add zoned disk udev rules for scheduler / dmsetup Luis R. Rodriguez
2018-06-14 10:01 ` Damien Le Moal
2018-06-14 10:01 ` Damien Le Moal
2018-06-14 13:39 ` Bart Van Assche
2018-06-14 13:39 ` Bart Van Assche
2018-06-14 13:42 ` Christoph Hellwig
2018-06-15 11:07 ` Martin Wilck
2018-06-15 11:07 ` Martin Wilck
2018-06-14 12:38 ` Mike Snitzer
2018-06-14 16:23 ` Bart Van Assche
2018-06-14 16:23 ` Bart Van Assche
2018-06-14 17:37 ` Luis R. Rodriguez
2018-06-14 17:46 ` Luis R. Rodriguez
2018-06-14 17:58 ` Mike Snitzer
2018-06-15 9:59 ` Damien Le Moal [this message]
2018-06-15 9:59 ` Damien Le Moal
2018-06-15 14:50 ` Mike Snitzer
2018-06-15 9:00 ` Damien Le Moal
2018-06-15 9:00 ` Damien Le Moal
2018-06-14 16:19 ` [PATCH] " Bart Van Assche
2018-06-14 16:19 ` Bart Van Assche
2018-06-14 17:44 ` Luis R. Rodriguez
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=3dca87db-d8ce-5229-0fd9-939501bc6b3a@wdc.com \
--to=damien.lemoal@wdc.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=ghe@suse.com \
--cc=hare@suse.de \
--cc=jaegeuk@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mwilck@suse.com \
--cc=snitzer@redhat.com \
--cc=tchvatal@suse.com \
--cc=yuchao0@huawei.com \
--cc=zren@suse.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.