Date: Sat, 6 Dec 2008 15:27:22 -0800 From: "Peter Wemm" <peter@wemm.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org, xcllnt@mac.com Subject: Re: RFC: making gpart default Message-ID: <e7db6d980812061527h7181f75bw4c85fc2c28553249@mail.gmail.com> In-Reply-To: <20081203.193714.693830802.imp@bsdimp.com> References: <e7db6d980811291356w54256e6du82350baf3c57d591@mail.gmail.com> <68B9D78C-C0CF-4D64-AF53-C3736EEC8D23@mac.com> <e7db6d980812011605h18b40700v1043e376ef392365@mail.gmail.com> <20081203.193714.693830802.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 3, 2008 at 6:37 PM, M. Warner Losh <imp@bsdimp.com> wrote:
> In message: <e7db6d980812011605h18b40700v1043e376ef392365@mail.gmail.com>
> "Peter Wemm" <peter@wemm.org> writes:
> : On Sat, Nov 29, 2008 at 7:30 PM, Marcel Moolenaar <xcllnt@mac.com> wrote:
> : >
> : > On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote:
> : [..]
> : >> * There should be some guidance or hints on laying out disks. For
> : >> example, a gpart create -s gpt on a raid volume ends up with a start
> : >> sector of 34 for the free space. There should be a documentation hint
> : >> to round up start sectors to a power of 2 and/or block size on a raid.
> : >> eg: if you have a raid with 64K stripes, then move the start sector
> : >> from 34 to 128. Otherwise we end up with file systems issuing
> : >> transactions that can split across multiple raid stripes. FWIW, I
> : >> conveniently filled this hole with boot code.
> : >
> : > Hmmm... gpart(8) typically can't store this kind
> : > of information on-disk, but other than that it
> : > supports alignment/padding already. We just need
> : > a way to tell gpart about it. Maybe this should
> : > come from the provider (i.e. underlying geom)...
> :
> : I was more thinking of a man page note to warn of the issue.
> :
> : Also, in the gpt case, it might make sense in gpt partition table case
> : to round up the initial size to a power of 2. Right now we lose 34
> : sectors from the beginning. Rounding it to 64 total at least gets us
> : to an even power of 2. UFS's frequent block size of 16K shouldn't
> : cross any underlying stripe boundaries in the usual case.
>
> This likely is a hang over from the MBR code that puts the first
> partition at one cylendar offset from the beginning to conform with
> the MBR conventions of (some?) Bioses that use that to get the
> parameters for the disk...
I don't recall what happens for "small" partitions, but I know from
experience that bioses care far more about the end sector geometry
than the start.
eg: typically we used to set start:
lba = 63, cyl 0, head 1, sector 1.
All that implies is that there are 63 sectors per track. It gives no
hints to the bios about number of heads.
When we set end:
lba = 1234567, cyl 1023, head 254, sector 63
then that implies number of heads and number of sectors. Cyl = 1023
means "rest of disk".
No bioses that I've come across in the last 8 years gave a damn about
the start info, just the end info. It was effectively required that
you "end" on a cylinder boundary. We have not been "start"ing on a
cylinder boundary - just a track/head boundary. Linux (and windows, I
think) do start on full cylinder boundaries for partitions >= 8GB.
head boundary start: cyl 0, head 1, sec 1
cylinder boundary start: cyl 1, head 0, sec 1.
Anyway.. the important thing is that we do actually have a choice.
Typically we'd have:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 160086465 (78167 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 254/ sector 63
But this is faster:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 512, size 285458473 (139384 Meg), flag 80 (active)
beg: cyl 0/ head 8/ sector 9;
end: cyl 1023/ head 254/ sector 63
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e7db6d980812061527h7181f75bw4c85fc2c28553249>