new class / geom_raid5

[R. B. Riddick]

--- "R. B. Riddick" <arne_woerner at 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