On 03/17/2015 03:15 PM, Rupert Dance wrote:
> Nroff
>
> ./stat: no data in nroff.time
I believe this has to do with the format of time 'time' command.
stat.c expects a particular date format that changes whether
/usr/bin/time is used or the shell version of data.
try adding TIME=/usr/bin/time to the top of general/runtests.wrk
steved.
There is a patched cthon04 out there. I think from Jeff Layton.
Frank
Sent from my iPhone
On Mar 17, 2015, at 3:35 PM, Steve Dickson <[email protected]> wrote:
> On 03/17/2015 03:15 PM, Rupert Dance wrote:
>> Nroff
>>
>> ./stat: no data in nroff.time
> I believe this has to do with the format of time 'time' command.
> stat.c expects a particular date format that changes whether
> /usr/bin/time is used or the shell version of data.
>
> try adding TIME=/usr/bin/time to the top of general/runtests.wrk
>
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/17/2015 09:26 PM, Frank Filz wrote:
> There is a patched cthon04 out there. I think from Jeff Layton.
>
> Frank
>
> Sent from my iPhone
>
> On Mar 17, 2015, at 3:35 PM, Steve Dickson <[email protected]> wrote:
>
>> On 03/17/2015 03:15 PM, Rupert Dance wrote:
>>> Nroff
>>>
>>> ./stat: no data in nroff.time
>> I believe this has to do with the format of time 'time' command.
>> stat.c expects a particular date format that changes whether
>> /usr/bin/time is used or the shell version of data.
>>
>> try adding TIME=/usr/bin/time to the top of general/runtests.wrk
Taking a closer look there is code that is commented out that
will solve this problem.
# if the default time command doesn't return the right format,
# you may have to use the following lines
#case `uname` in
#[lL]inux*)
# TIME=/usr/bin/time
# ;;
#*)
# TIME=/bin/time
# ;;
#esac
#if [ ! -f $TIME ]
#then
# TIME=/usr/bin/time
# if [ ! -f $TIME ]
# then
# echo "Where is the time command?"
# exit 1
# fi
#fi
Maybe its time to uncomment it...
steved.
Steve,
We tried uncommenting the code but we are still seeing failures. We are
running Connectathon on a variety of systems pairs testing both Mellanox and
Intel Hardware. Most of the combinations pass the Connectathon Basic,
Locking and Special tests but fail the General tests with the error message
"Nroff ./stat: no data in nroff.time"
There are several other combinations that cause other errors:
1. The test hangs and no error is reported. In these cases the client
system MUST be restarted before it becomes usable again. The server system
is restarted to get back to a known good state and clear the exports before
restarting testing
2. Connectathon Basic test hangs with the client system displaying: ./test5:
read and write
Thanks
Rupert
-----Original Message-----
From: Steve Dickson [mailto:[email protected]]
Sent: Thursday, March 19, 2015 11:04 AM
To: Frank Filz
Cc: Rupert Dance; [email protected]
Subject: Re: Connectathon Issues
On 03/17/2015 09:26 PM, Frank Filz wrote:
> There is a patched cthon04 out there. I think from Jeff Layton.
>
> Frank
>
> Sent from my iPhone
>
> On Mar 17, 2015, at 3:35 PM, Steve Dickson <[email protected]> wrote:
>
>> On 03/17/2015 03:15 PM, Rupert Dance wrote:
>>> Nroff
>>>
>>> ./stat: no data in nroff.time
>> I believe this has to do with the format of time 'time' command.
>> stat.c expects a particular date format that changes whether
>> /usr/bin/time is used or the shell version of data.
>>
>> try adding TIME=/usr/bin/time to the top of general/runtests.wrk
Taking a closer look there is code that is commented out that will solve
this problem.
# if the default time command doesn't return the right format, # you may
have to use the following lines #case `uname` in
#[lL]inux*)
# TIME=/usr/bin/time
# ;;
#*)
# TIME=/bin/time
# ;;
#esac
#if [ ! -f $TIME ]
#then
# TIME=/usr/bin/time
# if [ ! -f $TIME ]
# then
# echo "Where is the time command?"
# exit 1
# fi
#fi
Maybe its time to uncomment it...
steved.
Sorry for the delayed response
On 03/19/2015 12:57 PM, Rupert Dance wrote:
> We tried uncommenting the code but we are still seeing failures. We are
> running Connectathon on a variety of systems pairs testing both Mellanox and
> Intel Hardware. Most of the combinations pass the Connectathon Basic,
> Locking and Special tests but fail the General tests with the error message
> "Nroff ./stat: no data in nroff.time"
What does output from the time command look like?
>
> There are several other combinations that cause other errors:
>
> 1. The test hangs and no error is reported. In these cases the client
> system MUST be restarted before it becomes usable again. The server system
> is restarted to get back to a known good state and clear the exports before
> restarting testing
>
> 2. Connectathon Basic test hangs with the client system displaying: ./test5:
> read and write
Is it really hung or is it just slow? On the client, use tshark host <server>
to see if there is anything going over the wire...
steved.
On Mar 26, 2015, at 12:19 PM, Steve Dickson <[email protected]> wrote:
>> There are several other combinations that cause other errors:
>>
>> 1. The test hangs and no error is reported. In these cases the client
>> system MUST be restarted before it becomes usable again. The server system
>> is restarted to get back to a known good state and clear the exports before
>> restarting testing
>>
>> 2. Connectathon Basic test hangs with the client system displaying: ./test5:
>> read and write
> Is it really hung or is it just slow? On the client, use tshark host <server>
> to see if there is anything going over the wire?
I?m guessing Rupert is using NFS/RDMA. If true, tshark is not going to
be helpful.
Rupert, what is the output of ?uname -a? on your systems?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Chuck,
Here is what the systems are running,
3.10.0-123.el7.x86_64 #1 SMP Thu Sep 11 15:55:14 CDT 2014 x86_64 x86_64
x86_64 GNU/Linux
Scientific Linux release 7.0 (Nitrogen)
Thanks
Rupert
-----Original Message-----
From: Chuck Lever [mailto:[email protected]]
Sent: Thursday, March 26, 2015 1:58 PM
To: Steve Dickson
Cc: Rupert Dance; Linux NFS Mailing List
Subject: Re: Connectathon Issues
On Mar 26, 2015, at 12:19 PM, Steve Dickson <[email protected]> wrote:
>> There are several other combinations that cause other errors:
>>
>> 1. The test hangs and no error is reported. In these cases the
>> client system MUST be restarted before it becomes usable again. The
>> server system is restarted to get back to a known good state and
>> clear the exports before restarting testing
>>
>> 2. Connectathon Basic test hangs with the client system displaying:
./test5:
>> read and write
> Is it really hung or is it just slow? On the client, use tshark host
> <server> to see if there is anything going over the wire.
I'm guessing Rupert is using NFS/RDMA. If true, tshark is not going to be
helpful.
Rupert, what is the output of "uname -a" on your systems?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com