ioctl or api to get size of fdisk partition p0 (entire physical disk) on solaris x86
in [Solaris]
|
Prev: zfs snapshots for TAPE backup: 1: must be of entire pool? 2:if yes, then need TWICE as much disk?
Next: Newbie query about patch
From: mannu on 18 Feb 2010 08:01 Hello, From what I gathered from solaris experts and google: For solaris x86, p0 fdisk partition represents the entire physical disk and p1, p2, p3 and p4 are the partitions on which different operating systems can reside. s2 slice represents any of p1, p2, p3 or p4. Please help on following queries: 1. Is p0 always designated to be entire physical disk? I mean can entire physical disk will ever be p1, p2, p3 or p4? 2. Is there an ioctl or api (like readvtoc or DKIOCGVTOC for s2) that gives us size of p0 entire physical disk and also p1, p2, p3 and p4? 3. I was going through code in open solaris repository and they seem to be reading first 512 bytes from "p0" partition and interpreting it as "struct mboot" which in turn has information about p1, p2, p3 and p4 partitions. 4. I am interested in getting sizes of p0, p1, p2, p3 and p4 fdisk partitions. Thanks and Regards, Manish Singh.
From: Casper H.S. Dik on 18 Feb 2010 08:10 mannu <manishsinghhyb(a)gmail.com> writes: >Hello, >From what I gathered from solaris experts and google: >For solaris x86, p0 fdisk partition represents the entire physical >disk >and p1, p2, p3 and p4 are the partitions on which different operating >systems can reside. >s2 slice represents any of p1, p2, p3 or p4. >Please help on following queries: >1. Is p0 always designated to be entire physical disk? I mean can >entire physical disk > will ever be p1, p2, p3 or p4? >2. Is there an ioctl or api (like readvtoc or DKIOCGVTOC for s2) that > gives us size of p0 entire physical disk and also p1, p2, p3 and >p4? >3. I was going through code in open solaris repository and they seem >to be > reading first 512 bytes from "p0" partition and interpreting it as > "struct mboot" which in turn has information about p1, p2, p3 and >p4 partitions. >4. I am interested in getting sizes of p0, p1, p2, p3 and p4 fdisk >partitions. Look at the source of usr/src/cmd/fdisk/fdisk.c (cvs.opensolaris.org); it will, e.g., show the use of the DKIOCPARTINFO ioctl. Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
From: mannu on 18 Feb 2010 09:51 On Feb 18, 6:10 pm, Casper H.S. Dik <Casper....(a)Sun.COM> wrote: > mannu <manishsingh...(a)gmail.com> writes: > >Hello, > >From what I gathered from solaris experts and google: > >For solaris x86, p0 fdisk partition represents the entire physical > >disk > >and p1, p2, p3 and p4 are the partitions on which different operating > >systems can reside. > >s2 slice represents any of p1, p2, p3 or p4. > >Please help on following queries: > >1. Is p0 always designated to be entire physical disk? I mean can > >entire physical disk > > will ever be p1, p2, p3 or p4? > >2. Is there an ioctl or api (like readvtoc or DKIOCGVTOC for s2) that > > gives us size of p0 entire physical disk and also p1, p2, p3 and > >p4? > >3. I was going through code in open solaris repository and they seem > >to be > > reading first 512 bytes from "p0" partition and interpreting it as > > "struct mboot" which in turn has information about p1, p2, p3 and > >p4 partitions. > >4. I am interested in getting sizes of p0, p1, p2, p3 and p4 fdisk > >partitions. > > Look at the source of usr/src/cmd/fdisk/fdisk.c (cvs.opensolaris.org); > it will, e.g., show the use of the DKIOCPARTINFO ioctl. > > Casper > -- > Expressed in this posting are my opinions. They are in no way related > to opinions held by my employer, Sun Microsystems. > Statements on Sun products included here are not gospel and may > be fiction rather than truth. Hello Casper, Thank you very much for help. From open solaris code of fdisk.c, I came to following understanding. Please correct me if anything is wrongly understood: * DKIOCGMEDIAINFO ioctl is used to get sector size which is "struct dk_minfo.dki_lbsize" * DKIOCPARTINFO ioctl is used to get number of sectors which is "struct part_info.p_length" * fdisk code multiplies (struct dk_minfo.dki_lbsize * struct part_info.p_length) to get size in bytes. * In case DKIOCGMEDIAINFO ioctl fails, fdisk code multiplies (part_info.p_length * NBPSCTR) * NBPSCTR is defined in "/usr/include/sys/param.h" which is generally 512 bytes. Is the understanding correct? Thanks and Regards, Mannu.
From: mannu on 18 Feb 2010 10:06 On Feb 18, 7:51 pm, mannu <manishsingh...(a)gmail.com> wrote: > On Feb 18, 6:10 pm, Casper H.S. Dik <Casper....(a)Sun.COM> wrote: > > > > > mannu <manishsingh...(a)gmail.com> writes: > > >Hello, > > >From what I gathered from solaris experts and google: > > >For solaris x86, p0 fdisk partition represents the entire physical > > >disk > > >and p1, p2, p3 and p4 are the partitions on which different operating > > >systems can reside. > > >s2 slice represents any of p1, p2, p3 or p4. > > >Please help on following queries: > > >1. Is p0 always designated to be entire physical disk? I mean can > > >entire physical disk > > > will ever be p1, p2, p3 or p4? > > >2. Is there an ioctl or api (like readvtoc or DKIOCGVTOC for s2) that > > > gives us size of p0 entire physical disk and also p1, p2, p3 and > > >p4? > > >3. I was going through code in open solaris repository and they seem > > >to be > > > reading first 512 bytes from "p0" partition and interpreting it as > > > "struct mboot" which in turn has information about p1, p2, p3 and > > >p4 partitions. > > >4. I am interested in getting sizes of p0, p1, p2, p3 and p4 fdisk > > >partitions. > > > Look at the source of usr/src/cmd/fdisk/fdisk.c (cvs.opensolaris.org); > > it will, e.g., show the use of the DKIOCPARTINFO ioctl. > > > Casper > > -- > > Expressed in this posting are my opinions. They are in no way related > > to opinions held by my employer, Sun Microsystems. > > Statements on Sun products included here are not gospel and may > > be fiction rather than truth. > > Hello Casper, > Thank you very much for help. > From open solaris code of fdisk.c, I came to following > understanding. Please correct me if anything is wrongly understood: > > * DKIOCGMEDIAINFO ioctl is used to get sector size which is "struct > dk_minfo.dki_lbsize" > * DKIOCPARTINFO ioctl is used to get number of sectors which is > "struct part_info.p_length" > * fdisk code multiplies (struct dk_minfo.dki_lbsize * struct > part_info.p_length) to get size in bytes. > * In case DKIOCGMEDIAINFO ioctl fails, fdisk code multiplies > (part_info.p_length * NBPSCTR) > * NBPSCTR is defined in "/usr/include/sys/param.h" which is generally > 512 bytes. > > Is the understanding correct? > > Thanks and Regards, > Mannu. Also one question I still have. Is p0 always designated to be entire physical disk? I mean can entire physical disk will ever be p1, p2, p3 or p4? Thanks and Regards, Mannu.
From: Casper H.S. Dik on 19 Feb 2010 05:27
mannu <manishsinghhyb(a)gmail.com> writes: >Hello Casper, >Thank you very much for help. >From open solaris code of fdisk.c, I came to following >understanding. Please correct me if anything is wrongly understood: >* DKIOCGMEDIAINFO ioctl is used to get sector size which is "struct >dk_minfo.dki_lbsize" >* DKIOCPARTINFO ioctl is used to get number of sectors which is >"struct part_info.p_length" >* fdisk code multiplies (struct dk_minfo.dki_lbsize * struct >part_info.p_length) to get size in bytes. >* In case DKIOCGMEDIAINFO ioctl fails, fdisk code multiplies >(part_info.p_length * NBPSCTR) >* NBPSCTR is defined in "/usr/include/sys/param.h" which is generally >512 bytes. >Is the understanding correct? It is all documented in dkio(7i) (man dkio) Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth. |