From: Pankaj Raghav <p.raghav@samsung.com> To: "Damien Le Moal" <damien.lemoal@opensource.wdc.com>, "Javier González" <javier.gonz@samsung.com>, "Hannes Reinecke" <hare@suse.de>, "Johannes Thumshirn" <Johannes.Thumshirn@wdc.com>, "Mike Snitzer" <snitzer@redhat.com>, "Christoph Hellwig" <hch@lst.de> Cc: Luis Chamberlain <mcgrof@kernel.org>, Theodore Ts'o <tytso@mit.edu>, "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>, Keith Busch <kbusch@kernel.org>, Adam Manzanares <a.manzanares@samsung.com> Subject: Re: [dm-devel] [PATCH v4 00/13] support non power of 2 zoned devices Date: Fri, 20 May 2022 11:30:09 +0200 [thread overview] Message-ID: <aee22e8a-b89b-378c-3d5b-238c1215b01d@samsung.com> (raw) In-Reply-To: <be429864-09cb-e3fb-2afe-46a3453c4d73@opensource.wdc.com> On 5/20/22 08:41, Damien Le Moal wrote: >>>>> >>>>> 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. >>>> Keith and Adam had a similar suggestion to go create a device mapper (dm-unholy) when we tried the po2 emulation[1]. >>>> +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. > I see that many people in the community feel it is better to target the dm layer for the initial support of npo2 devices. I can give it a shot and maintain a native out-of-tree support for FSs for npo2 devices and merge it upstream as we see fit later. [1] https://lore.kernel.org/all/20220311223032.GA2439@dhcp-10-100-145-180.wdc.com/
WARNING: multiple messages have this Message-ID (diff)
From: Pankaj Raghav <p.raghav@samsung.com> To: "Damien Le Moal" <damien.lemoal@opensource.wdc.com>, "Javier González" <javier.gonz@samsung.com>, "Hannes Reinecke" <hare@suse.de>, "Johannes Thumshirn" <Johannes.Thumshirn@wdc.com>, "Mike Snitzer" <snitzer@redhat.com>, "Christoph Hellwig" <hch@lst.de> Cc: "axboe@kernel.dk" <axboe@kernel.dk>, Theodore Ts'o <tytso@mit.edu>, "dm-devel@redhat.com" <dm-devel@redhat.com>, "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>, "dsterba@suse.com" <dsterba@suse.com>, Luis Chamberlain <mcgrof@kernel.org>, Adam Manzanares <a.manzanares@samsung.com>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, Jaegeuk Kim <jaegeuk@kernel.org>, Keith Busch <kbusch@kernel.org>, "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org> Subject: Re: [dm-devel] [PATCH v4 00/13] support non power of 2 zoned devices Date: Fri, 20 May 2022 11:30:09 +0200 [thread overview] Message-ID: <aee22e8a-b89b-378c-3d5b-238c1215b01d@samsung.com> (raw) In-Reply-To: <be429864-09cb-e3fb-2afe-46a3453c4d73@opensource.wdc.com> On 5/20/22 08:41, Damien Le Moal wrote: >>>>> >>>>> 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. >>>> Keith and Adam had a similar suggestion to go create a device mapper (dm-unholy) when we tried the po2 emulation[1]. >>>> +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. > I see that many people in the community feel it is better to target the dm layer for the initial support of npo2 devices. I can give it a shot and maintain a native out-of-tree support for FSs for npo2 devices and merge it upstream as we see fit later. [1] https://lore.kernel.org/all/20220311223032.GA2439@dhcp-10-100-145-180.wdc.com/ -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2022-05-20 9:30 UTC|newest] Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CGME20220516165418eucas1p2be592d9cd4b35f6b71d39ccbe87f3fef@eucas1p2.samsung.com> 2022-05-16 16:54 ` [PATCH v4 00/13] support non power of 2 zoned devices Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav [not found] ` <CGME20220516165419eucas1p104aadda60df323e6154bfc3b92103b7b@eucas1p1.samsung.com> 2022-05-16 16:54 ` [PATCH v4 01/13] block: make blkdev_nr_zones and blk_queue_zone_no generic for npo2 zsze Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav [not found] ` <CGME20220516165421eucas1p2515446ac290987bdb9af24ffb835b287@eucas1p2.samsung.com> 2022-05-16 16:54 ` [PATCH v4 02/13] block: allow blk-zoned devices to have non-power-of-2 zone size Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav 2022-05-16 19:05 ` Pankaj Raghav 2022-05-16 19:05 ` [dm-devel] " Pankaj Raghav [not found] ` <CGME20220516165422eucas1p174acec28848a9c2178376f092af3fa1c@eucas1p1.samsung.com> 2022-05-16 16:54 ` [PATCH v4 03/13] nvme: zns: Allow ZNS drives that have non-power_of_2 " Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav [not found] ` <CGME20220516165424eucas1p2ee38cd64260539e5cac8d1fa4d0cba38@eucas1p2.samsung.com> 2022-05-16 16:54 ` [PATCH v4 04/13] nvmet: Allow ZNS target to support non-power_of_2 zone sizes Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav 2022-05-17 14:19 ` Johannes Thumshirn 2022-05-17 14:19 ` [dm-devel] " Johannes Thumshirn [not found] ` <CGME20220516165425eucas1p29fcd11d7051d9d3a9a9efc17cd3b6999@eucas1p2.samsung.com> 2022-05-16 16:54 ` [PATCH v4 05/13] btrfs: zoned: Cache superblock location in btrfs_zoned_device_info Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav 2022-05-16 21:58 ` David Sterba 2022-05-16 21:58 ` [dm-devel] " David Sterba 2022-05-17 7:55 ` Pankaj Raghav 2022-05-17 7:55 ` [dm-devel] " Pankaj Raghav [not found] ` <CGME20220516165427eucas1p1cfd87ca44ec314ea1d2ddc8ece7259f9@eucas1p1.samsung.com> 2022-05-16 16:54 ` [PATCH v4 06/13] btrfs: zoned: Make sb_zone_number function non power of 2 compatible Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav 2022-05-17 6:53 ` Johannes Thumshirn 2022-05-17 6:53 ` [dm-devel] " Johannes Thumshirn 2022-05-17 11:51 ` David Sterba 2022-05-17 11:51 ` [dm-devel] " David Sterba [not found] ` <CGME20220516165428eucas1p1374b5f9592db3ca6a6551aff975537ce@eucas1p1.samsung.com> 2022-05-16 16:54 ` [PATCH v4 07/13] btrfs: zoned: use generic btrfs zone helpers to support npo2 zoned devices Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav 2022-05-17 12:30 ` David Sterba 2022-05-17 12:30 ` [dm-devel] " David Sterba 2022-05-18 9:40 ` Pankaj Raghav 2022-05-18 9:40 ` Pankaj Raghav 2022-05-18 11:21 ` David Sterba 2022-05-18 11:21 ` [dm-devel] " David Sterba 2022-05-19 4:13 ` Naohiro Aota 2022-05-19 4:13 ` [dm-devel] " Naohiro Aota [not found] ` <CGME20220516165429eucas1p272c8b4325a488675f08f2d7016aa6230@eucas1p2.samsung.com> 2022-05-16 16:54 ` [PATCH v4 08/13] btrfs:zoned: make sb for npo2 zone devices align with sb log offsets Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav 2022-05-17 6:50 ` Johannes Thumshirn 2022-05-17 6:50 ` Johannes Thumshirn 2022-05-17 8:00 ` Pankaj Raghav 2022-05-17 8:00 ` [dm-devel] " Pankaj Raghav 2022-05-17 12:42 ` David Sterba 2022-05-17 12:42 ` [dm-devel] " David Sterba 2022-05-18 9:15 ` Pankaj Raghav 2022-05-18 9:15 ` [dm-devel] " Pankaj Raghav 2022-05-19 7:57 ` Johannes Thumshirn 2022-05-19 7:57 ` [dm-devel] " Johannes Thumshirn 2022-05-20 9:06 ` Pankaj Raghav 2022-05-20 9:06 ` [dm-devel] " Pankaj Raghav 2022-05-20 9:15 ` Johannes Thumshirn 2022-05-20 9:15 ` [dm-devel] " Johannes Thumshirn 2022-05-19 7:59 ` Naohiro Aota 2022-05-19 7:59 ` [dm-devel] " Naohiro Aota 2022-05-20 9:09 ` Pankaj Raghav 2022-05-20 9:09 ` [dm-devel] " Pankaj Raghav [not found] ` <CGME20220516165430eucas1p214cca8eaba1db2c98d947444cad4f18f@eucas1p2.samsung.com> 2022-05-16 16:54 ` [PATCH v4 09/13] btrfs: zoned: relax the alignment constraint for zoned devices Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav [not found] ` <CGME20220516165432eucas1p2e1ea74d44738e44745f49e37b6b9e503@eucas1p2.samsung.com> 2022-05-16 16:54 ` [PATCH v4 10/13] zonefs: allow non power of 2 " Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav [not found] ` <CGME20220516165434eucas1p12b178fb83cc93470933e3d72c40e9004@eucas1p1.samsung.com> 2022-05-16 16:54 ` [PATCH v4 11/13] null_blk: " Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav 2022-05-17 4:12 ` kernel test robot 2022-05-17 4:12 ` [dm-devel] " kernel test robot [not found] ` <CGME20220516165435eucas1p1dff8d9d039a76278ef1c09dba4b4e1fe@eucas1p1.samsung.com> 2022-05-16 16:54 ` [PATCH v4 12/13] null_blk: use zone_size_sects_shift for " Pankaj Raghav 2022-05-16 16:54 ` [dm-devel] " Pankaj Raghav [not found] ` <CGME20220516165436eucas1p178d079302dae3a9fca696b13b0390deb@eucas1p1.samsung.com> 2022-05-16 16:54 ` [dm-devel] [PATCH v4 13/13] dm-zoned: ensure only power of 2 zone sizes are allowed Pankaj Raghav 2022-05-16 16:54 ` Pankaj Raghav 2022-05-17 8:10 ` [PATCH v4 00/13] support non power of 2 zoned devices Christoph Hellwig 2022-05-17 8:10 ` [dm-devel] " Christoph Hellwig 2022-05-17 9:18 ` Javier González 2022-05-17 9:18 ` [dm-devel] " Javier González 2022-05-18 8:00 ` Christoph Hellwig 2022-05-18 8:00 ` [dm-devel] " Christoph Hellwig 2022-05-19 15:25 ` Javier González 2022-05-19 15:25 ` [dm-devel] " Javier González 2022-05-17 15:34 ` Theodore Ts'o 2022-05-17 15:34 ` Theodore Ts'o 2022-05-18 23:06 ` Luis Chamberlain 2022-05-18 23:06 ` Luis Chamberlain 2022-05-19 3:08 ` Damien Le Moal 2022-05-19 3:08 ` Damien Le Moal 2022-05-19 3:12 ` Luis Chamberlain 2022-05-19 3:12 ` Luis Chamberlain 2022-05-19 3:19 ` Damien Le Moal 2022-05-19 3:19 ` Damien Le Moal 2022-05-19 7:34 ` Johannes Thumshirn 2022-05-19 7:34 ` Johannes Thumshirn 2022-05-20 3:47 ` Damien Le Moal 2022-05-20 3:47 ` Damien Le Moal 2022-05-20 6:07 ` Hannes Reinecke 2022-05-20 6:07 ` Hannes Reinecke 2022-05-20 6:27 ` Javier González 2022-05-20 6:27 ` Javier González 2022-05-20 6:41 ` Damien Le Moal 2022-05-20 6:41 ` Damien Le Moal [not found] ` <CGME20220520065941eucas1p105cf273ede995dc4bf92f3245fad09b1@eucas1p1.samsung.com> 2022-05-20 6:59 ` Javier González 2022-05-20 6:59 ` Javier González 2022-05-20 9:30 ` Pankaj Raghav [this message] 2022-05-20 9:30 ` Pankaj Raghav 2022-05-20 17:18 ` David Sterba 2022-05-20 17:18 ` David Sterba 2022-05-23 8:25 ` Pankaj Raghav 2022-05-23 8:25 ` Pankaj Raghav 2022-05-20 9:30 ` Johannes Thumshirn 2022-05-20 9:30 ` Johannes Thumshirn [not found] ` <CGME20220520101610eucas1p1822ca6014e2a1d55ae74476f83c4de1d@eucas1p1.samsung.com> 2022-05-20 10:16 ` Javier González 2022-05-20 10:16 ` Javier González [not found] <CGME20220516133922eucas1p1c891cd1d82539b4e792acb5d1aa74444@eucas1p1.samsung.com> 2022-05-16 13:39 ` Pankaj Raghav 2022-05-16 14:15 ` Damien Le Moal 2022-05-16 14:15 ` Damien Le Moal 2022-05-16 14:33 ` notnand
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=aee22e8a-b89b-378c-3d5b-238c1215b01d@samsung.com \ --to=p.raghav@samsung.com \ --cc=Johannes.Thumshirn@wdc.com \ --cc=a.manzanares@samsung.com \ --cc=axboe@kernel.dk \ --cc=damien.lemoal@opensource.wdc.com \ --cc=dm-devel@redhat.com \ --cc=dsterba@suse.com \ --cc=gost.dev@samsung.com \ --cc=hare@suse.de \ --cc=hch@lst.de \ --cc=jaegeuk@kernel.org \ --cc=javier.gonz@samsung.com \ --cc=jiangbo.365@bytedance.com \ --cc=kbusch@kernel.org \ --cc=linux-block@vger.kernel.org \ --cc=linux-btrfs@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=mcgrof@kernel.org \ --cc=pankydev8@gmail.com \ --cc=snitzer@redhat.com \ --cc=tytso@mit.edu \ /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: linkBe 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.