On 2015-10-01 19:43:03 +0200, Stephan Seitz wrote:
> On Thu, Oct 01, 2015 at 01:54:07PM +0200, Vincent Lefevre wrote:
> >Is there a way to get traces as a normal user?
> >Otherwise I'll have to ask the sysadmin...
>
> Yes. If you do a „dpkg-reconfigure wireshark-common” you’ll get ask
> if normal
On 2015-09-28 20:12:50 -0700, Mike Kupfer wrote:
> I think it would be best to see packet traces from Vincent, if that's
> possible. (The trace should include traffic between the server and both
> clients.) I can think of a couple possible reasons why his Deb7 client
> behaves better than the
On Thu, Oct 01, 2015 at 01:54:07PM +0200, Vincent Lefevre wrote:
Is there a way to get traces as a normal user?
Otherwise I'll have to ask the sysadmin...
Yes. If you do a „dpkg-reconfigure wireshark-common” you’ll get ask if
normal user should be allowed to trace. If you say yes then a new
Vincent Lefevre wrote:
> Is there a way to get traces as a normal user?
Not that I know of.
mike
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 28.09.2015 um 18:59 schrieb Mike Kupfer:
> Peter Ludikovsky wrote:
>
>> The big difference happens at packets 58/54 (Deb7/Deb8). For
>> Deb7, the RENAME call is immediately answered by an NFS4_OK,
>> whereas for Deb8 as the client it's an
Peter Ludikovsky wrote:
> The big difference happens at packets 58/54 (Deb7/Deb8). For Deb7, the
> RENAME call is immediately answered by an NFS4_OK, whereas for Deb8 as
> the client it's an NFS4ERR_DELAY. I haven't seen any reason on the
> client communication that would explain that, however
On 2015-09-28 11:30:27 +0200, Peter Ludikovsky wrote:
> Maybe attach that information to your bug report as a point for
> investigation.
Thanks. I have pasted the message contents and added a link to it
(in the mailing-list archives).
--
Vincent Lefèvre - Web:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 25.09.2015 um 14:04 schrieb Vincent Lefevre:
> On 2015-09-25 10:11:10 +0200, Peter Ludikovsky wrote:
>> My guess is: Due to the rather large wsize/rsize, the clients
>> create a rather large attribute cache. As a result, when you cat
>> a file on
Peter Ludikovsky wrote:
> Am 28.09.2015 um 18:59 schrieb Mike Kupfer:
> > In the deb7 trace, the other client is .4, not .3. It does not get
> > a delegation when it opens file2 (see packet 39), so the server
> > can process the RENAME immediately.
> Hang on, the two traces haven't been made
On 2015-09-24 14:38:01 +0200, Peter Ludikovsky wrote:
> Other than that, what mount command did you use? Are you mounting the
> share yourself, or is this an fstab or autofs mount?
autofs
The only option used in /etc/auto.master is the obvious -o nosuid.
But the options seem to be the same on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 25.09.2015 um 09:32 schrieb Vincent Lefevre:
> On 2015-09-24 14:38:01 +0200, Peter Ludikovsky wrote:
>> Other than that, what mount command did you use? Are you mounting
>> the share yourself, or is this an fstab or autofs mount?
>
> autofs
>
>
On 2015-09-25 10:11:10 +0200, Peter Ludikovsky wrote:
> My guess is:
> Due to the rather large wsize/rsize, the clients create a rather large
> attribute cache. As a result, when you cat a file on the second
> machine it updates the atime in the cache, but doesn't yet transfer
> that information
On 2015-09-23 17:56:30 +0200, Peter Ludikovsky wrote:
> When mounted as NFS3 over UDP:
> -
> root@lab1# echo foo > file1
> root@lab1# cp file1 file2
>
> root@lab2# cat file2
> foo
>
> root@lab1# time mv file1 file2
> real 0m0.004s
> user 0m0.000s
> sys 0m0.000s
> -
>
> Same with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 24.09.2015 um 11:46 schrieb Vincent Lefevre:
> On 2015-09-23 17:56:30 +0200, Peter Ludikovsky wrote:
>> When mounted as NFS3 over UDP: - root@lab1# echo foo >
>> file1 root@lab1# cp file1 file2
>>
>> root@lab2# cat file2 foo
>>
>> root@lab1#
On 2015-09-22 15:19:10 +0200, Vincent Lefevre wrote:
> At my lab, with NFS accounts, some machines have been upgraded to
> Debian 8, and I get regular hangs on these machines, while they
> never occurred before on the same machine and still never occur
> on a machine that is still under Debian 7.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I tried to replicate your problem, but couldn't.
When mounted as NFS3 over UDP:
-
root@lab1# echo foo > file1
root@lab1# cp file1 file2
root@lab2# cat file2
foo
root@lab1# time mv file1 file2
real0m0.004s
user0m0.000s
sys
At my lab, with NFS accounts, some machines have been upgraded to
Debian 8, and I get regular hangs on these machines, while they
never occurred before on the same machine and still never occur
on a machine that is still under Debian 7.
This happens with one of my scripts, which does a lot of
17 matches
Mail list logo