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: <20070531194005.GH32105@kernel.dk>
Date:	Thu, 31 May 2007 21:40:06 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	david@...g.hm
Cc:	Phillip Susi <psusi@....rr.com>, David Chinner <dgc@....com>,
	Neil Brown <neilb@...e.de>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, dm-devel@...hat.com,
	linux-raid@...r.kernel.org, Stefan Bader <Stefan.Bader@...ibm.com>,
	Andreas Dilger <adilger@...sterfs.com>,
	Tejun Heo <htejun@...il.com>
Subject: Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems,   and dm/md.

On Thu, May 31 2007, david@...g.hm wrote:
> On Thu, 31 May 2007, Jens Axboe wrote:
> 
> >On Thu, May 31 2007, Phillip Susi wrote:
> >>David Chinner wrote:
> >>>That sounds like a good idea - we can leave the existing
> >>>WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
> >>>behaviour that only guarantees ordering. The filesystem can then
> >>>choose which to use where appropriate....
> >>
> >>So what if you want a synchronous write, but DON'T care about the order?
> >>  They need to be two completely different flags which you can choose
> >>to combine, or use individually.
> >
> >If you have a use case for that, we can easily support it as well...
> >Depending on the drive capabilities (FUA support or not), it may be
> >nearly as slow as a "real" barrier write.
> 
> true, but a "real" barrier write could have significant side effects on 
> other writes that wouldn't happen with a synchronous wrote (a sync wrote 
> can have other, unrelated writes re-ordered around it, a barrier write 
> can't)

That is true, the sync write also has side effects at the drive side
since it may have a varied cost depending on the workload (eg what
already resides in the cache when it is issued), unless FUA is active.
That is also true for the barrier of course, but only for previously
submitted IO as we don't reorder.

I'm not saying that a SYNC write wont be potentially useful, just that
it's definitely not free even outside of the write itself.

-- 
Jens Axboe

-
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/