From owner-freebsd-questions@FreeBSD.ORG Wed Dec 3 04:48:16 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C92A216A4CE for ; Wed, 3 Dec 2003 04:48:16 -0800 (PST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id B792343F85 for ; Wed, 3 Dec 2003 04:48:14 -0800 (PST) (envelope-from malcolm.kay@internode.on.net) Received: from beta.home (ppp136-184.lns1.adl2.internode.on.net [150.101.136.184])hB3Cm5Eq075555; Wed, 3 Dec 2003 23:18:06 +1030 (CST) Content-Type: text/plain; charset="iso-8859-1" From: Malcolm Kay Organization: At home To: Ion-Mihai Tetcu Date: Wed, 3 Dec 2003 23:18:04 +1030 User-Agent: KMail/1.4.3 References: <20031202125044.574ca489.itetcu@apropo.ro> <200312030029.14531.malcolm.kay@internode.on.net> <20031202171322.05f2854b.itetcu@apropo.ro> In-Reply-To: <20031202171322.05f2854b.itetcu@apropo.ro> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200312032318.04815.malcolm.kay@internode.on.net> cc: freebsd-questions@freebsd.org Subject: Re: fdisk question (long) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2003 12:48:16 -0000 On Wed, 3 Dec 2003 01:43, Ion-Mihai Tetcu wrote: > On Wed, 3 Dec 2003 00:29:14 +1030 > > Malcolm Kay wrote: > > On Tue, 2 Dec 2003 21:20, Ion-Mihai Tetcu wrote: > > > Hope someone will have the pacince to read all this ... > > > > > > I have a 120G HDD, in the BIOS is set as LBA. I've RTFM as much as = I > > > could, but there still are some things I clearly don't understand. = I > > > want to be sure that I can move this disk to another machine with > > > anouter BIOS and the system still boots up. > > > > > > I've used sysinstall to make partitions and the result is bellow: > > > > > > > > > it# fdisk ad0 > > > ******* Working on device /dev/ad0 ******* > > > parameters extracted from in-core disklabel are: > > > cylinders=3D232578 heads=3D16 sectors/track=3D63 (1008 blks/cyl) > > > > > > Figures below won't work with BIOS for partitions not in cyl 1 > > > parameters to be used for BIOS calculations are: > > > cylinders=3D232578 heads=3D16 sectors/track=3D63 (1008 blks/cyl) > > > > These figures are just figures that will probably work -- and are > > unlikely to have any connection to the physical disk structure. > > OK > > > > Media sector size is 512 > > > Warning: BIOS sector numbering starts with sector 1 > > > Information from DOS bootblock is: > > > The data for partition 1 is: > > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > > > start 63, size 497952 (243 Meg), flag 0 > > > beg: cyl 0/ head 1/ sector 1; > > > end: cyl 30/ head 254/ sector 63 > > > > Having sthe geometry set to 23578/16/63 (that is sixteen heads) > > it is rather strange to address head number 254. Maximum head > > number should then be 15. > > So you are saying that something is wrong here ? While the geometry is being reported as 16 heads it is certainly=20 inconsistent. Whether it will rear its head as a problem I simply don't know. > > > However it is also quite common to define large disk geometries > > as nnnnnn/255/63 which allows a maximum head number of 254. > > > > > The data for partition 2 is: > > > sysid 6 (0x06),(Primary 'big' DOS (>=3D 32MB)) > > > start 498015, size 41929650 (20473 Meg), flag 0 > > > beg: cyl 31/ head 0/ sector 1; > > > end: cyl 1023/ head 254/ sector 63 > > > > The CHS descriptor has overflowed -- nolonger meaningful. > > LBA works with the 498015/41929650 figures. > > OK > > > > The data for partition 3 is: > > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > > > start 42427665, size 192008880 (93754 Meg), flag 0 > > > beg: cyl 1023/ head 255/ sector 63; > > > end: cyl 1023/ head 254/ sector 63 > > > The data for partition 4 is: > > > > > > > > > Q1: How can the partition 3 end up before beginning ? > > > > The CHS entries are limited to 1023/255/63 which does not come > > anywhere near the disk capacity -- so once C reaches 1023 the CHS > > recording capacity has been exceeded. Or to put it another way the CH= S > > entries are somewhat meaningless on large disks. > > I know the CHS limits. > > > But the absolute start sector number and slice > > size is also recorded in the slice/partition table and this is used i= n > > LBA mode. > > So no mather what the BIOS reports, the start sector and the size of a > partition in sectors is the same, right ? > > > > Q2: What is the Warning: BIOS sector numbering starts with sector 1 > > > trying to say ? The cylinders=3D232578 heads=3D16 sectors/track=3D6= 3 shows > > > the same as in teh BIOS screen. > > > > Cylinder and head numbering starts at 0; sectors start at 1. A quirk > > of history that you need to know when using CHS. > > I don't think I understand. Suppose you had 4 heads; these would be identified as head numbers 0, 1, = 2=20 and 3. Now suppose you have 4 sectors(per track); these would be identified as=20 sector numbers 1, 2, 3 and 4. Do you now see the contrast referred to? > > > > Q3: The in-core parameters and those for BIOS calculation are the > > > same; this normal (from my experince) / when they won't mach ? > > > > > > So i decided to make it by hand (note that sysid 0 for the first > > > partition is a typo - it should be 165 and I'll want the / slice on > > > it, and I want to reserve the second partition for a winXP, and the > > > 3rd will be for the other slices). > > > > ... > > > > > Q4: I've supplied the start and size parameters by reading those > > > provided by the sysinstall partitioning. How can I calculate them ? > > > > Work with absolute sector numbers but chosen so that a slice always > > starts at sector 1 in the CHS scheme. > > Lets say I get new HDD. Could you tell me how do i do this ? How do I > find out the number of sectors and translate sectors in capacity (MB) ? > Or point me somewhere ? > > > > Q5: Why the new parameters are different from those of sysinstall ? > > > > Possibly a change of assumed CHS geometry > > I don't understand this. As I didn't changed anything. > I understand that what the system sees as the geometry can be influenced=20 by the parameters set in the MBR; but I would expect that once the MBR co= ntent=20 is fixed that the that the system will always see the same geometry for t= he=20 disk. Please note that this is what I understand -- not what I know to be= so =20 ;) I find it surprising that an MBR generated by sysinstall would exhibit th= is=20 head inconsistency. I've certainly not observed this here. On this machine I have one 60G and two 20G IDE drives all configured by=20 sysinstall. Fdisk reports geometry nnnnn/255/63 on two of the drives(the = 60G and one of the 20G) and nnnnn/16/63 on the other. But in each case the he= ad=20 numbers in the slice/partition table are consistent with the reported=20 geometry. > > > Q6: Is this schema OK and will I be able to use this disk in an > > > other computer and access all the partitions and slices ? > > > > Probably but I would feel happier with sysinstall generated values. > > The reason I've posted this is that I've lost about 50G of date after a= n > MB crash as on the new MB I've got fsck -> CAN NOT FIND SUPERBLOCK for > other slices that / and I don't end-up to repeat that again (and it was > done with sysinstall). > MB? A corrupt or improper BSD disklabel, or trying to access a ufs2 file syst= em=20 (FBSD 5.x) as ufs sounds more likely than fdisk problems. But make sure your slices (under fdisk) don't overlap. > The man page of fdisk says: > > start and size fields provide the start address and size of > =09=09=09=09a slice in sectors. > > flag 80 specifies that this is the active slice. > > cyl, sector and head fields are used to specify the beginning and > =09=09=09=09end addresses of the slice. > > Note: these numbers are calculated using BIOS's understanding of > the disk geometry and saved in the bootblock. > > What if the "BIOS's understanding" chanches (e.g. new mobo) ? > > Many thanks, Malcolm Kay