Date: Sat, 9 Dec 2017 19:24:03 -0700 From: Warner Losh <imp@bsdimp.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Mark Johnston <markj@freebsd.org>, Andriy Gapon <avg@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r326731 - head/sys/ufs/ffs Message-ID: <CANCZdfo2ExUoPAapN=TfU7PKAS9ncjYDWWntKn_M4c2T7e_RXQ@mail.gmail.com> In-Reply-To: <73337.1512865023@critter.freebsd.dk> References: <201712091544.vB9FiVUI096790@repo.freebsd.org> <a1d303b4-14b8-6a3d-3648-96a69bed7144@FreeBSD.org> <20171209223713.GA15275@raichu> <CANCZdfrSLKpwj_YVP-8k%2BWcJKPGqdvjZbCJgTFXCgbY7_6QUqw@mail.gmail.com> <73189.1512862030@critter.freebsd.dk> <CANCZdfrQPSey1h%2BX_09GNJaeZqsZh6FmDXe6avO66qKEfAL=Pg@mail.gmail.com> <73337.1512865023@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 9, 2017 at 5:17 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > -------- > In message <CANCZdfrQPSey1h+X_09GNJaeZqsZh6FmDXe6avO66qKEfAL= > Pg@mail.gmail.com>, Warner Losh writes: > > >That would be strange given that BIO_ORDERED is @gibbs baby ? > > > >Nah... I wrote the iosched code... and I find the concept somewhat flawed > >since it is at the disk level, not the partition level, so it winds up > >interfering with mixed traffic. And it really only makes sense for writes, > >but it affects reads. And it is a poor fit to Ata semantics, and not a lot > >better for scsi. And for nvme it creates a bottleneck in hardware > carefully > >designed to be free of bottlenecks... > > Don't take my comment as an endorsement of BIO_ORDERED... > > I think ordering is strictly a consumer responsibility for exactly > (and then some) of the reasons you mention. > > "End to end principle in systems design" and all that... Yes. I'd like to kill it completely... It's not needed and fosters the notion that there's more determinism in the ordering of events in the I/O stack than has existed since tagged queueing was a thing in the 90's. But there's no such thing as barriers in I/O devices today: that's handled in software by draining the queue, doing the one I/O, then starting the queue back up again.... So I'm with you that it's the client's job to wait for write X to complete before scheduling writes that depend on X to the I/O system. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo2ExUoPAapN=TfU7PKAS9ncjYDWWntKn_M4c2T7e_RXQ>