Guessing the CHS of a block device.

  • Thread starter Thread starter Seongsu Lee
  • Start date Start date
S

Seongsu Lee

Hi,

Is there any way to detect the CHS information of a block device
by only a software in Linux? I think the analysis of elapse time of
reading a block which has various distance of each another.

Any comments or similar tries will be helpful. Thank you in advance.
 
Seongsu Lee said:
Is there any way to detect the CHS information
of a block device by only a software in Linux?

Not really. The problem is that there isnt just one CHS value with
modern hard drives, the S varys in bands across the platter surface
and with other types of block devices like flash drives, there isnt even
any true equivalent to tracks, so there is nothing to detect timing wise.
I think the analysis of elapse time of reading a
block which has various distance of each another.

While true, the problem is that there isnt a true single CHS for modern hard drives.
 
Seongsu said:
Hi,

Is there any way to detect the CHS information of a block device
by only a software in Linux? I think the analysis of elapse time of
reading a block which has various distance of each another.

Any comments or similar tries will be helpful. Thank you in advance.

Modern drives do not have a fixed CHS geometry, period. They do report
a fictitious CHS geometry, though (which may only represent a fraction
of their total size). Modern PC BIOSes use LBA rather than CHS access
for such drives; old BIOSes use the fictitious CHS figures.

Older drives (I'm SWAGging no later than mid-'90s) did have a real CHS
geometry, and IIRC reported it.

Still older drives (probably talking before 1990) had a real CHS
geometry and did not report it (or at least a PC BIOS of the same era
didn't understand any reporting that they did, and required that the
user enter the information manually).

- bill
 
In comp.sys.ibm.pc.hardware.storage Seongsu Lee said:
Is there any way to detect the CHS information of a block device
by only a software in Linux?
I think the analysis of elapse time of
reading a block which has various distance of each another.
Any comments or similar tries will be helpful. Thank you in advance.

You want the physical data? With modern disks you can forget it.
Read-ahead, slim differences between trach-to-track and head-to-head,
diffrerent numbers of sectors in different tracks, different mapping
strategies to linear addresses and other things make measuring these
pretty impossible.

However you can easily get the data from the manufacturers datasheet.
Not that you really need it for anything I can think of. So the
real question is: Why do you want to do this?

Arno
 
Bill Todd said:
Modern drives do not have a fixed CHS geometry, period. They do report
a fictitious CHS geometry, though (which may only represent a fraction
of their total size).
Modern PC BIOSes use LBA rather than CHS access for such drives;

No, they don't. They offer newer services for applications and OSes
to use LBA mode. Those BIOSes still offer the older services too.
The applications and OSes decide what to use.
old BIOSes use the fictitious CHS figures.

They don't *offer* the LBA addressing mode services.
Older drives (I'm SWAGging no later than mid-'90s) did have a real CHS
geometry, and IIRC reported it.
IDE.


Still older drives (probably talking before 1990)

Before IDE and SCSI.
 
By saying 'block device' you're hinting at a logical device such as
portrayed by BIOS.
And since block structured devices have a habit of telling the bios
how their media have been organized you could just query the bios.

So you are really hinting at mechanical block devices like harddrives.

Bingo.
Read 2 single sectors, a (potential) track length apart.
If both sectors are in the same track then to read both it will take exact-
ly the same time as when reading both sectors including those in between.
That is still the case if the second sector is on the next head and the first
sector on that track.
However, if it is the second sector on that track then it will be read imme-
diately as if it was the second sector on the previous head because tracks
are skewed such that all sectors can be read sequentially without any extra
delays. So if the time to read those 2 sectors drops below the time that is
necessary to read all sectors in between then you know they are not in the
same track. By adjusting the 2 sector distance you'll find the exact switch-
over point and voila, you have your track length in sectors. Btw, this still
goes if you start halfway or anywhere in a track and end in the next track
in the cylinder as long as you keep the distance a full track length.

Similarly you should be able to work out the number of platters/heads
by working out the different skews with different platter combinations:
Head switch time is typically several sectors going by before the new head
is ready to read again so you should be able to subtract several sectors if
you skip a head (i.e. double the distance) in your two sectors distance and
still not need an extra rev time to read that second sector. When the se-
quence of checking this for every (potential) head breaks -when a track
change becomes involved- then there you now have your number of heads.

