[lustre-devel] adding IOCTL for ping

[Olaf Weber]

On 16-09-15 17:24, Patrick Farrell wrote:
> A further thought: wouldn't an ioctl be unusable on servers?

Presumably it would use the /dev/lnet device file, like the other ioctls in
libcfs/include/libcfs/libcfs_ioctl.h.

Olaf

> ________________________________________
> From: Simmons, James A. [simmonsja at ornl.gov]
> Sent: Wednesday, September 16, 2015 10:16 AM
> To: Ben Evans; Patrick Farrell; Christopher J. Morrone; lustre-devel at lists.lustre.org
> Subject: RE: [lustre-devel] adding IOCTL for ping
>
>> My understanding is that adding new proc interfaces is discouraged by
>> upstream linux.
>
> Please no new ioctls.
>
> On 9/15/15, 5:12 PM, "Patrick Farrell" <paf at cray.com> wrote:
>
>> Hmmm.  What about a proc interface instead?  This feels - to me - better
>> suited to that, since it's a control that isn't part of the I/O path in
>> any way.
>> ________________________________________
>> From: lustre-devel [lustre-devel-bounces at lists.lustre.org] on behalf of
>> Ben Evans [bevans at cray.com]
>> Sent: Tuesday, September 15, 2015 3:53 PM
>> To: Christopher J. Morrone; lustre-devel at lists.lustre.org
>> Subject: Re: [lustre-devel] adding IOCTL for ping
>>
>> You¹re correct, targets and client Ids would probably be better.  I was
>> simply thinking that it would be a relatively straightforward piece of
>> code to write that could add some good flexibility into Lustre.  Combine
>> it with an "X is dead, evict it² IOCTL and you could probably do quite a
>> bit of good, especially if you¹ve got a management system that is also
>> monitoring aliveness, locations of targets, etc.
>>
>> -Ben Evans
>>
>> On 9/15/15, 4:37 PM, "lustre-devel on behalf of Christopher J. Morrone"
>> <lustre-devel-bounces at lists.lustre.org on behalf of morrone2 at llnl.gov>
>> wrote:
>>
>>> Maybe there is just not enough detail in the proposal, but I am not
>>> seeing why associating this with NIDs is the right way to go.  I believe
>>> that the RAS work that would use the gossip protocol dealt, at least in
>>> part, with higher level concepts like targets.  The existing ptlrpc
>>> pinger pings targets, not NIDs.  That is one of the problematic design
>>> points of the existing system, that when N OSTs live on the same node
>>> clients need to send N pings to the same node.
>>>
>>> Chris
>>>
>>> On 09/15/2015 08:04 AM, Ben Evans wrote:
>>>> Would there be any interest in adding an IOCTL to update the ping
>>>> time/status for a particular NID?
>>>>
>>>> This should allow for implementation of a pinger in userspace which
>>>> updates the kernel on the status of various NIDs, and if I understand
>>>> the ping code well enough, would greatly curtail any pings that is sent
>>>> by the kernel.
>>>>
>>>> This might allow for things like Eric¹s gossip implementation to simply
>>>> bolt on top of Lustre without any internal kernel changes, or for
>>>> integration of external monitoring systems to tell Lustre that
>>>> failovers
>>>> have occurred, etc.
>>>>
>>>> -Ben Evans
>>>>
>>>>
>>>> _______________________________________________
>>>> lustre-devel mailing list
>>>> lustre-devel at lists.lustre.org
>>>> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>>>>
>>>
>>> _______________________________________________
>>> lustre-devel mailing list
>>> lustre-devel at lists.lustre.org
>>> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>>
>> _______________________________________________
>> lustre-devel mailing list
>> lustre-devel at lists.lustre.org
>> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>


-- 
Olaf Weber                 SGI               Phone:  +31(0)30-6696796
                            Veldzigt 2b       Fax:    +31(0)30-6696799
Sr Software Engineer       3454 PW de Meern  Vnet:   955-6796
Storage Software           The Netherlands   Email:  olaf at sgi.com