On 2020/09/08 23:02, Ian S. Worthington wrote: > Hello Damien -- > > Many thanks indeed for this most comprehensive answer. > >> On Linux, one easy thing to check is to look at: >> >> cat /sys/block/<disk name>/device/scsi_disk/X:Y:Z:N/zoned_cap >> >> A drive managed SMR disk that is no hiding its true nature will say >> "drive-managed". You will need kernel 5.8 to have this attribute files. >> Otherwise, you can use SG to inspect the VPD page 0xB1 (block device >> characteristics). Look for the value of bits 4-5 of byte 8 (ZONED field). If > the >> value is 2 (10b), then your disk is a drive managed SMR disk. > > I'm not on 5.8, so I guess that's why I don't have a zoned_cap. But: > > sudo sg_vpd --page=bdc /dev/sda > Block device characteristics VPD page (SBC): > Nominal rotation rate: 5400 rpm > Product type: Not specified > WABEREQ=0 > WACEREQ=0 > Nominal form factor not reported > ZONED=0 > RBWZ=0 > BOCS=0 > FUAB=0 > VBULS=0 > DEPOPULATION_TIME=0 (seconds) > > sudo sg_vpd --page=bdc -H /dev/sda > Block device characteristics VPD page (SBC): > 00 00 b1 00 3c 15 18 00 00 00 00 00 00 00 00 00 00 ...<............ > 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > This seems to suggest that this is NOT a "drive managed SMR disk". Are there > other types of SMR disks that could have zoned=0? zoned=0 means "not reported". So either your disk is a regular CMR one, or it is a drive-managed SMR one but it is not confirming it :) At this point, you may want to contact your drive vendor to ask for information. Some vendors (e.g. WD) already have clarified which of their drive models are drive managed SMR. Google it and you may be able to find more information online. > >>> 1. Why is the average speed, 2MB/s, so much lower than that reported by >>> CrystalDiskMark? >> >> Likely because CrystalDiskMark is very short and does not trigger internal >> sector management (GC) by the disk. Your 10h run most likely did. > > Unfortunately, it was showing that speed pretty much from the start. I ran it > again in three runs, both of 4k randwrite, with sizes of 256MB and 1GB (the > same as I used in my CDM test), and 10GB, viz: > > sudo fio --name SPINUP --eta-newline=5s --eta-interval=5s > -filename=/dev/sda --rw=randwrite --size=100t --io_size=14t --ioengine=libaio > --iodepth=4 --direct=1 --numjobs=1 --runtime=1m --group_reporting > --blocksize=4k > sudo fio --name 4K256m --eta-newline=5s --eta-interval=5s -filename=/dev/sda > --rw=randwrite --size=256m --io_size=256m --ioengine=libaio --iodepth=1 > --direct=1 --numjobs=1 --group_reporting --blocksize=4k > sudo fio --name 4K1g --eta-newline=5s --eta-interval=5s -filename=/dev/sda > --rw=randwrite --size=1g --io_size=1g --ioengine=libaio --iodepth=1 > --direct=1 --numjobs=1 --group_reporting --blocksize=4k > sudo fio --name 4K10g --eta-newline=5s --eta-interval=5s -filename=/dev/sda > --rw=randwrite --size=10g --io_size=10g --ioengine=libaio --iodepth=1 > --direct=1 --numjobs=1 --group_reporting --blocksize=4k --runtime=5m > > size KiB/s bw-min max avg (KiB/s) > 256MB 3216 1600 6896 3216 > 1G 3265 1712 12008 3263 > 10G 2886 1264 6976 2885 4K@QD=4 random write at 3MB/s is actually pretty normal. That is about 800 IOPS. I am getting similar results with CMR disks too. > I've noticed that always after finishing running these tests there minutes of > head seeking noise from the drive. Is this the GC to which you refer? I'm > curious as to what might it actually doing during this time, if we assume that > SG_VPD is correctly reporting that this is NOT an SMR drive? Is there other > internal sector management that it might be doing? Well, yes. There are a lot of things that drives can do to try to improve small random IO performance, especially writes. E.g. use opportunistic media caching (not in place writes) is special reserved areas of the disk, transforming the random pattern into a more sequential one. And such method of course results in these media cache areas being cleaned up later to free space (sectors are moved in place). And if this is really a drive managed SMR disk, then GC is a possibility too. But this is all speculation. Again, without detailed knowledge of the disk FW implementation (and if it is SMR or not), this is all guess work. > If I ran a test where I filled the drive to capacity using sequential writes > so the drive recorded all sectors as being in use, then wrote 10TB randwrite > using a 1MB blocksize to fill as much of any CMR cache as possible, then > finally redid the 10 hour test with 4k randwrite, could I then compare the > results of that final test to the short tests to definitively show if there > were any slowdowns that might be caused by reshingling in that final test? No idea. I do not think this can give a definitive/reliable answer. Getting clear information from the drive vendors seems to me like a much easier solution :) -- Damien Le Moal Western Digital Research
