I do appreciate all of your input. Please see my responses below. Larry
gdamore at sun.com > So my questions with this are, how does the end-user who has drives with HPA on them configure them. > > My main fear here is that we are creating yet another knob, with little explanation, and no automation behind it. > But maybe I'm missing something here. If indeed there is no automatic selection behind it, then I fear the end > result will just be more confusion and trouble amongst users. > > It does seem to me that Linux's behavior here is itself a bug. > If the HPA has been explicitly configured, then it seems a poor choice to silently clobber it. I agree that the the Linux behavior should be regarded as a bug, but the Linux folks obviously went to some effort to add the code to disable the feature and removing that code would cripple some of their installed user base. I doubt that they would remove it for us. The bug was originally reported in 2004, at that time a workaround was provided which was to use a utility (DLG toolkit) that was downloadable from one of the disk manufacturers (see bugster for details) that ran on DOS/Windows that allowed the user to set/control the feature. That utility is no longer available, so the workaround no longer works. Recently the install group has run into problem again and raised the priority to P1. So we needed to address it. It was initially believed that WinVT had the same behavior as Linux. The WinVT problems actually turned out to be other errors in fdisk. It has been demonstrated that WinVT uses the HPA as is. sommerfeld at sun.com > This is a "let's pretend the disk is smaller" interface. > > I think this needs to be visible, and probably also settable, through at > least format(1m); ata.conf is not the right granularity for an > administrative interface. See section 4.1 and 4.2 What you are suggesting is certainly possible, but there would be significant impact and risk with changing a drives capacity after the disk labels have been read and capacity is not stored in both the hba, target drivers, and filesystems on that drive. Controlling this feature at attach time has far less risk and the effort is more in line with the frequency of the problems occurence. This is a workaround for a real, but rarely scene problem. I don't see that is sufficient justification for the amount of work required to implement a new ioctl and implement the functionality in format. > > Is there a way to inquire/detect the fact that the HPA has been temporarily > disabled and will be restored on reboot? If so, then perhaps the ata driver > can refuse to report the HPA area to the operating system, regardless of > whether it is enabled or not? We can certainly tell when the drives currently reported capacity is different from it's native capacity. There isn't any way to tell what the setting will be after the next power cycle (except by power cycling the disk). We are not necessarily just switching between a zero value and a non zero value. There is a current setting (which may be any value) and a power on setting which may be any value. So the current setting might be HPA=100 and the power on might be 200. > > Since the details of the HPA are recorded in flash, then I believe if we did the > above thing (detect temporary disabling of HPA and treat it as if the HPA were still active), > then we'd be in good shape across reboots. Yes but.... The power on setting can't be determined, only the current setting. There are other consequences/impacts of not having all OS's on a disk agree on the size of a disk. Example GPT labels write the backup label in the last 33 sectors of the disk if our perceived end of disk was actually in the middle of a linux partition we wouldn't be very nice neighbors. 1.5 TB drives are due in 2008, fdisk has a max capacity of 1TB unless you're really brave about ignoring the sign it in the LBA field. so expect an increase the usage of GPT labels over fdisk labels. There is also an impact on the use of partitions in an fdisk extended partition, when the extended partition extends beyond the end of the disk. > Now it may also be true that there is a desire to manage the presence of the persistent HPA as well. Please keep in mind that this is a rarely seen problem. I do not expect most users to use or even know of the feature, but there are messages written by the driver in /var/adm/messages and there is sufficient documentation in our (proposed) manpage and on the internet in general. If a user is confronted with the problem, they should be able to easily find the documentation and change the drives setting. My expectation is that when a user actually uses this feature they will almost always use HPA="0P"; to permanently disable the HPA and recover normal disk function. Once they have booted the system with that setting, it can be removed from the ata.conf file. Would you like me to emphasize that in the documentation? I am not proposing that we develop Solaris features based on HPA, only that when we are confronted with a disk that has the feature set, that we provide our users with a method of dealing with it. James.McPherson at Sun.COM > Hi Alan and Larry, > how is the customer supposed to know that they should use a > signed integer for the length/size field? See the proposed manpage (bug 6625517) See the limited comments in ata.conf file Larry
