On 2020/04/19 0:56, Bart Van Assche wrote: > On 2020-04-17 05:15, Johannes Thumshirn wrote: >> In order to reduce memory consumption, the only cached item is the offset >> of the write pointer from the start of the zone, everything else can be >> calculated. On an example drive with 52156 zones, the additional memory >> consumption of the cache is thus 52156 * 4 = 208624 Bytes or 51 4k Byte >> pages. The performance impact is neglectable for a spinning drive. > > What will happen if e.g. syzkaller mixes write() system calls with SG_IO > writes? Can that cause a mismatch between the cached write pointer and > the write pointer maintained by the drive? If so, should SG_IO perhaps > be disallowed if the write pointer is cached? Bart, Yes, SG_IO write will change the WP on the device side, causing the driver WP cache to go out of sync with the device. We actually use that for testing and generating write errors. But that is not a problem limited to this new write pointer caching scheme. Any zoned drive user can hit this problem (dm-zoned or f2fs currently). More generally speaking, SG_IO writes can corrupt data/metadata on any regular disk without (for instance) the file system noticing until the corrupted data/metadata is accessed. SG_IO to a disk is not disabled if the disk has a mounted file system. Also, since the series adds unconditional write pointer caching with CONFIG_BLK_DEV_ZONED enabled, that would disable SG_IO permanently in this case, and negatively impact a lot of userspace tools relying on it (FW update, power management, SMART, etc). -- Damien Le Moal Western Digital Research
