Re: Moving a chunk - a related question

Hi, thanks very much for the responses. I did indeed re-link the down primary chunk to a new device and used onspaces to bring that chunk back online. (I had already tried that in the first place and got "Chunk does not exist" errors - which is why I thought I couldn't do it, but I think that replacement device must have also been faulty). Now I have another question! I've another down primary chunk (with an online mirror) - but in fact I really just want to drop these chunks. Do I have to mend them first as above, or will it let me drop the mirror and then drop a down chunk ..? Thankyou, Rosemary "Art S. Kagel" <art.kagel@gmail.com> wrote in message news:0d0e8586-f7f4-4a52-b7ca-8fdf9886e926@a39g2000pre.googlegroups.com... > On Nov 28, 8:28 am, "Rosie Rhodes" <rosem...@spider-networks.net> > wrote: >> Hi, >> I'd like to ask a question about this method (at the risk of appearing >> dim) - but in relation to having a broken disk affecting a primary chunk >> of >> a mirrored pair. > > You're working too hard. If a primary chunk fails and you have an > existing IDS mirror chunk for that chunk, > then you simply relink the damaged link to the replacement chunk and > use onspaces to mark the chunk back online. IDS will copy from the > good mirror to the replacement drive marking it inconsistent instead > of down until the copy completes. Once THAT sync operation completes, > IFF you want the original mirror to be the primary and the new disk > the mirror you would shutdown and swap the links then restart. > > Art S. Kagel > >> In a search of the archives I've seen this method given as a solution to >> having a primary chunk down due to disk failure (which is my problem) - >> the >> process being: >> >> 1. shutdown >> 2. swap the links, ie. link the primary to the mirror device and the >> mirror >> to the primary device >> 3. restart >> 4. drop and recreate the mirror. >> >> But when I tested this (on a healthy system) - >> I marked a primary chunk as down , shutdown. >> Swapped links, restarted - and the primary chunk is still marked as down, >> the mirror as online. >> But now, I can't drop the mirror until the primary is online. >> So I can run onspaces to bring the primary online. But it verifies the >> chunk >> by copying from the mirror (so I gather from onstat -D ) ..... but the >> mirror is now the disk which is broken, so although this works on my >> healthy >> system, it presumably won't work on the real problem ... ? >> (I did also try linking the primary to the mirror and the mirror to a >> replacement unused device - that just gave me assert-failed errors as I >> expected and ended up with both chunks down) >> >> Am I missing something ? >> Or do I actually have to do the dd thing. (I was hoping not because of >> the >> downtime)

"Rosie Rhodes" <rosemary@spider-networks.net> wrote in message news:39w7j.1969$eU4.65@newsfe4-win.ntli.net... > Hi, > thanks very much for the responses. > I did indeed re-link the down primary chunk to a new device and used > onspaces to bring that chunk back online. > (I had already tried that in the first place and got "Chunk does not > exist" errors - which is why I thought I couldn't do it, but I think that > replacement device must have also been faulty). > > Now I have another question! I've another down primary chunk (with an > online mirror) - but in fact I really just want to drop these chunks. > Do I have to mend them first as above, or will it let me drop the mirror > and then drop a down chunk ..? Ok sorry .. that was a bit dim - ignore that question, I have just dropped the dbspace as a whole using onspaces -d <dbspace> > Thankyou, > Rosemary > > "Art S. Kagel" <art.kagel@gmail.com> wrote in message > news:0d0e8586-f7f4-4a52-b7ca-8fdf9886e926@a39g2000pre.googlegroups.com... >> On Nov 28, 8:28 am, "Rosie Rhodes" <rosem...@spider-networks.net> >> wrote: >>> Hi, >>> I'd like to ask a question about this method (at the risk of appearing >>> dim) - but in relation to having a broken disk affecting a primary chunk >>> of >>> a mirrored pair. >> >> You're working too hard. If a primary chunk fails and you have an >> existing IDS mirror chunk for that chunk, >> then you simply relink the damaged link to the replacement chunk and >> use onspaces to mark the chunk back online. IDS will copy from the >> good mirror to the replacement drive marking it inconsistent instead >> of down until the copy completes. Once THAT sync operation completes, >> IFF you want the original mirror to be the primary and the new disk >> the mirror you would shutdown and swap the links then restart. >> >> Art S. Kagel >> >>> In a search of the archives I've seen this method given as a solution to >>> having a primary chunk down due to disk failure (which is my problem) - >>> the >>> process being: >>> >>> 1. shutdown >>> 2. swap the links, ie. link the primary to the mirror device and the >>> mirror >>> to the primary device >>> 3. restart >>> 4. drop and recreate the mirror. >>> >>> But when I tested this (on a healthy system) - >>> I marked a primary chunk as down , shutdown. >>> Swapped links, restarted - and the primary chunk is still marked as >>> down, >>> the mirror as online. >>> But now, I can't drop the mirror until the primary is online. >>> So I can run onspaces to bring the primary online. But it verifies the >>> chunk >>> by copying from the mirror (so I gather from onstat -D ) ..... but the >>> mirror is now the disk which is broken, so although this works on my >>> healthy >>> system, it presumably won't work on the real problem ... ? >>> (I did also try linking the primary to the mirror and the mirror to a >>> replacement unused device - that just gave me assert-failed errors as I >>> expected and ended up with both chunks down) >>> >>> Am I missing something ? >>> Or do I actually have to do the dd thing. (I was hoping not because of >>> the >>> downtime) > >