[Lustre-devel] (no subject)

[Lustre-devel] (no subject)

[sethpn at gmail.com]

Is there any Lenny packaged with Lustre 1.6.7? This will be great!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20090327/f7bcc52e/attachment.htm>

[Lustre-devel] (no subject)

[di.wang]

Hello, Michael

There is a logfile parser script in the attachment, which was written by 
Eric.

This script is very simple, but it should help you understand how we 
retrieve time step information from lustre debug log. On the server 
side, if you enable rpc_trace log, whenever the request arrive/start 
being processed/end of processing, there will be corresponding records 
being written into the debug log. Basically, you can get all the time 
step information from these records (actually only two of these records 
would be enough).


a. 
00000100:00100000:0.0:1272313858.472660:0:31581:0:(service.c:1625:ptlrpc_server_handle_request()) 
Handling RPC pname:cluuid+ref:pid:xid:nid:opc 
ll_mgs_00:7d4fb15c-1b1c-295f-e466-ea7d77089b52+10:4055:x1334115493386242:12345-0 at lo:400

This record means the req will being handled, so you can get the start 
time stamp(1272313858.472660) operation type (opc: 400, ping), xid 
(1334115493386242), client nid(12345-0 at lo) and so on.

b. 
00000100:00100000:0.0:1272313858.472687:0:31581:0:(service.c:1672:ptlrpc_server_handle_request()) 
Handled RPC pname:cluuid+ref:pid:xid:nid:opc 
ll_mgs_00:7d4fb15c-1b1c-295f-e466-ea7d77089b52+9:4055:x1334115493386242:12345-0 at lo:400 
Request procesed in 45us (77us total) trans 0 rc 0/0

This record means the req is already being handled, so you can get the 
end time stamp(1272313858.472687), operation type (opc: 400, ping), xid 
(1334115493386242), client nid(12345-0 at lo) and so no.

Note: (77us total) means how long it takes from the request arriving to 
the end of processing. so you can also get the request arriving time 
stamp here by (1272313858 - 77 = 1272312781).


So with these information you can draw the graph Eric mentioned in his 
email. If you have any questions, please let me know.

Thanks
WangDi


Eric Barton wrote:
>
> ------------------------------------------------------------------------
>
> Subject:
> RE: Visualising Lustre RPCs
> To:
> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" 
> <Tom.Wang@Sun.COM>
>
> To:
> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" 
> <Tom.Wang@Sun.COM>
> CC:
> <lustre-devel@lists.lustre.org>, "Galen M. Shipman" <gshipman@ornl.gov>
>
>
> Michael,
>
> The previous Lustre RPC visualisation effort I mentioned at the LUG 
> used the
>
> Lustre debug log entries of type D_RPCTRACE. We disabled all but these
>
> log messages and then used the Lustre debug daemon to collect them while
>
> we ran I/O tests. We then ran a simple logfile parser which used just 
> the log entries
>
> for request arrival?
>
> , start of processing and end of processing to graph request
>
> queue depth (arrival->end) and the number of requests being serviced 
> by type
>
> over time ? e.g?
>
> read3d
>
> ?which shows request queue depth (vertical) over time (axis labelled 
> 20-25) by
>
> server (axis labelled 0-80).
>
> *From:* Michael Kluge [mailto:Michael.Kluge at tu-dresden.de]
> *Sent:* 17 April 2010 6:26 AM
> *To:* Galen M. Shipman; Eric Barton
> *Subject:* Visualising Lustre RPCs
>
> Hi Galen, Eric,
>
> in order to get this little project started, I think what I need at 
> first to
>
> write a prototype for a converter are the following things:
>
> A set of test traces collected on maybe a handful of clients and some 
> servers
>
> is probably a good point to start with. It would be even better if we know
>
> what is in this traces so that we have an expectation what kind of things
>
> we want to see on the Vampir displays. This little program that Eric 
> mentioned
>
> that can read the trace file would be very helpful as well. And as the 
> last
>
> idea I have right now, a technical contact. I might come up with a couple
>
> of question after I have taken the first look onto the original trace 
> data
>
> and before I start writing code.
>
> Regards, Michael
>
>
> -- 
>
> Michael Kluge, M.Sc.
>
> Technische Universit?t Dresden
> Center for Information Services and
> High Performance Computing (ZIH)
> D-01062 Dresden
> Germany
>
> Contact:
> Willersbau, Room WIL A 208
> Phone: (+49) 351 463-34217
> Fax: (+49) 351 463-37773
> e-mail: michael.kluge at tu-dresden.de <mailto:michael.kluge@tu-dresden.de>
> WWW: http://www.tu-dresden.de/zih
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpc_parse.tgz
Type: application/x-compressed-tar
Size: 30287 bytes
Desc: not available
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20100428/e7d90469/attachment.bin>

[Lustre-devel] (no subject)

[Andreas Dilger]

AFAIK the Handling time is when request processing starts, not when it  
first arrived at the server. We would need to check I'd there is an  
RPCTRACE message from ptlrpc_handle_req_in() that we could use to  
determine the initial request arrival time.

