[Lustre-devel] moving obd_fail_check to libcfs

[Lustre-devel] moving obd_fail_check to libcfs

[Nic Henke]

Would there be any objection to a patch that'd move the current
obdclass-centric obd_fail_check and friends to libcfs ? I'd like to be
able to use the same logic inside LNET and our new LND without
replicating the code.

I'm thinking it would need to be renamed to CFS_FAIL_CHECK as well.

Thoughts or suggestions?

Nic

[Lustre-devel] moving obd_fail_check to libcfs

[Robert Read]

I don't think libcfs currently initializes any proc entries, so it's  
not clear how you will set obd_fail_loc.  In theory libcfs should just  
thin library of porting primitives, and things like logging and  
fail_check should be in a layer just above libcfs which could have a  
management interface.    So far we've just put some extra low-level  
functionality into libcfs, but at some point it should be refactored.  
I think when we need to add initialization code and an interface is  
that point.

robert


On Feb 22, 2009, at 8:15 PM, Nic Henke wrote:

> Would there be any objection to a patch that'd move the current
> obdclass-centric obd_fail_check and friends to libcfs ? I'd like to be
> able to use the same logic inside LNET and our new LND without
> replicating the code.
>
> I'm thinking it would need to be renamed to CFS_FAIL_CHECK as well.
>
> Thoughts or suggestions?
>
> Nic
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel

[Lustre-devel] moving obd_fail_check to libcfs

[Eric Barton]

Seems a fine thing to do - lets see the patch...

    Cheers,
              Eric

