Date: Sun, 19 Dec 2004 07:12:21 +0100 From: Nikolaj Hansen <nikolaj.hansen@barnabas.dk> To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 5.3 and vinum upgrade #2 Message-ID: <20041219061221.GA977@sauron.barnabas.dk> In-Reply-To: <1103416078.6339.4.camel@zappa.Chelsea-Ct.Org> References: <41C48A6F.7000203@barnabas.dk> <1103409359.52279.2.camel@zappa.Chelsea-Ct.Org> <200412190015.16449.msch@snafu.de> <1103416078.6339.4.camel@zappa.Chelsea-Ct.Org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 18, 2004 at 07:27:58PM -0500, Paul Mather wrote: > On Sun, 2004-12-19 at 00:15 +0100, Matthias Schuendehuette wrote: > > Am Samstag, 18. Dezember 2004 23:35 schrieb Paul Mather: > > > > > > The biggest problem you'll have is if your system suffers the ATA > > > "TIMEOUT - WRITE_DMA" woe that bedevils some of us under 5.3. When > > > that happens, your mirror will be knocked into a degraded state (half > > > of your mirrored plexes will be marked down) even though the drive is > > > okay. Unfortunately, without "setstate" being implemented in "gvinum" > > > to mark the drive as up, thereby allowing you to issue "gvinum > > > start"s for the "downed" plexes, there's little more you can do to > > > get the "failed" drive recognised as being in the "up" state other > > > than to reboot. [...] > > > > 'gvinum setstate' was MFCed from -current together with 'gvinum > > checkpatity' and 'gvinum rebuildparity' a week ago or so... > > > > So that should make it easier to handle these ATA-Problems... > > That's great to hear! (I'd been hoping for an MFC5.) It's handy, too, > as I just recently got another one of those "TIMEOUT - WRITE DMA" > induced "failures," which was getting to be a real drag. :-( > > I'll update my 5.3-STABLE system right away... > > Cheers, > > Paul. > -- > e-mail: paul@gromit.dlib.vt.edu > > "Without music to decorate it, time is just a bunch of boring production > deadlines or dates by which bills must be paid." > --- Frank Vincent Zappa > Hi again, I gave the 5.3 upgrade another swing. Now the situation is: $ uname -a FreeBSD sauron.barnabas.dk 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Sat Dec 18 18:39:09 CET 2004 root@sauron.barnabas.dk:/usr/obj/usr/src/sys/KERNEL_5_3 i386 I think I am understanding a little more of this now. In order to use my scsi / ATA setup, I need to use the geom_vinum.ko *and* the vinum.ko modules? At least this combo will let me manually start the server again by loading the modules and mount the drives. The state of the output can be listed as such: $ sudo vinum list 3 drives: D elben State: up /dev/da1s1h A: 0/7825 MB (0%) D donau State: up /dev/da0s1h A: 0/7825 MB (0%) D spree State: up /dev/ad4a A: 3/114473 MB (0%) 5 volumes: V var State: up Plexes: 2 Size: 600 MB V tmp State: up Plexes: 2 Size: 600 MB V home State: up Plexes: 2 Size: 1000 MB V usr State: up Plexes: 2 Size: 5625 MB V data01 State: up Plexes: 1 Size: 111 GB 9 plexes: P var.p0 C State: up Subdisks: 1 Size: 600 MB P tmp.p0 C State: up Subdisks: 1 Size: 600 MB P home.p0 C State: up Subdisks: 1 Size: 1000 MB P usr.p0 C State: up Subdisks: 1 Size: 5625 MB P var.p1 C State: up Subdisks: 1 Size: 600 MB P tmp.p1 C State: up Subdisks: 1 Size: 600 MB P home.p1 C State: up Subdisks: 1 Size: 1000 MB P usr.p1 C State: up Subdisks: 1 Size: 5625 MB P data01.p0 C State: up Subdisks: 1 Size: 111 GB 9 subdisks: S var.p0.s0 State: up D: donau Size: 600 MB S tmp.p0.s0 State: up D: donau Size: 600 MB S home.p0.s0 State: up D: donau Size: 1000 MB S usr.p0.s0 State: up D: donau Size: 5625 MB S var.p1.s0 State: up D: elben Size: 600 MB S tmp.p1.s0 State: up D: elben Size: 600 MB S home.p1.s0 State: up D: elben Size: 1000 MB S usr.p1.s0 State: up D: elben Size: 5625 MB S data01.p0.s0 State: up D: spree Size: 111 GB $ sudo gvinum list 3 drives: D elben State: up /dev/da1s1h A: 0/7825 MB (0%) D donau State: up /dev/da0s1h A: 0/7825 MB (0%) D spree State: up /dev/ad4a A: 3/114473 MB (0%) 5 volumes: V data01 State: up Plexes: 1 Size: 111 GB V usr State: down Plexes: 2 Size: 5625 MB V home State: down Plexes: 2 Size: 1000 MB V tmp State: down Plexes: 2 Size: 600 MB V var State: down Plexes: 2 Size: 600 MB 9 plexes: P data01.p0 C State: up Subdisks: 1 Size: 111 GB P usr.p1 C State: down Subdisks: 1 Size: 5625 MB P home.p1 C State: down Subdisks: 1 Size: 1000 MB P tmp.p1 C State: down Subdisks: 1 Size: 600 MB P var.p1 C State: down Subdisks: 1 Size: 600 MB P usr.p0 C State: down Subdisks: 1 Size: 5625 MB P home.p0 C State: down Subdisks: 1 Size: 1000 MB P tmp.p0 C State: down Subdisks: 1 Size: 600 MB P var.p0 C State: down Subdisks: 1 Size: 600 MB 9 subdisks: S data01.p0.s0 State: up D: spree Size: 111 GB S usr.p1.s0 State: stale D: elben Size: 5625 MB S home.p1.s0 State: stale D: elben Size: 1000 MB S tmp.p1.s0 State: stale D: elben Size: 600 MB S var.p1.s0 State: stale D: elben Size: 600 MB S usr.p0.s0 State: stale D: donau Size: 5625 MB S home.p0.s0 State: stale D: donau Size: 1000 MB S tmp.p0.s0 State: stale D: donau Size: 600 MB S var.p0.s0 State: up D: donau Size: 600 MB Is this correct? I suppose the ATA drives should be mounted on the new /dev/gvinum/* and the scsi drives on the /dev/vinum/*? My fstab and loader.conf are as follows: $ cat /etc/fstab /dev/da0s1b none swap sw 0 0 /dev/da1s1b none swap sw 0 0 /dev/da0s1a / ufs rw 1 1 /dev/vinum/home /home ufs rw 2 2 /dev/da1s1a /rootback ufs rw 2 1 /dev/vinum/tmp /tmp ufs rw 2 3 /dev/vinum/usr /usr ufs rw 2 4 /dev/vinum/var /var ufs rw 2 5 /dev/cd0 /cdrom cd9660 ro,noauto 0 0 /dev/acd0 /cdrom1 cd9660 ro,noauto 0 0 /dev/ad6s1 /data ufs rw 1 1 /dev/vinum/data01 /data2 ufs rw 1 1 $ cat /boot/loader.conf vesa_load="YES" agp_load="YES" geom_vinum_load="YES" vinum_load="YES" vinum.autostart="YES" linux_load="YES" dumpdev="/dev/da0s1b" hw.ata.ata_dma=1 # enable IDE DMA hw.ata.atapi_dma=1 # enable ATAPI/IDE DMA As I wrote earlier the above loader.conf is not working. If I leave out the load of the old vinum driver it does not seem to be possible to mount the scsi drives. If I leave out the geom_vinum a mount of a drive causes a kernel panic. It would be nice if any of you would comment on the above config. Perhaps I am ignorant, but it seems to me it would have been easier to make the regular vinum diver handle geom drives in place of making a new kernel object? Or perhaps theres a technical reason for not doing so? -- With regards / med venlig hilsen Nikolaj Hansen Algade 15, 2 tv 9000 Aalborg Danmark "Even on the highest throne in the world, we are seated, still, upon our arses." - Montaigne
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041219061221.GA977>