Hand on gmirror (Was: Re: gmirror bugs, how many?)
Pawel Jakub Dawidek
pjd at FreeBSD.org
Mon Nov 29 07:11:30 PST 2004
On Mon, Nov 29, 2004 at 12:52:40PM -0200, Jo?o Carlos Mendes Luís wrote:
+> >+> 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?
+> >
+> >Your disk will not be detected as a mirror component, because hardcoded
+> >name is different.
+>
+> Oops. Is there a check for that? For example, let's say that ad0s1 got
+> renamed to ad1s1, and hardcoded a reference to ad0s1. In this case,
+> there is a disk called ad0s1 in the system. Is gmirror smart enough in
+> this case?
In this case ad1s1 will not be connected to the mirror (but don't worry,
ad0s1 will not be connected as well).
+> >+> 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.
+> >
+> >Ehh, "blame" disklabel(8). First 16 sectors are reserved for boot code.
+>
+> And why this does not happen with ad0s1, etc?
I think it should, only using sysinstall for this will not allocate those
sectors. Anyway, it has nothing to do with gmirror.
--
Pawel Jakub Dawidek http://www.FreeBSD.org
pjd at FreeBSD.org http://garage.freebsd.pl
FreeBSD committer Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20041129/3175405f/attachment.bin
More information about the freebsd-hackers
mailing list