Cheers, Andreas

On 2010-04-28, at 19:25, "di.wang" <di.wang@oracle.com> wrote:

> Hello, Michael
>
> There is a logfile parser script in the attachment, which was  
> written by Eric.
>
> This script is very simple, but it should help you understand how we  
> retrieve time step information from lustre debug log. On the server  
> side, if you enable rpc_trace log, whenever the request arrive/start  
> being processed/end of processing, there will be corresponding  
> records being written into the debug log. Basically, you can get all  
> the time step information from these records (actually only two of  
> these records would be enough).
>
>
> a. 00000100:00100000:0.0:1272313858.472660:0:31581:0:(service.c: 
> 1625:ptlrpc_server_handle_request()) Handling RPC pname:cluuid 
> +ref:pid:xid:nid:opc ll_mgs_00:7d4fb15c-1b1c-295f-e466- 
> ea7d77089b52+10:4055:x1334115493386242:12345-0 at lo:400
>
> This record means the req will being handled, so you can get the  
> start time stamp(1272313858.472660) operation type (opc: 400, ping),  
> xid (1334115493386242), client nid(12345-0 at lo) and so on.
>
> b. 00000100:00100000:0.0:1272313858.472687:0:31581:0:(service.c: 
> 1672:ptlrpc_server_handle_request()) Handled RPC pname:cluuid 
> +ref:pid:xid:nid:opc ll_mgs_00:7d4fb15c-1b1c-295f-e466- 
> ea7d77089b52+9:4055:x1334115493386242:12345-0 at lo:400 Request  
> procesed in 45us (77us total) trans 0 rc 0/0
>
> This record means the req is already being handled, so you can get  
> the end time stamp(1272313858.472687), operation type (opc: 400,  
> ping), xid (1334115493386242), client nid(12345-0 at lo) and so no.
>
> Note: (77us total) means how long it takes from the request arriving  
> to the end of processing. so you can also get the request arriving  
> time stamp here by (1272313858 - 77 = 1272312781).
>
>
> So with these information you can draw the graph Eric mentioned in  
> his email. If you have any questions, please let me know.
>
> Thanks
> WangDi
>
>
> Eric Barton wrote:
>>
>> --- 
>> ---------------------------------------------------------------------
>>
>> Subject:
>> RE: Visualising Lustre RPCs
>> To:
>> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" <Tom.Wang@Sun.COM 
>> >
>>
>> To:
>> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" <Tom.Wang@Sun.COM 
>> >
>> CC:
>> <lustre-devel@lists.lustre.org>, "Galen M. Shipman" <gshipman@ornl.gov 
>> >
>>
>>
>> Michael,
>>
>> The previous Lustre RPC visualisation effort I mentioned at the LUG  
>> used the
>>
>> Lustre debug log entries of type D_RPCTRACE. We disabled all but  
>> these
>>
>> log messages and then used the Lustre debug daemon to collect them  
>> while
>>
>> we ran I/O tests. We then ran a simple logfile parser which used  
>> just the log entries
>>
>> for request arrival?
>>
>> , start of processing and end of processing to graph request
>>
>> queue depth (arrival->end) and the number of requests being  
>> serviced by type
>>
>> over time ? e.g?
>>
>> read3d
>>
>> ?which shows request queue depth (vertical) over time (axis labell 
>> ed 20-25) by
>>
>> server (axis labelled 0-80).
>>
>> *From:* Michael Kluge [mailto:Michael.Kluge at tu-dresden.de]
>> *Sent:* 17 April 2010 6:26 AM
>> *To:* Galen M. Shipman; Eric Barton
>> *Subject:* Visualising Lustre RPCs
>>
>> Hi Galen, Eric,
>>
>> in order to get this little project started, I think what I need at  
>> first to
>>
>> write a prototype for a converter are the following things:
>>
>> A set of test traces collected on maybe a handful of clients and  
>> some servers
>>
>> is probably a good point to start with. It would be even better if  
>> we know
>>
>> what is in this traces so that we have an expectation what kind of  
>> things
>>
>> we want to see on the Vampir displays. This little program that  
>> Eric mentioned
>>
>> that can read the trace file would be very helpful as well. And as  
>> the last
>>
>> idea I have right now, a technical contact. I might come up with a  
>> couple
>>
>> of question after I have taken the first look onto the original  
>> trace data
>>
>> and before I start writing code.
>>
>> Regards, Michael
>>
>>
>> -- 
>>
>> Michael Kluge, M.Sc.
>>
>> Technische Universit?t Dresden
>> Center for Information Services and
>> High Performance Computing (ZIH)
>> D-01062 Dresden
>> Germany
>>
>> Contact:
>> Willersbau, Room WIL A 208
>> Phone: (+49) 351 463-34217
>> Fax: (+49) 351 463-37773
>> e-mail: michael.kluge at tu-dresden.de <mailto:michael.kluge@tu-dresden.de 
>> >
>> WWW: http://www.tu-dresden.de/zih
>>
>
> <rpc_parse.tgz>
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel

