linux-kernel - Re: [dm-devel] 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]

Date:	Tue, 29 May 2007 11:25:42 +0200
From:	"Stefan Bader" <sbader3@...glemail.com>
To:	"device-mapper development" <dm-devel@...hat.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-raid@...r.kernel.org, "Jens Axboe" <jens.axboe@...cle.com>,
	"David Chinner" <dgc@....com>, "Phillip Susi" <psusi@....rr.com>,
	"Stefan Bader" <Stefan.Bader@...ibm.com>,
	"Andreas Dilger" <adilger@...sterfs.com>,
	"Tejun Heo" <htejun@...il.com>
Subject: Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

2007/5/28, Alasdair G Kergon <agk@...hat.com>:
> On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
> > 1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP.
>
> The device-mapper position has always been that we require
>
> >  a zero-length BIO_RW_BARRIER
>
> (i.e. containing no data to read or write - or emulated, possibly
> device-specific)
>
> before we can provide full barrier support.
>   (Consider multiple active paths - each must see barrier.)
>

Couldn't the same be ac hived by doing a sort of suspend, issuing the
barrier request, calling flush to all mapped devices and then wait for
in-flight I/O to go to zero? This certainly has the aspect of
performance degradation (but that seem to be a generic problem with
barriers not being specific enough).

> Until every device supports barriers -EOPNOTSUP support is required.
>   (Consider reconfiguration of stacks of devices - barrier support is a
>    dynamic block device property that can switch between available and
>    unavailable at any time.)
>
Is only an issue if not doing barrier handling in dm. In that case the
support in the devices is helpful but not required.

For something else: Alasdair, I am not a hundred percent sure about
that but I think that just passing the barrier flag on to mapped
devices might in some (maybe they are rare) cases cause a layer above
to think all data is on-disk while this isn't necessarily true (see my
previous post). What do you think?

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/