Date: Thu, 14 Sep 2000 18:01:47 +0930 From: Greg Lehey <grog@lemis.com> To: Aistis Zenkevicius <noc@unix.lt> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: vinum and/or fsck problems after crash Message-ID: <20000914180147.Q45769@wantadilla.lemis.com> In-Reply-To: <019e01c01e23$9f044640$1464a8c0@admin>; from noc@unix.lt on Thu, Sep 14, 2000 at 10:13:10AM %2B0200 References: <018601c01d8c$e27306b0$1464a8c0@admin> <20000914115715.E45769@wantadilla.lemis.com> <019e01c01e23$9f044640$1464a8c0@admin>
next in thread | previous in thread | raw e-mail | index | archive | help
[Format recovered--see http://www.lemis.com/email/email-format.html] Please don't wrap log file entries. On Thursday, 14 September 2000 at 10:13:10 +0200, Aistis Zenkevicius wrote: > hello Mr.Greg, > > [snip] >>> ...so far >>> after imitating crash [reset] i get plex [mp3.p0] "corrupt" and >>> using "stop -f" stoping subdisks, making "start" again and looks >>> like everything is ok aKa "up" . Problem is - system don't want to >>> mount that virtual drive, because it was unmounted not properly and >>> asks to run "fsck" which after a while [anyway 150gb...] says : >>> "CANNOT READ: BLK 298516880" and lot's of such messages. If i say >>> "no" to question to continue or not and make "vinum l" i get - "S >>> mp3.p0.s1 State: crashed" and sure "P mp3.p0 C State: corrupt" which >>> i don't understand. > > so here's info you asked [sorry that theres so much info]: > i have 4.0-RELEASE FREEBSD, there's no source code changes the only > thing - kernel is not generic, but compiled using my configuration file > which has UDMA enabled by default on drives, vinum drives are ibm ide > drives. > ------- > "vinum list" shows: > 2 drives: > D d1 State: up Device /dev/ad2s1e Avail: 0/73308 MB (0%) > D d2 State: up Device /dev/ad3s1e Avail: 0/73308 MB (0%) You shouldn't put two Vinum drives on the same IDE controller. It will (should) work, but performance will suffer. > 1 volumes: > V mp3 State: up Plexes: 1 Size: 143 GB > 1 plexes: > P mp3.p0 C State: corrupt Subdisks: 2 Size: 143 GB > 2 subdisks: > S mp3.p0.s0 State: up PO: 0 B Size: 71 GB > S mp3.p0.s1 State: crashed PO: 71 GB Size: 71 GB > ------- > /var/tmp/vinum_history: > 13 Sep 2000 12:47:02.649176 *** vinum started *** > 13 Sep 2000 12:47:05.541566 list > 13 Sep 2000 12:47:18.918029 start mp3.p0 > 13 Sep 2000 12:59:29.341195 stop mp3 > 13 Sep 2000 12:59:50.096871 l > 13 Sep 2000 13:00:57.079025 stop mp3.p0.s0 mp3.p0.s1 > 13 Sep 2000 13:01:14.003530 stop -f mp3.p0.s1 > 13 Sep 2000 13:01:16.931733 stop -f mp3.p0.s0 > 13 Sep 2000 13:01:32.592548 stop mp3.p0 > 13 Sep 2000 13:01:49.298794 stop -f mp3.p0 > 13 Sep 2000 13:01:58.990704 stop mp3 > 13 Sep 2000 13:02:06.972407 list > 13 Sep 2000 13:02:14.680123 start mp3 > 13 Sep 2000 13:02:17.162310 list > 13 Sep 2000 13:02:23.763403 quit > --------- > /var/log/messages: > Sep 13 12:46:22 blackcube /kernel: vinum: loaded > Sep 13 12:46:28 blackcube /kernel: vinum: reading configuration from /dev/ad3s1e > Sep 13 12:46:28 blackcube /kernel: vinum: updating configuration from /dev/ad2s1e > Sep 13 12:59:29 blackcube /kernel: vinum: volume mp3 is down > Sep 13 13:01:14 blackcube /kernel: vinum: mp3.p0.s1 is down by force > Sep 13 13:01:14 blackcube /kernel: vinum: mp3.p0.s0 is up > Sep 13 13:01:14 blackcube /kernel: vinum: mp3.p0.s1 is up > Sep 13 13:01:14 blackcube /kernel: vinum: mp3.p0 is up > Sep 13 13:01:14 blackcube /kernel: vinum: mp3 is up > Sep 13 13:01:16 blackcube /kernel: vinum: mp3.p0.s0 is down by force > Sep 13 13:01:16 blackcube /kernel: vinum: mp3.p0.s0 is up > Sep 13 13:01:17 blackcube /kernel: vinum: mp3.p0.s1 is up > Sep 13 13:01:49 blackcube /kernel: vinum: mp3.p0.s0 is down by force > Sep 13 13:01:49 blackcube /kernel: vinum: mp3.p0.s0 is up > Sep 13 13:01:49 blackcube /kernel: vinum: mp3.p0.s1 is up > Sep 13 13:01:49 blackcube /kernel: vinum: mp3.p0 is up > Sep 13 13:01:49 blackcube /kernel: vinum: mp3.p0.s1 is down by force > Sep 13 13:01:49 blackcube /kernel: vinum: mp3.p0.s0 is up > Sep 13 13:01:49 blackcube /kernel: vinum: mp3.p0.s1 is up > Sep 13 13:01:58 blackcube /kernel: vinum: volume mp3 is down > Sep 13 13:02:14 blackcube /kernel: vinum: mp3 is up These down messages come because the state is saved on the drives. The drive obviously crashed earlier One of the problems here is that we didn't see the original reason why mp3.p0.s1 went down. Looking at what comes below, I think I can guess, but it's a guess as long as I don't see the original log. > ------ > after that, i'm trying to mount /dev/vinum/mp3 and here it goes : > Sep 13 13:02:57 blackcube /kernel: ad2: UDMA ICRC READ ERROR blk# 281 retrying > Sep 13 13:02:57 blackcube last message repeated 2 times > Sep 13 13:02:57 blackcube /kernel: ad2: UDMA ICRC READ ERROR blk# 281ata1-master: WARNING: WAIT_READY active=ATA_ACTIVE_ATA > Sep 13 13:02:57 blackcube /kernel: falling back to PIO mode > Sep 13 13:02:57 blackcube /kernel: WARNING: R/W mount of /usr/mp3 denied. Filesystem is not clean - run fsck > ------- > and then i run fsck after some time i get : > Sep 13 16:03:34 blackcube /kernel: ad3: HARD READ ERROR blk# > 148382361ata1-slave: WARNING: WAIT_READY active=ATA_ACTIVE_ATA > Sep 13 16:03:39 blackcube /kernel: ad3: HARD READ ERROR blk# 148382361 status=59 error=40 > Sep 13 16:03:39 blackcube /kernel: ad3: DMA problem fallback to PIO mode > Sep 13 16:03:39 blackcube /kernel: mp3.p0.s1: fatal read I/O error > Sep 13 16:03:39 blackcube /kernel: vinum: mp3.p0.s1 is crashed by force > Sep 13 16:03:39 blackcube /kernel: vinum: mp3.p0 is corrupt > > hope this helps a bit...actually i'm starting to see that there's > something wrong with dma, but maybe i'm wrong. No, I think you're right. I'd suggest you fall back to PIO mode. What about the data? Strictly speaking, it's corrupted, and so you should restore from your last backup. Since it's presumably MP3 stuff, though, the damage done by a possible corruption would not be very great. At your own risk, you can use the vinum(8) command setstate up mp3.p0.s1 to bring the drives into an 'up' state. Until you do, you don't stand a chance of completing fsck. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply. For more information, see http://www.lemis.com/questions.html Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000914180147.Q45769>