[Lustre-devel] (no subject)

[di.wang]

Andreas Dilger wrote:
> AFAIK the Handling time is when request processing starts, not when it  
> first arrived at the server. We would need to check I'd there is an  
> RPCTRACE message from ptlrpc_handle_req_in() that we could use to  
> determine the initial request arrival time.
>   
Oh, you can also get the arriving time in "Handled RPC" msg
by Handled RPC_time - total time.

Thanks
WangDi
> Cheers, Andreas
>
> On 2010-04-28, at 19:25, "di.wang" <di.wang@oracle.com> wrote:
>
>   
>> Hello, Michael
>>
>> There is a logfile parser script in the attachment, which was  
>> written by Eric.
>>
>> This script is very simple, but it should help you understand how we  
>> retrieve time step information from lustre debug log. On the server  
>> side, if you enable rpc_trace log, whenever the request arrive/start  
>> being processed/end of processing, there will be corresponding  
>> records being written into the debug log. Basically, you can get all  
>> the time step information from these records (actually only two of  
>> these records would be enough).
>>
>>
>> a. 00000100:00100000:0.0:1272313858.472660:0:31581:0:(service.c: 
>> 1625:ptlrpc_server_handle_request()) Handling RPC pname:cluuid 
>> +ref:pid:xid:nid:opc ll_mgs_00:7d4fb15c-1b1c-295f-e466- 
>> ea7d77089b52+10:4055:x1334115493386242:12345-0 at lo:400
>>
>> This record means the req will being handled, so you can get the  
>> start time stamp(1272313858.472660) operation type (opc: 400, ping),  
>> xid (1334115493386242), client nid(12345-0 at lo) and so on.
>>
>> b. 00000100:00100000:0.0:1272313858.472687:0:31581:0:(service.c: 
>> 1672:ptlrpc_server_handle_request()) Handled RPC pname:cluuid 
>> +ref:pid:xid:nid:opc ll_mgs_00:7d4fb15c-1b1c-295f-e466- 
>> ea7d77089b52+9:4055:x1334115493386242:12345-0 at lo:400 Request  
>> procesed in 45us (77us total) trans 0 rc 0/0
>>
>> This record means the req is already being handled, so you can get  
>> the end time stamp(1272313858.472687), operation type (opc: 400,  
>> ping), xid (1334115493386242), client nid(12345-0 at lo) and so no.
>>
>> Note: (77us total) means how long it takes from the request arriving  
>> to the end of processing. so you can also get the request arriving  
>> time stamp here by (1272313858 - 77 = 1272312781).
>>
>>
>> So with these information you can draw the graph Eric mentioned in  
>> his email. If you have any questions, please let me know.
>>
>> Thanks
>> WangDi
>>
>>
>> Eric Barton wrote:
>>     
>>> --- 
>>> ---------------------------------------------------------------------
>>>
>>> Subject:
>>> RE: Visualising Lustre RPCs
>>> To:
>>> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" <Tom.Wang@Sun.COM 
>>>       
>>> To:
>>> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" <Tom.Wang@Sun.COM 
>>>       
>>> CC:
>>> <lustre-devel@lists.lustre.org>, "Galen M. Shipman" <gshipman@ornl.gov 
>>>       
>>> Michael,
>>>
>>> The previous Lustre RPC visualisation effort I mentioned at the LUG  
>>> used the
>>>
>>> Lustre debug log entries of type D_RPCTRACE. We disabled all but  
>>> these
>>>
>>> log messages and then used the Lustre debug daemon to collect them  
>>> while
>>>
>>> we ran I/O tests. We then ran a simple logfile parser which used  
>>> just the log entries
>>>
>>> for request arrival?
>>>
>>> , start of processing and end of processing to graph request
>>>
>>> queue depth (arrival->end) and the number of requests being  
>>> serviced by type
>>>
>>> over time ? e.g?
>>>
>>> read3d
>>>
>>> ?which shows request queue depth (vertical) over time (axis labell 
>>> ed 20-25) by
>>>
>>> server (axis labelled 0-80).
>>>
>>> *From:* Michael Kluge [mailto:Michael.Kluge at tu-dresden.de]
>>> *Sent:* 17 April 2010 6:26 AM
>>> *To:* Galen M. Shipman; Eric Barton
>>> *Subject:* Visualising Lustre RPCs
>>>
>>> Hi Galen, Eric,
>>>
>>> in order to get this little project started, I think what I need at  
>>> first to
>>>
>>> write a prototype for a converter are the following things:
>>>
>>> A set of test traces collected on maybe a handful of clients and  
>>> some servers
>>>
>>> is probably a good point to start with. It would be even better if  
>>> we know
>>>
>>> what is in this traces so that we have an expectation what kind of  
>>> things
>>>
>>> we want to see on the Vampir displays. This little program that  
>>> Eric mentioned
>>>
>>> that can read the trace file would be very helpful as well. And as  
>>> the last
>>>
>>> idea I have right now, a technical contact. I might come up with a  
>>> couple
>>>
>>> of question after I have taken the first look onto the original  
>>> trace data
>>>
>>> and before I start writing code.
>>>
>>> Regards, Michael
>>>
>>>
>>> -- 
>>>
>>> Michael Kluge, M.Sc.
>>>
>>> Technische Universit?t Dresden
>>> Center for Information Services and
>>> High Performance Computing (ZIH)
>>> D-01062 Dresden
>>> Germany
>>>
>>> Contact:
>>> Willersbau, Room WIL A 208
>>> Phone: (+49) 351 463-34217
>>> Fax: (+49) 351 463-37773
>>> e-mail: michael.kluge at tu-dresden.de <mailto:michael.kluge@tu-dresden.de 
>>>       
>>> WWW: http://www.tu-dresden.de/zih
>>>
>>>       
>> <rpc_parse.tgz>
>> _______________________________________________
>> 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] (no subject)

