On 2020/06/02 19:18, Coly Li wrote: > On 2020/6/2 16:54, Damien Le Moal wrote: >> On Tue, 2020-06-02 at 00:06 +0800, Coly Li wrote: >>>>> + * cache device. >>>>> + */ >>>>> + if (bio_op(bio) == REQ_OP_ZONE_RESET_ALL) >>>>> + nr_zones = s->d->disk->queue->nr_zones; >>>> >>>> Not: sending a REQ_OP_ZONE_RESET BIO to a conventional zone will be failed by >>>> the disk... This is not allowed by the ZBC/ZAC specs. So invalidation the cache >>>> for conventional zones is not really necessary. But as an initial support, I >>>> think this is fine. This can be optimized later. >>>> >>> Copied, will think of how to optimized later. So far in my testing, >>> resetting conventional zones may receive error and timeout from >>> underlying drivers and bcache code just forwards such error to upper >>> layer. What I see is the reset command hangs for a quite long time and >>> failed. I will find a way to make the zone reset command on conventional >>> zone fail immediately. >> >> It is 100% guaranteed that a zone reset issued to a conventional zone >> will fail. That is defined in ZBC/ZAC specifications. Resetting a >> single conventional zone is an error. We know the command will fail and >> the failure is instantaneous from the drive. The scsi layer should not >> retry these failed reset zone command, we have special error handling >> code preventing retries since we know that the command can only fail >> again. So I am not sure why you are seeing hang/long time before the >> failure is signaled... This may need investigation. >> >> > > Copied. Currently I plan to add a first_seq_zone_nr to bcache on-disk > super block, its value will be set by user space bcache-tools when the > backing device is formatted for bcache. Then the zone reset bio which > has smaller zone number will be rejected immediately by bcache code. > > This requires on-disk format change, I will do it later with other > on-disk change stuffs. I do not think you actually need an on-disk format change for this since that information can simply live in memory. Also, it is not entirely correct to assume that all conventional zones are at LBA 0 onward up to the first sequential zone. It just happens that this is what drives on the market look like today, but the standard allows conventional zones to be anywhere in the disk address space. The safe way to handle this is to do something like the block layer does using a bitmap indicating if a zone is sequential or conventional. Not that using the bitmap already attached to the device request queue is possible but not safe since the backend device could be a DM target, so a BIO device with a request queue that does not have zone bitmaps. So allocating your own bitmap and doing a report zones to initialize it when the device is started is safer and will give you something very solid with no on-disk format change needed. See fs/f2fs/super.c function init_blkz_info(), that is exactly what is done: allocation and initialization of a bitmap to identify zone types. > > Coly Li > -- Damien Le Moal Western Digital Research
