[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: CMake: remove USE_TSAN, use -DSANITIZE_THREAD instead

2018-03-13 Thread GerritHub
>From Dominique Martinet : Dominique Martinet has uploaded this change for review. ( https://review.gerrithub.io/403728 Change subject: CMake: remove USE_TSAN, use -DSANITIZE_THREAD instead ..

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: CMake sanitizers: s/saitizer/sanitizer/

2018-03-13 Thread GerritHub
>From Dominique Martinet : Dominique Martinet has uploaded this change for review. ( https://review.gerrithub.io/403729 Change subject: CMake sanitizers: s/saitizer/sanitizer/ .. CMake sanitizers:

Re: [Nfs-ganesha-devel] rpcping

2018-03-13 Thread Daniel Gryniewicz
rpcping was not thread safe. I have fixes for it incoming. Daniel On 03/13/2018 12:13 PM, William Allen Simpson wrote: On 3/13/18 2:38 AM, William Allen Simpson wrote: In my measurements, using the new CLNT_CALL_BACK(), the client thread starts sending a stream of pings.  In every case, it

Re: [Nfs-ganesha-devel] rpcping

2018-03-13 Thread William Allen Simpson
On 3/13/18 2:38 AM, William Allen Simpson wrote: In my measurements, using the new CLNT_CALL_BACK(), the client thread starts sending a stream of pings.  In every case, it peaks at a relatively stable rate. DanG suggested that timing was dominated by the system time calls. The previous

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Adding empty file const_strcuts.checkpatch

2018-03-13 Thread GerritHub
>From : supriti.si...@suse.com has uploaded this change for review. ( https://review.gerrithub.io/403704 Change subject: Adding empty file const_strcuts.checkpatch .. Adding empty file

Re: [Nfs-ganesha-devel] Better late than never - US Daylight Savings Time has started and that means weekly conference call is an hour earlier

2018-03-13 Thread Frank Filz
> Time has started and that means weekly conference call is an hour earlier > > > An hour later... No, an hour earlier. The time for the meeting is based on current Pacific time, not UT/GMT. So when the US enters Daylight Saving Time, the meeting switches to an hour earlier, and when we leave

Re: [Nfs-ganesha-devel] Better late than never - US Daylight Savings Time has started and that means weekly conference call is an hour earlier

2018-03-13 Thread Dominique Martinet
Daniel Gryniewicz wrote on Tue, Mar 13, 2018 at 10:07:33AM -0400: > An hour later... Nope, it is an hour earlier for us :) -- Dominique -- Check out the vibrant tech community on one of the world's most engaging tech

Re: [Nfs-ganesha-devel] Better late than never - US Daylight Savings Time has started and that means weekly conference call is an hour earlier

2018-03-13 Thread Daniel Gryniewicz
An hour later... Daniel On 03/13/2018 10:02 AM, Frank Filz wrote: -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

[Nfs-ganesha-devel] Better late than never - US Daylight Savings Time has started and that means weekly conference call is an hour earlier

2018-03-13 Thread Frank Filz
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Nfs-ganesha-devel mailing list

Re: [Nfs-ganesha-devel] intermittent malloc list corruption on shutdown in -dev.3

2018-03-13 Thread Dominique Martinet
Hi Jeff, the CEA bot has hit this twice in the past two or so weeks, so you're definitely not the only one seeing that -- unfortunately it's only ever hit it on the runs without ASAN so the traces are pretty much the same as what you get. This kind of messages mean we're messing about with

Re: [Nfs-ganesha-devel] rpcping

2018-03-13 Thread Matt Benjamin
On Tue, Mar 13, 2018 at 2:38 AM, William Allen Simpson wrote: > On 3/12/18 6:25 PM, Matt Benjamin wrote: >> >> If I understand correctly, we always insert records in xid order, and >> xid is monotonically increasing by 1. I guess pings might come back >> in any

Re: [Nfs-ganesha-devel] rpcping

2018-03-13 Thread William Allen Simpson
On 3/12/18 6:25 PM, Matt Benjamin wrote: If I understand correctly, we always insert records in xid order, and xid is monotonically increasing by 1. I guess pings might come back in any order, No, they always come back in order. This is TCP. I've gone to some lengths to fix the problem