[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