Re: Has anybody EVER successfully recovered VINUM?
See below --- Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: create original.config.file Yes, that's basically it. I tried that already. It did not have the desired effect. It created TWO MORE plexes, that did not have disk space to back them up (because the drives were fully allocated by the original configuration. Correct. This isn't the way to do it. I've just posted the correct URL: http://www.vinumvm.org/vinum/replacing-drive.html OK -- I have gotten to the point where I have a valid plex (I did it by installing a large, cheap IDE drive in the system and putting an entirely new plex on it). But when I try to mount the drive, mount complains that the volume needs to be fscked. Fsck refuses. I CAN however mount the file system and see the expected top level directories (liberty mysql orville reform tam). But I cannot view contents inside the direcotries. (see selected transcript below). So is my data toast, or is there a way to fsck /dev/vinum/raid? SELECTED TRANSCRIPT: S raid.p3.s0State: up PO:0 B Size: 2151 MB S raid.p3.s1State: up PO: 512 kB Size: 2151 MB S raid.p3.s2State: up PO: 1024 kB Size: 2151 MB S raid.p3.s3State: up PO: 1536 kB Size: 2151 MB S raid.p3.s4State: up PO: 2048 kB Size: 2151 MB S raid.p3.s5State: up PO: 2560 kB Size: 2151 MB S raid.p3.s6State: up PO: 3072 kB Size: 2151 MB S raid.p3.s7State: up PO: 3584 kB Size: 2151 MB S raid.p3.s8State: up PO: 4096 kB Size: 2151 MB S raid.p3.s9State: up PO: 4608 kB Size: 2151 MB vinum - quit bashful# mount /dev/vinum/raid /raid WARNING: R/W mount of /raid denied. Filesystem is not clean - run fsck mount: /dev/vinum/raid: Operation not permitted bashful# fsck /dev/vinum/raid ** /dev/vinum/raid BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE /dev/vinum/raid: NOT LABELED AS A BSD FILE SYSTEM (unused) bashful# mount -r /dev/vinum/raid /raid bashful# ls /raid liberty mysql orville reform tam bashful# ls /raid/liberty ls: /raid/liberty: Bad file descriptor bashful# ls /raid/reform /raid/reform bashful# ls /raid/reform/* ls: No match. bashful# ls /raid/orville ls: /raid/orville: Bad file descriptor __ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has anybody EVER successfully recovered VINUM?
On Thu, Dec 09, 2004 at 12:36:56PM +1030, Greg 'groggy' Lehey wrote: On Wednesday, 8 December 2004 at 11:52:55 +0100, Stijn Hoop wrote: AFAIK the only way to guarantee a consistent rebuild is to do it offline (at least in 4.x, haven't tested gvinum in 5.x yet). To play it safe you might want to unmount the volume before starting. I *have* to. The issue is contention round where stripes are being written. The code *should* avoid the contention, but it appears that there's a bug there somewhere. I certainly agree with you that you should umount the file system first. Well, it is a workaround but certainly acceptable to me. There's no reason to believe that this problem exists in gvinum: I believe the code has been completely rewritten. That is good to hear. I certainly have to further test gvinum RAID-5 in the near future. Now that setstate, checkparity rebuildparity have been implemented there's not a technical reason not to, except for possible bugs. --Stijn -- What kind of a two-bit operation are they running out of this treehouse, Cooper? I have seen some slipshod backwater burgs, but this place takes the cake. -- Special Agent Albert Rosenfield, Twin Peaks pgpZEy13hBx8E.pgp Description: PGP signature
Re: Has anybody EVER successfully recovered VINUM?
See below --- Toomas Aas [EMAIL PROTECTED] wrote: I once had a problem with *invalid* vinum drive which was solved following this advice from Greg Lehey: http://makeashorterlink.com/?V29425BF9 So the procedure that worked for you was??? resetconfig create original.config.file I have seen alusions to this procedure, and was planning to try it as a last resort (last because of the dire warnings that are associated with resetconfig). Nowhere however have I seen the above two lines explicitly juxtaposed, so I have been reluctant to try it. Before I try the above, I had an idea last night that I want to try: I will buy a large, cheap IDE drive (big enough to hold an entire plex) and ADD it to my configuration (with all subdisks on the IDE drive). At this point, I expect to be able to sync all subdisks of the IDE plex against one or the other of the existing plexi to obtain a completely functional plex, at which point my RAID should come alive for me to back it up. Does this plan seem workable? __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has anybody EVER successfully recovered VINUM?
On Thursday, 9 December 2004 at 7:06:35 -0800, orville weyrich wrote: See below --- Toomas Aas [EMAIL PROTECTED] wrote: I once had a problem with *invalid* vinum drive which was solved following this advice from Greg Lehey: http://makeashorterlink.com/?V29425BF9 That's a different issue, of course. So the procedure that worked for you was??? resetconfig From the man page: resetconfig The resetconfig command completely obliterates the vinum configu- ration on a system. Use this command only when you want to com- pletely delete the configuration. This doesn't sound like what you want to do. Which part of http://www.vinumvm.org/vinum/replacing-drive.html is a problem for you? Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers. pgpXDeSkHzqB3.pgp Description: PGP signature
Re: Has anybody EVER successfully recovered VINUM?
See below --- Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: On Thursday, 9 December 2004 at 7:06:35 -0800, --- Toomas Aas [EMAIL PROTECTED] wrote: I once had a problem with *invalid* vinum drive So the procedure that worked for you was??? resetconfig This doesn't sound like what you want to do. Which part of http://www.vinumvm.org/vinum/replacing-drive.html is a problem for you? The problem is that I have two subdisks, raid.p0.s9 and raid.p1.s4 that originally were associated with the drive ahc0t15. But when I try to add a new drive with the name ahc0t15, it does not associate itself with the two subdisks. Trying to start the subdisks gives the error: vinum - start raid.p0.s9 Can't start raid.p0.s9: Drive is down (5) Dumpconfig shows that the drive associated with the two subdisks is *invalid*: sd name raid.p0.s9 drive *invalid* plex raid.p0 len 4402583s driveoffset 265s state crashed plexoffset 0s but also shows the unused drive: Drive ahc0t15: Device /dev/da9s1e Created on bashful.weyrich.com at Wed Dec 8 17:24:07 2004 Config last updated Wed Dec 8 17:37:27 2004 Size: 4512230400 bytes (4303 MB) The procedure replacing-drive.html did work in another case. It doesn't seem to work here. Is there some other way to tell vinum that drive ahc0t15 should be associated with the subdisks raid.p0.s9 and raid.p1.s4? __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has anybody EVER successfully recovered VINUM?
see below --- Toomas Aas [EMAIL PROTECTED] wrote: orville weyrich wrote: So the procedure that worked for you was??? resetconfig NO!!! At no point in the procedure did I do resetconfig. create original.config.file Yes, that's basically it. I tried that already. It did not have the desired effect. It created TWO MORE plexes, that did not have disk space to back them up (because the drives were fully allocated by the original configuration. It took me a while to figure out how to undo that (I had to stop plexi p0 and p1 before trying to stop and remove the new plexi p2 and p3). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has anybody EVER successfully recovered VINUM?
On Thursday, 9 December 2004 at 17:04:38 -0800, orville weyrich wrote: see below --- Toomas Aas [EMAIL PROTECTED] wrote: orville weyrich wrote: So the procedure that worked for you was??? resetconfig NO!!! At no point in the procedure did I do resetconfig. create original.config.file Yes, that's basically it. I tried that already. It did not have the desired effect. It created TWO MORE plexes, that did not have disk space to back them up (because the drives were fully allocated by the original configuration. Correct. This isn't the way to do it. I've just posted the correct URL: http://www.vinumvm.org/vinum/replacing-drive.html Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers. pgpWWY2YKzkFl.pgp Description: PGP signature
Re: Has anybody EVER successfully recovered VINUM?
orville weyrich wrote: I cannot find instructions in the official documentation, nor in the FreeBSD Dairy. Have you read this: http://www.vinumvm.org/vinum/replacing-drive.html I've followed these steps to successfully recover from two cases of drive failure. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has anybody EVER successfully recovered VINUM?
On Tue, Dec 07, 2004 at 09:45:51PM -0800, orville weyrich wrote: I have been trying to figure out how to get VINUM to recognize a new disk after a disk failure, and no luck at all. I cannot find instructions in the official documentation, nor in the FreeBSD Dairy. Lots of places tell how to build a VINUM system. Nobody ever takls about how to recover from a disk failure. Can someone PLEASE help me recover? I have already posted complete information to this list, with no answer. I will give a short version now and provide more info if requested. Hi Orville, We have successfully replaced failed drives in Vinum RAID-5 volumes several times, on a couple of different machines. Obviously no guarantees that these steps will work for you, but this is what we did: 1. Pull the failed drive. The machines in question use Intel L440GX+ boards with hot-swap SCSI drive cages, so this was as simple as popping out the dead drive. 2. Plug in a new drive. The hardware and FreeBSD seemed quite happy with this, whether because the new drive was identical to the old one, or our SCSI layer is just smart enough to deal with this, I don't know. I've never had to replace a failed drive with a larger one, so I have no idea if this would work or not. 3. Clean any existing partition table and boot blocks off the new drive, just in case: # dd if=/dev/zero of=/dev/da0 bs=1k count=1 4. Put a default BSD disklabel on the new drive: # disklabel -w -r da0 auto 5. Edit the disklabel to add the Vinum partition: # disklabel -e -r da0 Just copy the 'c' partition line to 'a', change the partition type to 'vinum' and clear out the 'fsize' and 'bsize' fields. You can always check the disklabel on one of the other drives to see what it should look like. Of course this assumes you're dedidating the entire disk to the Vinum partition. If replacing the failed drive with a larger disk, adjust accordingly - the important thing is that the new partition is the same size as the old one. 6. Tell vinum to restart the failed subdisk: # vinum start raid.p0.s0 7. Wait ages while the new disk is 'revived'. I was quite impressed that the volume remained available with users accessing it throughout this procedure :-) To play it safe you might want to unmount the volume before starting. There was one instance where the machine was for some reason rebooted after the drive failure - vinum somehow completely forgot about that subdisk when it came back up. I *think* we fixed this by generating a new vinum config just for that subdisk, something like: drive d0 device /dev/da0a Once this was done vinum seemed happy to rebuild on the new drive. This procedure has worked for us several times, but I have no idea if it's the 'right' way to do this. Maybe we're just really lucky. So if you follow these instructions and end up trashing your disks, it's not my fault. I *really* recommend having a recent backup before starting, assuming the volume is still readable, just in case. Good luck! Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has anybody EVER successfully recovered VINUM?
Scott, your procedure is what I have used, except for: On Wed, Dec 08, 2004 at 10:09:05AM +, Scott Mitchell wrote: 6. Tell vinum to restart the failed subdisk: # vinum start raid.p0.s0 7. Wait ages while the new disk is 'revived'. I was quite impressed that the volume remained available with users accessing it throughout this procedure :-) Yes I was too -- however I wasn't as impressed with the fact that I had parity errors afterwards. Have you run 'vinum checkparity' after these rebuilds? In my case I suffered data corruption... AFAIK the only way to guarantee a consistent rebuild is to do it offline (at least in 4.x, haven't tested gvinum in 5.x yet). To play it safe you might want to unmount the volume before starting. I *have* to. --Stijn -- Coca-Cola is solely responsible for ensuring that people - too stupid to know not to tip half-ton machines on themselves - are safe. Forget parenting - the blame is entirely on the corporation for designing machines that look so innocent and yet are so deadly. -- http://www.kuro5hin.org/?op=displaystory;sid=2001/10/28/212418/42 pgp7178BubGOQ.pgp Description: PGP signature
Re: Has anybody EVER successfully recovered VINUM?
On Wed, Dec 08, 2004 at 11:52:55AM +0100, Stijn Hoop wrote: Scott, your procedure is what I have used, except for: On Wed, Dec 08, 2004 at 10:09:05AM +, Scott Mitchell wrote: 6. Tell vinum to restart the failed subdisk: # vinum start raid.p0.s0 7. Wait ages while the new disk is 'revived'. I was quite impressed that the volume remained available with users accessing it throughout this procedure :-) Yes I was too -- however I wasn't as impressed with the fact that I had parity errors afterwards. Have you run 'vinum checkparity' after these rebuilds? In my case I suffered data corruption... No, but I haven't seen any evidence of corruption in the ~1 year since the last time I did this, so I guess we got away with it. AFAIK the only way to guarantee a consistent rebuild is to do it offline (at least in 4.x, haven't tested gvinum in 5.x yet). To play it safe you might want to unmount the volume before starting. I *have* to. I normally would unmount first if possible, to make the rebuild run faster if nothing else. Guess I'll make sure to do so in future. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has anybody EVER successfully recovered VINUM?
On Wed, Dec 08, 2004 at 11:30:13AM +, Scott Mitchell wrote: On Wed, Dec 08, 2004 at 11:52:55AM +0100, Stijn Hoop wrote: I was quite impressed that the volume remained available with users accessing it throughout this procedure :-) Yes I was too -- however I wasn't as impressed with the fact that I had parity errors afterwards. Have you run 'vinum checkparity' after these rebuilds? In my case I suffered data corruption... No, but I haven't seen any evidence of corruption in the ~1 year since the last time I did this, so I guess we got away with it. Well I'm still not sure whether this was something hardware related as the box is still fishy. However, in the ~5 times that I did an offline rebuild I've never encountered parity errors as opposed to the ~3 times of online rebuilds that definitely screwed up the parity. In addition, the author of vinum couldn't assert that 4.x vinum supported online rebuilds (not a complaint, just a fact), so I'm not rebuilding online anymore. AFAIK the only way to guarantee a consistent rebuild is to do it offline (at least in 4.x, haven't tested gvinum in 5.x yet). To play it safe you might want to unmount the volume before starting. I *have* to. I normally would unmount first if possible, to make the rebuild run faster if nothing else. Guess I'll make sure to do so in future. I'm just saying that in my case it didn't work out well. As with any other advice, it might just work for you :) --Stijn -- A mouse is a device used to point at the xterm you want to type in. -- Kim Alm, alt.sysadmin.recovery pgp6rzoKRxgeA.pgp Description: PGP signature
Re: Has anybody EVER successfully recovered VINUM?
On Wed, Dec 08, 2004 at 12:34:27PM +0100, Stijn Hoop wrote: On Wed, Dec 08, 2004 at 11:30:13AM +, Scott Mitchell wrote: On Wed, Dec 08, 2004 at 11:52:55AM +0100, Stijn Hoop wrote: AFAIK the only way to guarantee a consistent rebuild is to do it offline (at least in 4.x, haven't tested gvinum in 5.x yet). To play it safe you might want to unmount the volume before starting. I *have* to. I normally would unmount first if possible, to make the rebuild run faster if nothing else. Guess I'll make sure to do so in future. I'm just saying that in my case it didn't work out well. As with any other advice, it might just work for you :) Sure, I'm definitely not disagreeing with anything you're saying here. I'm inclined to think I have just been lucky the few times I've had to do this in the past, and to maximise my good luck I should take the same precautions that you do in the future :-) I haven't played with gvinum yet either, but I'll probably be looking at a hardware solution (FreeBSD-supported hardware RAID or network-attached storage appliances) when the time comes to replace these servers. Vinum has been excellent, but I always find it really traumatic to deal with, mostly because I have to touch it every 6 months at most. There's always a frantic hour re-reading the documentation, followed by a lot of I really, really, hope this works moments before hitting Enter :-( Cheers, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has anybody EVER successfully recovered VINUM?
On Wed, Dec 08, 2004 at 11:54:45AM +, Scott Mitchell wrote: On Wed, Dec 08, 2004 at 12:34:27PM +0100, Stijn Hoop wrote: I'm just saying that in my case it didn't work out well. As with any other advice, it might just work for you :) Sure, I'm definitely not disagreeing with anything you're saying here. I'm inclined to think I have just been lucky the few times I've had to do this in the past, and to maximise my good luck I should take the same precautions that you do in the future :-) Oops, I think I didn't exactly get my point across, which was 'it may very well be that your way works for you, which is great'. I certainly was not trying to sound condescending (I think is the right word?). I haven't played with gvinum yet either, but I'll probably be looking at a hardware solution (FreeBSD-supported hardware RAID or network-attached storage appliances) when the time comes to replace these servers. Vinum has been excellent, but I always find it really traumatic to deal with, mostly because I have to touch it every 6 months at most. There's always a frantic hour re-reading the documentation, followed by a lot of I really, really, hope this works moments before hitting Enter :-( Yeah, I certainly recognize those moments. Having gotten through a lot of trouble in the last few months did do some good in that regard, I know my way around vinum a bit more. But unfortunately I have heard some horror stories with hardware RAID as well, so I'm staying with vinum in the forseeable future (at least I can help to find bugs there unlike firmware bugs in a PCI controller card). Cheers, --Stijn -- What if everything you see is more than what you see -- the person next to you is a warrior and the space that appears empty is a secret door to another world? What if something appears that shouldn't? You either dismiss it, or you accept that there is much more to the world than you think. Perhaps it really is a doorway, and if you choose to go inside, you'll find many unexpected things. -- Shigeru Miyamoto pgp1ImrAirR3E.pgp Description: PGP signature
Re: Has anybody EVER successfully recovered VINUM?
On Wed, Dec 08, 2004 at 01:01:30PM +0100, Stijn Hoop wrote: On Wed, Dec 08, 2004 at 11:54:45AM +, Scott Mitchell wrote: On Wed, Dec 08, 2004 at 12:34:27PM +0100, Stijn Hoop wrote: I'm just saying that in my case it didn't work out well. As with any other advice, it might just work for you :) Sure, I'm definitely not disagreeing with anything you're saying here. I'm inclined to think I have just been lucky the few times I've had to do this in the past, and to maximise my good luck I should take the same precautions that you do in the future :-) Oops, I think I didn't exactly get my point across, which was 'it may very well be that your way works for you, which is great'. I certainly was not trying to sound condescending (I think is the right word?). It's the right word, but you're not guilty of it! I'm always willing to learn a new/better way of doing something, especially if it avoids potential problems - even if I haven't actually experienced those problems myself. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has anybody EVER successfully recovered VINUM?
See below --- Toomas Aas [EMAIL PROTECTED] wrote: orville weyrich wrote: In any event, the example shown in the link lacks context. Is the failed drive named data1? It is automagically replaced by a new drive named data3? In all cases I've replaced a failed drive, I have named the new drive the same as old drive. THANK YOU THANK YOU THANK YOU That solved HALF my problem (i.e, it allowed me to revive one of my two down disks. This also shows that vinum CAN handle a fault in both plexes at the same time. BUT BUT BUT I still have another problem -- the same trick does not work for the OTHER down disk. vinum-dumpconfig shows: sd name raid.p0.s9 drive *invalid* plex raid.p0 len 4402583s driveoffset 265s state crashed plexoffset 0s Note the invalid where the name of my disk should be. Apparently VINUM has forgotten that raid.p0.s9 should be associated with the disk named ahc0t15, so creating a new disk named ahc0t15 does not associate with the necessary subdisk. (*nvalid* does not work as a disk name). How do I deal with THIS issue? __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has anybody EVER successfully recovered VINUM?
Yes I was too -- however I wasn't as impressed with the fact that I had parity errors afterwards. Have you run 'vinum checkparity' after these rebuilds? In my case I suffered data corruption... AFAIK the only way to guarantee a consistent rebuild is to do it offline (at least in 4.x, haven't tested gvinum in 5.x yet). To play it safe you might want to unmount the volume before starting. If this is indeed true, which I find a bit hard to believe, it should be fixed ASAP. I've never seen a RAID that had to be taken _offline_ to rebuild parity onto a failed and replaced drive. I've triggered rebuilds on a few so far, including h/w RAID, RAIDFrame and the Linux raid* thing, and it has always worked nicely while there was heavy load on the volume (with reduced performance during the rebuild, of course.) -- Matthias Buelow; [EMAIL PROTECTED],informatik.uni-wuerzburg}.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has anybody EVER successfully recovered VINUM?
On Wednesday, 8 December 2004 at 11:52:55 +0100, Stijn Hoop wrote: Scott, your procedure is what I have used, except for: On Wed, Dec 08, 2004 at 10:09:05AM +, Scott Mitchell wrote: 6. Tell vinum to restart the failed subdisk: # vinum start raid.p0.s0 7. Wait ages while the new disk is 'revived'. I was quite impressed that the volume remained available with users accessing it throughout this procedure :-) Yes I was too -- however I wasn't as impressed with the fact that I had parity errors afterwards. Have you run 'vinum checkparity' after these rebuilds? In my case I suffered data corruption... *sigh* Yes, there's some problem there. AFAIK the only way to guarantee a consistent rebuild is to do it offline (at least in 4.x, haven't tested gvinum in 5.x yet). To play it safe you might want to unmount the volume before starting. I *have* to. The issue is contention round where stripes are being written. The code *should* avoid the contention, but it appears that there's a bug there somewhere. I certainly agree with you that you should umount the file system first. There's no reason to believe that this problem exists in gvinum: I believe the code has been completely rewritten. Greg -- See complete headers for address and phone numbers. pgpIdH4cerh1f.pgp Description: PGP signature
