On Thu, Nov 8, 2018 at 12:12 AM Keith Busch [off-list ref] wrote:
On Thu, Nov 08, 2018 at 12:03:41AM +0800, Ming Lei wrote:
quoted
On Wed, Nov 7, 2018 at 11:47 PM Keith Busch [off-list ref] wrote:
quoted
On Wed, Nov 07, 2018 at 11:44:59PM +0800, Ming Lei wrote:
quoted
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