Bart, +Omar who has a similar question on blktests side. On Wed, 2019-02-20 at 08:00 -0800, Bart Van Assche wrote: > On Wed, 2019-02-20 at 16:17 +0900, Damien Le Moal wrote: > > From: Shin'ichiro Kawasaki <shinichiro.kawasaki@xxxxxxx> > > > > For fio to correctly handle the zonemode=zbd mode with partitions of > > zoned block devices, the partition block device file must be > > identified > > as a zoned disk. However, partition block device files do not have > > a zoned sysfs file. This patch allows a correct identification of > > the > > device file zone model by accessing the sysfs "zoned" file of the > > holder disk for partition devices. > > > > Change get_zbd_model() function to resolve the symbolic link to the > > sysfs path to obtain the canonical sysfs path. The canonical sysfs > > path of a partition device includes both of the holder device name > > and > > the partition device name. If the given device is a partition > > device, > > cut the partition device name in the canonical sysfs path to access > > the "zoned" file in the holder device sysfs path. > > Please explain what makes you think that it makes sense to create > partitions on a zoned block device. An application that wants to write > to a partition of a zoned block device needs access to the whole disk > anyway to get permission to submit the BLKREPORTZONE and BLKRESETZONE > ioctls. So why would anyone create partitions on a zoned block device? The BLKREPORTZONE and BLKRESETZONE ioctls do work as expected when issued against a partition device. That is, the sector values involved with these ioctls get remapped against the partition sector range with an addition or substraction of the partition sector offset. For this to work correctly, the kernel partition code only allows partitions on zoned block devices if the partitions are zone aligned (please see the use of the function part_zone_aligned() in the kernel file block/partition-generic.c). So an application working with a partition of a zoned block device does not need to issue these ioctls against the entire disk. Now for the use case. Indeed, for host-managed disks, this is not a very compeling use case, nor is it commonly in use in the field as far as I know. Chunking a host-managed disk into smaller drives with dm-linear is likely a better option. There is one use case I have seen in the field though where a partition was created over the conventional zones space of a disk to create an essentially normal (i.e. randomly writable) disk to put an ext4 file system on top for a metadata DB to manage data stored on the remaining sequential zones of the disk. Such choice allows to simplify the overall system design by enabling the use of proven components (ext4, DB) rather than writing or porting everything to fit a pure zoned block device model. The main use case is for host-aware disks as these can be written randomly anywhere and so are in essence "normal" disks, more so considering the fact that these drives SCSI device type is "0x0", equivalent to regular disk devices. As such, partitioning host-aware disks in the same manner as regular disks generally are is a valid use case. Together with the blktests fixes we posted yesterday, the intent of this fix is to allow for running tests against partitions to check the kernel partition sector remapping for zoned block disks. Specific tests in blktests are not needed, we only need the ability to specify a partition device file in blktests config (TEST_DEVS variable). This is to improve test coverage. We also run these tests with the same intent (sector remapping verification) for dm-linear devices too. Thank you for your review. Best regards. -- Damien Le Moal Western Digital Research
