Jens, On 11/9/16 11:02, Jens Axboe wrote: > 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 That worked. Still seeing hangs/failures at boot with the latest for-4.10/block (networkmanager failing, no login shell, etc) but with the above patch, I get a clean boot and login with network working. Once booted, simple tests on ext4 and xfs do not show any problem, but that was only very light testing. Best regards. -- Damien Le Moal, Ph.D. Sr. Manager, System Software Research Group, Western Digital Corporation Damien.LeMoal@xxxxxxx (+81) 0466-98-3593 (ext. 513593) 1 kirihara-cho, Fujisawa, Kanagawa, 252-0888 Japan www.wdc.com, www.hgst.com -- 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
