On 02/11/10 01:43 AM, Shidokht Yadegari wrote: > On 02/10/10 03:57, Jan Damborsky wrote: >> Hi Shidokht, >> >> thank you very much for your fast response ! >> Please see my comments in line. >> >> Jan >> >> >> On 02/ 9/10 08:34 PM, Shidokht Yadegari wrote: >>> On 02/09/10 01:25, Jan Damborsky wrote: >>>> Hi Shidokht, >>>> >>>> some time ago, when discussing issue related to >>>> ZFS pools, we touched the topic of concept of alternate slice >>>> in Solaris and OpenSolaris installer - see excerpt from one >>>> of your responses [1]. >>>> >>>> At that time, OpenSolaris installer didn't create ALT slice >>>> and if one was present, it was removed. That meant that >>>> we always ended up without ALT slice present on target disk >>>> which was source of issues in some scenarios - e.g. when >>>> creating mirrored configuration of ZFS pools or installing >>>> S10 on ATA disk which was previously installed with OpenSolaris. >>>> >>>> In current version of installers (due to fix for bug >>>> 13331) if ALT slice is present on the disk (for instance >>>> as a result of creating default VTOC when Solaris2 partition >>>> is created on x86 platform), it is preserved. >>> Hi Jan, >>> >>> This looks right to me. >> >> ok. >> >>> >>>> >>>> We would like to check with you if this is correct and >>>> appropriate behavior or if OpenSolaris installers should >>>> deal with ALT slice in different manner - e.g. if the >>>> installer should make sure that ALT slice is always created >>>> in appropriate scenarios (e.g. ATA/SATA disk handled by cmdk >>>> device driver). >>> >>> My suggestion is that we need to make sure ALT slice is created >>> on cmdk/ata driven disks because >>> >>> 1. zfs mirror issue you mentioned before. format will put an >>> ALT slice on the mirror disk. >>> 2. addbadsec is not yet EOLed. ;-( >>> 3. we need to be consistent across install and other disk >>> partitioning utilities. >> >> >> That sounds reasonable. Let me ask couple of questions related >> to the implementation. >> >> With respect to platforms affected, observations I have done so far >> indicate that only x86 platform is affected - ALT slice is never created >> on Sparc, since it applies only to cmdk(7D) driver which exists only >> on x86 - is it correct ? > > yes. >> >> Is there an easy and stable way to determine if particular disk >> is handled by cmkd, i.e. that it should be equipped with ALT slice ? > > In response to a DKIOCINFO, cmdk/dadk (and pv_cmdk) > advertise the disk with DKC_DIRECT in dki_ctype. And btw so > does the dad driver for sparc.
Thanks ! If I understand correctly, we could check for something like if (dki_ctype == DKC_DIRECT) AND (platform != sparc) Might it be correct ? > >> >> As far as geometry is concerned, when dealing with ALT slice, >> is it safe to assume that ALT slice always occupies cylinders 1-2 ? > That is the default value that the kernel driver assigns but I don't see > any restriction that it has to be there. (need a bit more checking). ok. Playing with format(1M), it seems it also assumes ALT slice starting on cylinder 1, since when I created it on other cylinders, format warned about 'No ALT slice found'. > > >> >> I can see that ALT slice is automatically created as part of >> default VTOC when Solaris partition is created. Are there any >> other scenarios when Solaris takes care of creating ALT slice >> automatically ? > > format when creating a label from scratch or switching from EFI/GPT. ok. > I don't think it will ensure that there needs to be an ALT slice if > it is just updating the VTOC. I agree - as we realized, format also allows to delete ALT slice when invoked in expert mode. > > >> >> >>> >>> The only time that one may have a problem is on disks where >>> opensolaris previously did not include an ALT slice and we are >>> now preserving other slices on that disk which occupy the same >>> space as where alt slice would have. >> >> >> That leads me to more generic question - what should installer do if >> there >> is no space to create ALT slice (e.g. cylinder 1-2 are already >> occupied) ? > > I am not sure. I am assuming the installer currently allows preserving > VTOC slice information on the disk, and that is when we will run into > this problem, > right? Yes. One example when I think we might run into this scenario is when SATA drive is being used in machine where SATA controller is handled by new SATA framework and then that disk is put into another machine for purposes of the installation where SATA controller is handled by cmdk and installer is asked to install into existing slice (no VTOC changes). Since format allows to manipulate disk without ALT slice (it just displays warning that No ALT slice was found), I am wondering if we might do the same in the installer - if cylinders 1-2 are already occupied and thus there is no space to create ALT slice (assuming here that we are not allowed to pick arbitrary starting cylinder), installer would just log warning message and proceed with the installation. >> >> >>> >>>> >>>> Also, as you indicated, the concept of alternate slice on >>>> drives handled by cmdk device driver in Solaris seems to be >>>> outdated and from longer term point of view it is something >>>> which might be removed - as it was done for SCSI or SATA drives >>>> handled by new SATA framework. >>>> Do you think that it might be reasonable to continue with >>>> that longer term effort ? >>> Imho yes. It reduces complexity and it is a feature >>> that I have not seen used in many many years. >> >> Based on this, what you might recommend as a reasonable way >> to proceed with this effort ? Might it be sufficient to file bug >> for this issue or more steps might be needed ? > Of course whoever will take responsibility of the RFE to EOL addbadsec > and friends, > would need to take it to PSARC and think about any potential backwards > compatibility > issues, etc. I am not sure what you are asking here. That is what I was not sure about - thank you for clarifying this. Do you happen to know what might appropriate bug category for filing this RFE ? Thank you very much, Jan
