* fdisk geometry
@ 2012-07-26 1:34 John Lane
2012-07-26 9:29 ` Davidlohr Bueso
0 siblings, 1 reply; 6+ messages in thread
From: John Lane @ 2012-07-26 1:34 UTC (permalink / raw)
To: util-linux
Hello, I'm in the middle of studying disk organisation to enhance my
understanding in this area. I have a few questions about fdisk (trying
to fill a gap in my knowledge if that's ok)...
In the below output of fdisk it shows (correctly) a geometry of 224
heads, 56 sectors/track. I'm unclear about where this information comes
from. Normally a disk's geometry would be reported as 255 heads and 63
sectors. I explicitly partitioned this disk using a 224/56 geometry, so
the report is correct. I'd just like to understand:
(a) where fdisk gets the information about the geometry from in this
specific case?
(b) when fdisk defaults to 255/63 is that because it's hard coded that
way or is there another reason?
I understand why it's 255/63 by default but haven't been able to
understand how the geometry is determined. I do know that it's all kind
of moot these days anyway because of sector based addressing but that
leads to one other question: given sector based addressing why does
fdisk even bother displaying a geometry any more ? Doesn't it just serve
to confuse?
# fdisk /dev/sda
Welcome to fdisk (util-linux 2.21.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sda: 80.0 GB, 80026361856 bytes
224 heads, 56 sectors/track, 12460 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc4c4122e
Device Boot Start End Blocks Id System
/dev/sda1 * 56 501759 250852 83 Linux
/dev/sda2 501760 156298239 77898240 8e Linux LVM
Command (m for help): q
Many thanks for your time,
John Lane.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: fdisk geometry
2012-07-26 1:34 fdisk geometry John Lane
@ 2012-07-26 9:29 ` Davidlohr Bueso
2012-07-26 9:57 ` Karel Zak
2012-07-28 0:20 ` John Lane
0 siblings, 2 replies; 6+ messages in thread
From: Davidlohr Bueso @ 2012-07-26 9:29 UTC (permalink / raw)
To: John Lane; +Cc: util-linux
On Thu, 2012-07-26 at 02:34 +0100, John Lane wrote:
> Hello, I'm in the middle of studying disk organisation to enhance my
> understanding in this area. I have a few questions about fdisk (trying
> to fill a gap in my knowledge if that's ok)...
use the source, Luke :)
>
> In the below output of fdisk it shows (correctly) a geometry of 224
> heads, 56 sectors/track. I'm unclear about where this information comes
> from. Normally a disk's geometry would be reported as 255 heads and 63
> sectors. I explicitly partitioned this disk using a 224/56 geometry, so
> the report is correct. I'd just like to understand:
>
> (a) where fdisk gets the information about the geometry from in this
> specific case?
fdisk gets the information from (i) user input, (ii) what the
kernel/bios thinks the geometry is, with the HDIO_GETGEO ioctl and (iii)
by inferring it from the partition table geometry.
> (b) when fdisk defaults to 255/63 is that because it's hard coded that
> way or is there another reason?
Correct.
>
> I understand why it's 255/63 by default but haven't been able to
> understand how the geometry is determined. I do know that it's all kind
> of moot these days anyway because of sector based addressing but that
> leads to one other question: given sector based addressing why does
> fdisk even bother displaying a geometry any more ? Doesn't it just serve
> to confuse?
That's because fdisk is/was mostly legacy code, we are currently
updating the program.
Cheers,
Davidlohr
>
> # fdisk /dev/sda
> Welcome to fdisk (util-linux 2.21.2).
>
> Changes will remain in memory only, until you decide to write them.
> Be careful before using the write command.
>
>
> Command (m for help): p
>
> Disk /dev/sda: 80.0 GB, 80026361856 bytes
> 224 heads, 56 sectors/track, 12460 cylinders, total 156301488 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0xc4c4122e
>
> Device Boot Start End Blocks Id System
> /dev/sda1 * 56 501759 250852 83 Linux
> /dev/sda2 501760 156298239 77898240 8e Linux LVM
>
> Command (m for help): q
>
> Many thanks for your time,
> John Lane.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: fdisk geometry
2012-07-26 9:29 ` Davidlohr Bueso
@ 2012-07-26 9:57 ` Karel Zak
2012-07-26 10:29 ` Davidlohr Bueso
2012-07-28 0:20 ` John Lane
1 sibling, 1 reply; 6+ messages in thread
From: Karel Zak @ 2012-07-26 9:57 UTC (permalink / raw)
To: Davidlohr Bueso; +Cc: John Lane, util-linux
On Thu, Jul 26, 2012 at 11:29:40AM +0200, Davidlohr Bueso wrote:
> > (a) where fdisk gets the information about the geometry from in this
> > specific case?
>
> fdisk gets the information from (i) user input, (ii) what the
> kernel/bios thinks the geometry is, with the HDIO_GETGEO ioctl and (iii)
> by inferring it from the partition table geometry.
BTW, does it make any sense to read the geometry from partition table
if the partition table has been aligned according to the device topology
(for example 1MiB offset and grain)?
> > fdisk even bother displaying a geometry any more ? Doesn't it just serve
> > to confuse?
IMHO for non-DOS compatible mode it would be better to ignore PT
geometry (read only info from kernel to have "some" values) and
don't display geometry in the default output, because it's completely
irrelevant.
The same we can do with -S -C -H options -- it would be better to
print a warning if the options are specified for non-DOS mode.
I still see on many places suggestions like "use -S -H to align your
flash disk" or so... all this is legacy.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: fdisk geometry
2012-07-26 9:57 ` Karel Zak
@ 2012-07-26 10:29 ` Davidlohr Bueso
2012-07-26 10:38 ` Karel Zak
0 siblings, 1 reply; 6+ messages in thread
From: Davidlohr Bueso @ 2012-07-26 10:29 UTC (permalink / raw)
To: Karel Zak; +Cc: John Lane, util-linux
On Thu, 2012-07-26 at 11:57 +0200, Karel Zak wrote:
> On Thu, Jul 26, 2012 at 11:29:40AM +0200, Davidlohr Bueso wrote:
> > > (a) where fdisk gets the information about the geometry from in this
> > > specific case?
> >
> > fdisk gets the information from (i) user input, (ii) what the
> > kernel/bios thinks the geometry is, with the HDIO_GETGEO ioctl and (iii)
> > by inferring it from the partition table geometry.
>
> BTW, does it make any sense to read the geometry from partition table
> if the partition table has been aligned according to the device topology
> (for example 1MiB offset and grain)?
Hmm not really, no. In any case we got rid of the pt geometry,
__discover_system_geometry() only gets the info from the kernel.
> > > fdisk even bother displaying a geometry any more ? Doesn't it just serve
> > > to confuse?
>
> IMHO for non-DOS compatible mode it would be better to ignore PT
> geometry (read only info from kernel to have "some" values) and
> don't display geometry in the default output, because it's completely
> irrelevant.
>
> The same we can do with -S -C -H options -- it would be better to
> print a warning if the options are specified for non-DOS mode.
>
I agree.
> I still see on many places suggestions like "use -S -H to align your
> flash disk" or so... all this is legacy.
>
> Karel
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: fdisk geometry
2012-07-26 10:29 ` Davidlohr Bueso
@ 2012-07-26 10:38 ` Karel Zak
0 siblings, 0 replies; 6+ messages in thread
From: Karel Zak @ 2012-07-26 10:38 UTC (permalink / raw)
To: Davidlohr Bueso; +Cc: John Lane, util-linux
On Thu, Jul 26, 2012 at 12:29:41PM +0200, Davidlohr Bueso wrote:
> On Thu, 2012-07-26 at 11:57 +0200, Karel Zak wrote:
> > On Thu, Jul 26, 2012 at 11:29:40AM +0200, Davidlohr Bueso wrote:
> > > > (a) where fdisk gets the information about the geometry from in this
> > > > specific case?
> > >
> > > fdisk gets the information from (i) user input, (ii) what the
> > > kernel/bios thinks the geometry is, with the HDIO_GETGEO ioctl and (iii)
> > > by inferring it from the partition table geometry.
> >
> > BTW, does it make any sense to read the geometry from partition table
> > if the partition table has been aligned according to the device topology
> > (for example 1MiB offset and grain)?
>
> Hmm not really, no. In any case we got rid of the pt geometry,
> __discover_system_geometry() only gets the info from the kernel.
I have moved get_partition_table_geometry() to dos_probe_label() :-)
It seems we need if (dos_compatible) there.
It means that for MBR we still read the PT geometry ;-)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: fdisk geometry
2012-07-26 9:29 ` Davidlohr Bueso
2012-07-26 9:57 ` Karel Zak
@ 2012-07-28 0:20 ` John Lane
1 sibling, 0 replies; 6+ messages in thread
From: John Lane @ 2012-07-28 0:20 UTC (permalink / raw)
To: dave; +Cc: util-linux
On 26/07/12 10:29, Davidlohr Bueso wrote:
> On Thu, 2012-07-26 at 02:34 +0100, John Lane wrote:
>> Hello, I'm in the middle of studying disk organisation to enhance my
>> understanding in this area. I have a few questions about fdisk (trying
>> to fill a gap in my knowledge if that's ok)...
> use the source, Luke :)
:)
>> In the below output of fdisk it shows (correctly) a geometry of 224
>> heads, 56 sectors/track. I'm unclear about where this information comes
>> from. Normally a disk's geometry would be reported as 255 heads and 63
>> sectors. I explicitly partitioned this disk using a 224/56 geometry, so
>> the report is correct. I'd just like to understand:
>>
>> (a) where fdisk gets the information about the geometry from in this
>> specific case?
> fdisk gets the information from (i) user input, (ii) what the
> kernel/bios thinks the geometry is, with the HDIO_GETGEO ioctl and (iii)
> by inferring it from the partition table geometry.
Thanks, yes I was able to deduce this from the source but I wasn't
confident I had it right.
Reading this confirms nicely what I thought was going on.
>> (b) when fdisk defaults to 255/63 is that because it's hard coded that
>> way or is there another reason?
> Correct.
>
>> I understand why it's 255/63 by default but haven't been able to
>> understand how the geometry is determined. I do know that it's all kind
>> of moot these days anyway because of sector based addressing but that
>> leads to one other question: given sector based addressing why does
>> fdisk even bother displaying a geometry any more ? Doesn't it just serve
>> to confuse?
> That's because fdisk is/was mostly legacy code, we are currently
> updating the program.
I've just seen the upcoming changes, removing the messages when
not in dos mode.
> Cheers,
> Davidlohr
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-07-27 23:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-26 1:34 fdisk geometry John Lane
2012-07-26 9:29 ` Davidlohr Bueso
2012-07-26 9:57 ` Karel Zak
2012-07-26 10:29 ` Davidlohr Bueso
2012-07-26 10:38 ` Karel Zak
2012-07-28 0:20 ` John Lane
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).