On Thu, Oct 13, 2022 at 9:34 AM Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > > > Logan, > > > 2) We could split up the fallocate call into multiple calls to zero > > the entire disk. This would allow a quicker ctrl-c to occur, however > > it's not clear what the best size would be to split it into. Even > > zeroing 1GB can take a few seconds, > > FWIW, we default to 32MB per request in SCSI unless the device > explicitly advertises wanting something larger. Hi Martin If the upper layer submit 1GB request, SCSI will split them and handle 32MB requests in default. If the upper layer wants SCSI to handle 1GB one time, it needs to pass some information to SCSI, right? > > > (with NVMe, discard only requires a single command to handle the > > entire disk > > In NVMe there's a limit of 64K blocks per range and 256 ranges per > request. So 8GB or 64GB per request for discard depending on the block > size. So presumably it will take several operations to deallocate an > entire drive. Could you tell the command how to check the block size. blockdev --getsz tells the sector size of the device. It should not be the block size you mentioned here. It looks like we can decide the best size once the blocksize is found. Regards Xiao > > > where as write-zeroes requires a minimum of one command per 2MB of > > data to zero). > > 32MB for 512-byte blocks and 256MB for 4096-byte blocks. Which matches > how it currently works for SCSI devices. > > > I was hoping write-zeroes could be made faster in the future, at least > > for NVMe. > > Deallocate had a bit of a head start and vendors are still catching up > in the zeroing department. Some drives do support using Deallocate for > zeroing and we quirk those in the driver so they should perform OK with > your change. > > -- > Martin K. Petersen Oracle Linux Engineering >
