"Arno Wagner" <me.TakeThisOut@privacy.net> wrote in message news:5a472mF2nqu51U1@mid.individual.net
> In comp.sys.ibm.pc.hardware.storage Seongsu Lee <senux.TakeThisOut@senux.com> wrote:
> > Hi,
> > Is there any way to detect the CHS information of a block device
> > by only a software in Linux?
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.
> > I think of analysis of elapsed time of reading blocks which have
> > various distance of each another.
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.
> > Any comments or similar tries will be helpful. Thank you in advance.
> 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.
>
> Arno >> Stay informed about: Guessing the CHS of a block device. 
FAQ
Profile
Private Messages
Log in
