[Ocfs2-tools-devel] [PATCH 4/6] O2info: Add running codes for '--fs-features'.

tristan tristan.ye at oracle.com
Mon Apr 26 00:48:14 PDT 2010


Joel Becker wrote:
> On Mon, Apr 26, 2010 at 10:38:51AM +0800, tristan wrote:
>   
>> I loved your new solutions;), how about we incorporate solution #2 and #3?
>>
>> We do it mostly like solution #3, but also returning successful
>> FILLED count by make info.info_count as 'in/out'.
>>     
>
> 	I don't like it, because we are basically returning error codes
> in two places.  That's not nice ;-)
>
>   
>> 1. rc == 0, info_count == full_count: all requests get successfully
>> handled, no need to check FL_ERROR.
>>
>> 2. rc == 0, info_count < full_count: means some unknown request
>> didn't get filled, no need to check FL_ERROR.
>>
>> 3. rc != 0: real error in kernel happens, if all FL_ERROR were ok in
>> each request, we're sure the error happened in ioctl() before or
>> after real request filling, otherwise, the error should be in the
>> operation of each request handling.
>>     
>
> 	Think about coding this up.  Just like my pseudocode for
> solution #2, it's ugly for every caller to do.  Each operation in o2info
> will have a bunch of ugly boilerplate.
>
>   
>> with above scheme, I've had another concern:
>>
>> Should we immediately return the ioctl(2) when hitting error in #N
>> request(N< inf_count), or we continuously to handle the rest
>> requests by just simply set the FL_ERROR of #N request?
>>     
>
> 	If you have scheme #3, you continue until the end of the request
> list.  It's like async I/O.  The error belongs to the request, not the
> ioctl(2) call.
>   

So I loved the #3 solution:-)

ioctl(2) only returns an error when error occurs before or after 
requests handling.


> Joel
>
>   




More information about the Ocfs2-tools-devel mailing list