lkml.org 
[lkml]   [2000]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: reading 1 hardsector size, not one block size
On Sat, Sep 30, 2000 at 01:47:48AM -0700, Andre Hedrick wrote:
> On Sat, 30 Sep 2000, Alexander Viro wrote:
>
> > How about /dev/hda? If you are talking about absolute block addresses you
> > are way below the partitioning level.
>
> But are you beyond what the detected capacity of the drive?

That, again, is the IDE driver issue, not the FS layer's. If you want to
access the extra data beyond the reported capacity (which was hidden by
BIOS say for hibernation), you need the IDE driver to report the extra
capacity to the rest of the kernel.

It's not important what the drive says, it's important what your IDE
driver says to the rest of the kernel.

> > Yes, it can, if your driver sets blksize_size correctly. _All_ information
> > about device size is taken from that array and it's driver's business to
> > put there whatever it believes to be the device size.
>
> But because of the nature of your request and the method of opening the
> device, would that not just wrap around the detected capacity?

No. It'll solicit 'read request beyond end of device' messages in dmesg.
And the request will of course fail. Beyond the capacity reported to the
kernel by the IDE driver. But that's all in your power.

> Now we are closer. Openning a device even raw and going through the drive
> will prevent you from getting there, sorry. That is how it works. The
> top level of the driver that mates with the list_head is bound and limited
> to what it found.

To what you told it when you initialized the device.

> But there is a transfer limit per request.

What has this to do with the rest?

> So you hit the limit of the known/reported drive, provide you did not
> crash the kernel by lying to it, do the partition tables remain in tack?
> If the fall appart because of false boundaries we have a bigger mess.

Yes. Why not? The partition tables don't need to change after adding
some extra blocks to the drive at the end.

****

Really, there is no problem with Linux accessing some extra areas hidden
by the BIOS (via the new IDE commands) or the firmware on Linux side.

The only trouble I believe you can get into:;

* The area can be used by BIOS to save a hardcopy of the system memory to it
during hibernation. You lose all data in the area each time your
hibernate your notebook.

* The area may be password protected (within the drive), and you may need to
guess the password to get there.

Anyway, I believe that it'd be good to report the REAL geometry to the
user, but also the faked one so that he sees what's happening. Possibly
allowing him to enable the full capacity say by using the kernel command
line.

--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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