Date: Mon, 13 Aug 2007 19:14:01 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Ivan Voras <ivoras@fer.hr> Cc: freebsd-geom@freebsd.org Subject: Re: Gvirstor "newfs" problem - help needed Message-ID: <20070813171401.GA8819@garage.freebsd.pl> In-Reply-To: <f9phs4$ov8$1@sea.gmane.org> References: <f9oaqg$ggm$1@sea.gmane.org> <31903.4141.qm@web30306.mail.mud.yahoo.com> <f9phs4$ov8$1@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Aug 13, 2007 at 02:12:50PM +0200, Ivan Voras wrote:
> Arne W=F6rner wrote:
> > Hi!
> >=20
> > --- Ivan Voras <ivoras@fer.hr> wrote:
> >> cg 0: bad magic number
> >>
> > I know that message from my tests with graid5...
> > It was clearly caused by a bug in graid5, but I cannot remember when or=
why it
> > happened...
> > I would guess, it happened because of some cache or request-sorting
> > mismanagement (the write didnt take place but the read was executed; or=
the
> > second write took place before the first write)... Is that possible in
> > gvirstor? Does newfs create such a request-pattern (overlapping write r=
equests
> > <-- would be a little bit astonishing)?
> >=20
> > But I can definitely say, that it was a bug in graid5...
>=20
> Thanks for replying! gvirstor doesn't reorder IO and i doesn't have a
> cache, so it's not that. I agree that it's almost certainly a bug in
> gvirstor.
>=20
> The only "slightly unusual" thing newfs does is that it first writes a
> "big" block, then reads a smaller block from within the written big
> block and doesn't like what it gets. But this scenario is well tested by
> my test cases and I don't see why it fails for newfs.
Ivan, try to configure gvirstor on top of gnop. Modify gnop to log only
requests between 81920 and 147456 (81920 + 65536). Something like:
if ((bp->bio_offset >=3D 81920 && bp->bio_offset < 147456) ||
(bp->bio_offset + bp->bio_length >=3D 81920 &&
bp->bio_offset + bp->bio_length < 147456)) {
G_NOP_LOGREQ(bp, "Request.");
}
Run newfs and watch which gvirstor I/O request triggers request into
this area - my guess is that gvirstor recalculates something incorrectly
and instead of writting somewhere else it writes into this very place.
--=20
Pawel Jakub Dawidek http://www.wheel.pl
pjd@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
--ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQFGwJFZForvXbEpPzQRAuKdAKCP+6v6rVdVfA21jRIwoth2QYEUEgCg1O7K
lo7h3RwFK10hHsKTTMlkrN8=
=NSgv
-----END PGP SIGNATURE-----
--ew6BAiZeqk4r7MaW--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070813171401.GA8819>