Thanks, I had called in and was listening. Larry
Alan Perry wrote: > 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 > >
