Re: Help with Vinum disk crash...
No, that's not correct. It does happen if you choose too small a stripe size, but that's the best reason for choosing larger stripes. That's described in much detail in the man page. How can it not be correct? When you write some data, it writes to all 4 disks, when you read it reads from 3 of them right? -D ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with Vinum disk crash...
On Tuesday, 24 February 2004 at 8:56:58 +0100, Danny Carroll wrote: No, that's not correct. It does happen if you choose too small a stripe size, but that's the best reason for choosing larger stripes. That's described in much detail in the man page. How can it not be correct? When you write some data, it writes to all 4 disks, when you read it reads from 3 of them right? No. It's described in the man page and on the web site. 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 Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Help with Vinum disk crash...
Greg, Thanks for all the responses. Unfortunatly I ran out of time and resorted to a restore of week old data. No big loss for me, but I really wanted to debug this to better understand what happened. I think it went something like this: ide drive crashes. kernel panics (for this or some other reason). ufs gets screwed up on the drive because of the panic. I can't prove any of this since I urgently needed about 150gb of space. So I re-formatted. Like I said it is a shame since I wanted to understand what happened now, but, then again, I was looking for an excuse to change back from vinum to normal. vinum and ide on my system results is very poor disk performance, I see a 10-fold increase in read/write actions. I'll be interested in revisiting vinum with some SCSI disks sometime soon. Anyway, thanks once again both of you for the efforts. -D ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with Vinum disk crash...
On Monday, 23 February 2004 at 12:44:19 +0100, Danny Carroll wrote: Greg, Thanks for all the responses. Unfortunatly I ran out of time and resorted to a restore of week old data. No big loss for me, but I really wanted to debug this to better understand what happened. I think it went something like this: ide drive crashes. kernel panics (for this or some other reason). ufs gets screwed up on the drive because of the panic. We already discussed this. The likelihood of such far-reaching damage is low. I can't prove any of this since I urgently needed about 150gb of space. So I re-formatted. Like I said it is a shame since I wanted to understand what happened now, but, then again, I was looking for an excuse to change back from vinum to normal. To be honest, I don't know what else we could have done, since you haven't supplied the information I asked for. vinum and ide on my system results is very poor disk performance, I see a 10-fold increase in read/write actions. I'll be interested in revisiting vinum with some SCSI disks sometime soon. How did you test it? 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 Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Help with Vinum disk crash...
We already discussed this. The likelihood of such far-reaching damage is low. Hmmm ok.. I can't prove any of this since I urgently needed about 150gb of space. So I re-formatted. Like I said it is a shame since I wanted to understand what happened now, but, then again, I was looking for an excuse to change back from vinum to normal. To be honest, I don't know what else we could have done, since you haven't supplied the information I asked for. I know and I am sorry for that. It was just bad timing. I asked for help and then within 24 hours found that I needed a lot of storage really fast. I had to make a decision whether or not to figure out what went wrong or to get on with the task as hand. vinum and ide on my system results is very poor disk performance, I see a 10-fold increase in read/write actions. I'll be interested in revisiting vinum with some SCSI disks sometime soon. How did you test it? I have 4 ata133 ide disks, all identical. They run off a promise ata133 io card. With vinum, all 4 disks are accessed at pretty much the same time, no matter what you do. Without, you only access the disk that you are writing to. It goes a lot faster but I have to manage my data usage more. I dont blame vinum, I blame my ide subsystem. -D ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with Vinum disk crash...
On Tuesday, 24 February 2004 at 8:30:15 +0100, Danny Carroll wrote: vinum and ide on my system results is very poor disk performance, I see a 10-fold increase in read/write actions. I'll be interested in revisiting vinum with some SCSI disks sometime soon. How did you test it? I have 4 ata133 ide disks, all identical. They run off a promise ata133 io card. With vinum, all 4 disks are accessed at pretty much the same time, no matter what you do. No, that's not correct. It does happen if you choose too small a stripe size, but that's the best reason for choosing larger stripes. That's described in much detail in the man page. Without, you only access the disk that you are writing to. It goes a lot faster but I have to manage my data usage more. I dont blame vinum, I blame my ide subsystem. No, it's not your IDE subsystem. That usually works better than you think. But performance is an issue. You need to test with access patterns which relate to what you're really doing: sequential access testing can often prove irrelevant. 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 Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Help with Vinum disk crash...
On Wednesday, 18 February 2004 at 9:34:29 +0100, Danny Carroll wrote: Quoting Greg 'groggy' Lehey [EMAIL PROTECTED]: I answered an almost identical question yesterday: it depends on the volume structure, which you haven't stated. Look at http://www.vinumvm.org/vinum/how-to-debug.html and supply in particular the output of 'vinum list', unless the following applies: If this volume has only one plex, you're lost, unless you can bring up the failed disk long enough to make a backup. Here is the output: 20 drives: As Tony Frank points out, this is 16 too many. But it shouldn't be related to your problems. I don't see the rest of the information I ask for. I am only interested in the big one (data) the others were just for experimentation I thought since the plex was setup as raid5 it would be ok? Should be. I have 4 106gb subdisks, and see 318Gb of data... The 4th subdisk is becuase of the loss from Raid5 right? This is the overhead for the RAID-5 parity. Did I set this up incorrectly? Only as noted. 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 Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Help with Vinum disk crash...
On Thursday, 19 February 2004 at 1:04:29 +1100, Tony Frank wrote: Hi, On Wed, Feb 18, 2004 at 01:15:18PM +0100, Danny Carroll wrote: Quoting Tony Frank [EMAIL PROTECTED]: So you have a subdisk down which means Vinum can still read from the plex but has to manually calculate the missing subdisk data. But I assume it cant write till I replace it.. I believe it should function for both read write in degraded mode. Any reads will have to be rebuilt hence there will be a big hit in performance. No, only reads of the missing disk need to be rebuilt. There's a detailed discussion of how RAID-5 works in degraded mode at http://www.vinumvm.org/vinum/implementation.html . Another option would be to force the particular subdisk down and try the above steps again. Something like: vinum down data.p0.s0 ??? The command would be vinum stop data.p0.s0 In my case I had to do vinum stop -f data.p0.s0 I'm not sure what would happen here, but it could be dangerous. The object is already inaccessible. The different states are maintained for two main reasons: 1. It tells the user how they got like that. 2. It tells Vinum whether the data on the object, if accessible, is still up to date. Crashed and down mean that the data is up to date, so a 'start' can complete immediately. Obsolete and stale mean that the data is no longer up to date. If you change the state of a subdisk from stale to down and then issue a start command, Vinum assumes that the object still contains the correct data, so it sets it up with no change. This will result in severe data corruption of the kind that you're seeing. However this should not have any impact to your situation. The volume is working at the Vinum level (although degraded) The problem here is that the data on the vinum volume appears to be somehow corrupt. Correct. I'm wondering if this happened as the result of something else, possibly finger trouble. The answer might be in the missing information asked for at http://www.vinumvm.org/vinum/how-to-debug.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 Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Help with Vinum disk crash...
On Thursday, 19 February 2004 at 9:46:35 +0100, Danny Carroll wrote: Tony et al,.. Thanks for the information... I really need the space now so I am going to wipe it and start from scratch, although I am not sure if I will use vinum again. I guess my main concern is that when one of my disks crashed, the ufs filesystem got corrupted and I really did not expect that to happen. It normally doesn't. There's something else going on here. Another thing, Greg, you mentioned that I should have a second plex if I wanted to protect the data. You mean like a mirror? Surely 1 is enough when we are talking raid-5? Yes, sorry. You need either RAID-5 or two plexes. 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 Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Help with Vinum disk crash...
On Friday, 20 February 2004 at 9:22:21 +1100, Tony Frank wrote: Hi, On Thu, Feb 19, 2004 at 09:46:35AM +0100, Danny Carroll wrote: Thanks for the information... I really need the space now so I am going to wipe it and start from scratch, although I am not sure if I will use vinum again. I guess my main concern is that when one of my disks crashed, the ufs filesystem got corrupted and I really did not expect that to happen. It could be ignorance on my part, I dont know but perhaps someone can help me understand how this could have happened? Filesystems can get corrupted if the system crashes and does not cleanly close the filesystem first. In your case I'm personally not too sure - some more questions perhaps can help. The kind of corruption caused by an unclean shutdown is nothing like this. - Were you using softupdates on the filesystem? This shouldn't make any difference. - Did the system panic/reboot when the disk crashed without shutting down cleanly? - What version of FreeBSD are you / were you running? Another thing, Greg, you mentioned that I should have a second plex if I wanted to protect the data. You mean like a mirror? Surely 1 is enough when we are talking raid-5? Raid-5 should still work if a single subdisk fails. In your original post you did not indicate if you were using raid5 setup. Yes, he did: V data State: up Plexes: 1 Size:320 GB P data.p0R5 State: degraded Subdisks: 4 Size:320 GB S data.p0.s0State: stalePO:0 B Size:106 GB S data.p0.s1State: up PO: 3924 kB Size:106 GB S data.p0.s2State: up PO: 7848 kB Size:106 GB S data.p0.s3State: up PO: 11 MB Size:106 GB The R5 on the plex line indicates that it's RAID-5. 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 Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Help with Vinum disk crash...
Tony et al,.. Thanks for the information... I really need the space now so I am going to wipe it and start from scratch, although I am not sure if I will use vinum again. I guess my main concern is that when one of my disks crashed, the ufs filesystem got corrupted and I really did not expect that to happen. It could be ignorance on my part, I dont know but perhaps someone can help me understand how this could have happened? Another thing, Greg, you mentioned that I should have a second plex if I wanted to protect the data. You mean like a mirror? Surely 1 is enough when we are talking raid-5? Thanks for your help... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with Vinum disk crash...
Hi, On Thu, Feb 19, 2004 at 09:46:35AM +0100, Danny Carroll wrote: Thanks for the information... I really need the space now so I am going to wipe it and start from scratch, although I am not sure if I will use vinum again. I guess my main concern is that when one of my disks crashed, the ufs filesystem got corrupted and I really did not expect that to happen. It could be ignorance on my part, I dont know but perhaps someone can help me understand how this could have happened? Filesystems can get corrupted if the system crashes and does not cleanly close the filesystem first. In your case I'm personally not too sure - some more questions perhaps can help. - Were you using softupdates on the filesystem? - Did the system panic/reboot when the disk crashed without shutting down cleanly? - What version of FreeBSD are you / were you running? Another thing, Greg, you mentioned that I should have a second plex if I wanted to protect the data. You mean like a mirror? Surely 1 is enough when we are talking raid-5? Raid-5 should still work if a single subdisk fails. In your original post you did not indicate if you were using raid5 setup. If you had configured the subdisks as a concatenated or striped plex then there would most likely be no way to continue with a disk missing unless there existed a second plex with a copy of the data. Regards, Tony ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with Vinum disk crash...
Quoting Greg 'groggy' Lehey [EMAIL PROTECTED]: I answered an almost identical question yesterday: it depends on the volume structure, which you haven't stated. Look at http://www.vinumvm.org/vinum/how-to-debug.html and supply in particular the output of 'vinum list', unless the following applies: If this volume has only one plex, you're lost, unless you can bring up the failed disk long enough to make a backup. Here is the output: 20 drives: D data1 State: up Device /dev/ad4s1a Avail: 3/109471 MB (0%) D ftp1 State: up Device /dev/ad4s1e Avail: 0/600 MB (0%) D www1 State: up Device /dev/ad4s1f Avail: 0/2048 MB (0%) D mail1 State: up Device /dev/ad4s1g Avail: 0/2048 MB (0%) D rback1 State: up Device /dev/ad4s1h Avail: 0/3072 MB (0%) D data2 State: up Device /dev/ad5s1a Avail: 6/109471 MB (0%) D ftp2 State: up Device /dev/ad5s1e Avail: 0/600 MB (0%) D www2 State: up Device /dev/ad5s1f Avail: 0/2048 MB (0%) D mail2 State: up Device /dev/ad5s1g Avail: 0/2048 MB (0%) D rback2 State: up Device /dev/ad5s1h Avail: 0/3072 MB (0%) D data3 State: up Device /dev/ad6s1a Avail: 6/109471 MB (0%) D ftp3 State: up Device /dev/ad6s1e Avail: 0/600 MB (0%) D www3 State: up Device /dev/ad6s1f Avail: 0/2048 MB (0%) D mail3 State: up Device /dev/ad6s1g Avail: 0/2048 MB (0%) D rback3 State: up Device /dev/ad6s1h Avail: 0/3072 MB (0%) D data4 State: up Device /dev/ad7s1a Avail: 6/109471 MB (0%) D ftp4 State: up Device /dev/ad7s1e Avail: 0/600 MB (0%) D www4 State: up Device /dev/ad7s1f Avail: 0/2048 MB (0%) D mail4 State: up Device /dev/ad7s1g Avail: 0/2048 MB (0%) D rback4 State: up Device /dev/ad7s1h Avail: 0/3072 MB (0%) 5 volumes: V data State: up Plexes: 1 Size:320 GB V www State: up Plexes: 1 Size: 6142 MB V mail State: up Plexes: 1 Size: 6142 MB V ftp State: up Plexes: 1 Size: 1799 MB V rback State: up Plexes: 1 Size: 9214 MB 5 plexes: P data.p0R5 State: degraded Subdisks: 4 Size:320 GB P www.p0 R5 State: degraded Subdisks: 4 Size: 6142 MB P mail.p0R5 State: degraded Subdisks: 4 Size: 6142 MB P ftp.p0 R5 State: degraded Subdisks: 4 Size: 1799 MB P rback.p0 R5 State: degraded Subdisks: 4 Size: 9214 MB 20 subdisks: S data.p0.s0State: stalePO:0 B Size:106 GB S data.p0.s1State: up PO: 3924 kB Size:106 GB S data.p0.s2State: up PO: 7848 kB Size:106 GB S data.p0.s3State: up PO: 11 MB Size:106 GB S www.p0.s0 State: crashed PO:0 B Size: 2047 MB S www.p0.s1 State: up PO: 392 kB Size: 2047 MB S www.p0.s2 State: up PO: 784 kB Size: 2047 MB S www.p0.s3 State: up PO: 1176 kB Size: 2047 MB S mail.p0.s0State: crashed PO:0 B Size: 2047 MB S mail.p0.s1State: up PO: 392 kB Size: 2047 MB S mail.p0.s2State: up PO: 784 kB Size: 2047 MB S mail.p0.s3State: up PO: 1176 kB Size: 2047 MB S ftp.p0.s0 State: crashed PO:0 B Size:599 MB S ftp.p0.s1 State: up PO: 292 kB Size:599 MB S ftp.p0.s2 State: up PO: 584 kB Size:599 MB S ftp.p0.s3 State: up PO: 876 kB Size:599 MB S rback.p0.s0 State: crashed PO:0 B Size: 3071 MB S rback.p0.s1 State: up PO: 658 kB Size: 3071 MB S rback.p0.s2 State: up PO: 1316 kB Size: 3071 MB S rback.p0.s3 State: up PO: 1974 kB Size: 3071 MB I am only interested in the big one (data) the others were just for experimentation I thought since the plex was setup as raid5 it would be ok? I have 4 106gb subdisks, and see 318Gb of data... The 4th subdisk is becuase of the loss from Raid5 right? Did I set this up incorrectly? I have most of the stuff on backup but if I can get it back I will be much happier... -D ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with Vinum disk crash...
Hi there, On Wed, Feb 18, 2004 at 09:34:29AM +0100, Danny Carroll wrote: Quoting Greg 'groggy' Lehey [EMAIL PROTECTED]: If this volume has only one plex, you're lost, unless you can bring up the failed disk long enough to make a backup. Here is the output: 20 drives: D data1 State: up Device /dev/ad4s1a Avail: 3/109471 MB (0%) D ftp1 State: up Device /dev/ad4s1e Avail: 0/600 MB (0%) D www1 State: up Device /dev/ad4s1f Avail: 0/2048 MB (0%) D mail1 State: up Device /dev/ad4s1g Avail: 0/2048 MB (0%) D rback1 State: up Device /dev/ad4s1h Avail: 0/3072 MB (0%) D data2 State: up Device /dev/ad5s1a Avail: 6/109471 MB (0%) D ftp2 State: up Device /dev/ad5s1e Avail: 0/600 MB (0%) D www2 State: up Device /dev/ad5s1f Avail: 0/2048 MB (0%) D mail2 State: up Device /dev/ad5s1g Avail: 0/2048 MB (0%) D rback2 State: up Device /dev/ad5s1h Avail: 0/3072 MB (0%) D data3 State: up Device /dev/ad6s1a Avail: 6/109471 MB (0%) D ftp3 State: up Device /dev/ad6s1e Avail: 0/600 MB (0%) D www3 State: up Device /dev/ad6s1f Avail: 0/2048 MB (0%) D mail3 State: up Device /dev/ad6s1g Avail: 0/2048 MB (0%) D rback3 State: up Device /dev/ad6s1h Avail: 0/3072 MB (0%) D data4 State: up Device /dev/ad7s1a Avail: 6/109471 MB (0%) D ftp4 State: up Device /dev/ad7s1e Avail: 0/600 MB (0%) D www4 State: up Device /dev/ad7s1f Avail: 0/2048 MB (0%) D mail4 State: up Device /dev/ad7s1g Avail: 0/2048 MB (0%) D rback4 State: up Device /dev/ad7s1h Avail: 0/3072 MB (0%) Ok, this is wrong - you really just want to define one vinum drive per physical device. Ie for a particular disk, give it a single 'vinum' partition using disklabel. Then use different subdisks to split your space up. 5 volumes: V data State: up Plexes: 1 Size:320 GB This is should be ok - it means vinum thinks the volume is still accessable. 5 plexes: P data.p0R5 State: degraded Subdisks: 4 Size:320 GB From man 4 vinum : degradedA RAID-5 plex entry which is accessible, but one subdisk is down, requiring recovery for many I/O requests. So you have a subdisk down which means Vinum can still read from the plex but has to manually calculate the missing subdisk data. 20 subdisks: S data.p0.s0State: stalePO:0 B Size:106 GB S data.p0.s1State: up PO: 3924 kB Size:106 GB S data.p0.s2State: up PO: 7848 kB Size:106 GB S data.p0.s3State: up PO: 11 MB Size:106 GB Again from man 4 vinum : stale A subdisk entry which has been created completely. All fields are correct, the disk has been updated, and the data was valid, but since then the drive has been crashed and updates have been lost. I am only interested in the big one (data) the others were just for experimentation I thought since the plex was setup as raid5 it would be ok? Yes, Vinum believes it can still access your data. I have 4 106gb subdisks, and see 318Gb of data... The 4th subdisk is becuase of the loss from Raid5 right? Yes, one disk per stripe will be used for parity. Did I set this up incorrectly? I suggest you read http://www.vinumvm.org/cfbsd/vinum.pdf - the last section comments again on the particulars for drive subdisk layout. From your original message: When I do try and mount the volume, it says the following: [02:25 PM [EMAIL PROTECTED]:/var/log]#mount /dev/vinum/data /usr/jails/ftp/data mount: /dev/vinum/data on /usr/jails/ftp/data: incorrect super block Typically I see this problem when trying to mount filesystem with incorrect type. Was your filesystem ufs? If not you probably need to specify the type to mount command using -t parameter. See man 8 mount for details. Have you tried running fsck against the volume? Assuming ufs filesystem, I'd suggest starting with: fsck -n -t ufs /dev/vinum/data Note the -n option tells fsck not to correct any errors but will give you an indication about what is going on. There are extra things you can try (recover using alternate super-block) but perhaps wait and see the results first? Another option would be to force the particular subdisk down and try the above steps again. Hope it helps, Tony ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with Vinum disk crash...
Quoting Tony Frank [EMAIL PROTECTED]: Ok, this is wrong - you really just want to define one vinum drive per physical device. Ie for a particular disk, give it a single 'vinum' partition using disklabel. Then use different subdisks to split your space up. I was afraid of that Noted 5 volumes: V data State: up Plexes: 1 Size:320 GB This is should be ok - it means vinum thinks the volume is still accessable. That is what I thought, but it wond mount, see below... From man 4 vinum : degradedA RAID-5 plex entry which is accessible, but one subdisk is down, requiring recovery for many I/O requests. So you have a subdisk down which means Vinum can still read from the plex but has to manually calculate the missing subdisk data. But I assume it cant write till I replace it.. Yes, Vinum believes it can still access your data. I have 4 106gb subdisks, and see 318Gb of data... The 4th subdisk is becuase of the loss from Raid5 right? Yes, one disk per stripe will be used for parity. Did I set this up incorrectly? I suggest you read http://www.vinumvm.org/cfbsd/vinum.pdf - the last section comments again on the particulars for drive subdisk layout. Typically I see this problem when trying to mount filesystem with incorrect type. Was your filesystem ufs? If not you probably need to specify the type to mount command using -t parameter. See man 8 mount for details. Have you tried running fsck against the volume? Assuming ufs filesystem, I'd suggest starting with: fsck -n -t ufs /dev/vinum/data Note the -n option tells fsck not to correct any errors but will give you an indication about what is going on. fsck -n -t ufs did not work...Seems like fsck does not know -t ... You dont want to see the output from that... Nearly every inode has problems.. I ran it without the -n and the first entry looks like this: UNKNOWN FILE TYPE I=188225^C[12:39 PM [EMAIL PROTECTED]:/usr/home/danny]#fsck /dev/vinum/data ** /dev/vinum/data ** Last Mounted on /usr/jails/ftp/data ** Phase 1 - Check Blocks and Sizes UNKNOWN FILE TYPE I=29 There are extra things you can try (recover using alternate super-block) but perhaps wait and see the results first? How do I read an alternative superblock wih a vinum drive??? Another option would be to force the particular subdisk down and try the above steps again. Something like: vinum down data.p0.s0 ??? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with Vinum disk crash...
Hi, On Wed, Feb 18, 2004 at 01:15:18PM +0100, Danny Carroll wrote: Quoting Tony Frank [EMAIL PROTECTED]: So you have a subdisk down which means Vinum can still read from the plex but has to manually calculate the missing subdisk data. But I assume it cant write till I replace it.. I believe it should function for both read write in degraded mode. Any reads will have to be rebuilt hence there will be a big hit in performance. Typically I see this problem when trying to mount filesystem with incorrect type. Was your filesystem ufs? If not you probably need to specify the type to mount command using -t parameter. See man 8 mount for details. Have you tried running fsck against the volume? Assuming ufs filesystem, I'd suggest starting with: fsck -n -t ufs /dev/vinum/data Note the -n option tells fsck not to correct any errors but will give you an indication about what is going on. fsck -n -t ufs did not work...Seems like fsck does not know -t ... You dont want to see the output from that... Nearly every inode has problems.. I got confused with mount there. :) I ran it without the -n and the first entry looks like this: UNKNOWN FILE TYPE I=188225^C[12:39 PM [EMAIL PROTECTED]:/usr/home/danny]#fsck /dev/vinum/data ** /dev/vinum/data ** Last Mounted on /usr/jails/ftp/data ** Phase 1 - Check Blocks and Sizes UNKNOWN FILE TYPE I=29 Well -n is useful in that it makes no changes... There are extra things you can try (recover using alternate super-block) but perhaps wait and see the results first? How do I read an alternative superblock wih a vinum drive??? superblock is a filesystem function - so you run fsck with -b option as so: fsck -b x where x is the replacement superblock. Typically 32 is a valid replacement (says this in fsck man page) so you might want to try fsck -n -b 32 /dev/vinum/data The newfs output will give you a list of the superblocks created. You can 'rerun' newfs with: newfs -N -v /dev/vinum/data Be sure to include the -N as otherwise it will overwrite your volume. If 32 wont work you can try a higher number Another option would be to force the particular subdisk down and try the above steps again. Something like: vinum down data.p0.s0 ??? The command would be vinum stop data.p0.s0 In my case I had to do vinum stop -f data.p0.s0 In your case if you have replaced the faulty drive you should be able to run 'vinum start data.p0.s0' to have the subdisk rebuilt in the background. This will take a long time for your listed volume sizes. However this should not have any impact to your situation. The volume is working at the Vinum level (although degraded) The problem here is that the data on the vinum volume appears to be somehow corrupt. If the fsck option with alternate superblock doesn't help I think the only option is a restore of data. If you do that I would recommend rebuilding the vinum configuration. Arrange a single vinum partition per disk and then use multiple subdisks to share the storage amongst different plexes. Here's output of a scenario I just now ran on my test box: I got a lot of errors with fsck which are strange to me as I have only two files on the filesystem. More investigation ongoing (probably tomorrow as it's now late) Throughout the various activities vinum gives full access to the volume with only one subdisk lost. raider# vinum stop data.p0.s0 Can't stop data.p0.s0: Device busy (16) raider# vinum lv -r data V data State: up Plexes: 1 Size: 16 GB P data.p0R5 State: up Subdisks: 5 Size: 16 GB S data.p0.s0State: up PO:0 B Size: 4298 MB S data.p0.s1State: up PO: 492 kB Size: 4298 MB S data.p0.s2State: up PO: 984 kB Size: 4298 MB S data.p0.s3State: up PO: 1476 kB Size: 4298 MB S data.p0.s4State: up PO: 1968 kB Size: 4298 MB raider# vinum stop -f data.p0.s0 vinum: data.p0.s0 is down by force vinum: data.p0 is degraded raider# vinum lv -r data V data State: up Plexes: 1 Size: 16 GB P data.p0R5 State: degraded Subdisks: 5 Size: 16 GB S data.p0.s0State: down PO:0 B Size: 4298 MB S data.p0.s1State: up PO: 492 kB Size: 4298 MB S data.p0.s2State: up PO: 984 kB Size: 4298 MB S data.p0.s3State: up PO: 1476 kB Size: 4298 MB S data.p0.s4State: up PO: 1968 kB Size: 4298 MB raider# ll /data total 1046000 -rw-r--r-- 1 root wheel 510709760 Feb 17 22:45 objtest.tar -rw-r--r-- 1 root wheel 559839232 Feb 17 22:40 office2k.iso raider# umount /data vinum: data.p0.s0 is obsolete by force raider# vinum lv -r data V data State: up Plexes: 1 Size: 16 GB
Help with Vinum disk crash...
Hello, About 6 weeks ago one of the disks in my Vinum array crashed. However, the major problem is now that the file system is corrupt. It appears I have lost all of my 300Gb virtual disk... This is what I found in the message log. Jan 2 04:13:07 guard /kernel: ad4s1a: hard error reading fsbn 317875665 of 150983369-150983370 (ad4s1 bn 317875665; cn 19786 tn 215 sn 30) trying PIO mode Jan 2 04:13:08 guard /kernel: ad4s1a: hard error reading fsbn 317875665 of 150983369-150983370 (ad4s1 bn 317875665; cn 19786 tn 215 sn 30) status=59 error=40 Jan 2 04:13:08 guard /kernel: vinum: data.p0.s0 is crashed by force Jan 2 04:13:08 guard /kernel: vinum: data.p0 is degraded Jan 2 04:13:08 guard /kernel: fatal:data.p0.s0 read error, block 150983369 for 1024 bytes Jan 2 04:13:08 guard /kernel: data.p0.s0: user buffer block 452942752 for 1024 bytes Jan 2 04:13:09 guard /kernel: vinum: data.p0.s0 is stale by force I had not had time to look at this till now When I do try and mount the volume, it says the following: [02:25 PM [EMAIL PROTECTED]:/var/log]#mount /dev/vinum/data /usr/jails/ftp/data mount: /dev/vinum/data on /usr/jails/ftp/data: incorrect super block I suspect that the physical disk is dead, but I should be able to re-mount the volume with only 3 (out of 4 ) disks right? -D -- This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst Young Group. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with Vinum disk crash...
[Format recovered--see http://www.lemis.com/email/email-format.html] Log output wrapped. On Tuesday, 17 February 2004 at 14:27:51 +0100, Danny Carroll wrote: Hello, About 6 weeks ago one of the disks in my Vinum array crashed. However, the major problem is now that the file system is corrupt. It appears I have lost all of my 300Gb virtual disk... This is what I found in the message log. Jan 2 04:13:07 guard /kernel: ad4s1a: hard error reading fsbn 317875665 of 150983369-150983370 (ad4s1 bn 317875665; cn 19786 tn 215 sn 30) trying PIO mode Jan 2 04:13:08 guard /kernel: ad4s1a: hard error reading fsbn 317875665 of 150983369-150983370 (ad4s1 bn 317875665; cn 19786 tn 215 sn 30) status=59 error=40 Jan 2 04:13:08 guard /kernel: vinum: data.p0.s0 is crashed by force Jan 2 04:13:08 guard /kernel: vinum: data.p0 is degraded Jan 2 04:13:08 guard /kernel: fatal:data.p0.s0 read error, block 150983369 for 1024 bytes Jan 2 04:13:08 guard /kernel: data.p0.s0: user buffer block 452942752 for 1024 bytes Jan 2 04:13:09 guard /kernel: vinum: data.p0.s0 is stale by force I had not had time to look at this till now When I do try and mount the volume, it says the following: [02:25 PM [EMAIL PROTECTED]:/var/log]#mount /dev/vinum/data /usr/jails/ftp/data mount: /dev/vinum/data on /usr/jails/ftp/data: incorrect super block I suspect that the physical disk is dead, but I should be able to re-mount the volume with only 3 (out of 4 ) disks right? I answered an almost identical question yesterday: it depends on the volume structure, which you haven't stated. Look at http://www.vinumvm.org/vinum/how-to-debug.html and supply in particular the output of 'vinum list', unless the following applies: If this volume has only one plex, you're lost, unless you can bring up the failed disk long enough to make a backup. 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. pgp0.pgp Description: PGP signature
