Talk:Cylinder-head-sector

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Computer hardware task force (assessed as Mid-importance).

Surplus Sectors?

The lines: "Most modern drives have a surplus space that doesn't make a cylinder boundary. Each partition should always start and end at a cylinder boundary. Only some of the most modern OSs may disregard this rule, but this can cause some compatibility problems, especially if the user wants to boots up to more than one OS on the same drive."

...seem a bit out of place, because there's a section on IDE drives immediately following.

It is talking about IDE drives, when it says "most modern drives," ...right?

I don't understand about the "surplus space" - doesn't Zone Bit Recording take care of that?

Or is it that, even under ZBR, there's a little bit of extra space on each cylinder?

Doesn't ZBR make the cylinder completely transparent, and you're basically just addressing sectors? How would a program know where the cylinder boundary is, since each cylinder has a different number of sectors? LionKimbro

No, this refers to the fact that under an operating system (such as DOS and most Windows(tm) versions) which requires its partitions to end on a pseudo cylinder boundary (usually of 255 heads and 63 sectors), there will almost always be some odd number of user accessible sectors on a disk that don't divide exactly into that geometry. Daniel B. Sedory 00:01, 11 June 2007 (UTC)[reply]

"Only some of the most modern operating systems"??? Hasn't Linux always (i.e., for 15 years, as of 2006) allowed any kind of partition boundaries?

The History section here is obviously a bit out of date, since CHS tuples haven't actually corresponded to disk hardware in a very long time! Other than that, yes, Linux has been using different boundaries than DOS ever since it could; probably to mitigate the difference between the pseudo-geometry used and the number of surplus (unused) sectors left at the end of the disk. Face it: Any OS that's based on pseudo-CHS values (even Linux), rather than individual sectors, will likely have SOME sectors that can't fit into its partition boundaries for whatever arbitrary values you choose! Daniel B. Sedory 00:01, 11 June 2007 (UTC)[reply]

There is no trusted source for this statement:

"For operating systems such as Microsoft DOS or Windows (before Vista), each partition must start and end at a cylinder boundary."

My personal experience: at least since Win98SE theese non cylinder boundary partitions and partition tables can be read, although their partitioning programs don`t create non cylinder boundary partitions. Only Symantec/Notrton Partition Magic 8.x won`t handle such partitions. Non of you ever had mixed linux and windows installations on a single harddrive? Nerver used GParted for creating windows partitions? 89.58.155.42 (talk) 18:58, 2 April 2008 (UTC)[reply]

I find this to be absolutely true. Partitions that don't begin and end on a cylinder boundry work just fine. It would seem that since modern systems use LBA anyway, using archaic CHS values is rather pointless. I especially hate cylinder boundries on memory cards where for examle I had a 64MB Compact Flash that had 1.5MB of unallocated space. I have not found a formatting program yet that allocates all the space. Thank goodness for PTEDIT32 and hex editors. I am able to get all the space out of my cards now. Such edited cards drive Partition Magic bonkers, but otherwise I never had a problem. 66.114.93.6 (talk) 06:16, 18 July 2008 (UTC)[reply]

Change from PTEDIT32 to Beeblebrox Partition Editor ;-) 89.58.158.188 (talk) 09:25, 11 August 2008 (UTC)[reply]

I would never trust a device which breaches the golden rule that all partitions must be aligned with a cylinder boundary! While it is certainly true that some partitioning programs will (recklessly) permit the creation of invalid, i.e. unaligned, partitions it would be rash to suggest that this amounts to a validation of that type of partition, because such claims are typically made on the mere basis that it was possible to create the partition. The acid test is not in creating it, but in filling up the partition, to the last byte, and then analysing it for data corruption errors. I have come across many claims that rest on the mere fact that a partition was created unaligned; but few of those claims had actually been put to the test by writing data to the device in the (doubtful but critical) final cylinder. Stephen Poppitt (talk) 13:17, 1 October 2010 (UTC)[reply]

