This was approved at today's PSARC meeting. Lawrence Lee wrote:
> 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
