linux-kernel - Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5201e28f0705290212q60dc1bcfkfc234b321f3c3b64@mail.gmail.com>
Date:	Tue, 29 May 2007 11:12:27 +0200
From:	"Stefan Bader" <sbader3@...glemail.com>
To:	"Neil Brown" <neilb@...e.de>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	dm-devel@...hat.com, linux-raid@...r.kernel.org,
	"Jens Axboe" <jens.axboe@...cle.com>,
	"David Chinner" <dgc@....com>, "Alasdair Kergon" <agk@...hat.com>
Subject: Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

> > 2007/5/25, Neil Brown <neilb@...e.de>:
> > BIO_RW_FAILFAST: means low-level driver shouldn't do much (or no)
> > error recovery. Mainly used by mutlipath targets to avoid long SCSI
> > recovery. This should just be propagated when passing requests on.
>
> Is it "much" or "no"?
> Would it be reasonable to use this for reads from a non-degraded
> raid1?  What about writes?
>
This depends on the device driver's implementation. AFAIK there is no
fix rule how to handle that flag exactly. The SCSI driver seems to
omit internal recovery procedures but requests still can take as long
as the SCSI request time-out. I am not sure of all internals. Maybe
some error recovery is done as long as it shouldn't take very long.
For the DASD driver on zSeries this flags will only affect situations
when the driver decides there is no other way of succeeding. Recovery
is still done.
Using this flag was intended to move error handling to an upper layer
in the device stack. For multipathing it is good to be able to map a
request to another path instead of waiting until the SCSI layer
finally would give up with one path. For a RAID1 this might cause
requests to fail which would have been recovered. This might require
more error handling in md.
The error code as it is at this time doesn't say much in detail. I
once saw patches (and there are comments about a path missing from
Jens Axboe) to pass sense data (from SCSI) in the bio. I am not sure
whether this was dropped for some reason or just is in the pipe. Jens?

Stefan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/