Hard Drive Geometry 101
Al
I am hoping some kind people on this NG could help me better
understand HDD Geometry. Dont get me wrong I have done some googling,
and read some wiki's - but some parts are still very blurry. I have
also used the man command since most of what I am doing is in linux.
Most of my questions have been brought about by various LInux tools I
have been experimenting with, such as testdisk, mount, and fdisk.
I will outline what I understand so far, if any of these statements
are wrong please let me know.
I understand so far:
That hard disks have physical geometry CHS, but modern hard disk CHS
bears no direct relationship to the physical geometry of the disk. I
think the modern CHS is sometimes called Psuedo CHS.
C and H numbering starts at 0, but S starts at 1.
The the definition of a sector (on the physical disk anyway) is a
strip extending from the center of the platter to the edge. And a
block is the intersection of a cylinder and a sector. Sometimes use
the terms block and sector to mean the same thing (block).
Block usually 512 bytes.
With read hard disk geometry C*H*S = number of blocks
Thus number of blocks * 512 = disk size?
Is there a relationship mathmatically, size wise, between a block and
a sector? ie 4 blocks = 1 sector or whatever?
Now to involve some real world data:
al@al-ubuntu:~$ sudo fdisk -l
[sudo] password for al:
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xaf010487
Device Boot Start End Blocks Id System
/dev/sda1 * 1 121601 976760001 83 Linux
I know that start and end are cylinder values and I assume that blocks
is the size of the partition in blocks. Assuming I was correct before
when I stated that blocks are 512 bytes in size, then:
976760001 * 512 bytes = disk size in bytes - but it doesnt, it equals
500101120512 bytes which is way off 1000204886016 bytes from the
header in fdisk. Why?
From fdisk headerline "255 heads, 63 sectors/track, 121601 cylinders"
- now using C*H*S = number of blocks
121601 * 255 * 63 = 1953520065 blocks
and because 512 bytes to a block:
512 * 1953520065 = 1000202273280 bytes (which should be the same as
the disk size given in the fdisk header line "1000204886016 bytes" but
it isnt. Why?)
The same disk:
TestDisk 6.10, Data Recovery Utility, July 2008
Christophe GRENIER <gre...@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
Partition Start End Size in sectors
1 * Linux 0 1 1 121600 254 63 1953520002
Now start and end are full CHS values and we can also see the size of
the partition in sectors. I have been told that:
(255 * 63 * 121601) - (63 * 1) = 1953520002
Which is the size in sectors. But I dont quite understand the
calculations.
In its simplest form the End CHS size - Start CHS size = size of
partition (True/False?)
Because of numbering starting at 0 start end CHS values in calculation
are:
121601,255,63 (True/False?)
Start CHS values, by the same reasoning should be:
0,2,2 (Clearly this is not whats used in the calculation - why?)
Well this has been a long post, and I suspect the answer will raise
more questions.
Thanks in advance for any replies.
-Al
Grant
>Hi Folks,
>
>I am hoping some kind people on this NG could help me better
>understand HDD Geometry. Dont get me wrong I have done some googling,
>and read some wiki's - but some parts are still very blurry. I have
>also used the man command since most of what I am doing is in linux.
>
>Most of my questions have been brought about by various LInux tools I
>have been experimenting with, such as testdisk, mount, and fdisk.
>
>I will outline what I understand so far, if any of these statements
>are wrong please let me know.
>
>I understand so far:
>That hard disks have physical geometry CHS, but modern hard disk CHS
>bears no direct relationship to the physical geometry of the disk. I
>think the modern CHS is sometimes called Psuedo CHS.
Er, LBA -- Logical Block Addressing?
>
>C and H numbering starts at 0, but S starts at 1.
>
>The the definition of a sector (on the physical disk anyway) is a
>strip extending from the center of the platter to the edge. And a
>block is the intersection of a cylinder and a sector. Sometimes use
>the terms block and sector to mean the same thing (block).
>
>Block usually 512 bytes.
1024 bytes for modern linux fdisk.
>
>With read hard disk geometry C*H*S = number of blocks
>Thus number of blocks * 512 = disk size?
>
>Is there a relationship mathmatically, size wise, between a block and
>a sector? ie 4 blocks = 1 sector or whatever?
There's different block sizes, depending on usage. Filesystem may
allocate space in 1k or 4k (or larger?) blocks depending on partition
size.
>
>Now to involve some real world data:
>
>al@al-ubuntu:~$ sudo fdisk -l
>[sudo] password for al:
>
>Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
>255 heads, 63 sectors/track, 121601 cylinders
>Units = cylinders of 16065 * 512 = 8225280 bytes
>Disk identifier: 0xaf010487
>
> Device Boot Start End Blocks Id System
>/dev/sda1 * 1 121601 976760001 83 Linux
>
>I know that start and end are cylinder values and I assume that blocks
>is the size of the partition in blocks. Assuming I was correct before
>when I stated that blocks are 512 bytes in size, then:
>
>976760001 * 512 bytes = disk size in bytes - but it doesnt, it equals
>500101120512 bytes which is way off 1000204886016 bytes from the
>header in fdisk. Why?
Forget CHS -- the important number for large disks is the 8225280
bytes per cylinder.
Look at fdisk's 'x' mode display? It shows the uninterpreted sizes:
Command (m for help): p
Disk /dev/sda: 80.0 GB, 80025280000 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x45e0afb2
Device Boot Start End Blocks Id System
/dev/sda1 1 1024 8225248+ 83 Linux
/dev/sda2 1025 2048 8225280 83 Linux
/dev/sda3 * 2049 3072 8225280 83 Linux
/dev/sda4 3073 9728 53464320 5 Extended
/dev/sda5 3073 3200 1028128+ 82 Linux swap
/dev/sda6 3201 3968 6168928+ 83 Linux
/dev/sda7 3969 4736 6168928+ 83 Linux
/dev/sda8 4737 9728 40098208+ 83 Linux
Command (m for help): x
Expert command (m for help): p
Disk /dev/sda: 255 heads, 63 sectors, 9729 cylinders
Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 00 1 1 0 254 63 1023 63 16450497 83
2 00 254 63 1023 254 63 1023 16450560 16450560 83
3 80 254 63 1023 254 63 1023 32901120 16450560 83
4 00 254 63 1023 254 63 1023 49351680 106928640 05
5 00 254 63 1023 254 63 1023 63 2056257 82
6 00 254 63 1023 254 63 1023 63 12337857 83
7 00 254 63 1023 254 63 1023 63 12337857 83
8 00 254 63 1023 254 63 1023 63 80196417 83
Grant.
--
http://bugsplatter.id.au
Al
> Forget CHS -- the important number for large disks is the 8225280
> bytes per cylinder.
Can you use the 8225280 bytes per cylinder with total number of
cylinders to calculate disk size?
>
> Look at fdisk's 'x' mode display? It shows the uninterpreted sizes:
>
> Command (m for help): p
>
> Disk /dev/sda: 80.0 GB, 80025280000 bytes
> 255 heads, 63 sectors/track, 9729 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0x45e0afb2
ie: Why does the 8225280 * 9729 <not equal> 8002528000 bytes???
After all its the cylinder size * number of cylinders???
-Al
Al
>
> There's different block sizes, depending on usage. Filesystem may
> allocate space in 1k or 4k (or larger?) blocks depending on partition
> size.
>
So are you saying block size is a function of File System?
-Al
cal...@fly.srk.fer.hr.invalid
> >The the definition of a sector (on the physical disk anyway) is a
> >strip extending from the center of the platter to the edge. And a
> >block is the intersection of a cylinder and a sector. Sometimes use
> >the terms block and sector to mean the same thing (block).
> >
> >Block usually 512 bytes.
> 1024 bytes for modern linux fdisk.
Normal block is 512 bytes per sector... Some advanced storage systems have
520 bytes per sector (512 for data and 8 for ECC)...
With some utilities, such as SCSITool, it's possible to format SCSI/SAS/FC
drives with different block sizes...
During filesystem format, you can choose different settings (from 512 bps to
8 MBps for VMware's VMFS)...
--
U sahti ustasao tuce Madjarski sisau pasiru jucer. By runf
Damir Lukic, calypso@_MAKNIOVO_fly.srk.fer.hr
http://inovator.blog.hr
http://calypso-innovations.blogspot.com/
Rod Speed
Yep.
Rod Speed
> Hi Folks,
Lo Folky,
> I am hoping some kind people on this NG could help me better understand HDD Geometry.
What about the unkind ones ?
> Dont get me wrong I have done some googling, and read some
> wiki's - but some parts are still very blurry. I have also used the
> man command since most of what I am doing is in linux.
> Most of my questions have been brought about by various LInux tools
> I have been experimenting with, such as testdisk, mount, and fdisk.
> I will outline what I understand so far, if any of these statements
> are wrong please let me know.
> I understand so far:
> That hard disks have physical geometry CHS,
Not in the sense that all cylinders have the same number of sectors per track.
Today, the sectors per track varys in bands across the platter.
> but modern hard disk CHS bears no direct
> relationship to the physical geometry of the disk.
Correct. And CHS values arent necessarily used for
access either, its more usual to use logical blocks today.
The drive itself converts that to a particular CHS value.
> I think the modern CHS is sometimes called Psuedo CHS.
Or logical CHS.
> C and H numbering starts at 0, but S starts at 1.
> The the definition of a sector (on the physical disk anyway)
> is a strip extending from the center of the platter to the edge.
Nope, that is completely wrong. A sector is part of
a track and tracks are concentric circles on the platter.
A cylinder is a collection of tracks at the same distance from
the center of the platter, one track per platter side/per head.
> And a block is the intersection of a cylinder and a sector.
Nope, a block is just a sector at the physical drive level.
> Sometimes use the terms block and sector to mean the same thing (block).
Same thing (sector) actually.
> Block usually 512 bytes.
Not with Linux file systems.
> With read hard disk geometry C*H*S = number of blocks
> Thus number of blocks * 512 = disk size?
Yes.
> Is there a relationship mathmatically, size wise, between
> a block and a sector? ie 4 blocks = 1 sector or whatever?
A block is just one sector at the physical drive level.
> Now to involve some real world data:
> al@al-ubuntu:~$ sudo fdisk -l
> [sudo] password for al:
> Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
> 255 heads, 63 sectors/track, 121601 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0xaf010487
> Device Boot Start End Blocks Id System
> /dev/sda1 * 1 121601 976760001 83 Linux
> I know that start and end are cylinder values and I assume that blocks
> is the size of the partition in blocks. Assuming I was correct before
> when I stated that blocks are 512 bytes in size, then:
> 976760001 * 512 bytes = disk size in bytes - but it doesnt, it equals
> 500101120512 bytes which is way off 1000204886016 bytes from the
> header in fdisk. Why?
You should have mulitiplied by 1024 instead of 512.
> From fdisk headerline "255 heads, 63 sectors/track, 121601 cylinders"
> - now using C*H*S = number of blocks
>
> 121601 * 255 * 63 = 1953520065 blocks
Nope, sectors.
> and because 512 bytes to a block:
> 512 * 1953520065 = 1000202273280 bytes (which should be the same as
> the disk size given in the fdisk header line "1000204886016 bytes" but
> it isnt. Why?)
Because the linux block is 1024
> The same disk:
> TestDisk 6.10, Data Recovery Utility, July 2008
> Christophe GRENIER <gre...@cgsecurity.org>
> http://www.cgsecurity.org
> Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
> Current partition structure:
> Partition Start End Size in sectors
> 1 * Linux 0 1 1 121600 254 63 1953520002
> Now start and end are full CHS values and we can also see the size of
> the partition in sectors. I have been told that:
> (255 * 63 * 121601) - (63 * 1) = 1953520002
> Which is the size in sectors. But I dont quite understand the calculations.
Its 255 instead of 254 because the cylinder numbering starts at 0
> In its simplest form the End CHS size - Start CHS size = size of partition (True/False?)
Falso.
> Because of numbering starting at 0 start end CHS values in calculation
> are:
> 121601,255,63 (True/False?)
True with the 255, but its more complicated than that.
> Start CHS values, by the same reasoning should be:
> 0,2,2
Nope, those dont start at 0, they start at 1.
> (Clearly this is not whats used in the calculation - why?)
> Well this has been a long post, and I suspect the answer will raise more questions.
> Thanks in advance for any replies.
Even ones that tell you to shove your head up a dead bear's arse ?
Al
> Al wrote:
> > Hi Folks,
> > C and H numbering starts at 0, but S starts at 1.
> > The the definition of a sector (on the physical disk anyway)
> > is a strip extending from the center of the platter to the edge.
>
> Nope, that is completely wrong. A sector is part of
> a track and tracks are concentric circles on the platter.
Not in this picture it isnt sunshine : http://en.wikipedia.org/wiki/Cylinder-head-sector
its a pie shaped slice from the center.
>
> > Block usually 512 bytes.
>
> Not with Linux file systems.
So why does the header from fdisk say "Units = cylinders of 16065 *
512 = 8225280 bytes" - note the 512 value.
>
> > With read hard disk geometry C*H*S = number of blocks
> > Thus number of blocks * 512 = disk size?
>
> Yes.
>
> > Is there a relationship mathmatically, size wise, between
> > a block and a sector? ie 4 blocks = 1 sector or whatever?
>
> A block is just one sector at the physical drive level.
So a block and a sector are the same thing?
>
> > Now to involve some real world data:
> > al@al-ubuntu:~$ sudo fdisk -l
> > [sudo] password for al:
> > Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
> > 255 heads, 63 sectors/track, 121601 cylinders
> > Units = cylinders of 16065 * 512 = 8225280 bytes
> > Disk identifier: 0xaf010487
> > Device Boot Start End Blocks Id System
> > /dev/sda1 * 1 121601 976760001 83 Linux
> > I know that start and end are cylinder values and I assume that blocks
> > is the size of the partition in blocks. Assuming I was correct before
> > when I stated that blocks are 512 bytes in size, then:
> > 976760001 * 512 bytes = disk size in bytes - but it doesnt, it equals
> > 500101120512 bytes which is way off 1000204886016 bytes from the
> > header in fdisk. Why?
>
> You should have mulitiplied by 1024 instead of 512.
976760001 * 1024 = 1000202241024 which is still not equal to
1000204886016.
>
> > From fdisk headerline "255 heads, 63 sectors/track, 121601 cylinders"
> > - now using C*H*S = number of blocks
>
> > 121601 * 255 * 63 = 1953520065 blocks
>
> Nope, sectors.
C*H*S according to the wiki gives the size in blocks :
http://en.wikipedia.org/wiki/Cylinder-head-sector#CHS_Addressing - I
guess thats another area where the wiki disagrees with you?
>
> > and because 512 bytes to a block:
> > 512 * 1953520065 = 1000202273280 bytes (which should be the same as
> > the disk size given in the fdisk header line "1000204886016 bytes" but
> > it isnt. Why?)
>
> Because the linux block is 1024
Again even if I use 1024 * 1953520065 = 1000202273280 which is still
not equal to fdisk header line "1000204886016 bytes" - can you
explain that?
>
> > The same disk:
> > TestDisk 6.10, Data Recovery Utility, July 2008
> > Christophe GRENIER <gren...@cgsecurity.org>
> >http://www.cgsecurity.org
> > Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
> > Current partition structure:
> > Partition Start End Size in sectors
> > 1 * Linux 0 1 1 121600 254 63 1953520002
> > Now start and end are full CHS values and we can also see the size of
> > the partition in sectors. I have been told that:
> > (255 * 63 * 121601) - (63 * 1) = 1953520002
> > Which is the size in sectors. But I dont quite understand the calculations.
>
> Its 255 instead of 254 because the cylinder numbering starts at 0
>
> > In its simplest form the End CHS size - Start CHS size = size of partition (True/False?)
>
> Falso.
Why?
>
> > Because of numbering starting at 0 start end CHS values in calculation
> > are:
> > 121601,255,63 (True/False?)
>
> True with the 255, but its more complicated than that.
>
> > Start CHS values, by the same reasoning should be:
> > 0,2,2
>
> Nope, those dont start at 0, they start at 1.
>
Al
Franc Zabkar
finger to keyboard and composed:
>I understand so far:
>That hard disks have physical geometry CHS, but modern hard disk CHS
>bears no direct relationship to the physical geometry of the disk.
In the early 1990s, drives already began to support address
translation where you could specify any logical CHS combination that
didn't exceed a drive's capacity. The drive would then perform its own
internal conversion to physical CHS values.
>The the definition of a sector (on the physical disk anyway) is a
>strip extending from the center of the platter to the edge.
Nowadays drives use Zone Bit Recording. Each zone has a constant
number of sectors/track, with the outermost zone having the most, and
the innermost zone the least. This equalises the bit densities across
the surface of the platter.
See http://en.wikipedia.org/wiki/Zone_bit_recording
Here is an excellent, in-depth technical article on modern hard
drives:
- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
Rod Speed
>>> The the definition of a sector (on the physical disk anyway)
>>> is a strip extending from the center of the platter to the edge.
>> Nope, that is completely wrong. A sector is part of
>> a track and tracks are concentric circles on the platter.
> Not in this picture it isnt sunshine :
You're misinterpretting that, moonshine.
> http://en.wikipedia.org/wiki/Cylinder-head-sector
> its a pie shaped slice from the center.
Thats a different sort of sector, not the 512 byte sector you referred to elsewhere.
There is no way that that pie shaped sector could be just 512 bytes.
http://en.wikipedia.org/wiki/Disk_sector makes it much clearer and
http://en.wikipedia.org/wiki/File:Disk-structure2.svg
makes it much clearer, the 512 bytes sectors are C in that diagram.
>>> Block usually 512 bytes.
>> Not with Linux file systems.
> So why does the header from fdisk say "Units = cylinders of 16065 *
> 512 = 8225280 bytes" - note the 512 value.
That uses the word units.
>>> With read hard disk geometry C*H*S = number of blocks
>>> Thus number of blocks * 512 = disk size?
>> Yes.
>>> Is there a relationship mathmatically, size wise, between
>>> a block and a sector? ie 4 blocks = 1 sector or whatever?
>> A block is just one sector at the physical drive level.
> So a block and a sector are the same thing?
At the physical drive level, yes. But not necessarily at the file system level.
>>> Now to involve some real world data:
>>> al@al-ubuntu:~$ sudo fdisk -l
>>> [sudo] password for al:
>>> Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
>>> 255 heads, 63 sectors/track, 121601 cylinders
>>> Units = cylinders of 16065 * 512 = 8225280 bytes
>>> Disk identifier: 0xaf010487
>>> Device Boot Start End Blocks Id System
>>> /dev/sda1 * 1 121601 976760001 83 Linux
>>> I know that start and end are cylinder values and I assume that
>>> blocks
>>> is the size of the partition in blocks. Assuming I was correct
>>> before
>>> when I stated that blocks are 512 bytes in size, then:
>>> 976760001 * 512 bytes = disk size in bytes - but it doesnt, it
>>> equals 500101120512 bytes which is way off 1000204886016 bytes from
>>> the
>>> header in fdisk. Why?
>> You should have mulitiplied by 1024 instead of 512.
> 976760001 * 1024 = 1000202241024 which is still not equal to 1000204886016.
Sure, the difference is with the first track which isnt part of
the partition and the last cylinder which is usually reserved etc.
>>> From fdisk headerline "255 heads, 63 sectors/track, 121601
>>> cylinders" - now using C*H*S = number of blocks
>>> 121601 * 255 * 63 = 1953520065 blocks
>> Nope, sectors.
> C*H*S according to the wiki gives the size in blocks :
> http://en.wikipedia.org/wiki/Cylinder-head-sector#CHS_Addressing - I
> guess thats another area where the wiki disagrees with you?
Nope, blocks and sectors are the same, as otherwise discussed.
>>> and because 512 bytes to a block:
>>> 512 * 1953520065 = 1000202273280 bytes (which should be the same as
>>> the disk size given in the fdisk header line "1000204886016 bytes"
>>> but it isnt. Why?)
>> Because the linux block is 1024
> Again even if I use 1024 * 1953520065 = 1000202273280 which is still not
> equal to fdisk header line "1000204886016 bytes" - can you explain that?
See above.
>>> The same disk:
>>> TestDisk 6.10, Data Recovery Utility, July 2008
>>> Christophe GRENIER <gren...@cgsecurity.org>
>>> http://www.cgsecurity.org
>>> Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
>>> Current partition structure:
>>> Partition Start End Size in sectors
>>> 1 * Linux 0 1 1 121600 254 63 1953520002
>>> Now start and end are full CHS values and we can also see the size of
>>> the partition in sectors. I have been told that:
>>> (255 * 63 * 121601) - (63 * 1) = 1953520002
>>> Which is the size in sectors. But I dont quite understand the calculations.
>> Its 255 instead of 254 because the cylinder numbering starts at 0
>>> In its simplest form the End CHS size - Start CHS size = size of partition (True/False?)
>> False.
> Why?
Sorry, I should proof read complicated stuff like this, I meant True.
Franc Zabkar
finger to keyboard and composed:
>I understand so far:
>That hard disks have physical geometry CHS, but modern hard disk CHS
>bears no direct relationship to the physical geometry of the disk.
In the early 1990s, drives already began to support address
translation where you could specify any logical CHS combination that
didn't exceed a drive's capacity. The drive would then perform its own
internal conversion to physical CHS values.
>The the definition of a sector (on the physical disk anyway) is a
>strip extending from the center of the platter to the edge.
Nowadays drives use Zone Bit Recording. Each zone has a constant
number of sectors/track, with the outermost zone having the most, and
the innermost zone the least. This equalises the bit densities across
the surface of the platter.
See http://en.wikipedia.org/wiki/Zone_bit_recording
Here is an excellent, in-depth technical article on modern hard
drives:
http://hddscan.com/doc/HDD_Tracks_and_Zones.html
I think of a block as a logical construct rather than a physical one,
although you can think of it in physical terms as well. It depends on
the context ...
>Now to involve some real world data:
>TestDisk 6.10, Data Recovery Utility, July 2008
>
>Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
>Current partition structure:
> Partition Start End Size in sectors
>
> 1 * Linux 0 1 1 121600 254 63 1953520002
>
>Now start and end are full CHS values and we can also see the size of
>the partition in sectors. I have been told that:
>
>(255 * 63 * 121601) - (63 * 1) = 1953520002
>
>Which is the size in sectors. But I dont quite understand the
>calculations.
Historically, the maximum number of sectors per track is 63, and the
maximum number of heads (aka tracks per cylinder) is 255. AIUI, this
is because the original disc controller's registers allocated 6 bits
for S and 8 bits for H.
>In its simplest form the End CHS size - Start CHS size = size of
>partition (True/False?)
LBA = (C x 255 x 63) + (H x 63) + (S - 1)
Partition size (in sectors) = End LBA - Start LBA + 1
= (Ce - Cs) x 255 x 63 + (He - Hs) x 63 + (Se - Ss) + 1
where e/s are the end/start values of CHS.
Historically, the first partition usually starts at LBA 63 because the
first track (LBA 0 - LBA 62) contains the MBR, partition table, and
sometimes additional boot code, eg disc overlays, or a boot manager to
allow booting from one of several partitions.
Arno
> Hi Folks,
> I am hoping some kind people on this NG could help me better
> understand HDD Geometry. Dont get me wrong I have done some googling,
> and read some wiki's - but some parts are still very blurry. I have
> also used the man command since most of what I am doing is in linux.
> Most of my questions have been brought about by various LInux tools I
> have been experimenting with, such as testdisk, mount, and fdisk.
> I will outline what I understand so far, if any of these statements
> are wrong please let me know.
> I understand so far:
> That hard disks have physical geometry CHS, but modern hard disk CHS
> bears no direct relationship to the physical geometry of the disk. I
> think the modern CHS is sometimes called Psuedo CHS.
Correct.
> C and H numbering starts at 0, but S starts at 1.
I think so.
> The the definition of a sector (on the physical disk anyway) is a
> strip extending from the center of the platter to the edge. And a
> block is the intersection of a cylinder and a sector. Sometimes use
> the terms block and sector to mean the same thing (block).
Wrong. Historically it was so, but that was never the definition.
A sector is the part of a track (curcular for HDDs, but a spiral for
CDROM, e.g.) needed to store the smallest unit that can be read or
writen by one access.
> Block usually 512 bytes.
Avoid the term "block". Use sector for pysical blocks and "cluster"
for logical blocks managed by the OS.
> With read hard disk geometry C*H*S = number of blocks
> Thus number of blocks * 512 = disk size?
Yes.
> Is there a relationship mathmatically, size wise, between a block and
> a sector? ie 4 blocks = 1 sector or whatever?
See above. "Block" has no fixed meaning in this context.
Clusters are comprised of one or several sectors, typically
starting by 4 sectors/cluster, but it is a formatting
time option (i.e. mkfs option).
> Now to involve some real world data:
> al@al-ubuntu:~$ sudo fdisk -l
> [sudo] password for al:
> Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
> 255 heads, 63 sectors/track, 121601 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0xaf010487
> Device Boot Start End Blocks Id System
> /dev/sda1 * 1 121601 976760001 83 Linux
> I know that start and end are cylinder values and I assume that blocks
> is the size of the partition in blocks. Assuming I was correct before
> when I stated that blocks are 512 bytes in size, then:
> 976760001 * 512 bytes = disk size in bytes - but it doesnt, it equals
> 500101120512 bytes which is way off 1000204886016 bytes from the
> header in fdisk. Why?
You have a third meaning of "block" here, a historic one. That
is "unit of 1024 bytes of space". I think this comes from SunOS.
> From fdisk headerline "255 heads, 63 sectors/track, 121601 cylinders"
> - now using C*H*S = number of blocks
> 121601 * 255 * 63 = 1953520065 blocks
> and because 512 bytes to a block:
> 512 * 1953520065 = 1000202273280 bytes (which should be the same as
> the disk size given in the fdisk header line "1000204886016 bytes" but
> it isnt. Why?)
Because teh C/H/S numbers are an approcimation. There usually is some
extra space at the end that does not quite fit into the C/H/S masure.
Linux has been using LBA (one number per sector) for a long time,
fsisk is just from before that time and the C/H/S methaphor works
relatively well, so it was never changed. But you can look at cfdisk,
sfdisk and parted. They use direct sizes, and, let me tell you, they
can be a pain if you want to create a partition exactly the same size
as an existing one.
> The same disk:
> TestDisk 6.10, Data Recovery Utility, July 2008
> Christophe GRENIER <gre...@cgsecurity.org>
> http://www.cgsecurity.org
> Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
> Current partition structure:
> Partition Start End Size in sectors
> 1 * Linux 0 1 1 121600 254 63 1953520002
> Now start and end are full CHS values and we can also see the size of
> the partition in sectors. I have been told that:
> (255 * 63 * 121601) - (63 * 1) = 1953520002
> Which is the size in sectors. But I dont quite understand the
> calculations.
> In its simplest form the End CHS size - Start CHS size = size of
> partition (True/False?)
No. That is the ideal case. It is possible to create partitions that
do not start/end on a cylinder boundary.
> Because of numbering starting at 0 start end CHS values in calculation
> are:
> 121601,255,63 (True/False?)
> Start CHS values, by the same reasoning should be:
> 0,2,2 (Clearly this is not whats used in the calculation - why?)
We have 121601 cylinders, that is 0....121600. But they have
254 heads, instead of the true (ans stated a line earlier) 255.
Seems to me they have the number of the first head wrong, which
should be 0. Possibly a simple programming error.
> Well this has been a long post, and I suspect the answer will raise
> more questions.
> Thanks in advance for any replies.
No problem.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: ar...@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
Arno
> On Nov 19, 9:29?am, Grant <g_r_a_n...@bugsplatter.id.au> wrote:
>> Forget CHS -- the important number for large disks is the 8225280
>> bytes per cylinder.
> Can you use the 8225280 bytes per cylinder with total number of
> cylinders to calculate disk size?
>>
>> Look at fdisk's 'x' mode display? ?It shows the uninterpreted sizes:
>>
>> Command (m for help): p
>>
>> Disk /dev/sda: 80.0 GB, 80025280000 bytes
>> 255 heads, 63 sectors/track, 9729 cylinders
>> Units = cylinders of 16065 * 512 = 8225280 bytes
>> Disk identifier: 0x45e0afb2
> ie: Why does the 8225280 * 9729 <not equal> 8002528000 bytes???
> After all its the cylinder size * number of cylinders???
Only for the virtual C/H/S geometry. The there is some redidual space
at the end that can be accessed using LBA (as Linux does).
Arno
>> allocate space in 1k or 4k (or larger?) blocks depending on partition
>> size.
>>
> So are you saying block size is a function of File System?
Not really. "block" has no fixed meaning. A "filesystem block",
also called "cluster" siometimes is is indeed a unit depending
on the filesystem parameters. See the -b option to mke2fs, e.g..
Unfortunalely the term "block" is in widespread use, but it only
gets meaning when you know the context.
Al
> Al <bigal...@gmail.com> wrote:
> >> >a sector? ie 4 blocks = 1 sector or whatever?
>
> >> There's different block sizes, depending on usage. ?Filesystem may
> >> allocate space in 1k or 4k (or larger?) blocks depending on partition
> >> size.
>
> > So are you saying block size is a function of File System?
>
> Not really. "block" has no fixed meaning. A "filesystem block",
> also called "cluster" siometimes is is indeed a unit depending
> on the filesystem parameters. See the -b option to mke2fs, e.g..
>
> Unfortunalely the term "block" is in widespread use, but it only
> gets meaning when you know the context.
>
> Arno
>
> --
> GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
> ----
> Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
Thanks for the detailed reply, and I will read in depth tomorrow.
Testdisk reports a size in sectors.
Fdisk reports a size in blocks
Mounting partitions with offset wants a offset in??? (blocks/sectors?)
And then there is LBA
Is there a way to convert any of this to say bytes?
All bloody confusing to be honest. Is the LBA addressing people refer
to the same addressing system used by Fdisk? What about offset?
Cheers
-Al
Rod Speed
> On Nov 19, 9:33 pm, Arno <m...@privacy.net> wrote:
>> Al <bigal...@gmail.com> wrote:
>>>>> a sector? ie 4 blocks = 1 sector or whatever?
>>
>>>> There's different block sizes, depending on usage. ?Filesystem may
>>>> allocate space in 1k or 4k (or larger?) blocks depending on
>>>> partition size.
>>
>>> So are you saying block size is a function of File System?
>>
>> Not really. "block" has no fixed meaning. A "filesystem block",
>> also called "cluster" siometimes is is indeed a unit depending
>> on the filesystem parameters. See the -b option to mke2fs, e.g..
>>
>> Unfortunalely the term "block" is in widespread use, but it only
>> gets meaning when you know the context.
> Thanks for the detailed reply, and I will read in depth tomorrow.
>
> Testdisk reports a size in sectors.
> Fdisk reports a size in blocks
> Mounting partitions with offset wants a offset in??? (blocks/sectors?)
> And then there is LBA
> Is there a way to convert any of this to say bytes?
Yes, but there is no point in doing that.
> All bloody confusing to be honest. Is the LBA addressing
> people refer to the same addressing system used by Fdisk?
Nope.
> What about offset?
Nope.
Al
> Partition size (in sectors) = End LBA - Start LBA + 1
>
> = (Ce - Cs) x 255 x 63 + (He - Hs) x 63 + (Se - Ss) + 1
TestDisk 6.10, Data Recovery Utility, July 2008
Christophe GRENIER <gren...@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
Partition Start End Size in sectors
1 * Linux 0 1 1 121600 254 63 1953520002
= (121600 - 0) x 255 x 63 + (254 - 1) x 63 + (63 - 1) + 1
= (121600) x 255 x 63 + (253) x 63 + (62) + 1
= 1953504000 + 15939 + 63
= 1953520002
Brilliant.
Al
Your answer is so detailed I cant follow it.
>
> > What about offset?
>
> Nope.
Another great point of clarification.
Rod Speed
>>>>>>> a sector? ie 4 blocks = 1 sector or whatever?
>>>>>> There's different block sizes, depending on usage. ?
>>>>>> Filesystem may allocate space in 1k or 4k (or larger?)
>>>>>> blocks depending on partition size.
>>>>> So are you saying block size is a function of File System?
>>>> Not really. "block" has no fixed meaning. A "filesystem block",
>>>> also called "cluster" siometimes is is indeed a unit depending
>>>> on the filesystem parameters. See the -b option to mke2fs, e.g..
>>>> Unfortunalely the term "block" is in widespread use,
>>>> but it only gets meaning when you know the context.
>>> Thanks for the detailed reply, and I will read in depth tomorrow.
>>> Testdisk reports a size in sectors.
>>> Fdisk reports a size in blocks
>>> Mounting partitions with offset wants a offset in???
>>> (blocks/sectors?) And then there is LBA
>>> Is there a way to convert any of this to say bytes?
>> Yes, but there is no point in doing that.
>>> All bloody confusing to be honest. Is the LBA addressing
>>> people refer to the same addressing system used by Fdisk?
>> Nope.
> Your answer is so detailed I cant follow it.
Your problem. Fdisk uses CHS values, not LBA numbers.
>>> What about offset?
>> Nope.
> Another great point of clarification.
You're welcome.
Al
>>LBA = (C x 255 x 63) + (H x 63) + (S - 1)
and test data:
Al <biga...@gmail.com> wrote:
>Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
>Current partition structure:
> Partition Start End Size in sectors
>
> 1 * Linux 0 1 1 121600 254 63 1953520002
thus start LBA:
LBA = (0 x 255 x 63) + (1 x 63) + (1 - 1)
= 0 + 63 + 0
= 63
and end LBA:
LBA = (121600 x 255 x 63) + (254 x 63) + (63 - 1)
= 1953504000 + 16002 + 62
= 1953520064
1) Are the units of LBA blocks? And if so, does (LBAe - LBAs) * 512 =
partition size?
2) Should the C and H values in the calculation be 64 and 121601
(because the numbering starts at 0?)
One of the commands I am dealing with is MOUNT and with the offset
switch.
Plenty of sites tell you to multiply the start (Cylinders) by 512 to
get the offset value. Therefore what unit is the offset value in?
Cheers
-Al
Al
Al wrote:
> Franc Zabkar <fzab...@iinternode.on.net> wrote:
> >>LBA = (C x 255 x 63) + (H x 63) + (S - 1)
>
> and test data:
>
> Al <biga...@gmail.com> wrote:
> >Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
> >Current partition structure:
> > Partition Start End Size in sectors
> >
> > 1 * Linux 0 1 1 121600 254 63 1953520002
>
> thus start LBA:
>
> LBA = (0 x 255 x 63) + (1 x 63) + (1 - 1)
> = 0 + 63 + 0
> = 63
>
> and end LBA:
>
> LBA = (121600 x 255 x 63) + (254 x 63) + (63 - 1)
> = 1953504000 + 16002 + 62
> = 1953520064
I also noitce that LBAe-LBAs (1953520064-63) = 1953520001 which is one
number off the correct size in sectors for the partition. Why one
number wrong?
-Al
Rod Speed
Usual maths, its always end-start+1
Rod Speed
> Franc Zabkar <fzab...@iinternode.on.net> wrote
>>> LBA = (C x 255 x 63) + (H x 63) + (S - 1)
> and test data:
> Al <biga...@gmail.com> wrote:
>> Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
>> Current partition structure:
>> Partition Start End Size in sectors
>> 1 * Linux 0 1 1 121600 254 63 1953520002
> thus start LBA:
> LBA = (0 x 255 x 63) + (1 x 63) + (1 - 1)
> = 0 + 63 + 0
> = 63
> and end LBA:
> LBA = (121600 x 255 x 63) + (254 x 63) + (63 - 1)
> = 1953504000 + 16002 + 62
> = 1953520064
> 1) Are the units of LBA blocks?
Nope, sectors.
> And if so, does (LBAe - LBAs) * 512 = partition size?
Yes. But thats sectors, not blocks.
> 2) Should the C and H values in the calculation be 64 and 121601
> (because the numbering starts at 0?)
It doesnt with heads and cylinders, only with sectors.
Franc Zabkar
finger to keyboard and composed:
>1) Are the units of LBA blocks? And if so, does (LBAe - LBAs) * 512 =
>partition size?
LBA = Logical Block Address
For a typical hard drive, 1 LBA = 1 sector = 512 bytes.
Partion size = (LBAe - LBAs + 1) * 512
For example, a partition consisting of two sectors, LBA 10 and LBA 11,
has a size of (11 - 10 + 1) * 512.
>2) Should the C and H values in the calculation be 64 and 121601
>(because the numbering starts at 0?)
Each cylinder has 255 heads (aka tracks), and each track has 63
sectors.
The very first sector is LBA 0 or CHS 0/0/1. We haven't completed a
full cylinder, nor a full track, so C=0 and H=0.
LBAs are assigned sequentially. Start at the first sector of the first
track under the first head, and then go around the track. This gives
you 63 sectors. Switch to the first track under the second head and
count the next 63 sectors. Then repeat this process until you go
around the first track under the 255th head. Now you have completed
one full cylinder. Return to the first head and go around the second
track. Keep switching heads until you complete the second cylinder and
then begin on the third cylinder. Etc, etc ...
>One of the commands I am dealing with is MOUNT and with the offset
>switch.
>
>Plenty of sites tell you to multiply the start (Cylinders) by 512 to
>get the offset value. Therefore what unit is the offset value in?
Sorry, that makes no sense to me. Perhaps a Linux user could help you?
Al
> On Fri, 20 Nov 2009 00:07:24 -0800 (PST), Al <bigal...@gmail.com> put
> finger to keyboard and composed:
>
> >1) Are the units of LBA blocks? And if so, does (LBAe - LBAs) * 512 =
> >partition size?
>
> LBA = Logical Block Address
>
> For a typical hard drive, 1 LBA = 1 sector = 512 bytes.
>
> Partion size = (LBAe - LBAs + 1) * 512
Ok that makes good sense.
Does it follow that 1 LBA = 1 block = 512 bytes?
>
> For example, a partition consisting of two sectors, LBA 10 and LBA 11,
> has a size of (11 - 10 + 1) * 512.
>
> >2) Should the C and H values in the calculation be 64 and 121601
> >(because the numbering starts at 0?)
I think I confused myself there - S numbering starts at 1. (and CH at
0). The 63 is a S.
>
> Each cylinder has 255 heads (aka tracks), and each track has 63
> sectors.
>
> The very first sector is LBA 0 or CHS 0/0/1. We haven't completed a
> full cylinder, nor a full track, so C=0 and H=0.
>
> LBAs are assigned sequentially. Start at the first sector of the first
> track under the first head, and then go around the track. This gives
> you 63 sectors. Switch to the first track under the second head and
> count the next 63 sectors. Then repeat this process until you go
> around the first track under the 255th head. Now you have completed
> one full cylinder. Return to the first head and go around the second
> track. Keep switching heads until you complete the second cylinder and
> then begin on the third cylinder. Etc, etc ...
>
> >One of the commands I am dealing with is MOUNT and with the offset
> >switch.
>
> >Plenty of sites tell you to multiply the start (Cylinders) by 512 to
> >get the offset value. Therefore what unit is the offset value in?
>
> Sorry, that makes no sense to me. Perhaps a Linux user could help you?
FWIW This guy shows how simple it is. He multiples the C start by 512
to get the offset value.
http://darkdust.net/writings/diskimagesminihowto#Mountingthediskimage
I am picking that you can multiple the C * 512 to get the offset in
bytes?
-Al
Rod Speed
>>> 1) Are the units of LBA blocks? And if so, does (LBAe - LBAs) * 512 = partition size?
>> LBA = Logical Block Address
>> For a typical hard drive, 1 LBA = 1 sector = 512 bytes.
>> Partion size = (LBAe - LBAs + 1) * 512
> Ok that makes good sense.
> Does it follow that 1 LBA = 1 block = 512 bytes?
Like he said FOR A TYPICAL HARD DRIVE.
Franc Zabkar
finger to keyboard and composed:
>On Nov 21, 2:27�pm, Franc Zabkar <fzab...@iinternode.on.net> wrote:
>> On Fri, 20 Nov 2009 00:07:24 -0800 (PST), Al <bigal...@gmail.com> put
>> finger to keyboard and composed:
>>
>> >1) Are the units of LBA blocks? And if so, does (LBAe - LBAs) * 512 =
>> >partition size?
>>
>> LBA = Logical Block Address
>>
>> For a typical hard drive, 1 LBA = 1 sector = 512 bytes.
>>
>> Partion size = (LBAe - LBAs + 1) * 512
>
>Ok that makes good sense.
>Does it follow that 1 LBA = 1 block = 512 bytes?
All the hard drives you are likely to encounter have block sizes equal
to the sector size, ie 512 bytes (= 256 words).
However, the ATA-8 specification allows for other sizes.
See words 106 and 117-118 of the Identify Device data block, as
described in the following document.
Working Draft AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS):
http://www.t13.org/Documents/UploadedDocuments/docs2008/D1699r6a-ATA8-ACS.pdf
>FWIW This guy shows how simple it is. He multiples the C start by 512
>to get the offset value.
>
>http://darkdust.net/writings/diskimagesminihowto#Mountingthediskimage
>
>I am picking that you can multiple the C * 512 to get the offset in
>bytes?
>
>-Al
The author of that tutorial is multiplying the start LBA by 512 to get
the offset in bytes into the disc image.
Bilky White
news:7mm5moF...@mid.individual.net...
>
> You're welcome.
>
You're useless.
Rod Speed
own lines, or anything else at all either, desperately cowering behind
Bilky Brown wrote just the puerile shit that you'd expect from a
desperately cowering gutless fuckwit brown chav child.