On 2020/02/04 12:57, Bob Liu wrote: > On 2/3/20 11:06 PM, Damien Le Moal wrote: >> On 2020/02/03 21:47, Bob Liu wrote: >>> On 1/8/20 3:40 PM, Damien Le Moal wrote: >>>> On 2020/01/08 16:13, Nobody wrote: >>>>> From: Bob Liu <bob.liu@xxxxxxxxxx> >>>>> >>>>> Motivation: >>>>> Now the dm-zoned device mapper target exposes a zoned block device(ZBC) as a >>>>> regular block device by storing metadata and buffering random writes in >>>>> conventional zones. >>>>> This way is not very flexible, there must be enough conventional zones and the >>>>> performance may be constrained. >>>>> By putting metadata(also buffering random writes) in separated device we can get >>>>> more flexibility and potential performance improvement e.g by storing metadata >>>>> in faster device like persistent memory. >>>>> >>>>> This patch try to split the metadata of dm-zoned to an extra block >>>>> device instead of zoned block device itself. >>>>> (Buffering random writes also in the todo list.) >>>>> >>>>> Patch is at the very early stage, just want to receive some feedback about >>>>> this extension. >>>>> Another option is to create an new md-zoned device with separated metadata >>>>> device based on md framework. >>>> >>>> For metadata only, it should not be hard at all to move to another >>>> conventional zone device. It will however be a little more tricky for >>>> conventional zones used for data since dm-zoned assumes that this random >>>> write space is also zoned. Moving this space to a conventional device >>>> requires implementing a zone emulation (fake zones) for the regular >>>> drive, using a zone size that matches the size of sequential zones. >>>> >>>> Beyond this, dm-zoned also needs to be changed to accept partial drives >>>> and the dm core code to accept mixing of regular and zoned disks (that >>>> is forbidden now). >>>> >>>> Another approach worth exploring is stacking dm-zoned as is on top of a >>>> modified dm-linear with the ability to emulate conventional zones on top >>>> of a regular block device (you only need report zones method >>>> implemented). >>> >>> Looks like the only way to do this emulation is in user space tool(dm-zoned-tools). >>> Write metadata(which contains emulated zone information constructed by dm-zoned-tools) >>> into regular block device. >> >> User space tool will indeed need some modifications to allow the new >> format. But I would not put this as "doing the emulation" since at that >> level, zones are only an information checked for alignment of metadata >> space and overall capacity of the target. With a regular disk holding the >> metadata, all that needs to be done is assume that this drive is ion fact >> composed solely of conventional zones with the same size as the larger SRM >> disk backend. The total set of zones "assumed" + "real zones from SMR" >> consitute the set of zones that dmzadm will work with for determining the >> overall format, while currently it only uses the set of real zones. >> >>> It's impossible to add code to every regular block device for emulating conventional zones. >> >> There is no need to do that. dm-zoned can emulate fake conventional zones > > Oh, what I intend to say is it's impossible adding "BLKREPORTZONE" to regular block device driver. > We have to construct fake zone information for regular device all by dmzadm, based on current information > we can get from regular device. OK. We are in sync. I misunderstood you. Yes, there is no need to emulate completely a zone disk at the driver level. dmzadm (and dm-zoned module) can generate a list of fake conventional zones very easily for the regular drive. > > $ dmzadm --format `regular device` `real zoned device` --force > >> for the regular device (disk or ssd) holding the metadata. Since >> conventional zones do not have any IO restriction nor do they need any zone >> management command (no zone reset), dm-zoned only needs to create a set of >> struct dm_zone for the emulated zones of the regular disk and "manually" >> fill the zone information. This initialization is done in dmz_init_zones(). >> Some changes there to create these struct dm_zone and all the remaining >> metadata and write buffering code should not need any change at all (modulo >> the different bdev reference). Do you see the idea ? >> >> The only place that will need some care is sync processing as 2 devices >> will need to be issued flushes instead of one. The reference to the >> different bdev depending on the zone being accessed will need some care in >> many places too, including reclaim. But dm-kcopy being used there, this >> should be fairly easy. >> >> Adding a bdevid (an index) field to struct dm_zone, together with an array >> of bdev pointers in struct dmz_dev, should do the trick to simplify >> zone-to-bdev or block-to-bdev conversions (helper functions needed for that). >> >> Thoughts ? >> > > Thank you for all these suggestions. > > Regards, > Bob > > > > -- Damien Le Moal Western Digital Research
