Date: Fri, 02 Jul 1999 04:22:10 +0200 From: Palle Girgensohn <girgen@partitur.se> To: Greg Lehey <grog@lemis.com> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: vinum for root partition? Message-ID: <377C2252.B4682706@partitur.se> References: <377BEE3B.A10C4D8@partitur.se> <19990702105804.I87392@freebie.lemis.com> <377C1980.3A0B4FDD@partitur.se> <19990702112415.K87392@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote: > > On Friday, 2 July 1999 at 3:44:32 +0200, Palle Girgensohn wrote: > > Greg Lehey wrote: > >> > >> [Format recovered--see http://www.lemis.com/email/email-format.html] > >> > >> On Friday, 2 July 1999 at 0:39:55 +0200, Palle Girgensohn wrote: > >>> Hi! > >>> > >>> I'm just setting up a system with two scsi drives, using vinum for > >>> mirroring only. Is it possible to use vinum for the also root partition > >>> somehow? I realize it not simple. > >> > >> Sure, it's just a SMOP. > > > > Sorry, My English isn't native... SMOP? :?) > > To quote the New Hackers' Dictionary: > > :SMOP: /S-M-O-P/ /n./ [Simple (or Small) Matter of > Programming] 1. A piece of code, not yet written, whose anticipated > length is significantly greater than its complexity. Used to refer > to a program that could obviously be written, but is not worth the > trouble. Also used ironically to imply that a difficult problem > can be easily solved because a program can be written to do it; the > irony is that it is very clear that writing such a program will be > a great deal of work. "It's easy to enhance a FORTRAN compiler to > compile COBOL as well; it's just an SMOP." 2. Often used > ironically by the intended victim when a suggestion for a program > is made which seems easy to the suggester, but is obviously (to the > victim) a lot of work. > > >>> Here's my disklabel (same for both drives): > >>> # size offset fstype [fsize bsize bps/cpg] > >>> a: 144585 0 4.2BSD 1024 8192 16 # (Cyl. 0 - 8) > >>> b: 803250 144585 swap # (Cyl. 9 - 58) > >>> c: 17928698 0 unused 0 0 # (Cyl. 0 - 1116*) > >>> e: 16980863 947835 4.2BSD 1024 8192 16 # (Cyl. 59 - 1116*) > >>> > >>> My plan is to sync the the 'a' partitions, so if one disk dies, the > >>> other root partition is useable. But, I guess the system will have to > >>> reboot if the drive crashes, since the root fs will be unusable. > >> > >> If you're using Vinum, you should have only one partition per disk. > > > > Yes, there's no reason to have more than one vinum partition, I realize > > that. You don't mean to say that there's a problem with this setup, I > > hope? :-/ It seems to be working fine, anyway. > > It's fine without Vinum. With Vinum, I'd expect: > > # size offset fstype [fsize bsize bps/cpg] > a: 17928698 0 vinum 0 0 # (Cyl. 0 - 1116*) > c: 17928698 0 unused 0 0 # (Cyl. 0 - 1116*) > Hmm.. I need a root somewhere... of course, I cited the wrong disklabel (almost right, but missed the "vinum"): here's what it really looks like: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 144585 0 4.2BSD 1024 8192 16 # (Cyl. 0 - 8) b: 803250 144585 swap # (Cyl. 9 - 58) c: 17928698 0 unused 0 0 # (Cyl. 0 - 1116*) e: 16980863 947835 vinum # (Cyl. 59 - 1116*) and a vinum.conf like device disk1 /dev/da1e ... I use vinum on other systems, and they have run flawlessly for months now, only problem beeing that at least one system cannot use 'vinum start' to startup, but instead needs 'vinum read /dev/da1 /dev/da2 /dev/da3...' to start (lastest version on 3.2-STABLE). I read about the possible deadlock with using vinum for swap, so I have swaps separately, and in this case also a root fs. This works for me, but maybe I'm just lucky? BTW: Vinum is really good stuff. Thanks! Regards, Palle 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?377C2252.B4682706>