[Di]

Greetings,

I am attempting to port the SysV lnet script as part of a transition to systemd. I ran into the following in lustre/scripts/lnet:

        if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f "$LUSTRE_LNET_CONFIG_FILE" ]; then
                $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
        else
                lctl network up || exit 1
        fi

Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by default) be removed so that way lnetctl is used exclusively?

Thanks,
Giuseppe Di Natale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20170105/7e17c5c9/attachment.htm>

[lustre-devel] (no subject)

[Amir Shehata]

lctl usage is kept for backwards compatibility. Eventually, we should be
moving to using lnetctl exclusively. Which lustre-release we should do that
in, is the question. 2.10?

thanks
amir

On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov> wrote:

> Greetings,
>
> I am attempting to port the SysV lnet script as part of a transition to
> systemd. I ran into the following in lustre/scripts/lnet:
>
>         if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
> "$LUSTRE_LNET_CONFIG_FILE" ]; then
>                 $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
>         else
>                 lctl network up || exit 1
>         fi
>
> Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
> default) be removed so that way lnetctl is used exclusively?
>
> Thanks,
> Giuseppe Di Natale
>
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20170110/8d4158a6/attachment.htm>

[lustre-devel] (no subject)

[Christopher J. Morrone]

Sounds good to me.  Ideally, lnetctl should be able to do everything
that lctl could do (plus all of the new features).  Has it reached
parity?  If not, what else still remains to be done?

Chris

On 01/10/2017 12:15 PM, Amir Shehata wrote:
> lctl usage is kept for backwards compatibility. Eventually, we should be
> moving to using lnetctl exclusively. Which lustre-release we should do
> that in, is the question. 2.10?
> 
> thanks
> amir
> 
> On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov
> <mailto:dinatale2@llnl.gov>> wrote:
> 
>     Greetings,
> 
>     I am attempting to port the SysV lnet script as part of a transition
>     to systemd. I ran into the following in lustre/scripts/lnet:
> 
>             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
>     "$LUSTRE_LNET_CONFIG_FILE" ]; then
>                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
>             else
>                     lctl network up || exit 1
>             fi
> 
>     Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
>     default) be removed so that way lnetctl is used exclusively?
> 
>     Thanks,
>     Giuseppe Di Natale
> 
>     _______________________________________________
>     lustre-devel mailing list
>     lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
>     http://lists.lustre.org/listinfo.cgi/lustre-devel-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] (no subject)

[Amir Shehata]

lnetctl was designed to control LNet only. We have not moved the rest of
the lctl functionality. lctl does a lot of other lustre specific functions.

The idea was to have lnetctl be only LNet specific, and lctl lustre
specific. In essence we are attempting to decouple LNet from lustre. There
has been some talk about upstreaming LNet before lustre with all the work
that James Simmons from ORNL is doing.

thanks
amir

On 10 January 2017 at 14:06, Christopher J. Morrone <morrone2@llnl.gov>
wrote:

> Sounds good to me.  Ideally, lnetctl should be able to do everything
> that lctl could do (plus all of the new features).  Has it reached
> parity?  If not, what else still remains to be done?
>
> Chris
>
> On 01/10/2017 12:15 PM, Amir Shehata wrote:
> > lctl usage is kept for backwards compatibility. Eventually, we should be
> > moving to using lnetctl exclusively. Which lustre-release we should do
> > that in, is the question. 2.10?
> >
> > thanks
> > amir
> >
> > On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov
> > <mailto:dinatale2@llnl.gov>> wrote:
> >
> >     Greetings,
> >
> >     I am attempting to port the SysV lnet script as part of a transition
> >     to systemd. I ran into the following in lustre/scripts/lnet:
> >
> >             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
> >     "$LUSTRE_LNET_CONFIG_FILE" ]; then
> >                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
> >             else
> >                     lctl network up || exit 1
> >             fi
> >
> >     Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
> >     default) be removed so that way lnetctl is used exclusively?
> >
> >     Thanks,
> >     Giuseppe Di Natale
> >
> >     _______________________________________________
> >     lustre-devel mailing list
> >     lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
> >     http://lists.lustre.org/listinfo.cgi/lustre-devel-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20170110/358aa93b/attachment.htm>

