[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Sector value off by one when using chs units

From: Graeme Hewson
Subject: Sector value off by one when using chs units
Date: Sat, 19 Mar 2011 19:21:36 +0000
User-agent: KMail/1.9.10

When units are set to chs, parted accepts and prints sector numbers on the 
assumption that they index from 0. In fact, sector numbers in CHS values 
should index from 1 (unlike cylinder and head numbers, which do index from 
0). Of course, in the context of LBA, indexing sectors from 0 is correct.

I found this message in the bug-parted list from September 2004: 

Here the author, a parted developer, wrote:

> I think it is stupid to count [sectors] from 1.  I unilaterally
> decided to count from 0 (just like cylinders and heads are).

Well, I (and I suspect many other people) "just know" what I asserted above. 
In the interests of getting parted changed, I've made an attempt to find the 
source documentation.

The original writer to the above thread (who submitted a patch) referred to 
http://www.win.tue.nl/~aeb/linux/Large-Disk-3.html as providing an instance 
of the normal formula for translating CHS to LBA, "c*H*S + h*S + (s-1)".

That's an impressive document, but not authoritative. Even more impressive, 
but again, not ultimately authoritative, is this: 

This thorough examination of the Windows 7 MBR provides a typical example, 
showing the first partition starting at (LBA/relative) sector 2048 or CHS 
0,32,33, implying that CHS sectors start at 1: 
http://mirror.href.com/thestarman/asm/mbr/W7MBR.htm#INTRO. I tested parted on 
a Windows 7 MBR, and parted printed 0,32,32.

quotes from the ATA-2 document:

> LBA = ( (cylinder * heads_per_cylinder + heads ) * sectors_per_track ) + 
sector - 1

The ATA-2 document is a publication of the INCITS T13 Technical Committee: 
http://www.t13.org which "is responsible for all interface standards relating 
to the popular AT Attachment (ATA) storage interface utilized as the disk 
drive interface on most personal and mobile computers today." Unfortunately, 
the standards are not free, even if the relevant standard is still available 
for purchase. However, some draft documents remain on the public Internet.

A proposed draft of ATA/ATAPI-5, dated 25 September 1998, is at 
A later working draft, dated 11 May 1999, is on the related T10 (SCSI) 
Technical Committee's Web site: 
http://www.t10.org/t13/project/d1321r1-ATA-ATAPI-5.pdf. These documents 
state, in section 6.2 (Page 19):

"A CHS address is made up of three fields: the sector number, the head number, 
and the cylinder number. Sectors are numbered from 1 to the maximum value 
allowed by the current CHS translation but shall not exceed 255. Heads are 
numbered from 0 to the maximum value allowed by the current CHS translation 
but shall not exceed 15. Cylinders are numbered from 0 to the maximum value 
allowed by the current CHS translation but cannot exceed 65,535."

Note that this is talking about the drive doing the translation, for 
compatibility purposes, between its native LBA addressing and the host's CHS 
addressing. ATA/ATAPI-6 obsoleted CHS translation, as the draft at 
(dated 26 February 2002) says in section 6.2 (Page 22): "In standards 
ATA/ATAPI-5 and earlier, a CHS translation was defined. This translation is 
obsolete but may be implemented as defined in ATA/ATAPI-5." 


So I hope I've demonstrated that CHS sectors indeed index from 1. It's not 
tidy, it's not elegant, but it's a published, albeit obsolete, standard, and 
not a matter of opinion.

Please could the patch referred to above be considered? Maybe 
http://parted.alioth.debian.org/cgi-bin/trac.cgi/ticket/218 is also relevant.

It's a small point, and becoming less and less relevant, of course, but there 
are enough quirks and pitfalls in the area that we don't need an avoidable 

Whether or not the code is changed, I suggest the manual should be updated to 
make clear the distinction between CHS and LBA sector numbering.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]