I'm finding there are special memory card formatting programs that allocate all of the space. Most are written specially for the chipsets in various USB card readers. I now have three inexpensive card readers that each work with three different formatting programs. Also for most people you can just format in a camera or other suitable device. But part of my original problem was I was using cards only on a computer, and one device that does not have a built in formatter. 66.114.93.6 (talk) 05:50, 29 April 2009 (UTC)[reply]

Two heads/platter: Not always!

I'm aware of drives (the current 5200RPM Hitachi 2.5" drives) some of which have an odd number of heads (the 20GB drive has one platter with one head, the 60GB drive has two platters with three heads). I suspect that this is rather common.

I'm sorry I can't log in at the moment but ... The above may be true for the drives that were made in the 1980s, for the original IBM PC. The values now, make no particular sense that is applicable to all drives from every drive maker. The manufacturer is responsible for making the presentation of the physical disk medium to a place where someone writing operating system level code, can reliably address it. This requires some cooperation from the BIOS folks who have traditionally been responsible for reporting the correct disk size, to the OS. As of the Vista version of the Windows OS, Windows will began to assume some of the responsibility for obtaining information from the BIOS. (There was a time when no BIOS had a setting that pertains to a PnP OS). Linux has ignored BIOS settings for quite some time. These things aside, it is clear that some contributors do not even know. A track and a cylinder are definitely /not/ the same thing but I just saw text that says they are. In addition, the drawing of the platters for this entry should show the platter stack from an oblique angle so that the drawing is not misinterpreted to say the same thing. To add to this, since a floppy is always a single platter, the number of cylinders is the same as the number of tracks (as the definition I read and changed stated) if the platter can hold data on one side, only. Probably the only thing that persists is that there is one head per writable side of each platter. The point to make clear is that the heads are not part of the disks, or of the disk stack, although they are part of the drive. —Preceding unsigned comment added by 67.40.35.153 (talk) 04:35, 20 November 2008 (UTC)[reply]

CHS count

This article might want to mention something about how the cylinders, heads and sectors are counted. I was just reading about the classical PC (DOS) partition table and how the first sector is located at cylinder 0, head 0, sector 1 (CHS 001). This is where the master boot record (MBR) is stored. However, the address CHS 000 seems to be illegal. Are all CHS addresses ending in 0 invalid, or just this first one? --Jwinius 15:49, 19 April 2007 (UTC)[reply]

In case anyone else wants to know as well, the answer is that all CHS specified locations must conform to a few range rules to be valid (legal). The allowed values are:

1. Cylinder: 0 - 1023 (for a maximum total of 1024).
2.     Head: 0 - 254  (for a maximum total of 255).
3.   Sector: 1 - 63   (for a maximum total of 63).

As one proceeds through LBA counts of 0, 1, 2, etc., the following are a few corresponding CHS tuples that may be very helpful in understanding their relationship (for drives that have 63 sectors per head):

LBA 0 = CHS 0,0,1
LBA 62 = CHS 0,0,63
LBA 63 = CHS 0,1,1

Likewise, for drives that have a pseudo-geometry of 255 heads per cylinder (which may be determined by your operating system these days; e.g., many Linux installs are based on only 16 heads/cylinder, whereas the same physical disk might have 255 heads/cylinder under a Windows OS), the following would be true:

LBA 16,002 = CHS 0,254,1
LBA 16,064 = CHS 0,254,63
LBA 16,065 = CHS 1,0,1

And the maximum LBA sector that CHS can provide a valid corresponding tuple for is at: CHS 1023,254,63 which is equivalent to an LBA of 16,450,559 for 16,450,560 sectors, total; which was passed when hard disks began to exceed a size of 8,422,686,720 bytes, (about 8.42 GB; or 7.84 GiB). Daniel B. Sedory 22:31, 10 June 2007 (UTC)[reply]

