1 |
On Sat, Feb 27, 2010 at 8:53 AM, walt <w41ter@×××××.com> wrote: |
2 |
> On 02/26/2010 06:23 PM, BRM wrote: |
3 |
>> |
4 |
>> ----- Original Message ---- |
5 |
>> |
6 |
>>> From: Mark Knecht<markknecht@×××××.com> |
7 |
>>> On Fri, Feb 26, 2010 at 4:09 PM, walt wrote: |
8 |
>>>> |
9 |
>>>> Is there really any need for the "cylinder" these days? |
10 |
> |
11 |
>>> Who cares what cylinder it's on, and |
12 |
>>> who cares which head is getting the data? It doesn't matter to us |
13 |
>>> users... |
14 |
> |
15 |
>> ...Boot Loader writers (e.g. grub) need to care about it since LBA |
16 |
> |
17 |
>> is not quite available right away - you have to focus on other things |
18 |
>> until you can load the rest of the boot loader. |
19 |
> |
20 |
> Ah, this may be a big part of what's confusing me because I've done a |
21 |
> lot of playing around with grub. |
22 |
> |
23 |
> At what point *does* LBA become available, and who makes it available? |
24 |
> Is this one of those stupid BIOS things? |
25 |
> |
26 |
|
27 |
I don't think that it's specifically a BIOS thing, but BIOS is |
28 |
involved at least on older machines. |
29 |
|
30 |
LBA is always 'available' (as far as I know) because it's in the hard |
31 |
drive. It's the way the drive expects the system to talk to it. The |
32 |
issue is how do the software layers talk with the drive. |
33 |
|
34 |
In the case of very old PC hardware, and I think it still exists for |
35 |
compatibility reasons, programs used to use a IBM BIOS call - Int13 I |
36 |
think - to talk to the drive at all. I'm not a software guy, and |
37 |
certainly not an IBM BIOS assembly language guy, but it may be that |
38 |
the Int13 call to BIOS required CHS. I don't know. |
39 |
|
40 |
Basically you have to make some sort of call to find the drive and get |
41 |
things moving. If BIOS enables LBA under the hood, which I expect it |
42 |
does these days, then the Int13 call using CHS gets converted to LBA |
43 |
and sent across the cable. The drive is however (I think) ALWAYS |
44 |
responding to LBA. There's not a lot of reason for them to support |
45 |
anything else excpet for internal testing. |
46 |
|
47 |
Note that since CHS to LBA conversion is just a bunch of integer |
48 |
multiples and adds if the system BIOS takes an Int13 call with CHS as |
49 |
input it's simple for it to convert it to LBA, and since the important |
50 |
part is sector alignment which is the least significant part it's the |
51 |
one that most closely matches with the numbers in the LBA. |
52 |
|
53 |
I'm pretty sure that once your system starts booting the consistent |
54 |
use of LBA through the whole stack happens as the kernel gets itself |
55 |
and appropriate drivers loaded, but again, this is all supposition on |
56 |
my part. Once those are up and running it's probably LBA completely |
57 |
and CHS isn't important. Note that for big drives it seems that fdisk |
58 |
will __always__ tell me the drive has 63 sectors/track and 255 heads |
59 |
but I sincerely doubt that's true physically. |
60 |
|
61 |
Hope this helps, and I hope I'm not too far off base. Read more here |
62 |
and help me understand better: |
63 |
|
64 |
http://en.wikipedia.org/wiki/Logical_block_addressing |
65 |
|
66 |
http://en.wikipedia.org/wiki/INT13 |
67 |
|
68 |
Cheers, |
69 |
Mark |