Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Fri, 20 May 2022 08:59:39 +0200
From:   Javier =?utf-8?B?R29uesOhbGV6?= <javier.gonz@samsung.com>
To:     Damien Le Moal <damien.lemoal@opensource.wdc.com>
CC:     Hannes Reinecke <hare@suse.de>,
        Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
        Luis Chamberlain <mcgrof@kernel.org>,
        "Theodore Ts'o" <tytso@mit.edu>, Christoph Hellwig <hch@lst.de>,
        Pankaj Raghav <p.raghav@samsung.com>,
        "axboe@kernel.dk" <axboe@kernel.dk>,
        "pankydev8@gmail.com" <pankydev8@gmail.com>,
        "gost.dev@samsung.com" <gost.dev@samsung.com>,
        "jiangbo.365@bytedance.com" <jiangbo.365@bytedance.com>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "dm-devel@redhat.com" <dm-devel@redhat.com>,
        "dsterba@suse.com" <dsterba@suse.com>,
        "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
        Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [dm-devel] [PATCH v4 00/13] support non power of 2 zoned
 devices
Message-ID: <20220520065939.yjqlgsxs3qchpgzo@mpHalley-2.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <be429864-09cb-e3fb-2afe-46a3453c4d73@opensource.wdc.com>
CMS-TYPE: 201P
References: <20220517081048.GA13947@lst.de> <YoPAnj9ufkt5nh1G@mit.edu>
        <7f9cb19b-621b-75ea-7273-2d2769237851@opensource.wdc.com>
        <20220519031237.sw45lvzrydrm7fpb@garbanzo>
        <69f06f90-d31b-620b-9009-188d1d641562@opensource.wdc.com>
        <PH0PR04MB74166C87F694B150A5AE0F009BD09@PH0PR04MB7416.namprd04.prod.outlook.com>
        <4a8f0e1b-0acb-1ed4-8d7a-c9ba93fcfd02@opensource.wdc.com>
        <16f3f9ee-7db7-2173-840c-534f67bcaf04@suse.de>
        <20220520062720.wxdcp5lkscesppch@mpHalley-2.localdomain>
        <be429864-09cb-e3fb-2afe-46a3453c4d73@opensource.wdc.com>
        <CGME20220520065941eucas1p105cf273ede995dc4bf92f3245fad09b1@eucas1p1.samsung.com>
Precedence: bulk

On 20.05.2022 15:41, Damien Le Moal wrote:
>On 5/20/22 15:27, Javier González wrote:
>> On 20.05.2022 08:07, Hannes Reinecke wrote:
>>> On 5/19/22 20:47, Damien Le Moal wrote:
>>>> On 5/19/22 16:34, Johannes Thumshirn wrote:
>>>>> On 19/05/2022 05:19, Damien Le Moal wrote:
>>>>>> On 5/19/22 12:12, Luis Chamberlain wrote:
>>>>>>> On Thu, May 19, 2022 at 12:08:26PM +0900, Damien Le Moal wrote:
>>>>>>>> On 5/18/22 00:34, Theodore Ts'o wrote:
>>>>>>>>> On Tue, May 17, 2022 at 10:10:48AM +0200, Christoph Hellwig wrote:
>>>>>>>>>> I'm a little surprised about all this activity.
>>>>>>>>>>
>>>>>>>>>> I though the conclusion at LSF/MM was that for Linux itself there
>>>>>>>>>> is very little benefit in supporting this scheme.  It will massively
>>>>>>>>>> fragment the supported based of devices and applications, while only
>>>>>>>>>> having the benefit of supporting some Samsung legacy devices.
>>>>>>>>>
>>>>>>>>> FWIW,
>>>>>>>>>
>>>>>>>>> That wasn't my impression from that LSF/MM session, but once the
>>>>>>>>> videos become available, folks can decide for themselves.
>>>>>>>>
>>>>>>>> There was no real discussion about zone size constraint on the zone
>>>>>>>> storage BoF. Many discussions happened in the hallway track though.
>>>>>>>
>>>>>>> Right so no direct clear blockers mentioned at all during the BoF.
>>>>>>
>>>>>> Nor any clear OK.
>>>>>
>>>>> So what about creating a device-mapper target, that's taking npo2 drives and
>>>>> makes them po2 drives for the FS layers? It will be very similar code to
>>>>> dm-linear.
>>>>
>>>> +1
>>>>
>>>> This will simplify the support for FSes, at least for the initial drop (if
>>>> accepted).
>>>>
>>>> And more importantly, this will also allow addressing any potential
>>>> problem with user space breaking because of the non power of 2 zone size.
>>>>
>>> Seconded (or maybe thirded).
>>>
>>> The changes to support npo2 in the block layer are pretty simple, and
>>> really I don't have an issue with those.
>>> Then adding a device-mapper target transforming npo2 drives in po2
>>> block devices should be pretty trivial.
>>>
>>> And once that is in you can start arguing with the the FS folks on
>>> whether to implement it natively.
>>>
>>
>> So you are suggesting adding support for !PO2 in the block layer and
>> then a dm to present the device as a PO2 to the FS? This at least
>> addresses the hole issue for raw zoned block devices, so it can be a
>> first step.
>
>Yes, and it also allows supporting these new !po2 devices without
>regressions (read lack of) in the support at FS level.
>
>>
>> This said, it seems to me that the changes to the FS are not being a
>> real issue. In fact, we are exposing some bugs while we generalize the
>> zone size support.
>
>Not arguing with that. But since we are still stabilizing btrfs ZNS
>support, adding more code right now is a little painful.
>
>>
>> Could you point out what the challenges in btrfs are in the current
>> patches, that it makes sense to add an extra dm layer?
>
>See above. No real challenge, just needs to be done if a clear agreement
>can be reached on zone size alignment constraints. As mentioned above, the
>btrfs changes timing is not ideal right now though.
>
>Also please do not forget applications that may expect a power of 2 zone
>size. A dm-zsp2 would be a nice solution for these. So regardless of the
>FS work, that new DM target will be *very* nice to have.
>
>>
>> Note that for F2FS there is no blocker. Jaegeuk picked the initial
>> patches, and he agreed to add native support.
>
>And until that is done, f2fs will not work with these new !po2 devices...
>Having the new dm will avoid that support fragmentation which I personally
>really dislike. With the new dm, we can keep support for *all* zoned block
>devices, albeit needing a different setup depending on the device. That is
>not nice at all but at least there is a way to make things work continuously.

All the above sounds very reasonable. Thanks Damien.

If we all can agree, we can address this in the next version and come
maintain the native FS support off-tree until you see that general btrfs
support for zoned devicse is stable. We will be happy to help with this
too.