Date: Wed, 13 Mar 2013 14:45:23 -0700 From: Cody Ritts <cr@caltel.com> To: freebsd-fs@freebsd.org Subject: Re: Aligning MBR for ZFS boot help Message-ID: <5140F373.1010907@caltel.com> In-Reply-To: <20130313232247.B1078@besplex.bde.org> References: <513C1629.50501@caltel.com> <alpine.BSF.2.00.1303101006490.5989@wonkity.com> <513CD9AB.5080903@caltel.com> <alpine.BSF.2.00.1303101326530.7218@wonkity.com> <513CE369.4030303@caltel.com> <alpine.BSF.2.00.1303101349540.7637@wonkity.com> <1362951595.99445.2.camel@btw.pki2.com> <alpine.BSF.2.00.1303101807550.8481@wonkity.com> <CABXB=RTt-j0SGxktWMfLcgLAEN6Vi%2Bf=psBuN0jQaJthk_3cbw@mail.gmail.com> <513E1208.5020804@caltel.com> <20130312203745.A1130@besplex.bde.org> <513F8F04.60206@caltel.com> <20130313232247.B1078@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Holy crap, there is so much baggage with CHS, I had no idea we were still dragging it along to this extent. I really appreciate you emphasizing its importance, I was ready to just blow off the incorrect geometry and be happy with my hacked sector start. So here is my drive... > root@:/root # diskinfo -v ada0 > ada0 > 512 # sectorsize > 64023257088 # mediasize in bytes (59G) > 125045424 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 124053 # Cylinders according to firmware. > 16 # Heads according to firmware. > 63 # Sectors according to firmware. So, if I now want to create an aligned single partition, here are the steps I think I should be taking: Sectors should be < 64 Heads should be < 256 for OLD OLD stuff, cylinders should be < 1024 if you want boundaries on a power of 2, those the number of sectors and heads should also be a power of 2. So, would all of these be potential valid values? s32 h128 512*32*128 = 2097152B = 2MB cylinder s32 h64 512*32*64 = 1048576B = 1MB cylinder s16 h128 512*16*128 = 1048576B = 1MB cylinder s4 h8 512*4*4 = 8192B = 8K cylinder I am assuming that once I know my cylinder size, I just divide the total size of my hard drive to come up with cylinder count? s4 h8 64023257088 / 8192 = 7815339c (8k is the largest power of 2 that the drive will evenly divide into) s32 h64 64023257088 / 1048576 = 61057.3359375 Round down to 61057. (does the cylinder need to end on the end of the disk?) So, here is what i calculated: c61057 h64 s32 I want an offset of 2M, file system should be reduced to 61055M (61055 * 1024 * 1024)/512 = 125040640s) Here are the commands that I ran: > cat << EOF > command > g c61057 h64 s32 > p 1 0xa5 4096 125040640 > a 1 > EOF > root@:/root # fdisk -f command ada0 > ******* Working on device /dev/ada0 ******* > fdisk: WARNING line 1: number of cylinders (61057) may be out-of-range > (must be within 1-1024 for normal BIOS operation, unless the entire disk > is dedicated to FreeBSD) > root@:/root # fdisk -p ada0 > # /dev/ada0 > g c124053 h16 s63 > p 1 0xa5 4096 125040640 > a 1 note, it auto goes back when exporting > root@:/root # gpart show ada0 > => 63 125045361 ada0 MBR (59G) > 63 4033 - free - (2M) > 4096 125040640 1 freebsd [active] (59G) > 125044736 688 - free - (344k) > root@:/root # gpart delete -i 1 ada0 > root@:/root # gpart add -t freebsd -b 4096 -s 125040640 ada0 > ada0s1 added > root@:/root # gpart show ada0 > => 63 125045361 ada0 MBR (59G) > 63 4095 - free - (2M) > 4158 125040573 1 freebsd (59G) > 125044731 693 - free - (346k) gpart does not care > root@:/root # fdisk -f command ada0 > ******* Working on device /dev/ada0 ******* > fdisk: WARNING line 1: number of cylinders (61057) may be out-of-range > (must be within 1-1024 for normal BIOS operation, unless the entire disk > is dedicated to FreeBSD) > root@:/root # fdisk ada0 > ******* Working on device /dev/ada0 ******* > parameters extracted from in-core disklabel are: > cylinders=124053 heads=16 sectors/track=63 (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=124053 heads=16 sectors/track=63 (1008 blks/cyl) > > 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 4096, size 125040640 (61055 Meg), flag 80 (active) > beg: cyl 2/ head 0/ sector 1; > end: cyl 640/ head 63/ sector 32 > The data for partition 2 is: > <UNUSED> > The data for partition 3 is: > <UNUSED> > The data for partition 4 is: > <UNUSED> So, setting the geom simply does this: >> sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) >> start 4096, size 125040640 (61055 Meg), flag 80 (active) >> beg: cyl 2/ head 0/ sector 1; >> end: cyl 640/ head 63/ sector 32 I cannot set geom in my bios, nor does not show me what it thinks geom is. Obviously anything that only supports 1024 cylinders will not think it is very funny. I feel like I am missing some part of this puzzle, or is that all there is to this to correct geom for proper alignment on an MBR? So, by setting those CHS values I am: making the partition table more compatible with other operating systems and BIOSes? and giving some utilities the CHS stuff they need to function right? Thanks, Cody On 3/13/13 6:33 AM, Bruce Evans wrote: > On Tue, 12 Mar 2013, Cody Ritts wrote: > >> On 3/12/13 3:25 AM, Bruce Evans wrote: >>>> Update -- >>>> >>>> fdisk WILL allow you to align without regards to drive geometry >>>> >>>> It can only be done in interactive mode: >>>> http://lists.freebsd.org/pipermail/freebsd-geom/2011-May/004780.html >>> >>> It can be set in all modes. At least according to the man page: >> >> In interactive mode, you can simply set the start and size of your >> partition be done with it and boot away. > > That will usually give nonsense beginning and ending CHS values. This will > usually prevent BIOSes and non-broken versions of FreeBSD from detecting > the geometry. It would also prevent booting on BIOSes that uses the CHS > values; this is not usually a problem now. So this misconfiguration will > mainly mess up printing of the partition table in utilities that print > the CHS utilities, and cause warnings in utilities that want the CHS values > to be correct, and propagate the misconfiguratation. > >> If you then export that config file, and re-run it, you are back to >> being aligned to CHS. > > Only if the config file is broken. > >> I would imagine that adjusting your CHS ~correctly~ in the config file >> will allow you to to do it, but I have not found myself motivated to >> really learn about adjusting those values. I will have to pick that >> up someday I suppose. > > Yes this is necessary and very easy. Just type in the same geometry that > you need to type in at the start of interactive fdisk to avoid the above > problems. > >> For informational purposes here is >> 1) partition w/ offset >> 2) show results >> 3) export/import config >> 4) show results with adjusted offset >> >>> root@:/root # fdisk -i ada0 >>> Do you want to change our idea of what BIOS thinks ? [n] > > You do want the change this. Use something like 32 sectors 64 heads > (1MB cylinders). > >>> Do you want to change it? [n] y >>> Supply a decimal value for "sysid (165=FreeBSD)" [165] >>> Supply a decimal value for "start" [63] 4096 >>> Supply a decimal value for "size" [125045361] 125041328 >>> Correct this automatically? [n] > > After changing "what BIOS thinks" to something like the above, fdisk > shouldn't see anything to correct. The start of 4096 is a multiple > of 32*64 = 2048. > > I just noticed that despite being too chatty, "what BIOS thinks" > has bad grammar. > >>> Explicitly specify beg/end address ? [n] >>> Are we happy with this entry? [n] y >>> Do you want to change it? [n] >>> Do you want to change it? [n] >>> Do you want to change it? [n] >>> Do you want to change the active partition? [n] >>> Should we write new partition table? [n] y >>> >>> root@:/root # gpart show ada0 >>> => 63 125045361 ada0 MBR (59G) >>> 63 4033 - free - (2M) >>> 4096 125041328 1 freebsd [active] (59G) > > Looks like it got a bogus 63 from the same place as fdisk (from the > "firmware" goemetry. > > The free area isn't really 4033 block sectors at 63, but 4095 blocks > starting at 1 (for non-broken BIOSes and OSes). I used to start > partitions at offset 1, but now use 63 for portability. However, 63 > isn't portable either. The BIOS or another OS might have a different > idea of the geometry. > >>> root@:/root # fdisk -p ada0 >>> # /dev/ada0 >>> g c124053 h16 s63 >>> p 1 0xa5 4096 125041328 >>> a 1 > > This shows fdisk -p using the same garbage default geometry as interactive > fdisk. So fdisk -p output is not directly usable. > > There is no place in the partition table to store the geometry directly. > It can sometimes be determined indirectly, but neither the kernel nor > fdisk does so. Old kernels did so, and fdisk depended on this. > However, fdisk shouldn't depend on this, so that fdisk can work on > images of partition tables. Linux fdisk (fdisk-linux in ports) does > this correctly. Not using OS-specific ioctls for this also improves > portability. The kernel support for this was mainly to ensure that > all FreeBSD utilities got a consistent view of the geometry, back when > consistent views mattered. It's still confusing when the views are > different. > >>> root@:/root # fdisk -p ada0 > command >>> >>> root@:/root # fdisk -f command ada0 >>> ******* Working on device /dev/ada0 ******* >>> fdisk: WARNING line 2: number of cylinders (124053) may be out-of-range >>> (must be within 1-1024 for normal BIOS operation, unless the >>> entire disk >>> is dedicated to FreeBSD) >>> fdisk: WARNING: adjusting start offset of partition 1 >>> from 4096 to 4158, to fall on a head boundary >>> fdisk: WARNING: adjusting size of partition 1 from 125041328 to >>> 125041266 >>> to end on a cylinder boundary > > This is broken. The non-interactive version should not adjust anything. > Even the interactive version defaults to not adjusting. > >>> root@:/root # fdisk -p ada0 >>> # /dev/ada0 >>> g c124053 h16 s63 >>> p 1 0xa5 4158 125041266 >>> a 1 >>> >>> root@:/root # gpart show ada0 >>> => 63 125045361 ada0 MBR (59G) >>> 63 4095 - free - (2M) >>> 4158 125041266 1 freebsd [active] (59G) > > So the bugs of fdisk -p producing wrong geometry, not editing its output > to fix this, and the broken adjustment done by fdisk -f, result in the > partiton offsets being corrupted by fdisk -f. > > Bruce >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5140F373.1010907>