Re: IBM HDAPS things are looking up

Re: IBM HDAPS things are looking up

[Lenz Grimmer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jens!

Thanks for the sample code. I've trimmed the recipient list a bit...

Jens Axboe wrote:

> Perhaps the IDLE or IDLEIMMEDIATE commands imply a head parking, that
> would make sense. As you say, you can hear a drive parking its head.
> Here's a test case, it doesn't sound like it's parking the hard here.

Not here either, but let me check, if I understand this correctly:

> #include <stdio.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <sys/ioctl.h>
> #include <linux/hdreg.h>
> 
> int main(int argc, char *argv[])
> {
> 	char cmd[4] = { 0xe1, 0, 0, 0 };

The "0xe1" in here is what is defined as "WIN_IDLEIMMEDIATE" in hdreg.h,
correct?

> 	int fd;
> 
> 	if (argc < 2) {
> 		printf("%s <dev>\n", argv[0]);
> 		return 1;
> 	}
> 
> 	fd = open(argv[1], O_RDONLY);

Hmm, don't I need to actually have *write* access for sending an ioctl?

> 	if (fd == -1) {
> 		perror("open");
> 		return 1;
> 	}
> 
> 	if (ioctl(fd, HDIO_DRIVE_CMD, cmd))
> 		perror("ioctl");
> 
> 	close(fd);
> 	return 0;
> }

I will give it another try, after clarifying the above questions - maybe
there is a command that will perform the desired task. If not, I guess
we're back at snooping what the Windows driver does here...

Bye,
	LenZ
- --
- ------------------------------------------------------------------
 Lenz Grimmer <lenz@grimmer.com>                             -o)
 [ICQ: 160767607 | Jabber: LenZGr@jabber.org]                /\\
 http://www.lenzg.org/                                       V_V
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCyTcySVDhKrJykfIRAqAEAJ93Fx7EpdtAfoR7ab61D9CDgIFX1ACfekHD
9Dxg1MDYwph+8tQfHicWii8=
=YM7P
-----END PGP SIGNATURE-----

Re: IBM HDAPS things are looking up

[Jens Axboe]

On Mon, Jul 04 2005, Lenz Grimmer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Jens!
> 
> Thanks for the sample code. I've trimmed the recipient list a bit...
> 
> Jens Axboe wrote:
> 
> > Perhaps the IDLE or IDLEIMMEDIATE commands imply a head parking, that
> > would make sense. As you say, you can hear a drive parking its head.
> > Here's a test case, it doesn't sound like it's parking the hard here.
> 
> Not here either, but let me check, if I understand this correctly:
> 
> > #include <stdio.h>
> > #include <unistd.h>
> > #include <fcntl.h>
> > #include <sys/ioctl.h>
> > #include <linux/hdreg.h>
> > 
> > int main(int argc, char *argv[])
> > {
> > 	char cmd[4] = { 0xe1, 0, 0, 0 };
> 
> The "0xe1" in here is what is defined as "WIN_IDLEIMMEDIATE" in hdreg.h,
> correct?

Correct.

> > 	int fd;
> > 
> > 	if (argc < 2) {
> > 		printf("%s <dev>\n", argv[0]);
> > 		return 1;
> > 	}
> > 
> > 	fd = open(argv[1], O_RDONLY);
> 
> Hmm, don't I need to actually have *write* access for sending an ioctl?

No, but you need CAP_SYS_RAWIO capability. So run it as root.

> > 	if (fd == -1) {
> > 		perror("open");
> > 		return 1;
> > 	}
> > 
> > 	if (ioctl(fd, HDIO_DRIVE_CMD, cmd))
> > 		perror("ioctl");
> > 
> > 	close(fd);
> > 	return 0;
> > }
> 
> I will give it another try, after clarifying the above questions - maybe
> there is a command that will perform the desired task. If not, I guess
> we're back at snooping what the Windows driver does here...

I'm not aware of a generally specificed command, it's likely that the
ibm drive has a vendor specific one. Or that one of the idle commands
can be configured to park the drive. Or... I'm not sure you'll find
anything interesting in the windows driver, I would imagine that the
user app is the one issuing the ide command (like the linux equiv would
as well).

-- 
Jens Axboe

Re: IBM HDAPS things are looking up

[Alejandro Bonilla]

Jens Axboe wrote:

>
>That's madness, we can't add a kernel thread for every single little
>silly thing. You don't need to stop any io, you just want to make sure
>that your park request gets issued right after the current io has
>finished.
>  
>
HI,

    For me, the heads have to park so fast. That I would be afraid of a 
