Re: [PATCH 1/3] ide: add "ignore_hpa" module parameter

[Frans Pop]

On Tuesday 26 May 2009, Bartlomiej Zolnierkiewicz wrote:
> First time with the introduction of the default IDE HPA behavior of
> always giving the access to the full capacity of a disk and leaving
> decisions about HPA preservation/removal up to the installer & user.
>
> Second time when said distributions switched from IDE to libata (which
> uses the different default behavior as it limits the capacity to
> non-HPA part).

Has there really been something like a deliberate switch?

In my experience with Debian there's been no such thing. ATA has just been 
gradually enabled. (And initially that resulted in quite a mess because 
some devices would be supported by two drivers and the kernel couldn't 
even make up its own mind which one it preferred, resulting in random 
switches between drivers. At least that was resolved at some point.)

However, I must admit that Debian has not handled the IDE-ATA switch very 
well. So far users have mostly been left to deal with any fallout for 
themselves.

> Please note that no fancy sysfs support was needed to prevent the
> problem: both stacks (ide & libata) support HDIO_DRIVE_TASK ioctl which
> can be used to execute commands needed to retrieve/change HPA setting.

I don't really see how that would help. The fact that fancy ioctls exist 
does not mean users or even distros have the knowledge needed to use 
them. IMHO such issues should be dealt with at the level where that 
knowledge is available: the kernel community.

> Moreover the (much needed) work from Tejun doesn't help a tiny bit in
> case of people migrating their *working* setups from IDE to libata

>From what I've seen now that seems the most important case that needs 
supporting, as well as the case where a working setup would migrate from 
IDE with old HPA default to IDE with new HPA default.

Naive thought: wouldn't it be possible to check whether a partition 
overlaps the HPA boundary and warn or even bug out in that case?

> (at least in distro upgrade case this could have been handled by distro
> installer but see above) and hitting the compatibility issue mentioned
> in bug #13365.

At least in the case of Debian there is no such thing as a "distro 
installer" involved in upgrades. Debian only uses its installer for new 
installs, not for upgrades between releases. The last is purely done by 
regular package management.

It's also not sufficient to rely on that anyway because users sometimes do 
install newer upstream kernels (whether because of issues or to help with 
kernel development/testing), which means no distro upgrade is involved.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/