| Message ID | 20220525154957.393656-9-p.raghav@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | support non power of 2 zoned devices | expand |
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@samsung.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. 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.
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@samsung.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. 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.
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@samsung.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.
On 5/26/22 10:25, Damien Le Moal wrote: >> 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. > Ok. I will make sure the DM target is a part of the next series along with the zonefs patch. Meanwhile, could you review the patches for the block, nvme and null blk that is already a part of this series? I have made the changes in those patches as you requested in previous revisions. Thanks, Pankaj
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),
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@samsung.com> --- drivers/md/dm-table.c | 6 ++++++ 1 file changed, 6 insertions(+)