Can zbc target use device file as backstore?

[dcstrange]

When i was trying to create a ZBC TCMU target as Zone block device emulator using this command,

/> cd /backstores/user:zbc
/backstores/user:zbc> create name=zbc0 size=20G cfgstring=model-HM/zsize-256/conv-10@/dev/sdb

with setting the dev file /dev/sdb as backing storage, but it failed.

I know it will work by a regular file, but since regular files will still pass through the file system which has a variable data block layout, I think it is probably not a good way to emulate the zone behavior in the physical address space.

So I wonder that if there is possible to use a physical device as the backstore of the zbc target, since I've noticed that the TCMU interface (maybe) allows doing this by target_core_iblock(). @

[julietteattard]

I looked at this too, and there were some operations that work on regular files but won't work on a block device file, specifically this truncate operation

tcmu-runner/file_zbc.c

Line 681 in ddc7d14

ret = ftruncate(zdev->fd, zdev->meta_size + cfg->dev_size);

There is also a very intentional looking check,

tcmu-runner/file_zbc.c

Line 789 in ddc7d14

if (!S_ISREG(st.st_mode)) {

which is where the immediate failure happens.

I don't think there's anything actively preventing a patchset from being authored to loosen the requirements, and I don't think it has anything to do with target_core_iblock, but more that managing the metadata and data blocks inside a much larger file (an entire block device) sounds complicated.

What do you mean by emulate the zone behavior in the physical address space ? Layout of the data of the data on the underlying (real) disk? Looking at the ext4 layout from my test system I don't see any indications of fragmentation, even after giving the disk a run-through with small writes multiple times.

[dcstrange]

Thanks, @ryanattard. I see it cannot work on the device file since it needs the ftruncate() operation to resize the file according to the user setting. But there are still my concerns.

My first concern is that access to the metadata of the file system will trigger more small I/O compared to operating on the original HM-SMR drive, especially if ext4 does not allocate inodes in advance.

Second, I'm afraid that the blocks of a zone may not be continuous in PBA when using the large regular file. For example, if I randomly write this file with small blocks across regions (the drive is empty at the beginning), the filesystem will allocate inodes and data pages on demand for these scattered LBA that does likely not correspond to the layout of PBA.

If I don't need ftruncate, why can't I use raw disks as backend storage?

[kdave]

I'd like to use the regular block device as backing device for zbc too, testing zoned support on btrfs. I can create the backing files on a regular filesystem but that's another layer of indirection that is IMO unnecessary. I've tried to omit the size= parameter so it could pick the real block device size instead, but the parameter is mandatory. Truncating block device may not work but if the size is exactly the same, it should work as for regular files. Requiring a regular file is IMO an artificial requirement that only limits the usecase.