-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 11 October 2004 17:56, Paul Mather wrote: > On Mon, 11 Oct 2004 14:26:06 +0100, Chris Elsworth <chris_at_shagged.org> > > wrote: > > So, I'm left quite unsure whether the warnings are harmless or not. > > Pawel, can we just use existing labels on disks and apply a gmirror > > over it, or should we be re-labelling inside the mirror device? > > I believe it is safer to re-bsdlabel the mirror device rather than use > an existing disklabel. Remember, the mirror device uses one sector at > the end of each provider to store its metadata. So, if you use the > existing provider's disklabel, you will at the very least get complaints > concerning the label about the "c" partition extending past the end of > the device (because the "c" partition will be one sector too long now). Just an example how to find out, if there is a risk that metadata will overwrite userdata on an existing slice: Our disk is ad6. Our existing slice is ad6s1, it holds 4 partitions (/ swap /usr /home) We want to mirror the whole disk. # boot -v ad6: <Maxtor 6Y120P0/YAR41BW0> ATA-7 disk at ata3-master ad6: 117246MB (240121728 sectors), 238216 C, 16 H, 63 S, 512 B ^^^^^^^^^ ^^^ ** raw size is 240121728 sectors ** sectorsize is 512 bytes. ** last sector 240121728 will hold our new gmirror metadata. ad6: 16 secs/int, 1 depth queue, UDMA133 [0] f:00 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:240107427 ^^^^ ** the 63 sector offset displayed by bsdlabel after gmirror has been started [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: new disk ad6 GEOM: Configure ad6s1, start 32256 length 122935002624 end 122935034879 ^^^^^ ^^^^^^^^^^^^ ** slice starts at sector 63 [32256/512] ** slice ends at sector 240107489 [122935034879/512] Now we have all information we need: Raw disksize in sectors 240121728 Slice ad6s1 ends at sector 240107489 So we see that our new metadata, which will be stored in sector 240121728, never will touch any userdata inside slice ad6s1. Curiously, we want to check what happens in real life: # gmirror label -b split -s 16384 mirror0 ad6 # gmirror list Geom name: mirror0 State: COMPLETE Components: 2 Balance: split Slice: 16384 Flags: NONE SyncID: 3 ID: 2363178490 Providers: 1. Name: mirror/mirror0 Mediasize: 122942324224 (114G) ** new gmirror device 240121727 sectors [122942324224/512] Sectorsize: 512 Mode: r4w4e2 Consumers: 1. Name: ad6 Mediasize: 122942324736 (114G) ** raw device 240121728 sectors [122942324736/512] ** sector 24012178 holds our metadata Sectorsize: 512 Mode: r4w4e3 State: ACTIVE Priority: 1 Flags: DIRTY SyncID: 3 ID: 3530324446 check if metadata really live in sector 240121728: # dd if=/dev/ad6 of=/root/meta skip=240121727 count=1 # more /root/meta GEOM::MIRROR [...] > Also, if you are unlucky, the mirror metadata might overwrite (and > render inaccessible) a sector's worth of actual filesystem data in the > last sector from the original provider when you create the mirror. That > could cause problems. > > Labelling the mirror device ensures that filesystem data is not on any > inaccessible sectors (assuming you don't deliberately create an invalid > label on the new mirror device:). > > FWIW, I outline in a posting to freebsd-geom the steps I took to do a > fresh install of FreeBSD 5.3-BETA to create an root-on-gmirror setup > (http://lists.freebsd.org/pipermail/freebsd-geom/2004-September/000307.html >). A similar technique could be used to gmirror an existing setup. Thanks, for the link (Chris already pointed me to this thread). I will try this on a testmachine. > > Cheers, > > Paul. - -- Christian Hiris <4711_at_chello.at> | OpenPGP KeyID 0x3BCA53BE OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBbAyY09WjGjvKU74RAkbAAJ9C6RtG1gQT7oDFvt7KJzJ8ojCk0gCfbqM5 rk69wA8jyRTcVQN4wPYrYgk= =T1Oy -----END PGP SIGNATURE-----Received on Tue Oct 12 2004 - 14:55:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:16 UTC