Correct GEOM bio handling

[Poul-Henning Kamp]

In message <20040610214726.G23746 at leelou.in.tern>, Lukas Ertl writes:

>A plex needs to be synced because its data is out-of-date.  The solution I 
>was thinking of is to create a kthread which reads the data from a 'good' 
>plex and writes it out to the 'bad' plex.  Now, it would be ideal if 
>'normal' requests (which are not part of this rebuild process) are already 
>accepted while the rebuild process is still on-going.

Normally what you do is you block the bad plex for reading but not
for writing.  That means all normal writes go also to the bad plex,
no matter where on the bad plex they are located.

Your rebuilder will then read from the good and write to the bad in
a sequential fashion, and when it is done, the bad plex is good too
and can be releases for reading.

Some implementations use compressed bitmaps, so that they know that
bits where a normal write happened can be skipped by the rebuilder.

Some even use "parasitic rebuild" where normal reads are written
to the bad plex as well (if not already up to date) in order to
save on the I/O operations.

>The rebuilding itself works fine, the requests on the waitqueue are 
>detected, but they seem to be ignored once I g_io_request() them, and the 
>process that initiated them is stuck.

Can you find where they are ?  Are they on the I/O list ?

What if you set debugflags=4, can you see where they went ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.