Date: Sat, 9 Dec 2017 17:37:13 -0500 From: Mark Johnston <markj@freebsd.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r326731 - head/sys/ufs/ffs Message-ID: <20171209223713.GA15275@raichu> In-Reply-To: <a1d303b4-14b8-6a3d-3648-96a69bed7144@FreeBSD.org> References: <201712091544.vB9FiVUI096790@repo.freebsd.org> <a1d303b4-14b8-6a3d-3648-96a69bed7144@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 09, 2017 at 08:03:37PM +0200, Andriy Gapon wrote: > On 09/12/2017 17:44, Mark Johnston wrote: > > Some GEOMs do not appear to handle BIO_ORDERED correctly, meaning that the > > Nitpick: this should be "geoms" or, even better, "GEOM classes" :-) Ok. :) > > barrier write may not work as intended. > Could the loss of BIO_ORDERED in g_duplicate_bio() contribute to the problem > with those GEOM classes? It does look like a bug that g_duplicate_bio() doesn't preserve that flag. However, the issue I was looking at was in gmirror: when a mirror is being synchronized, gmirror will delay writes that collide with an active synchronization request. However, subsequent writes which do not collide are passed directly to the mirrors, so an ordering violation is possible. I plan to fix this. I haven't checked, but graid might have a similar issue. I also noticed that gsched doesn't take BIO_ORDERED into account when sorting requests. Isilon has an I/O scheduler which has this problem too.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171209223713.GA15275>