NOTE: All of the above and more has been added to the article since Jwinius asked about it. Daniel B. Sedory 27 November 2008.

If CHS 0,0,0 is invalid, how does one write a MBR?--DustWolf (talk) 20:00, 23 June 2008 (UTC)[reply]

Please clarify the question, "how does one write an MBR?" Do you mean how does a utility program or OS know where to find or write it? If they use a function call that requires CHS notation, it would be CHS 0,0,1. If the function uses LBA instead, then it would be LBA 0. Daniel B. Sedory (talk) 04:26, 27 November 2008 (UTC)[reply]

While the rule that CHS addressing starts with sector 1 (that is CHS 0/0/1) applies in general (on IBM PC compatible machines), I'm wondering, if this rule still holds true for non-standard formats such as the 640 KB format on the BBC Master 512 under DOS Plus 2.1. In this specific floppy format, the low-level physical sectors in a track start with sector #0, not with sector #1, as is common almost anywhere else. I wonder, if the convention to assume CHS 0/0/1 as the first physical sector is merely a result of the fact that normally, the first sector in a floppy disk track is sector #1. If so, CHS 0/0/0 could be a valid address in this 640 KB format. However, it is also possible, that we have to add another (normally invisible) translation layer here and the sector numbers for CHS addressing are assumed to be renumbered low-level sectors. I think this question can be answered by checking how floppy controllers work and are programmed by the BIOS in IBM compatible machines. While I can look this up, I thought I bring it up here as well. --Matthiaspaul (talk) 12:21, 1 August 2012 (UTC)[reply]

Merging Disk sector into this article

Just a quick note here to mention that I'll be slowly merging the small amount of material at Disk sector into various sections here. Any comments would be appreciated. Daniel B. Sedory 19:27, 7 October 2007 (UTC)[reply]

I don't think a merge makes sense. The Disk sector article is about actual disk sectors while this article is about a hard-disk addressing method which uses physical cylinder, head, and sector to which the data is to be written as the address for the data. To merge these articles would be similar to merging House with House numbering. Sagsaw (talk) 00:50, 29 December 2007 (UTC)[reply]

First, the 'merge request' has been on these articles for a long time; I didn't place it here, but since I've spent much time editing both of these articles, thought I'd consider how to go about it and make a smooth transition. (It hasn't been a high priority for me though.) I'm not at all opposed to leaving them as they are; though I do see redundancy and that Disk sector is presently not much larger than 'dictionary-sized' entries rather than being encyclopedic. What I would really like is for one of the Wiki 'higher authorities' to make a judgment call on this. Daniel B. Sedory (talk) 04:06, 31 December 2007 (UTC)[reply]

It seems a bit weird that The Disk sector article is much smaller than The Cylinder-head-sector article. If a merge were to take place, I'd suggest CHS be a sub-part of the Disk sector article, since that's logically how things are. This would obviously take some careful planning and perhaps some paring down of the material on the CHS page (it seems to spend paras describing some terms where a wikilink should suffice). I'm not sure it is a good idea to merge them at present. I came to the Disk sector article to find out how large a disk sector was, and despite it being short, it's a concise article that told me exactly what I wanted to know. I wouldn't have wanted to page over loads of stuff about the largely historical CHS to get to that information. -- Jon Dowland (talk) 16:38, 7 March 2008 (UTC)[reply]

CHS addressing is not entirely historical. When dealing, for example, with common sizes of USB flash drives (also known as USB pen drives or thumb drives), they are nearly always smaller than 8GB, and so can be addressed using the CHS system. As they almost universally use FAT32 instead of NTFS, all of the original conventions of CHS addressing apply to them. When they experience data storage issues, an understanding of CHS addressing can be very helpful in fixing them. Stephen Poppitt (talk) 13:07, 1 October 2010 (UTC)[reply]

Block vs. Sector (as smallest storage unit on an HDD)

