On 11/28/24 08:36, Bart Van Assche wrote: > > On 11/27/24 3:18 PM, Damien Le Moal wrote: >> The BIO that failed is not recovered. The user will see the failure. The error >> recovery report zones is all about avoiding more failures of plugged zone append >> BIOs behind that failed BIO. These can succeed with the error recovery. >> >> So sure, we can fail all BIOs. The user will see more failures. If that is OK, >> that's easy to do. But in the end, that is not a solution because we still need >> to get an updated zone write pointer to be able to restart zone append >> emulation. Otherwise, we are in the dark and will not know where to send the >> regular writes emulating zone append. That means that we still need to issue a >> zone report and that is racing with queue freeze and reception of a new BIO. We >> cannot have new BIOs "wait" for the zone report as that would create a hang >> situation again if a queue freeze is started between reception of the new BIO >> and the zone report. Do we fail these new BIOs too ? That seems extreme. > > This patch removes the disk->fops->report_zones() call from the > blk-zoned.c code: > https://lore.kernel.org/linux-block/20241119002815.600608-6-bvanassche@xxxxxxx/. > Is it really not possible to get that > approach working for SAS SMR drives? If a torn write happens, is the > residual information in the response from the drive reliable? Let me dig into this again and see if that can work. -- Damien Le Moal Western Digital Research