Cylinders, now that is really tedious. You need to find every notch (band in
which the number of sectors per track is constant) change and convert the
number of sectors in every notch/band into cylinders for that notch/band
and add them all up in the end.

Btw, this is basic theory based on harddrive physical.
Converting this into practical program code involves reading more than
just 2 sectors in a track as that takes just takes 8ms (7200 rpm) to
4 ms (15k rpm) and spindle latency (time between issuing the reads and
the first sector actually coming by the head) can almost double that.
You probably also want to measure the MB/s and RPM of the drive to
calculate your sectors_per_track_test starting range.
You also need to figure out how to avoid cacheing and queueing since that
obviously interferes with how the whole physical scenario is to play out.
You want the physical data? With modern disks you can forget it.
Nonsense.

Read-ahead,

That's like saying you can't do benchmarks either. Obviously you can.
Cacheing is easy to avoid, as benchmark practice will show you.
slim differences between trach-to-track and head-to-head,

For sectors per track they don't make a difference.
And as long as they aren't exactly the same they can be differen-
tiated between in number of sectors skewed and detected as such.
diffrerent numbers of sectors in different tracks,

So you know you have to check the whole disk if you want the numbers
for the whole disk, so what.
Tedious, probably not practical, but doable.
different mapping strategies to linear addresses

There aren't any, they are both linear.
The only pitfalls are the user reassigned bad sector replacements, so sing-
le address range tests are not advisable. For measuring accuracy you pro-
bably have to read several revolutions and cylinders at a time anyways.
and other things

Other things huh, impressive.
make measuring these pretty impossible.

Yet benchmarks manage to do access time pretty close too.
Some benchmarks/apps even manage to predict RPM very accurately.
So even with MB/s and the RPM you (approximately) have the sectors
per track calculated.

Babblebot, clueless as always.
However you can easily get the data from the manufacturers datasheet.
Not that you really need it for anything I can think of.
So the real question is: Why do you want to do this?

Because he can, babblebot.
 
Seongsu Lee said:
Is there any way to detect the CHS information of a block device
by only a software in Linux? I think the analysis of elapse time of
reading a block which has various distance of each another.

You could try this, but be aware that:

(a) Track-to-track seek times are smaller than rotational latency.
If you can't figure out how to deal with rotational latency,
you will have to do a very large number of reads to extract
any statistically significant measurement of what causes a seek.

(b) There's random variation in the disk introduced by such things
as temperature compensation. Again this means you'll need an
awful lot of sector reads to learn anything.

(c) Head switch times are too small to measure reliably.

(d) The number of sectors per track varies from point to point on
the drive.

What are you trying to figure out? This doesn't seem a useful thing
to do.

Anton
 
Hey, is that you again, babblebot?

Anton Rang said:
You could try this, but be aware that:
(a) Track-to-track seek times are smaller than rotational latency.
If you can't figure out how to deal with rotational latency,
you will have to do a very large number of reads to extract
any statistically significant measurement of what causes a seek.

Uhuh. And this is helpful how exactly.
There are no seeks in sequential reading.
(b) There's random variation in the disk introduced by such things
as temperature compensation. Again this means you'll need an
awful lot of sector reads to learn anything.

Learn what exactly.
(c) Head switch times are too small to measure reliably.

Uhuh. And how does that differ from track (cylinder) switch times.

Like the babblebot you are providing problems to a solution, a solution that you don't even bother to describe.

And this has what to do with CHS, exactly?
(d) The number of sectors per track varies from point to point on
the drive.

Gee, now where did you learn that.
What are you trying to figure out? This doesn't seem a useful thing
to do.

Babblebot revisited.
 
Folkert said:
Hey, is that you again, babblebot?

Shut up, Folkert. The S/N ratio in c.a.s. has been fairly decent
lately, until you crawled back out from under your rock.

Please crawl back in again.

- bill
 
Shut up, Folkert.

And you are?
The S/N ratio in c.a.s. has been fairly decent lately,

No wonder, when no one in your group was actually able enough to
offer a solution to the OP. No one with even a glimpse of a clue.

Maybe you shut them up too?
 
Buddy said:
And you are?

Someone with a low tolerance for loud-mouthed morons.
No wonder, when no one in your group was actually able enough to
offer a solution to the OP. No one with even a glimpse of a clue.

I addressed his apparent confusion about CHS nearly two weeks ago.
Perhaps you were snoozing and missed it. In any event, since you appear
to have nothing substantive to contribute yourself...

- bill
 
Back
Top