When I started editing this article, its use of the term 'Sector' in CHS (Cylinder,Head,Sector) as the geometrical sector (or slice) common to mathematics, etc. was (and still is) rather compelling. So, I kept that usage as best I could even when adding content to the article Disk sector; based upon what I'd read here and in Circular sector. As a reflection on this topic, I'm asking (musing) whether or not block should continue being used here as the smallest 'chunk of data' one can 'read from/write to' an HDD through its interface (controller card), and how best to point out that 'Sectors' in CHS notation doesn't necessarily mean the same thing as Sectors in HDD capacity calculations. I'm still thinking this through but wanted to present some data and ideas concerning this.

One possible reason the use of "block" was replaced by the now more common term "sector," may be that 'block' was viewed as being somewhat artificially inserted into formulas for computing a disk's capacity: We know many of these formulas use the pseudo drive values of: "63 sectors" and "255 heads," but what units are associated with them? If we use a formula often found in simplified web presentations: S sectors/head x H heads/cylinder x C cylinders, we can't help but notice both the 'head' and 'cylinder' units cancel each other out, giving us S x H x C sectors; apparently keeping all the units straight. But do these units actually correspond with reality?

Did the change from the real number of physical 'sectors' and drive 'heads' (perhaps when Zone bit recording became standard on all new HDDs?) signal the rise of 'sectors' vs. 'blocks'?

The formulas presented in this article arrive at drive capacity from some physically real units that still apply to floppy diskettes: S SectorSlices/Side x H Sides x C Cylinders = S x H x C (SectorSlices x Cylinders) (where Side is equivalent to 'head'). The only way to resolve this result into a single unit is by defining another term as equivalent to "SectorSlices x Cylinders"; which this article does by stating:

blocksPerPlatterSide = (cylindersPerPlatter)*(SectorsPerPlatter)

which is directly related to its definition of block as: The intersection of a cylinder and a sector (SectorSlices x Cylinders). So, what's wrong with the first formula I presented here from popular web sites? I'll have to leave that for another time! Daniel B. Sedory 10:34, 17 June 2007 (UTC)[reply]

