[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3c04e29f-2c99-c350-bc87-0c0633b4d19d@opensource.wdc.com>
Date: Thu, 26 May 2022 17:25:18 +0900
From: Damien Le Moal <damien.lemoal@...nsource.wdc.com>
To: Pankaj Raghav <p.raghav@...sung.com>, axboe@...nel.dk,
snitzer@...hat.com, Johannes.Thumshirn@....com, hch@....de,
hare@...e.de
Cc: dsterba@...e.com, dm-devel@...hat.com, jiangbo.365@...edance.com,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-nvme@...ts.infradead.org, jaegeuk@...nel.org,
gost.dev@...sung.com
Subject: Re: [PATCH v6 8/8] dm: ensure only power of 2 zone sizes are allowed
On 2022/05/26 17:12, Pankaj Raghav wrote:
> Hi Damien,
> On 5/26/22 01:13, Damien Le Moal wrote:
>> On 5/26/22 00:49, Pankaj Raghav wrote:
>>> Ensure that only power of 2 zoned devices are enabled for dm targets that
>>> supports zoned devices. This constraint can be relaxed once non power of
>>> 2 zone size support is added to the DM layer.
>>>
>>> Signed-off-by: Pankaj Raghav <p.raghav@...sung.com>
>>> ---
>>> drivers/md/dm-table.c | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
>>> index 03541cfc2317..2a8af70d1d4a 100644
>>> --- a/drivers/md/dm-table.c
>>> +++ b/drivers/md/dm-table.c
>>> @@ -251,6 +251,12 @@ static int device_area_is_invalid(struct dm_target *ti, struct dm_dev *dev,
>>> if (bdev_is_zoned(bdev)) {
>>> unsigned int zone_sectors = bdev_zone_sectors(bdev);
>>>
>>> + if (!is_power_of_2(zone_sectors)) {
>>> + DMWARN("%s: %pg only power of two zone size supported",
>>> + dm_device_name(ti->table->md), bdev);
>>> + return 1;
>>> + }
>>> +
>>> if (start & (zone_sectors - 1)) {
>>> DMWARN("%s: start=%llu not aligned to h/w zone size %u of %pg",
>>> dm_device_name(ti->table->md),
>>
>> I thought the agreed upon idea is be to add a dm-linear like target to
>> emulate power of 2 zone size so that we can keep btrfs and f2fs running on
>> this new class of device. So why this patch ?
>>
>> The entire series as is will fragment zoned block device support, which is
>> not a good thing at all. Without the new dm target, none of the current
>> kernel supported zone stuff will work.
>>
> I have mentioned this in my cover letter:
> The support is planned to be added in two phases:
> - Add npo2 support to block, nvme layer and necessary stop gap patches
> in the filesystems
> - Add dm target for npo2 devices so that they are presented as a po2
> device to filesystems
>
> This series is targeting the first phase where we have stop gap patches
> and add support to the block and nvme layer and in the next phase we
> will add a dm linear like target for npo2 zone sizes which can be used
> by all the filesystems. This patch makes sure that we can't use npo2
> zoned devices without the proper support that will be added in the next
> phase in the DM.
Personally, I do not want to see a kernel version where zone support is broken
for some devices. So I definitely prefer everything in one go or nothing.
>
> Even though we decided we would like to take the direction of DM, I am
> still awaiting reply from Christoph who raised concerns about npo2 zoned
> device support and Mike Snitzer about this approach. That is one of the
> reason I split this effort into two phases.
>> The zonefs patch is also gone from the series. Why ? As is, zonefs will
>> break if it is passed a non power of 2 zone size drive.
>>
> I think this was my mistake. If you agree with the above approach, then
> I can add a stop gap patch also to zonefs npo2 zoned devices. This way
> all the zone filesystem support goes via DM for npo2 zoned devices. I am
> proposing this so that initially we always have only one way of
> accessing a npo2 zoned device (via DM) from **filesystems** until we add
> native support.
--
Damien Le Moal
Western Digital Research
Powered by blists - more mailing lists