> -----Original Message-----
> From: lustre-devel-bounces at lists.lustre.org [mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of Nic Henke
> Sent: 22 February 2009 5:16 PM
> To: lustre-devel at lists.lustre.org
> Subject: [Lustre-devel] moving obd_fail_check to libcfs
> 
> Would there be any objection to a patch that'd move the current
> obdclass-centric obd_fail_check and friends to libcfs ? I'd like to be
> able to use the same logic inside LNET and our new LND without
> replicating the code.
> 
> I'm thinking it would need to be renamed to CFS_FAIL_CHECK as well.
> 
> Thoughts or suggestions?
> 
> Nic
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel

[Lustre-devel] moving obd_fail_check to libcfs

[Eric Barton]

Although I could agree that there should be levels of abstraction
above libcfs, it is, de facto, the place we put _all_ generic code
- not just stateless porting primitives, but everything that can be
used everywhere.

I don't actually think of obd_fail_check as inexorably bound with
/proc.  But since that's the current implementation, it's probably
my oversight not to have shared that sense of direction.

Nic, is the patch totally /proc - centric?  Wangdi is doing the work
to remove /proc-ness and make our tuneables, configurables and monitoring
more portable.  He needs to be involved...

    Cheers,
              Eric

> -----Original Message-----
> From: lustre-devel-bounces at lists.lustre.org [mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of Robert Read
> Sent: 23 February 2009 11:11 AM
> To: Nic Henke
> Cc: lustre-devel at lists.lustre.org
> Subject: Re: [Lustre-devel] moving obd_fail_check to libcfs
> 
> I don't think libcfs currently initializes any proc entries, so it's
> not clear how you will set obd_fail_loc.  In theory libcfs should just
> thin library of porting primitives, and things like logging and
> fail_check should be in a layer just above libcfs which could have a
> management interface.    So far we've just put some extra low-level
> functionality into libcfs, but at some point it should be refactored.
> I think when we need to add initialization code and an interface is
> that point.
> 
> robert
> 
> 
> On Feb 22, 2009, at 8:15 PM, Nic Henke wrote:
> 
> > Would there be any objection to a patch that'd move the current
> > obdclass-centric obd_fail_check and friends to libcfs ? I'd like to be
> > able to use the same logic inside LNET and our new LND without
> > replicating the code.
> >
> > I'm thinking it would need to be renamed to CFS_FAIL_CHECK as well.
> >
> > Thoughts or suggestions?
> >
> > Nic
> > _______________________________________________
> > Lustre-devel mailing list
> > Lustre-devel at lists.lustre.org
> > http://lists.lustre.org/mailman/listinfo/lustre-devel
> 
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel

[Lustre-devel] moving obd_fail_check to libcfs

[di wang]

Hello,
Eric Barton wrote:
> Although I could agree that there should be levels of abstraction
> above libcfs, it is, de facto, the place we put _all_ generic code
> - not just stateless porting primitives, but everything that can be
> used everywhere.
>
> I don't actually think of obd_fail_check as inexorably bound with
> /proc.  But since that's the current implementation, it's probably
> my oversight not to have shared that sense of direction.
>
> Nic, is the patch totally /proc - centric?  Wangdi is doing the work
> to remove /proc-ness and make our tuneables, configurables and monitoring
> more portable.  He needs to be involved...
>
>   
Yes, after we have our own /proc stuff in lustre, which might be land to 
HEAD in 2 or 3 weeks. All the new proc stuff is implemented in libcfs 
layer, then we will move as much as obd proc stuff(obd lprocfs layer) to 
libcfs layer, then they(include obd_fail_check) can be shared with LNET.

The only difference for those sysctl parameters is that you may not use 
/etc/sysctl.conf to control them anymore, and lctl set_param is the only 
interface here.

Actually, you can also move this now. but it means you need move those 
obd proc api to libcfs layer,  which  might  not  be  small  amount  of  
work.

Thanks
WangDi
>     Cheers,
>               Eric
>
>   

[Lustre-devel] moving obd_fail_check to libcfs

[Nicholas Henke]

di wang wrote:
> Hello,
> Eric Barton wrote:
>> Although I could agree that there should be levels of abstraction
>> above libcfs, it is, de facto, the place we put _all_ generic code
>> - not just stateless porting primitives, but everything that can be
>> used everywhere.
>>
>> I don't actually think of obd_fail_check as inexorably bound with
>> /proc.  But since that's the current implementation, it's probably
>> my oversight not to have shared that sense of direction.
>>
>> Nic, is the patch totally /proc - centric?  Wangdi is doing the work
>> to remove /proc-ness and make our tuneables, configurables and monitoring
>> more portable.  He needs to be involved...

Not totally, no - just the user-space data manipulation. Once that variable is 
set, the code is pretty agnostic.

> Yes, after we have our own /proc stuff in lustre, which might be land to 
> HEAD in 2 or 3 weeks. All the new proc stuff is implemented in libcfs 
> layer, then we will move as much as obd proc stuff(obd lprocfs layer) to 
> libcfs layer, then they(include obd_fail_check) can be shared with LNET.
> 

Is there a branch name I could checkout to look at this ? I'd like to make sure 
the fail_loc move would be easy to tie into that.

> The only difference for those sysctl parameters is that you may not use 
> /etc/sysctl.conf to control them anymore, and lctl set_param is the only 
> interface here.
> 
> Actually, you can also move this now. but it means you need move those 
> obd proc api to libcfs layer,  which  might  not  be  small  amount  of  
> work.

It isn't too bad - they use the CFS_PROC_PROTO and not all of the lprocfs_XXX() 
functionality.

It should like this would have a limited lifetime in 1.6.X and 1.8.X, but I'm 
fine with that. That gives us a bit of time :-)

Nic

[Lustre-devel] moving obd_fail_check to libcfs

[di wang]

Hello,

Nicholas Henke wrote:
>
> Is there a branch name I could checkout to look at this ? I'd like to 
> make sure the fail_loc move would be easy to tie into that.
It is in the b_hd_params, and you can also check bug 15384.

Thanks
WangDi
>> The only difference for those sysctl parameters is that you may not 
>> use /etc/sysctl.conf to control them anymore, and lctl set_param is 
>> the only interface here.
>>
>> Actually, you can also move this now. but it means you need move 
>> those obd proc api to libcfs layer,  which  might  not  be  small  
>> amount  of  work.
>
> It isn't too bad - they use the CFS_PROC_PROTO and not all of the 
> lprocfs_XXX() functionality.
>
> It should like this would have a limited lifetime in 1.6.X and 1.8.X, 
> but I'm fine with that. That gives us a bit of time :-)
>
> Nic
>

[Lustre-devel] moving obd_fail_check to libcfs

[Nicholas Henke]

Nic Henke wrote:
> Would there be any objection to a patch that'd move the current
> obdclass-centric obd_fail_check and friends to libcfs ? I'd like to be
> able to use the same logic inside LNET and our new LND without
> replicating the code.
> 
> I'm thinking it would need to be renamed to CFS_FAIL_CHECK as well.
> 
> Thoughts or suggestions?
> 
> Nic

For those of you playing the at-home game, bug 18750 is filed for this.

Nic