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: <200706022257.l52MvGc06632@www.watkins-home.com>
Date:	Sat, 2 Jun 2007 18:57:11 -0400
From:	"Guy Watkins" <linux-raid@...kins-home.com>
To:	"'Jens Axboe'" <jens.axboe@...cle.com>,
	"'Tejun Heo'" <htejun@...il.com>
Cc:	"'David Chinner'" <dgc@....com>, <david@...g.hm>,
	"'Phillip Susi'" <psusi@....rr.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>
Subject: RE: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems,   and dm/md.

} -----Original Message-----
} From: linux-raid-owner@...r.kernel.org [mailto:linux-raid-
} owner@...r.kernel.org] On Behalf Of Jens Axboe
} Sent: Saturday, June 02, 2007 10:35 AM
} To: Tejun Heo
} Cc: David Chinner; david@...g.hm; Phillip Susi; Neil Brown; linux-
} fsdevel@...r.kernel.org; linux-kernel@...r.kernel.org; dm-
} devel@...hat.com; linux-raid@...r.kernel.org; Stefan Bader; Andreas Dilger
} Subject: Re: [RFD] BIO_RW_BARRIER - what it means for devices,
} filesystems, and dm/md.
} 
} On Sat, Jun 02 2007, Tejun Heo wrote:
} > Hello,
} >
} > Jens Axboe wrote:
} > >> Would that be very different from issuing barrier and not waiting for
} > >> its completion?  For ATA and SCSI, we'll have to flush write back
} cache
} > >> anyway, so I don't see how we can get performance advantage by
} > >> implementing separate WRITE_ORDERED.  I think zero-length barrier
} > >> (haven't looked at the code yet, still recovering from jet lag :-)
} can
} > >> serve as genuine barrier without the extra write tho.
} > >
} > > As always, it depends :-)
} > >
} > > If you are doing pure flush barriers, then there's no difference.
} Unless
} > > you only guarantee ordering wrt previously submitted requests, in
} which
} > > case you can eliminate the post flush.
} > >
} > > If you are doing ordered tags, then just setting the ordered bit is
} > > enough. That is different from the barrier in that we don't need a
} flush
} > > of FUA bit set.
} >
} > Hmmm... I'm feeling dense.  Zero-length barrier also requires only one
} > flush to separate requests before and after it (haven't looked at the
} > code yet, will soon).  Can you enlighten me?
} 
} Yeah, that's what the zero-length barrier implementation I posted does.
} Not sure if you have a question beyond that, if so fire away :-)
} 
} --
} Jens Axboe

I must admit I have only read some of the barrier related posts, so this
issue may have been covered.  If so, sorry.

What I have read seems to be related to a single disk.  What if a logical
disk is used (md, LVM, ...)?  If a barrier is issued to a logical disk and
that driver issues barriers to all related devices (logical or physical),
all the devices MUST honor the barrier together.  If 1 device crosses the
barrier before another reaches the barrier, corruption should be assumed.
It seems to me each block device that represents more than 2 other devices
must do a flush at a barrier so that all devices will cross the barrier at
the same time.

Guy

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