On 2010-06-28 10:14, FUJITA Tomonori wrote: > On Mon, 28 Jun 2010 09:57:38 +0200 > Christoph Hellwig <hch@xxxxxx> wrote: > >> On Sun, Jun 27, 2010 at 09:32:07PM +0900, FUJITA Tomonori wrote: >>> On Sun, 27 Jun 2010 13:07:12 +0200 >>> Christoph Hellwig <hch@xxxxxx> wrote: >>> >>>>> How about this? >>>> >>>> As I tried to explain before this utterly confuses the I/O completion >>>> path. With the patch applied even a simple mkfs.xfs that issues discard >>>> just hangs. >>> >>> Wired. I just tried mkfs.xfs against scsi_debug with my block patches >>> (I saw one discard command). Seemed that it worked fine. >> >> I've tracked it down to the call to scsi_requeue_command in scsi_end_request. >> When the command is marked BLOCK_PC we'll just get it back as such in >> ->prep_fn next time, but now it's reverting to the previous state. > > If scsi_end_request() calls scsi_requeue_command(), the command has a > left over (i.e. hasn't finished all the data), right? You hit such > condition with discard commands? > > BLOCK_PC requests don't hit this case since blk_end_request() always > return false for PC. You can get requeues on the ->queuecommand() path as well, for a variety of reasons, and that would be what Christoph is hitting. -- Jens Axboe -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