[lustre-devel] (no subject)

[Dilger, Andreas]

It's fine to add the lnet-specific functionality from lctl to lnetctl, but we shouldn't remove existing functionality from lctl to avoid breaking scripts that may be using it today.  4+ releases after all of the LNet specific lctl functionality has been added to lnetctl we can start printing deprecation warnings, and after 8+ releases they can be removed.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel High Performance Data Division

On 2017/01/10, 18:08, "lustre-devel on behalf of Amir Shehata" <lustre-devel-bounces at lists.lustre.org<mailto:lustre-devel-bounces@lists.lustre.org> on behalf of amir.shehata.whamcloud at gmail.com<mailto:amir.shehata.whamcloud@gmail.com>> wrote:

lnetctl was designed to control LNet only. We have not moved the rest of the lctl functionality. lctl does a lot of other lustre specific functions.

The idea was to have lnetctl be only LNet specific, and lctl lustre specific. In essence we are attempting to decouple LNet from lustre. There has been some talk about upstreaming LNet before lustre with all the work that James Simmons from ORNL is doing.

thanks
amir

On 10 January 2017 at 14:06, Christopher J. Morrone <morrone2 at llnl.gov<mailto:morrone2@llnl.gov>> wrote:
Sounds good to me.  Ideally, lnetctl should be able to do everything
that lctl could do (plus all of the new features).  Has it reached
parity?  If not, what else still remains to be done?

Chris

On 01/10/2017 12:15 PM, Amir Shehata wrote:
> lctl usage is kept for backwards compatibility. Eventually, we should be
> moving to using lnetctl exclusively. Which lustre-release we should do
> that in, is the question. 2.10?
>
> thanks
> amir
>
> On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2 at llnl.gov<mailto:dinatale2@llnl.gov>
> <mailto:dinatale2 at llnl.gov<mailto:dinatale2@llnl.gov>>> wrote:
>
>     Greetings,
>
>     I am attempting to port the SysV lnet script as part of a transition
>     to systemd. I ran into the following in lustre/scripts/lnet:
>
>             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
>     "$LUSTRE_LNET_CONFIG_FILE" ]; then
>                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
>             else
>                     lctl network up || exit 1
>             fi
>
>     Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
>     default) be removed so that way lnetctl is used exclusively?
>
>     Thanks,
>     Giuseppe Di Natale
>
>     _______________________________________________
>     lustre-devel mailing list
>     lustre-devel at lists.lustre.org<mailto:lustre-devel@lists.lustre.org> <mailto:lustre-devel at lists.lustre.org<mailto:lustre-devel@lists.lustre.org>>
>     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>     <http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org>
>
>
>
>
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org<mailto:lustre-devel@lists.lustre.org>
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>

_______________________________________________
lustre-devel mailing list
lustre-devel at lists.lustre.org<mailto:lustre-devel@lists.lustre.org>
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20170111/60435393/attachment-0001.htm>

[lustre-devel] (no subject)

[Christopher J. Morrone]

Right, I meant copy in lnet-specific functionality from lctl to lnetctl.
 I didn't mean to sound like I was suggesting moving the rest of lctl's
non-lnet parts into lnetctl.

Chris

