On 2023/8/1 19:06, Christoph Hellwig wrote: > On Tue, Aug 01, 2023 at 01:04:32PM +0200, Christoph Hellwig wrote: >> On Mon, Jul 31, 2023 at 06:28:01PM +0200, Hannes Reinecke wrote: >>> The flush machinery is sending flushes before and/or after the original >>> request (preflush/postflush). For blocked transports (ie during FC RSCN >>> handling) the transport will error out commands depending on the FAILFAST >>> setting. If FAILFAST is set the SCSI layer gets an STS_TRANSPORT error >>> (causing the I/O to be retried), but STS_ERROR if not set (causing I/O to >>> failed). >>> >>> So if the FAILFAST setting is _not_ aligned between flush_rq and the >>> original we'll get an error on the flush rq and a retry on the original rq, >>> causing the entire command to fail. >>> >>> I guess we need to align them. >> >> But you can't, because multiple pre/postflushes are coalesced into a >> single outstanding flush request. They can and will not match quite >> commonly. > > And if you mean the REQ_FAILFAST_TRANSPORT added by dm - this will > never even see the flush state machine, as that is run in dm-mpath > which then inserts the fully built flush request into the lower request > queue. At least for request based multipath, bio could hit it. Yes, multiple pre/postflushes are coalesced into a single flush request. So we can't figure out which request to use. >From the above explanation, can we just drop this inherit logic? It seems strange or wrong here. Thanks.