kernel panil or something that could happen if you park the head so fast 
that it won't even tell the kernel it did, or because ext3 couldn't 
update or any crazy reason.

    I use a lot a project called laptop_mode, which suspend the hd until 
you do a request to the kernel or the HD and it spins up the HD. I think 
somehow, the kernel is not fast enough to do what we want, I mean, I 
don't see it.

    Imagine you are in starbucks, your laptop is over a 1.2 M table, 
Linus just said that a new kernel is out. So you simply download it, and 
now you are compiling it. But, you invited your kid to Starbucks. And 
while your CPU is at 100% and full throttle HD usage. Then your kid 
trips on the cable or simply pushes the PC out.

    Do you think that the kernel will STOP, HOLD and park the head in 
less than a second? OR on the time we need?

    I would say is a dammed good kernel if it would. (could RTOS, make 
things faster)

Simply send the flames my way if you think I'm totally wrong. Which I 
might be. I really don't know...

.Alejandro

Re: IBM HDAPS things are looking up

[dean gaudet]

On Mon, 4 Jul 2005, Alejandro Bonilla wrote:

>    Do you think that the kernel will STOP, HOLD and park the head in less than
> a second? OR on the time we need?

this is why the windows driver uses heuristics to decide when the laptop 
is possibly unstable and *may* fall soon... because it takes something 
like 700ms to actually park.  (a url floated by with the whitepaper-level 
details at some point.)

btw -- my usual box is a t42p running winxp, and i disable the parking 
code... whatever my normal usage is tends to trigger the parking 
heuristics too readily.  it's a cool idea, but i'm skeptical of its 
real-world value.

as for other details it's trivial to lock the daemon in memory and run it 
at nice -4 to get a head start on parking even when at 100% cpu and under 
memory load.

-dean

Re: IBM HDAPS things are looking up

[Jens Axboe]

On Mon, Jul 04 2005, Alejandro Bonilla wrote:
> Jens Axboe wrote:
> 
> >
> >That's madness, we can't add a kernel thread for every single little
> >silly thing. You don't need to stop any io, you just want to make sure
> >that your park request gets issued right after the current io has
> >finished.
> > 
> >
> HI,
> 
>    For me, the heads have to park so fast. That I would be afraid of a 
> kernel panil or something that could happen if you park the head so fast 
> that it won't even tell the kernel it did, or because ext3 couldn't 
> update or any crazy reason.
> 
>    I use a lot a project called laptop_mode, which suspend the hd until 
> you do a request to the kernel or the HD and it spins up the HD. I think 
> somehow, the kernel is not fast enough to do what we want, I mean, I 
> don't see it.
> 
>    Imagine you are in starbucks, your laptop is over a 1.2 M table, 
> Linus just said that a new kernel is out. So you simply download it, and 
> now you are compiling it. But, you invited your kid to Starbucks. And 
> while your CPU is at 100% and full throttle HD usage. Then your kid 
> trips on the cable or simply pushes the PC out.
> 
>    Do you think that the kernel will STOP, HOLD and park the head in 
> less than a second? OR on the time we need?
> 
>    I would say is a dammed good kernel if it would. (could RTOS, make 
> things faster)
> 
> Simply send the flames my way if you think I'm totally wrong. Which I 
> might be. I really don't know...

You have to wait for the current command to finish, that is the fastest
approach. Aborting it would likely take longer. So what I describe
above, is really as fast as you can issue that command. If you are busy
doing io (writes, from the sound of the above), a single command doesn't
take very long as it goes to cache. Lets just say 10ms as a nice
pessimistic number. On average, that means you have 5ms until that
command finishes and you can issue the park. Submitting the park command
doesn't take long, the time is dominated by the actual park time. Which
is hardware bound, there's not much we can improve there in software.

The actualy accel daemon would run at an appropriate scheduling
priority/class, to ensure good response there.

-- 
Jens Axboe

Re: IBM HDAPS things are looking up

[Lenz Grimmer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Pavel Machek wrote:

> Actually, "spin disk down and keep it down" would be nice for other
> reasons. Taking computer for a jog playing mp3s from ramdisk is
> something I'd like to do...

Isn't that called "laptop-mode" and available already? I remember that
Jens wrote something like that :)

Bye,
	LenZ
- --
- ------------------------------------------------------------------
 Lenz Grimmer <lenz@grimmer.com>                             -o)
 [ICQ: 160767607 | Jabber: LenZGr@jabber.org]                /\\
 http://www.lenzg.org/                                       V_V
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCyZxvSVDhKrJykfIRAkH/AJ9lMUvtxgNdZ6eRHAWGjuTxx5GyqACggF/O
p4V0PprkPpDWX/uFgp8Plgs=
=ffpU
-----END PGP SIGNATURE-----

