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. > > 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). > > 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. I don't think it will ensure that there needs to be an ALT slice if it is just updating the VTOC. > > >> >> 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? > > >> >>> >>> 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. --shidokht