(Given the detail intended for this article, it seems a waste to make a generalization such as a given parameter is the smallest. Besides, science tried to do this with the atom, then turned out to be wrong. The point to take home is, "it depends" on your reference frame and this is usually based on your need at the time the information is sought. I can't imagine when relative size really does matter.) —Preceding unsigned comment added by 67.40.35.153 (talk) 04:38, 20 November 2008 (UTC)[reply]

Whether we use the word block or sector, if you read the article (or read through any of the ATA specifications) you'd find this is a definition, not a generalization: "These blocks are the smallest geometrical breakdown of a disk, and represent the smallest amount of data which can be transferred to or from a disk (usually 512 bytes)." You will also note that the size of a block can vary depending upon the media (CD-ROM discs have a larger sector size than present hard disks) or some future technological change. Did the majority of scientists ever say there couldn't be anything smaller than an atom, or just that it was the smallest thing we knew about at the time? But the point here is this article has nothing to do with guessing what the smallest building blocks of nature might be; only what a particular technology's creators have defined something to be. Daniel B. Sedory (talk) 04:02, 27 November 2008 (UTC)[reply]

There is some semantic correlation between the terms 'block' and 'allocation unit', the latter being the expression used by the Windows operating system itself to define the smallest addressable space. Perhaps, therefore, there is some merit to the references to 'block' being changed to 'allocation unit'. Certainly, there is no correlation between 'block' and 'sector', as the interchangeable terms 'cluster' and 'allocation unit' are always used by the O/S to describe the disk addresses, for example when dealing with the File Allocation Table, in which the cluster addresses for each file are stored. 'Sector' (as a 512 byte structure) has no meaningful function as a term, where the smallest allocation unit is 4KB. Within the FAT32 filesystem the smallest allocation unit may be as large as 32KB on a partition exceeding 32GB. Stephen Poppitt (talk) 12:48, 1 October 2010 (UTC)[reply]

Blocks and sectors?

Αcording to the book "Data Management Systems" 3rd edition, by Ramakrishnan and Gehrke, (pages 306-307): "Each track is divided into arcs, called sectors [...]. The size of a disk block can be set when the disk is initialized as a multiple of the sector size." This is a much different definition than the one given here. What are the sources for the definition of sector and block here? —Preceding unsigned comment added by 195.148.60.152 (talk) 12:56, 27 October 2008 (UTC)[reply]

The point you make is valid, and corresponds to the distinction between 'sector' and 'allocaton unit' as used by the Windows O/S. The reference to a disk block which you quote is in point of fact a definition of the term 'allocation unit' as used by Microsoft. Stephen Poppitt (talk) 12:52, 1 October 2010 (UTC)[reply]

16,064 vs. 16,065?

The article says in section “Cylinders” that 255 * 63 is 16,064. At least this is the way I understood the wording. Actually, 255 * 63 is 16,065. So, where’s the mistake in the article? If there is a special reason to use 16,064 sectors per cylinder, more explanatory text around that should be added. If the number is wrong, it just needs to be changed.

–87.181.116.237 (talk) 11:21, 4 October 2010 (UTC)[reply]

Somebody fixed that. Do you have a source for this alleged standard cylinder size? –82.113.99.139 (talk) 14:18, 30 July 2011 (UTC)[reply]

Cylinder (disk drive)

Please merge the Cylinder (disk drive) stub into this article. –82.113.99.139 (talk) 14:18, 30 July 2011 (UTC)[reply]

Some older disk drives had numbered cylinders and heads but did not have sectors, e.g., IBM 1301, 2311, 2314, 3330. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:52, 3 August 2011 (UTC)[reply]

Well, we could mention this detail in a CHS "cylinder" section. So far the most interesting part of the "cylinder" stub is its talk page. If that is a serious obstacle simply remove the merge tags added by me; otherwise I see no problem with one sector per track. –89.204.153.138 (talk) 03:32, 15 September 2011 (UTC)[reply]

In essence

Hi, Ocdex trimmed two occurences of "The in essence" something to "In essence" something in the Heads section, is that as it should be? I undid my "fix" of the 1st case when the 2nd case convinced me that this was an intentional modification. –89.204.153.138 (talk) 03:49, 15 September 2011 (UTC)[reply]

Physical size of sector

Is the figure depicting a disk sector accurate? If one read this with the information in the article I'm having a hard time adapting this into a physical reality.

Using the figure:

Say a HDD platter side is divided into 32 tracks. Number 1 is nearest center, 32 is on the outer edge.
Take a graphical sector, (like the red in picture). Extract one disc sector¹ from track 32 and one from track 1.
Stretch them out in a linear fashion you'll get something like:

  +-----+
  |     |  Track 1
  +-----+

  +---------------------------+
  |                           |  Track 32
  +---------------------------+

Are those two both supposed to hold the same amount of bits? E.g. 512*8?

Are they even larger then 512*8 due to the fact of what is described under disk sectors: "In disk drives, each physical sector is made up of three basic parts, the sector header, the data area and the error-correcting code (ECC)."

^[1] Disk sector: "Thus, the disk sector (Figure 1, item C) refers to the intersection of a track and geometrical sector."

--Warumwarum (talk) 11:01, 9 October 2013 (UTC)[reply]

Regarding your first question if both sectors hold the same amount of information: Your observation is correct, but, yes, they do, at least in this model. In reality, the length difference isn't that extreme, as the central portion of the disk, which does not hold any information, is much larger than in your sketch.

While this logical model is accurate for (most) floppy disks and old hard disks, there are exceptions:

Some floppy disks (for example in the Sirius 1) had a facility to change the rotation speed depending on the track read. They would be slower on the outer tracks, so that more sectors could be stored there without altering the data rate.

Modern harddisks (for some decades) also store more physical sectors in the outer tracks than in the inner tracks. For obvious reasons, they cannot change the rotational speed, but they change the data rate with which the information is read internally (faster on the outer tracks). However, since the ROM BIOS and operating systems could not cope with this, they will emulate a disk with a simply C/H/S geometry and translate this into their internal mapping and geometry. As this happens inside the drive, it is totally transparent to the outside.

Regarding your other question: Yes, while logical sectors typically have a payload of 512 bytes (sometimes other smaller or larger values are possible as well), the physical sectors as they are stored on the medium contain somewhat more information, they have IDs, checksums, lead-in and lead-out sections and there are certain types of gaps between those sectors.

--Matthiaspaul (talk) 14:36, 9 October 2013 (UTC)[reply]

Great read. Thank you. My main concern was if the physical size actually differed, or if the picture only was a way to view it. Used to think it was more like this, and that the CHS scheme was more of a way to explain it to mortals.

--Warumwarum (talk) 19:21, 9 October 2013 (UTC)[reply]

Your "sliced cake" diagram is simplified (it does not show the gaps, lead-in and lead-out sections between the sectors, and it also assumes a sector interleave of 1:1 and a track sector skew of 0) but it is otherwise accurate for most floppy drives (where the physical C/H/S geometry and the logical C/H/S geometry is the same) as well as for hard disks prior to the introduction of zone bit recording.

The linked picture illustrates a hard drive which implements zone bit recording (a feature introduced in the early 1990s some while after the introduction of on-drive controllers) and some amount of track sector skew.

Track sector skew: It takes a moment to move the head from one track to another. A typical use case is that consecutive sectors are read. Without sector skew, the head might just miss the logically following sector after have switched tracks (or heads). Therefore the whole arrangement of sectors on a track is slightly rotated compared to the next track. The exact amount necessary depends on the time necessary to switch between tracks.

A similar measure named sector interleave (not shown) was used on old disks on slow systems; the logical sectors within a track were interleaved by a certain factor, that is, the physical order of sectors within a track was not consecutive. By adjusting the sector interleave to the system's transfer speed, the time necessary to wait for the next logical sector to be under the head when needed could be optimized. The slower the system or faster the drive, the higher the optimal interleave factor.

Sector skew and interleave factor were important to know or find out when low-level formating a harddisk (as was common before the introduction of on-drive controllers). End users no longer have to deal with this for some decades, as a drive's controller will emulate a suitable logical C/H/S geometry (or not even this when using LBA). Also, the operating system will not deal with physical sectors, but only with logical sectors.

--Matthiaspaul (talk) 22:24, 9 October 2013 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 6 external links on Cylinder-head-sector. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 02:23, 16 August 2017 (UTC)[reply]

Allocation units vs blocks vs clusters and other terms

This article should clarify that "allocation unit", "block", and "cluster" are all terms referring to the same concept on different platforms. And if I'm missing some subtle difference between some of these terms, that should probably also be made clear. Currently different paragraphs use one or two terms and it's not always clear whether or to what extent they are interchangeable. It might be worth noting that some historical systems even used other terms. The term in the TRS-80 world was "granule" and one OS on that platform, NEWDOS/80 even introduced another level of abstraction termed the "lump". — Hippietrail (talk) 02:59, 13 June 2020 (UTC)[reply]

"late 2000s"

It's a little early in the 2000s to be commenting on the "late 2000s" already. Can this be re-worded? I'm really not sure which time period is being referred to:

but many tools for manipulating the master boot record (MBR) partition table still aligned partitions to cylinder boundaries; thus, artifacts of CHS addressing were still seen in partitioning software by the late 2000s 24.196.190.186 (talk) 13:24, 26 August 2022 (UTC)[reply]