Date: Thu, 10 Jun 2004 22:13:08 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Lukas Ertl <le@freebsd.org> Cc: geom@freebsd.org Subject: Re: Correct GEOM bio handling Message-ID: <65669.1086898388@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 10 Jun 2004 22:05:22 %2B0200." <20040610214726.G23746@leelou.in.tern>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20040610214726.G23746@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?65669.1086898388>