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-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
