Date: Tue, 25 Jul 2006 06:26:58 -0700 (PDT) From: "R. B. Riddick" <arne_woerner@yahoo.com> To: freebsd-geom@freebsd.org Subject: Re: new class / geom_raid5 Message-ID: <20060725132658.35256.qmail@web30313.mail.mud.yahoo.com> In-Reply-To: <20060714122936.17967.qmail@web30302.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- "R. B. Riddick" <arne_woerner@yahoo.com> wrote: > I solved the deadlock by pretending a lack of memory, so that the request, > that > was to be ->start()'ed is pushed back to the end of the down queue, which > slows > down all requests of every geom (due to pace) a little bit, doesn't it? > Now I put those write requests, that might be in violation of consistency rules, into an own queue, that is flushed, when the conflicting synchronization cycle is over... So now we do not have that artificial delay problem due to the ENOMEM trick... I hope, my assumption that the write requests are executed in the order they are g_io_request'ed, is right... Or isn't it? Is it necessary to wait for the call to ...done() before I order a conflicting g_io_request()? E. g.: If we had a write request A to a dirty area immediately before it is synchronized: Can we be sure, that the synchro-reads already find the data out of request A? Has somebody done some graid5-tests in the meantime? Am I doing something wrong? I mean: Regarding the etiquette of this list or so... -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060725132658.35256.qmail>