On 01/10/2017 08:18 PM, Dilger, Andreas wrote:
> It's fine to add the lnet-specific functionality from lctl to lnetctl,
> but we shouldn't remove existing functionality from lctl to avoid
> breaking scripts that may be using it today.  4+ releases after all of
> the LNet specific lctl functionality has been added to lnetctl we can
> start printing deprecation warnings, and after 8+ releases they can be
> removed.
> 
>  
> 
> Cheers, Andreas
> 
> -- 
> 
> Andreas Dilger
> 
> Lustre Principal Architect
> 
> Intel High Performance Data Division
> 
>  
> 
> On 2017/01/10, 18:08, "lustre-devel on behalf of Amir Shehata"
> <lustre-devel-bounces@lists.lustre.org
> <mailto:lustre-devel-bounces@lists.lustre.org> on behalf of
> amir.shehata.whamcloud at gmail.com
> <mailto:amir.shehata.whamcloud@gmail.com>> wrote:
> 
>  
> 
> lnetctl was designed to control LNet only. We have not moved the rest of
> the lctl functionality. lctl does a lot of other lustre specific functions.
> 
>  
> 
> The idea was to have lnetctl be only LNet specific, and lctl lustre
> specific. In essence we are attempting to decouple LNet from lustre.
> There has been some talk about upstreaming LNet before lustre with all
> the work that James Simmons from ORNL is doing.
> 
>  
> 
> thanks
> 
> amir
> 
>  
> 
> On 10 January 2017 at 14:06, Christopher J. Morrone <morrone2@llnl.gov
> <mailto:morrone2@llnl.gov>> wrote:
> 
>     Sounds good to me.  Ideally, lnetctl should be able to do everything
>     that lctl could do (plus all of the new features).  Has it reached
>     parity?  If not, what else still remains to be done?
> 
>     Chris
> 
>     On 01/10/2017 12:15 PM, Amir Shehata wrote:
>     > lctl usage is kept for backwards compatibility. Eventually, we
>     should be
>     > moving to using lnetctl exclusively. Which lustre-release we should do
>     > that in, is the question. 2.10?
>     >
>     > thanks
>     > amir
>     >
>     > On 4 January 2017 at 16:16, Di Natale, Giuseppe
>     <dinatale2 at llnl.gov <mailto:dinatale2@llnl.gov>
>     > <mailto:dinatale2 at llnl.gov <mailto:dinatale2@llnl.gov>>> wrote:
>     >
>     >     Greetings,
>     >
>     >     I am attempting to port the SysV lnet script as part of a
>     transition
>     >     to systemd. I ran into the following in lustre/scripts/lnet:
>     >
>     >             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
>     >     "$LUSTRE_LNET_CONFIG_FILE" ]; then
>     >                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure ||
>     exit 1
>     >             else
>     >                     lctl network up || exit 1
>     >             fi
>     >
>     >     Can the check for LUSTRE_LNET_CONFIG_UTILITY 
>     (/usr/sbin/lnetctl by
>     >     default) be removed so that way lnetctl is used exclusively?
>     >
>     >     Thanks,
>     >     Giuseppe Di Natale
>     >
>     >     _______________________________________________
>     >     lustre-devel mailing list
>     >     lustre-devel at lists.lustre.org
>     <mailto:lustre-devel@lists.lustre.org>
>     <mailto:lustre-devel@lists.lustre.org
>     <mailto:lustre-devel@lists.lustre.org>>
>     >     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>     >     <http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org>
> 
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > lustre-devel mailing list
>     > lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
>     > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>     >
> 
>     _______________________________________________
>     lustre-devel mailing list
>     lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
>     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> 
>  
> 

[lustre-devel] (no subject)

[James Simmons]

> Right, I meant copy in lnet-specific functionality from lctl to lnetctl.
>  I didn't mean to sound like I was suggesting moving the rest of lctl's
> non-lnet parts into lnetctl.

I think Chris means is that if we make liblnetconfig mandatory then we can
link lctl to that library and replace alot of the functionality lctl is 
doing itself with the work in liblnetconfig.

Currently the library situation is a mess. We have:

liblnetconfig.so (okay)
libcfs.a
libcfsutil.a
libptlctl.a
liblustreapi.so

For liblustreapi.so it linked the libcfs*.a and libptlctl.a static
libraries. If you look at libptlctl.a its just composed of two source
files. One is debug.c which really belongs in libcfs. The other could
be replaced by libnetconfig. So we can kill off libptlctl.a. For
libcfsutil.a that should just merge into libcfs.

> On 01/10/2017 08:18 PM, Dilger, Andreas wrote:
> > It's fine to add the lnet-specific functionality from lctl to lnetctl,
> > but we shouldn't remove existing functionality from lctl to avoid
> > breaking scripts that may be using it today.  4+ releases after all of
> > the LNet specific lctl functionality has been added to lnetctl we can
> > start printing deprecation warnings, and after 8+ releases they can be
> > removed.
> > 
> >  
> > 
> > Cheers, Andreas
> > 
> > -- 
> > 
> > Andreas Dilger
> > 
> > Lustre Principal Architect
> > 
> > Intel High Performance Data Division
> > 
> >  
> > 
> > On 2017/01/10, 18:08, "lustre-devel on behalf of Amir Shehata"
> > <lustre-devel-bounces@lists.lustre.org
> > <mailto:lustre-devel-bounces@lists.lustre.org> on behalf of
> > amir.shehata.whamcloud at gmail.com
> > <mailto:amir.shehata.whamcloud@gmail.com>> wrote:
> > 
> >  
> > 
> > lnetctl was designed to control LNet only. We have not moved the rest of
> > the lctl functionality. lctl does a lot of other lustre specific functions.
> > 
> >  
> > 
> > The idea was to have lnetctl be only LNet specific, and lctl lustre
> > specific. In essence we are attempting to decouple LNet from lustre.
> > There has been some talk about upstreaming LNet before lustre with all
> > the work that James Simmons from ORNL is doing.
> > 
> >  
> > 
> > thanks
> > 
> > amir
> > 
> >  
> > 
> > On 10 January 2017 at 14:06, Christopher J. Morrone <morrone2@llnl.gov
> > <mailto:morrone2@llnl.gov>> wrote:
> > 
> >     Sounds good to me.  Ideally, lnetctl should be able to do everything
> >     that lctl could do (plus all of the new features).  Has it reached
> >     parity?  If not, what else still remains to be done?
> > 
> >     Chris
> > 
> >     On 01/10/2017 12:15 PM, Amir Shehata wrote:
> >     > lctl usage is kept for backwards compatibility. Eventually, we
> >     should be
> >     > moving to using lnetctl exclusively. Which lustre-release we should do
> >     > that in, is the question. 2.10?
> >     >
> >     > thanks
> >     > amir
> >     >
> >     > On 4 January 2017 at 16:16, Di Natale, Giuseppe
> >     <dinatale2 at llnl.gov <mailto:dinatale2@llnl.gov>
> >     > <mailto:dinatale2 at llnl.gov <mailto:dinatale2@llnl.gov>>> wrote:
> >     >
> >     >     Greetings,
> >     >
> >     >     I am attempting to port the SysV lnet script as part of a
> >     transition
> >     >     to systemd. I ran into the following in lustre/scripts/lnet:
> >     >
> >     >             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
> >     >     "$LUSTRE_LNET_CONFIG_FILE" ]; then
> >     >                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure ||
> >     exit 1
> >     >             else
> >     >                     lctl network up || exit 1
> >     >             fi
> >     >
> >     >     Can the check for LUSTRE_LNET_CONFIG_UTILITY 
> >     (/usr/sbin/lnetctl by
> >     >     default) be removed so that way lnetctl is used exclusively?
> >     >
> >     >     Thanks,
> >     >     Giuseppe Di Natale
> >     >
> >     >     _______________________________________________
> >     >     lustre-devel mailing list
> >     >     lustre-devel at lists.lustre.org
> >     <mailto:lustre-devel@lists.lustre.org>
> >     <mailto:lustre-devel@lists.lustre.org
> >     <mailto:lustre-devel@lists.lustre.org>>
> >     >     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> >     >     <http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org>
> > 
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > lustre-devel mailing list
> >     > lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
> >     > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> >     >
> > 
> >     _______________________________________________
> >     lustre-devel mailing list
> >     lustre-devel at lists.lustre.org <mailto:lustre-devel@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] (no subject)

