Virginia Wray wrote:
> On 10/20/09 12:35, Sarah Jelinek wrote:
>> Hi Ginnie,
>>
>>>
>>> Jean and I talked about this. The way the extended partition team 
>>> wrote their code they didn't centralize the error codes in one 
>>> location. after each return from libfdisk_init, there is a switch 
>>> statement that processes the return value.  You can see an example of 
>>> this here  
>>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/boot/installgrub/installgrub.c#312.
>>>  
>>>
>>> At the time of our discussion, we decided not to code it this way.  
>>> I'm interested in your thoughts on this.
>>
>> In looking at the way this is used in your pointer, it seems like we 
>> should modify our code to handle the cases where we have invalid 
>> geometry. The "no logical partition" error seems ok to continue from. 
>> The others seem like errors we should handle in a different way. What 
>> is the impact of continuing in your code if we cannot read the 
>> partition due to one of these errors?
>>
>> So, my suggestion is something like this:
>>
>> if ((rval = libfdisk_init(&epp, device_p0, NULL, FDISK_READ_DISK))
>>          != FDISK_SUCCESS) {
>>
>>     switch (rval) {
>>                  /*
>>                  * there is no Solaris logical partition
>>                   */
>>                 case FDISK_EBADLOGDRIVE:
>>                 case FDISK_ENOLOGDRIVE:
>>                     continue;
>>             case FDISK_ENOVGEOM:
>>                  case FDISK_ENOPGEOM:
>>                case FDISK_ENOLGEOM:
>>                 /*
>>                  * Do some error handling and return
>>                  */
>>                 break;
>>             default:
>>                 /*
>>                  * libfdisk_init failed. Do some error
>>                  * error handling and return.
>>                  */
>>                 break;
>>     }
>>
>> Would this work?
>>
>> thanks,
>> sarah
>>
>>
> Hi Sarah -
> 
> I want to reiterate so that I'm sure I'm clear. If the logical drive is 
> bad or no logical drive exists in the extended partition, then it is ok 
> to continue
> iterating through the fdisk partitions on the disk that is being 
> checked. 

I guess I have a question to your question :-).... is it ever possible 
that an extended partition would not contain a logical partition? Also, 
is it possible there could be gaps that would not be a logical partition 
within an extended partition?

I ask because, if we don't find a logical partition at any spot in the 
extended partition, it appears that the code path is to continue, and 
try to read the next partition. It appears based on code examples you 
provided that this is a possibility. It doesn't mean the disk is bad or 
that any partition is bad(based on the way it is coded), simply that 
there is no logical partition at that spot.

If, however, there is a problem with the disk geometry, or
> libfdisk_init fails for some other reason, then  provide an error 
> handling, do not continue iterating through the
> fdisk partitions on the disk that is being checked, and return from the 
> function. In other words, with these problems, we're going to skip the
> disk.

Seems to me if we are in this state we have:

1. a disk with an extended partition defined
2. We are trying to init libfdisk on that disk, to read the logical 
partition data.
3. We fail to do #2 because we have an error.

We should skip the disk. Because if we cannot read it for some error(not 
that there isn't a logical partition) then it isn't likely we can read 
anything else on the disk. However, continuing to move through 
partitions won't likely cause us any issues, as at that point in time 
the call to libfdisk_init should error out similarly, so we won't get 
any data. It is just unnecessary to continue to process the subsequent 
partitions on this disk.

thanks,
sarah
***
> 
> Is that what you're suggesting?
> 
> thx,
> 

Reply via email to