Re: IBM HDAPS things are looking up

[Pavel Machek]

Hi!

> > Actually, "spin disk down and keep it down" would be nice for other
> > reasons. Taking computer for a jog playing mp3s from ramdisk is
> > something I'd like to do...
> 
> Isn't that called "laptop-mode" and available already? I remember that
> Jens wrote something like that :)

Laptop-mode is "keep hdd spinned down as much as possible" -- to save
battery power. What this project and jogging mp3s need is "keep hdd
spinned down!" -- to prevent hdd damage.
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: IBM HDAPS things are looking up

[Lee Revell]

On Mon, 2005-07-04 at 11:36 -0700, dean gaudet wrote:
> as for other details it's trivial to lock the daemon in memory and run
> it at nice -4 to get a head start on parking even when at 100% cpu and
> under memory load.
> 

Negative nice values are not the correct solution when dealing with RT
constraints like this, you need SCHED_FIFO.  You can't afford the chance
that the scheduler could decide to run another task due to some internal
heuristic.

Lee

Re: IBM HDAPS things are looking up

[Alejandro Bonilla]

Bodo Eggert wrote:

>Clemens Koller <clemens.koller@anagramm.de> wrote:
>
>  
>
>>Well, sure, it's not a notebook HDD, but maybe it's possible
>>to give headpark a more generic way to get the heads parked?
>>    
>>
>
>I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
>which the park command would seek. Maybe you could do something similar
>and park the head on the last cylinder if the other options fail.
>  
>
This makes me wonder... If you replace the internal HD with a non IBM or 
IBM supported Hard Drive, will it still park the head and will it 
support all the stuff?

.Alejandro

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Bodo Eggert]

Clemens Koller <clemens.koller@anagramm.de> wrote:

> Well, sure, it's not a notebook HDD, but maybe it's possible
> to give headpark a more generic way to get the heads parked?

I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
which the park command would seek. Maybe you could do something similar
and park the head on the last cylinder if the other options fail.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Jens Axboe]

On Fri, Jul 08 2005, Bodo Eggert wrote:
> Clemens Koller <clemens.koller@anagramm.de> wrote:
> 
> > Well, sure, it's not a notebook HDD, but maybe it's possible
> > to give headpark a more generic way to get the heads parked?
> 
> I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
> which the park command would seek. Maybe you could do something similar
> and park the head on the last cylinder if the other options fail.

Yeah, in ancient times you would simply issue a SEEK to the landing zone
and the drive would park. Those days are long gone.

The SEEK is just a hint anyways, with the sophisticated caching that
drives do today I wouldn't rely on it doing anything reliable.

-- 
Jens Axboe

Re: IBM HDAPS things are looking up

[Jens Axboe]

On Thu, Jul 07 2005, Alejandro Bonilla wrote:
> Bodo Eggert wrote:
> 
> >Clemens Koller <clemens.koller@anagramm.de> wrote:
> >
> > 
> >
> >>Well, sure, it's not a notebook HDD, but maybe it's possible
> >>to give headpark a more generic way to get the heads parked?
> >>   
> >>
> >
> >I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
> >which the park command would seek. Maybe you could do something similar
> >and park the head on the last cylinder if the other options fail.
> > 
> >
> This makes me wonder... If you replace the internal HD with a non IBM or 
> IBM supported Hard Drive, will it still park the head and will it 
> support all the stuff?

Depends, the drive must support the IDLE_IMMEDIATE unload subfeature, as
described in ata7.

-- 
Jens Axboe

Re: IBM HDAPS things are looking up (was: Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer))

[Vojtech Pavlik]

On Fri, Jul 08, 2005 at 02:56:08AM +0200, Bodo Eggert wrote:

> Clemens Koller <clemens.koller@anagramm.de> wrote:
> 
> > Well, sure, it's not a notebook HDD, but maybe it's possible
> > to give headpark a more generic way to get the heads parked?
> 
> I remember my old MFM HDD, which had a Landing Zone stored in the BIOS to
> which the park command would seek. Maybe you could do something similar
> and park the head on the last cylinder if the other options fail.
 
This is not really a good idea. It worked for the old drives, because
you weren't supposed to move them around.

The shock when the machine hits the ground will cause the head to move
anyway and bounce across the whole surface.

Real parking makes a click because the head is moved outside the surface
and locked in that position.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR