On 11/08/2016 06:28 PM, Jens Axboe wrote:
On 11/08/2016 06:25 PM, Damien Le Moal wrote:
On 11/9/16 10:09, Christoph Hellwig wrote:
Ok, sounds like I'm really the one to blame. I'll see if I can
find a reproducer. Damien, or you using device mapper on that
system?
No LVM/md/dm used on boot. Mount is direct to the block device (SSDs
with ext4). The devices are simple SSDs, so no polling involved.
The hangs suspiciously look like they are either background write or
flush. So I was wondering if it is indeed related to FLUSH/FUA as Logan
suggested or the background write stuff, rather than the direct-IO
optimization & polling.
The background write stuff is not in either of those branches, plus the
backtrace would have looked different. Yours is showing us waiting for a
request. I don't think it's the direct-io or polling code, it looks like
a generic issue.
Will try again/bisect to see if I can get more info.
Maybe try and revert the one that Logan pointed his finger at, if that
is doable.
It smells like an accounting error. One thing that I don't like with the
current scheme is the implicit knowledge that certain flags imply sync
as well. If we clear any of those flags, then we screw up accounting at
the end.
Does this make a difference?
diff --git a/block/blk-flush.c b/block/blk-flush.c
index c486b7aa62ee..d70983e28115 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -395,6 +395,8 @@ void blk_insert_flush(struct request *rq)
if (!(fflags & (1UL << QUEUE_FLAG_FUA)))
rq->cmd_flags &= ~REQ_FUA;
+ rq->cmd_flags |= REQ_SYNC;
+
/*
* An empty flush handed down from a stacking driver may
* translate into nothing if the underlying device does not
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