[James Simmons]

> lnetctl was designed to control LNet only. We have not moved the rest of the lctl functionality. lctl does
> a lot of other lustre specific functions.
> The idea was to have lnetctl be only LNet specific, and lctl lustre specific. In essence we are attempting
> to decouple LNet from lustre. There has been some talk about upstreaming LNet before lustre with all the
> work that James Simmons from ORNL is doing.

Already done. LNet is ahead a bit for the upstream client from master but 
just recently I have been backporting that work to the OpenSFS branch.
Its almost synced up now. As for LNet leaving staging Greg wanted both
LNet and lustre to leaving staging at the same time.

> thanks
> amir
> 
> On 10 January 2017 at 14:06, Christopher J. Morrone <morrone2@llnl.gov> wrote:
>       Sounds good to me.? Ideally, lnetctl should be able to do everything
>       that lctl could do (plus all of the new features).? Has it reached
>       parity?? If not, what else still remains to be done?
> 
>       Chris
> 
>       On 01/10/2017 12:15 PM, Amir Shehata wrote:
>       > lctl usage is kept for backwards compatibility. Eventually, we should be
>       > moving to using lnetctl exclusively. Which lustre-release we should do
>       > that in, is the question. 2.10?
>       >
>       > thanks
>       > amir
>       >
>       > On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov
>       > <mailto:dinatale2@llnl.gov>> wrote:
>       >
>       >? ? ?Greetings,
>       >
>       >? ? ?I am attempting to port the SysV lnet script as part of a transition
>       >? ? ?to systemd. I ran into the following in lustre/scripts/lnet:
>       >
>       >? ? ? ? ? ? ?if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
>       >? ? ?"$LUSTRE_LNET_CONFIG_FILE" ]; then
>       >? ? ? ? ? ? ? ? ? ? ?$LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
>       >? ? ? ? ? ? ?else
>       >? ? ? ? ? ? ? ? ? ? ?lctl network up || exit 1
>       >? ? ? ? ? ? ?fi
>       >
>       >? ? ?Can the check for LUSTRE_LNET_CONFIG_UTILITY? (/usr/sbin/lnetctl by
>       >? ? ?default) be removed so that way lnetctl is used exclusively?
>       >
>       >? ? ?Thanks,
>       >? ? ?Giuseppe Di Natale
>       >
>       >? ? ?_______________________________________________
>       >? ? ?lustre-devel mailing list
>       >? ? ?lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
>       >? ? ?http://lists.lustre.org/listinfo.cgi/lustre-devel-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] (no subject)

[James Simmons]

> Sounds good to me.  Ideally, lnetctl should be able to do everything
> that lctl could do (plus all of the new features).  Has it reached
> parity?  If not, what else still remains to be done?

No lctl pings and the peer and connection handling is missing. I did
some work to support the missing features in lnetctl and combined with
multi-rail should fill in the gaps. Also we are missing lnetctl ping
but I think multi-rail might fix that. Not 100% sure tho.

