On Thu, Nov 8, 2018 at 12:12 AM Keith Busch <keith.busch@xxxxxxxxx> wrote: > > On Thu, Nov 08, 2018 at 12:03:41AM +0800, Ming Lei wrote: > > On Wed, Nov 7, 2018 at 11:47 PM Keith Busch <keith.busch@xxxxxxxxx> wrote: > > > > > > On Wed, Nov 07, 2018 at 11:44:59PM +0800, Ming Lei wrote: > > > > blk_update_request() may tell us how much progress made, :-) > > > > > > Except when it doesn't, which is 100% of the time for many block > > > drivers, including nvme. > > > > Please look at blk_mq_end_request()(<- nvme_complete_rq()), which > > calls blk_update_request(). > > Huh? That just says 100% of the request size was transerred no matter > what was actually transferred. > > The protocol doesn't have a way to express what transfer size occured > with a command's completion, and even it did, there's no way I'd trust > every firmware not to screw it. That sounds something like below: 1) userspace requires to read 8 sectors starting from sector 0 2) nvme tells hardware to do that, and hardware transfers only 4 sectors(0~3) data to memory, but still tells driver we have done 8 sectors(0~7). What if there are real data in sectors 4~7? Is it NVMe specific issue or common problem in other storage hardware? SCSI does call blk_update_request() and handles partial completion. Thanks, Ming Lei
