From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 26 19:55:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 662BF16A4CE; Fri, 26 Nov 2004 19:55:54 +0000 (GMT) Received: from minerva.int.gov.br (nat.int.gov.br [200.20.196.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 677D443D55; Fri, 26 Nov 2004 19:55:53 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from [10.0.8.17] (dinf-02 [10.0.8.17]) by minerva.int.gov.br (Postfix) with ESMTP id 4A397BE56E; Fri, 26 Nov 2004 17:55:51 -0200 (BRDT) Message-ID: <41A78A47.3050309@jonny.eng.br> Date: Fri, 26 Nov 2004 17:55:51 -0200 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <41A4FD60.4050501@jonny.eng.br> <20041125224547.GB7232@darkness.comp.waw.pl> <41A6B76F.4020101@jonny.eng.br> <20041126082340.GC7232@darkness.comp.waw.pl> In-Reply-To: <20041126082340.GC7232@darkness.comp.waw.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Hand on gmirror (Was: Re: gmirror bugs, how many?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2004 19:55:54 -0000 Pawel Jakub Dawidek wrote: > All I'm saying is that you first should create a mirror, then create slices > and partitions on top of mirror provider, because you want to use > mirror/vol0s1a, not ad0s1a. Note, that mirror/vol0 is one sector shorter > than ad0 and imagine a situation when gmirror stores metadata in the same > place where BSD stores it - if you first create a mirror and then > partitions on ad0 you'll overwrite gmirror metadata. This very painful, > that in MBR metadata is visible on traffic providers and I don't want to > repeat that mistake. > > +> >+> Now, lets reboot. I could not unload geom_mirror, since it was > +> >+> preloaded during boot, is this expected? The device could not be > +> >+> unloaded, but the volume disapeared (gmirror list, ls /dev/mirror). > +> > > +> >If there is no mirror configured, you should be able to unload it. > +> > +> Before putting it in /boot/loader.conf, unload worked, even with mirror > +> devices configured, IIRC. Only after loader.conf preloading this > +> problem appeared. > > What error do you get when you try to do this? Step by step: - The system has started with a preloaded geom_mirror: sigesc::root jcmendes [521] kldstat Id Refs Address Size Name 1 13 0xc0400000 3126c4 kernel 2 1 0xc0713000 10be8 geom_mirror.ko 3 14 0xc0724000 59340 acpi.ko 4 1 0xc106a000 6000 linprocfs.ko 5 1 0xc1070000 18000 linux.ko 6 1 0xc1183000 2000 fade_saver.ko sigesc::root jcmendes [522] cat /boot/loader.conf geom_mirror_load="YES" sigesc::root jcmendes [523] - There is a running mirror partition: sigesc::root jcmendes [523] gmirror list Geom name: vol0 State: COMPLETE Components: 1 Balance: load Slice: 4096 Flags: NONE SyncID: 1 ID: 4105191088 Providers: 1. Name: mirror/vol0 Mediasize: 8447426048 (7.9G) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: ad1s1 Mediasize: 8447426560 (7.9G) Sectorsize: 512 Mode: r0w0e0 State: ACTIVE Priority: 0 Flags: NONE SyncID: 1 ID: 4260835530 Geom name: vol0.sync sigesc::root jcmendes [524] - Now let's try to remove (disable was my intention, a bad idea): sigesc::root jcmendes [524] gmirror unload Could not unload module: Device not configured. sigesc::root jcmendes [525] gmirror list sigesc::root jcmendes [526] gmirror load Command 'load' not available. sigesc::root jcmendes [527] gmirror list sigesc::root jcmendes [528] kldstat Id Refs Address Size Name 1 13 0xc0400000 3126c4 kernel 2 1 0xc0713000 10be8 geom_mirror.ko 3 14 0xc0724000 59340 acpi.ko 4 1 0xc106a000 6000 linprocfs.ko 5 1 0xc1070000 18000 linux.ko 6 1 0xc1183000 2000 fade_saver.ko sigesc::root jcmendes [529] ls -l /dev/mirror/ total 1 dr-xr-xr-x 2 root wheel 512 Nov 26 12:19 . dr-xr-xr-x 5 root wheel 512 Nov 26 12:19 .. sigesc::root jcmendes [530] - Well, something not good happened. The device did not unload, and do not list any device anymore. Trying to "reload" it has no effect. - This used to work before preloading it in loader.conf, but then I would not be able to boot a mirror partition. > > +> The man page says only: > +> > +> -h Hardcode providers' names in metadata. > +> > +> and does not explain when I should use this. > +> > +> Do you mean that if I want it to use ad1s1 as the provider, and not ad1, > +> -h is what I want? > > Only when you share the last sector between those two providers. > You can still create ad1s1, which is one sector shorter. Good idea. This should go into the manual also... Indeed, the -h option is what I wanted and the "bug" is in the manual. What would happen if I change the disc ID in this case? > +> And even if gmirror is correct, there's also the problem shown with > +> disklabel in my previous email. > > What problem is there when you use proper order of doing things? I could not describe how repeat it. Maybe it was a side effect of not cleaning the disc before. Let me start from a clean disk. To make sure no previous data causes any error, I have first zeroed the contents of the test disk. Then I ran "fdisk -i ad1", "gmirror label -h -b load vol0 ad1s1" and finally "disklabel -w -B mirror/vol0". After this the /dev and disklabel state is: sigesc::root jcmendes [552] ls -l /dev/ad1* /dev/mirror/* crw-r----- 1 root operator 4, 16 Nov 26 11:46 /dev/ad1 crw-r----- 1 root operator 4, 31 Nov 26 11:50 /dev/ad1s1 crw-r----- 1 root operator 4, 132 Nov 26 11:20 /dev/ad1s1a crw-r----- 1 root operator 4, 133 Nov 26 11:20 /dev/ad1s1c crw-r----- 1 root operator 4, 121 Nov 26 11:59 /dev/mirror/vol0 crw-r----- 1 root operator 4, 134 Nov 26 11:20 /dev/mirror/vol0a crw-r----- 1 root operator 4, 135 Nov 26 11:20 /dev/mirror/vol0c sigesc::root jcmendes [553] disklabel mirror/vol0 # /dev/mirror/vol0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 16498864 16 unused 0 0 c: 16498880 0 unused 0 0 # "raw" part, don't edit sigesc::root jcmendes [554] Seems good until now. Except for the offset 16 of the "a" partition. Is this necessary? The man page says that the only sector reserved for metadata is the provider's last one. I've made some tests after this, including changing the disklabel offset to 0, without no problem until now. I think that using 0 makes the disk fully compatible with a no-mirror one, and copying is easier. If I understood correctly your statements, this is your intention too, so this could be a bug. Now let me try the off by -1 approach. sigesc::root jcmendes [509] fdisk -i ad1 ... Information from DOS bootblock is: 1: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 16498880 (8056 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1007/ head 15/ sector 62 2: 3: 4: Should we write new partition table? [n] y sigesc::root jcmendes [510] - Note that the last sector is 62 and not 63, I've changed it, despite some warnings. sigesc::root jcmendes [517] disklabel -w -B mirror/vol0 sigesc::root jcmendes [518] disklabel mirror/vol0 # /dev/mirror/vol0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 16498863 16 unused 0 0 c: 16498879 0 unused 0 0 # "raw" part, don't edit sigesc::root jcmendes [519] Again, the same problem with offset 16. But the block devices look like ok: sigesc::root jcmendes [519] ls -l /dev/ad1* /dev/mirror/* crw-r----- 1 root operator 4, 16 Nov 26 17:38 /dev/ad1 crw-r----- 1 root operator 4, 59 Nov 26 17:39 /dev/ad1s1 crw-r----- 1 root operator 4, 85 Nov 26 12:19 /dev/ad1s1a crw-r----- 1 root operator 4, 86 Nov 26 12:19 /dev/ad1s1c crw-r----- 1 root operator 4, 72 Nov 26 17:41 /dev/mirror/vol0 crw-r----- 1 root operator 4, 87 Nov 26 12:19 /dev/mirror/vol0a crw-r----- 1 root operator 4, 88 Nov 26 12:19 /dev/mirror/vol0c sigesc::root jcmendes [520] Maybe my anxiety to see this working made me panic with the first problems and I let my mistakes be taken as system bugs. BTW, this system is using 5.3-stable, from cvsup syncronized at Nov 22. Thanks for your help.