[lkml]   [2000]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: reading 1 hardsector size, not one block size

On Fri, 29 Sep 2000, Andre Hedrick wrote:

> Yes all OEM's do this because they need everything to look the same.
> This is why you may get a replacement drive that is in reality a 30GB
> drive but because you had a 15GB drive originally, that is the capacity of
> the new drive. It has been "de-stroked" by half.
> Now lets install the Linux on this 100 sector drive and tell it that it is
> only 90 sectors in size. Linux can only access that which it knows about
> via the FS. Thus accessing the drive by the FS will restrict you access
> to all regions of the drive.

??? If "FS" means "filesystem" - it couldn't care less. If your driver can
give these blocks some numbers and is ready to serve requests - fine,
filesystem will neither know nor care about the way you are doing that.
For all it cares you might have a _really_ big roll of paper tape and sit
there punching the data with a toothpick.

> If we match head and tails (we will need to soon).
> D(0) and D(100) need to match.
> This is a backup sector, in case D(0) gets wacked, but a Broken Pane.
> The BIOS/OS could recover with a redirected look.
> Now O(101)->O(110) is were DIAG records by the OEM are keep and there is
> no way to get then with out access the OEM subset of the MAN vender unique
> access commands.
> Now back to D(91)->D(99) are buffer sectors or OEM public data access for
> what ever they want.
> Cheers,
> Andre Hedrick
> The Linux ATA/IDE guy
> If you are confuse, good, this is where they want us to be, but I
> understand the issues, and will continue to help decode the lingo.

It would help if you started with decoding TLA and TLAs...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.050 / U:1.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site