Re: [PATCH 0/2] New zoned loop block device driver

[Damien Le Moal <dlemoal@kernel.org>]

On 2/5/25 12:43 PM, Ming Lei wrote:
>>> Can you share how you create rublk/zoned and zloop and the underlying
>>> device info? Especially queue depth and nr_queues(both rublk/zloop &
>>> underlying disk) plays a big role.
>>
>> rublk:
>>
>> cargo run -r -- add zoned --size 524288 --zone-size 256 --conv-zones 0 \
>> 		--logical-block-size 4096 --queue ${nrq} --depth 128 \
>> 		--path /mnt/zloop/0
>>
>> zloop:
>>
>> echo "add conv_zones=0,capacity_mb=524288,zone_size_mb=256,\
>> base_dir=/mnt/zloop,nr_queues=${nrq},queue_depth=128" > /dev/zloop-control
> 
> zone is actually stateful, maybe it is better to use standalone backing
> directory/files.

I do not understand what you are saying... I reformat the backing FS and
recreate the same /mnt/zloop/0 directory for every test, to be sure I am not
seeing an artifact from the FS.

>> The backing storage is using XFS on a PCIe Gen4 4TB M.2 SSD (my Xeon machine is
>> PCIe Gen3 though). This drive has a large enough max_qid to provide one IO queue
>> pair per CPU for up to 32 CPUs (16-cores / 32-threads).
> 
> I just setup one XFS over nvme in real hardware, still can't reproduce the big gap in
> your test result. Kernel is v6.13 with zloop patch v2.
> 
> `8 queues` should only make a difference for the test of "QD=32,   4K rnd wr, 8 jobs".
> For other single job test, single queue supposes to be same with 8 queues.
> 
> The big gap is mainly in test of 'QD=32, 128K seq wr, 1 job ', maybe your local
> change improves zloop's merge? In my test:
> 
> 	- ublk/zoned : 912 MiB/s
> 	- zloop(v2) : 960 MiB/s.
> 
> BTW, my test is over btrfs, and follows the test script:
> 
>  fio --size=32G --time_based --bsrange=128K-128K --runtime=40 --numjobs=1 \
>  	--ioengine=libaio --iodepth=32 --directory=./ublk --group_reporting=1 --direct=1 \
> 	--fsync=0 --name=f1 --stonewall --rw=write

If you add an FS on top of the emulated zoned deive, you are testing the FS
perf as much as the backing dev. I focused on the backing dev so I ran fio
directly on top of the emulated drive. E.g.:

fio --name=test --filename=${dev} --rw=randwrite \
                --ioengine=libaio --iodepth=32 --direct=1 --bs=4096 \
                --zonemode=zbd --numjobs=8 --group_reporting --norandommap \
                --cpus_allowed=0-7 --cpus_allowed_policy=split \
                --runtime=${runtime} --ramp_time=5 --time_based

(you must use libaio here)

-- 
Damien Le Moal
Western Digital Research