> 
> Chris
> 
> On 01/10/2017 12:15 PM, Amir Shehata wrote:
> > lctl usage is kept for backwards compatibility. Eventually, we should be
> > moving to using lnetctl exclusively. Which lustre-release we should do
> > that in, is the question. 2.10?
> > 
> > thanks
> > amir
> > 
> > On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov
> > <mailto:dinatale2@llnl.gov>> wrote:
> > 
> >     Greetings,
> > 
> >     I am attempting to port the SysV lnet script as part of a transition
> >     to systemd. I ran into the following in lustre/scripts/lnet:
> > 
> >             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
> >     "$LUSTRE_LNET_CONFIG_FILE" ]; then
> >                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
> >             else
> >                     lctl network up || exit 1
> >             fi
> > 
> >     Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
> >     default) be removed so that way lnetctl is used exclusively?
> > 
> >     Thanks,
> >     Giuseppe Di Natale
> > 
> >     _______________________________________________
> >     lustre-devel mailing list
> >     lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
> >     http://lists.lustre.org/listinfo.cgi/lustre-devel-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] (no subject)

[Christopher J. Morrone]

On 01/16/2017 01:02 PM, James Simmons wrote:
> 
>> Sounds good to me.  Ideally, lnetctl should be able to do everything
>> that lctl could do (plus all of the new features).  Has it reached
>> parity?  If not, what else still remains to be done?
> 
> No lctl pings and the peer and connection handling is missing. I did
> some work to support the missing features in lnetctl and combined with
> multi-rail should fill in the gaps. Also we are missing lnetctl ping
> but I think multi-rail might fix that. Not 100% sure tho.

Thanks, James.  That is the information that I was looking for.

Chris

[lustre-devel] (no subject)

[Amir Shehata]

We have a patch for lnetctl ping coming in soon.

On 16 January 2017 at 13:02, James Simmons <jsimmons@infradead.org> wrote:

>
> > Sounds good to me.  Ideally, lnetctl should be able to do everything
> > that lctl could do (plus all of the new features).  Has it reached
> > parity?  If not, what else still remains to be done?
>
> No lctl pings and the peer and connection handling is missing. I did
> some work to support the missing features in lnetctl and combined with
> multi-rail should fill in the gaps. Also we are missing lnetctl ping
> but I think multi-rail might fix that. Not 100% sure tho.
>
> >
> > Chris
> >
> > On 01/10/2017 12:15 PM, Amir Shehata wrote:
> > > lctl usage is kept for backwards compatibility. Eventually, we should
> be
> > > moving to using lnetctl exclusively. Which lustre-release we should do
> > > that in, is the question. 2.10?
> > >
> > > thanks
> > > amir
> > >
> > > On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov
> > > <mailto:dinatale2@llnl.gov>> wrote:
> > >
> > >     Greetings,
> > >
> > >     I am attempting to port the SysV lnet script as part of a
> transition
> > >     to systemd. I ran into the following in lustre/scripts/lnet:
> > >
> > >             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
> > >     "$LUSTRE_LNET_CONFIG_FILE" ]; then
> > >                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit
> 1
> > >             else
> > >                     lctl network up || exit 1
> > >             fi
> > >
> > >     Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
> > >     default) be removed so that way lnetctl is used exclusively?
> > >
> > >     Thanks,
> > >     Giuseppe Di Natale
> > >
> > >     _______________________________________________
> > >     lustre-devel mailing list
> > >     lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.
> lustre.org>
> > >     http://lists.lustre.org/listinfo.cgi/lustre-devel-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20170118/75d022c0/attachment.htm>

(no subject)

[Fabian Huegel]

We cleaned up a lot of checkpatch errors and warnings in obd_class.h,
but there are still some CHECKs and two warnings about flow control
inside macros left.

Changing those macros to inline functions would probably
be a good idea, unfortunatly it's not straightforward since they use
'#op' to print the name of the operation.

We also did some aligning to make the code more readable and removed
an unnecessary macro.

We only tested, that the kernel still compiles and the lustre kernel
module loads successfully, but given the harmless nature of these
changes we don't expect any problems.

The patches are based on the staging-testing branch of the staging tree.

[lustre-devel] (no subject)

[Ben Evans]

I've been working off and on with this.  Since you're getting into the
counters in a couple of the patches, part of the reason for all the
#defines here are because MDC, MDT and OST counters are all shoved into
the same array dynamically, sometimes.  It would be a much cleaner
approach to have a separate array for the MDC stats, then print them
conditionally.

This would reduce all of the calls to these macros to counter increments.

-Ben Evans

On 1/11/18, 12:16 PM, "Fabian Huegel" <fabian_huegel@web.de> wrote:

>We cleaned up a lot of checkpatch errors and warnings in obd_class.h,
>but there are still some CHECKs and two warnings about flow control
>inside macros left.
>
>Changing those macros to inline functions would probably
>be a good idea, unfortunatly it's not straightforward since they use
>'#op' to print the name of the operation.
>
>We also did some aligning to make the code more readable and removed
>an unnecessary macro.
>
>We only tested, that the kernel still compiles and the lustre kernel
>module loads successfully, but given the harmless nature of these
>changes we don't expect any problems.
>
>The patches are based on the staging-testing branch of the staging tree.
>