Hi Jan, On 02/11/10 00:43, Jan Damborsky wrote: > On 02/11/10 01:43 AM, Shidokht Yadegari wrote: >> On 02/10/10 03:57, Jan Damborsky wrote: ...
>> >>> >>> 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 ? Yes or you can have it inside an ifdef. ... > >>> >>>> >>>> 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. Sounds reasonable to me. > >>> >>> >>>> >>>>> >>>>> 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 ? solaris/utility/diskformat sounds good to me. The fix will require changes to cmdk, cmlb, pv_cmdk, format, addbadsec, header files,... (and installer ;-)) best regards, --shidokht > > Thank you very much, > Jan >
