Re: [OpenAFS] Strange access problems on one client

[Marc Dionne]

Carson Gaspar wrote:

Hans-Werner Paulsen wrote:

On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote:



+else if (hval >= 1<<31)



this patch is fine for architectures where the size of "unsigned long"
is 4 bytes. But on the x86_64 architecture this will not work, because
the size is 8 bytes. One can use "unsigned int".


Ummm... no. This whole thing is way too fragile. If you care about how 
many bits the variable has, you MUST use something like uint32_t. Or you 
can not care, and use sizeof() to generate your comparison. But you MUST 
NOT use "int" or "long" and hard-code bit shifts.


Sure enough - with the original patch I was trying to confirm that this 
was indeed the issue, and didn't try to be generic.


How about something like this, with an unsigned int for hval:

   else if (hval >= 1<<(sizeof(hval)*8-1))

which seems functionally equivalent to the original code and not 
dependent on the size of hval.


Now I'm curious as to why the specific value returned by DirHash even 
matters.  Even with the gcc bug it would be consistent for a given 
string on the same client.  Does this value have to match what's 
computed for the same string on the file server side? (looks like 
DirHash is also used in fileserver) If so, it looks like the original 
code could produce different values with different size ints on the 
server and client.


Marc
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Derrick Brashear]

On 10/11/07, Jeffrey Altman <[EMAIL PROTECTED]> wrote:
>
> Marc Dionne wrote:
> > Now I'm curious as to why the specific value returned by DirHash even
> > matters.  Even with the gcc bug it would be consistent for a given
> > string on the same client.  Does this value have to match what's
> > computed for the same string on the file server side?
>
> The hash is used to look up the name in the AFS3 directory hash table
> that is received by the client from the file server.
>
> > (looks like
> > DirHash is also used in fileserver) If so, it looks like the original
> > code could produce different values with different size ints on the
> > server and client.
>
> Good thing we are lucky that 'int' is 32-bits on all of the platforms we
> care about.   I agree this should be afs_int32.


the entire dir package is bad about specifying int, long or afs_int32;
making stylistic changes now is probably not the best idea.

Re: [OpenAFS] Strange access problems on one client

[Jeffrey Altman]

Marc Dionne wrote:
> Now I'm curious as to why the specific value returned by DirHash even
> matters.  Even with the gcc bug it would be consistent for a given
> string on the same client.  Does this value have to match what's
> computed for the same string on the file server side?

The hash is used to look up the name in the AFS3 directory hash table
that is received by the client from the file server.

> (looks like
> DirHash is also used in fileserver) If so, it looks like the original
> code could produce different values with different size ints on the
> server and client.

Good thing we are lucky that 'int' is 32-bits on all of the platforms we
care about.   I agree this should be afs_int32.

Jeffrey Altman





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OpenAFS] Strange access problems on one client

[Derrick Brashear]

You wacky kids and your excessive widereplies.

Anyway, if I have time to do testing, I will. Otherwise, if someone wants to
do a clean version of this, please do.

On 10/11/07, Carson Gaspar <[EMAIL PROTECTED]> wrote:
>
> Hans-Werner Paulsen wrote:
> > On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote:
>
> >> +else if (hval >= 1<<31)
>
> > this patch is fine for architectures where the size of "unsigned long"
> > is 4 bytes. But on the x86_64 architecture this will not work, because
> > the size is 8 bytes. One can use "unsigned int".
>
> Ummm... no. This whole thing is way too fragile. If you care about how
> many bits the variable has, you MUST use something like uint32_t. Or you
> can not care, and use sizeof() to generate your comparison. But you MUST
> NOT use "int" or "long" and hard-code bit shifts.
>
>

Re: [OpenAFS] Strange access problems on one client

[Matt Benjamin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I think Derrick was being careful when he said it a) fixed the issue and
b) was harmless.

Matt

Marc Dionne wrote:
> Carson Gaspar wrote:
>> Hans-Werner Paulsen wrote:
>>> On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote:
>>
 +else if (hval >= 1<<31)
>>
>>> this patch is fine for architectures where the size of "unsigned long"
>>> is 4 bytes. But on the x86_64 architecture this will not work, because
>>> the size is 8 bytes. One can use "unsigned int".
>>
>> Ummm... no. This whole thing is way too fragile. If you care about how
>> many bits the variable has, you MUST use something like uint32_t. Or
>> you can not care, and use sizeof() to generate your comparison. But
>> you MUST NOT use "int" or "long" and hard-code bit shifts.
> 
> Sure enough - with the original patch I was trying to confirm that this
> was indeed the issue, and didn't try to be generic.
> 
>
- --

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDuGCJiSUUSaRdSURCC7EAJ9QSM14weKgsjT0EZcUnS9O0cSCUACgj+mb
P7FrrFgD3q4cp6GKWKBqRR0=
=LHDI
-END PGP SIGNATURE-
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Marc Dionne]

Carson Gaspar wrote:

Hans-Werner Paulsen wrote:

On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote:



+else if (hval >= 1<<31)



this patch is fine for architectures where the size of "unsigned long"
is 4 bytes. But on the x86_64 architecture this will not work, because
the size is 8 bytes. One can use "unsigned int".


Ummm... no. This whole thing is way too fragile. If you care about how 
many bits the variable has, you MUST use something like uint32_t. Or you 
can not care, and use sizeof() to generate your comparison. But you MUST 
NOT use "int" or "long" and hard-code bit shifts.


Sure enough - with the original patch I was trying to confirm that this 
was indeed the issue, and didn't try to be generic.


How about something like this, with an unsigned int for hval:

   else if (hval >= 1<<(sizeof(hval)*8-1))

which seems functionally equivalent to the original code and not 
dependent on the size of hval.


Now I'm curious as to why the specific value returned by DirHash even 
matters.  Even with the gcc bug it would be consistent for a given 
string on the same client.  Does this value have to match what's 
computed for the same string on the file server side? (looks like 
DirHash is also used in fileserver) If so, it looks like the original 
code could produce different values with different size ints on the 
server and client.


Marc
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Carson Gaspar]

Hans-Werner Paulsen wrote:

On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote:



+else if (hval >= 1<<31)



this patch is fine for architectures where the size of "unsigned long"
is 4 bytes. But on the x86_64 architecture this will not work, because
the size is 8 bytes. One can use "unsigned int".


Ummm... no. This whole thing is way too fragile. If you care about how 
many bits the variable has, you MUST use something like uint32_t. Or you 
can not care, and use sizeof() to generate your comparison. But you MUST 
NOT use "int" or "long" and hard-code bit shifts.


--
Carson
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Hans-Werner Paulsen]

On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote:
> Anyone care to test out the attached patch for src/dir/dir.c
> 
> The hashing code in the DirHash() function relies on integer overflow to 
> make the hval value turn into a negative value.  gcc 4.2 assumes that 
> this value can never go negative and optimizes out the (hval < 0) test.
> 
> Marc
> 
> diff -u -r1.24 dir.c
> --- src/dir/dir.c 13 Oct 2005 15:12:12 -  1.24
> +++ src/dir/dir.c 7 Oct 2007 17:10:37 -
> @@ -478,8 +478,9 @@
>  {
>  /* Hash a string to a number between 0 and NHASHENT. */
>  register unsigned char tc;
> -register int hval;
> +unsigned long hval;
>  register int tval;
> +
>  hval = 0;
>  while ((tc = (*string++))) {
>   hval *= 173;
> @@ -488,7 +489,7 @@
>  tval = hval & (NHASHENT - 1);
>  if (tval == 0)
>   return tval;
> -else if (hval < 0)
> +else if (hval >= 1<<31)
>   tval = NHASHENT - tval;
>  return tval;
>  }

this patch is fine for architectures where the size of "unsigned long"
is 4 bytes. But on the x86_64 architecture this will not work, because
the size is 8 bytes. One can use "unsigned int".

HW

-- 
Hans-Werner Paulsen [EMAIL PROTECTED]
MPI für Astrophysik Tel 089-3-2602
Karl-Schwarzschild-Str. 1   Fax 089-3-2235  
D-85741 Garching
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Russ Allbery]

Norbert Schuch <[EMAIL PROTECTED]> writes:

> I had the same problem -- No such file or directory errors -- after
> upgrading the 2.6.21 (self-compiled) kernel to the most recent Debian
> sources. After some experiments, I figured out that it probably depends
> on the gcc version. The new kernel has been compiled with gcc-4.2, and
> indeed no kernel in the 2.6.21 series works with openafs if compiled
> with gcc-4.2.  If I however compile it with gcc-4.0, it works again with
> openafs.

> So trying a different gcc version might help.

It'll be fixed in Debian unstable as soon as I can find a free hour or
two.

-- 
Russ Allbery ([EMAIL PROTECTED]) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Norbert Schuch]

Hi,

I had the same problem -- No such file or directory errors -- after
upgrading the 2.6.21 (self-compiled) kernel to the most recent Debian
sources. After some experiments, I figured out that it probably depends on
the gcc version. The new kernel has been compiled with gcc-4.2, and indeed
no kernel in the 2.6.21 series works with openafs if compiled with gcc-4.2.
If I however compile it with gcc-4.0, it works again with openafs.

So trying a different gcc version might help.


Regards,
Norbert

-- 
View this message in context: 
http://www.nabble.com/Strange-access-problems-on-one-client-tf4256181.html#a13067818
Sent from the OpenAFS - General mailing list archive at Nabble.com.

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Dirk Heinrichs]

Am Sonntag, 7. Oktober 2007 schrieb ext Derrick Brashear:

> Omari Stephens confirmed this fixed a test system, and regardless it's
> harmless, so we'll run with this.

I'm glad to see the issue could be resolved.

Bye...

Dirk
-- 
Dirk Heinrichs  | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: [EMAIL PROTECTED]
Wanheimerstraße 68  | Web:  http://www.capgemini.com
D-40468 Düsseldorf  | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net


signature.asc
Description: This is a digitally signed message part.

Re: [OpenAFS] Strange access problems on one client

[Derrick Brashear]

Omari Stephens confirmed this fixed a test system, and regardless it's
harmless, so we'll run with this.

Thanks!


On 10/7/07, Marc Dionne <[EMAIL PROTECTED]> wrote:
>
> Norbert Schuch wrote:
> > Hi,
> >
> >
> > Dirk Heinrichs-2 wrote:
> >> I'm currently facing strange behaviour on one client machine, which
> looks
> >> like:
> >>
> >> [...]
> >> [EMAIL PROTECTED] ~ % LANG="" ll /afs/altum.de
> >> ls: cannot access /afs/altum.de/music: No such file or directory
> >>
> >
> > I had the same problem after compiling a new kernel. However,
> > I have discovered meanwhile that it is caused by the
> > gcc version used: The 2.6.21.1 to 2.6.21.7 kernels all do NOT
> > work with openafs-1.4.4 when compiled with gcc-4.2 (although
> > both compile, and the driver is loaded -- only the afs cannot be
> > accessed), whereas they work if compiled with gcc-4.0.
> >
> >
> > Regards,
> > Norbert
>
> Anyone care to test out the attached patch for src/dir/dir.c
>
> The hashing code in the DirHash() function relies on integer overflow to
> make the hval value turn into a negative value.  gcc 4.2 assumes that
> this value can never go negative and optimizes out the (hval < 0) test.
>
> Marc
>
>
> Index: src/dir/dir.c
> ===
> RCS file: /cvs/openafs/src/dir/dir.c,v
> retrieving revision 1.24
> diff -u -r1.24 dir.c
> --- src/dir/dir.c   13 Oct 2005 15:12:12 -  1.24
> +++ src/dir/dir.c   7 Oct 2007 17:10:37 -
> @@ -478,8 +478,9 @@
> {
>  /* Hash a string to a number between 0 and NHASHENT. */
>  register unsigned char tc;
> -register int hval;
> +unsigned long hval;
>  register int tval;
> +
>  hval = 0;
>  while ((tc = (*string++))) {
> hval *= 173;
> @@ -488,7 +489,7 @@
>  tval = hval & (NHASHENT - 1);
>  if (tval == 0)
> return tval;
> -else if (hval < 0)
> +else if (hval >= 1<<31)
> tval = NHASHENT - tval;
>  return tval;
> }
>
>

Re: [OpenAFS] Strange access problems on one client

[Marc Dionne]

Norbert Schuch wrote:

Hi,


Dirk Heinrichs-2 wrote:
I'm currently facing strange behaviour on one client machine, which looks 
like:


[...]
[EMAIL PROTECTED] ~ % LANG="" ll /afs/altum.de
ls: cannot access /afs/altum.de/music: No such file or directory



I had the same problem after compiling a new kernel. However, 
I have discovered meanwhile that it is caused by the 
gcc version used: The 2.6.21.1 to 2.6.21.7 kernels all do NOT 
work with openafs-1.4.4 when compiled with gcc-4.2 (although 
both compile, and the driver is loaded -- only the afs cannot be 
accessed), whereas they work if compiled with gcc-4.0.



Regards,
Norbert


Anyone care to test out the attached patch for src/dir/dir.c

The hashing code in the DirHash() function relies on integer overflow to 
make the hval value turn into a negative value.  gcc 4.2 assumes that 
this value can never go negative and optimizes out the (hval < 0) test.


Marc

Index: src/dir/dir.c
===
RCS file: /cvs/openafs/src/dir/dir.c,v
retrieving revision 1.24
diff -u -r1.24 dir.c
--- src/dir/dir.c   13 Oct 2005 15:12:12 -  1.24
+++ src/dir/dir.c   7 Oct 2007 17:10:37 -
@@ -478,8 +478,9 @@
 {
 /* Hash a string to a number between 0 and NHASHENT. */
 register unsigned char tc;
-register int hval;
+unsigned long hval;
 register int tval;
+
 hval = 0;
 while ((tc = (*string++))) {
hval *= 173;
@@ -488,7 +489,7 @@
 tval = hval & (NHASHENT - 1);
 if (tval == 0)
return tval;
-else if (hval < 0)
+else if (hval >= 1<<31)
tval = NHASHENT - tval;
 return tval;
 }

Re: [OpenAFS] Strange access problems on one client

[Norbert Schuch]

Hi,


Dirk Heinrichs-2 wrote:
> 
> I'm currently facing strange behaviour on one client machine, which looks 
> like:
> 
> [...]
> [EMAIL PROTECTED] ~ % LANG="" ll /afs/altum.de
> ls: cannot access /afs/altum.de/music: No such file or directory
> 

I had the same problem after compiling a new kernel. However, 
I have discovered meanwhile that it is caused by the 
gcc version used: The 2.6.21.1 to 2.6.21.7 kernels all do NOT 
work with openafs-1.4.4 when compiled with gcc-4.2 (although 
both compile, and the driver is loaded -- only the afs cannot be 
accessed), whereas they work if compiled with gcc-4.0.


Regards,
Norbert

-- 
View this message in context: 
http://www.nabble.com/Strange-access-problems-on-one-client-tf4256181.html#a13077327
Sent from the OpenAFS - General mailing list archive at Nabble.com.

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Russ Allbery]

"Derrick Brashear" <[EMAIL PROTECTED]> writes:

> Wow. That sucks.

> FWIW, Simon Wilkinson reports the new Fedora kernels aren't triggering
> this on his test system.

> As a note those kernels will be online shortly.

The Debian bug reporter was using stock kernel source from kernel.org and
building it himself.  He hasn't gotten back to me yet on whether the
kernel in Debian unstable is also affected.

-- 
Russ Allbery ([EMAIL PROTECTED]) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Derrick Brashear]

On 9/28/07, Dirk Heinrichs <[EMAIL PROTECTED]> wrote:
>
> Am Mittwoch, 26. September 2007 schrieb ext Derrick Brashear:
>
> > Ok, so it's just calling the access routines, meaning, nothing in
> OpenAFS
> > changed. If you can tell us at which version of the kernel things start
> > breaking it would be probably an easy fix for us from there.
>
> Seems this laptop died a sudden death last night while compiling an older
> kernel for testing this issue. So I'm out of this for now :-(


Wow. That sucks.

FWIW, Simon Wilkinson reports the new Fedora kernels aren't triggering this
on his test system.

As a note those kernels will be online shortly.

Re: [OpenAFS] Strange access problems on one client

[Dirk Heinrichs]

Am Mittwoch, 26. September 2007 schrieb ext Derrick Brashear:

> Ok, so it's just calling the access routines, meaning, nothing in OpenAFS
> changed. If you can tell us at which version of the kernel things start
> breaking it would be probably an easy fix for us from there.

Seems this laptop died a sudden death last night while compiling an older 
kernel for testing this issue. So I'm out of this for now :-(

Bye...

Dirk
-- 
Dirk Heinrichs  | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: [EMAIL PROTECTED]
Wanheimerstraße 68  | Web:  http://www.capgemini.com
D-40468 Düsseldorf  | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net


signature.asc
Description: This is a digitally signed message part.

Re: [OpenAFS] Strange access problems on one client

[Derrick Brashear]

Ok, so it's just calling the access routines, meaning, nothing in OpenAFS
changed. If you can tell us at which version of the kernel things start
breaking it would be probably an easy fix for us from there.

On 9/26/07, Dirk Heinrichs <[EMAIL PROTECTED]> wrote:
>
> Am Dienstag, 25. September 2007 schrieb Russ Allbery:
> > Dirk Heinrichs <[EMAIL PROTECTED]> writes:
> > > It's neither in the src nor in the doc tarball, so it's no wonder that
> > > Gentoo doesn't install it. Where can I find it?
> >
> > It's generated during the build process in src/afs/afszcm.cat and
> > installed when you do a make dest, but it looks like it was never added
> to
> > make install (probably for lack of a good location in which to put
> it).  I
> > fixed that for the Debian packages, but didn't come up with a clean
> patch
> > and hence haven't found a way to merge it upstream yet.
>
> OK, found it on an Ubuntu system and copied it over. So here's a new
> fstrace
> dump.
>
> Again, the command was:
>
> % LANG="" ll /afs/grand.central.org/
> ls: cannot access /afs/grand.central.org/local: No such file or directory
> ls: cannot access /afs/grand.central.org/software: No such file or
> directory
> total 14K
> drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
> drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
> drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
> d? ? ??   ?? local/
> drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
> drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
> d? ? ??   ?? software/
> drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
> drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/
>
> Bye...
>
> Dirk
>
>

Re: [OpenAFS] Strange access problems on one client

[Dirk Heinrichs]

Am Dienstag, 25. September 2007 schrieb Russ Allbery:
> Dirk Heinrichs <[EMAIL PROTECTED]> writes:
> > It's neither in the src nor in the doc tarball, so it's no wonder that
> > Gentoo doesn't install it. Where can I find it?
>
> It's generated during the build process in src/afs/afszcm.cat and
> installed when you do a make dest, but it looks like it was never added to
> make install (probably for lack of a good location in which to put it).  I
> fixed that for the Debian packages, but didn't come up with a clean patch
> and hence haven't found a way to merge it upstream yet.

OK, found it on an Ubuntu system and copied it over. So here's a new fstrace 
dump.

Again, the command was:

% LANG="" ll /afs/grand.central.org/
ls: cannot access /afs/grand.central.org/local: No such file or directory
ls: cannot access /afs/grand.central.org/software: No such file or directory
total 14K
drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
d? ? ??   ?? local/
drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
d? ? ??   ?? software/
drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/

Bye...

Dirk
AFS Trace Dump -

   Date: Wed Sep 26 18:58:45 2007

Found 1 logs.

Contents of log cmfx:
time 956.767009, pid 20043: Access vp 0xc2fc3c40 mode 0x40 len (0x0, 0x3800) 
time 956.767020, pid 20043: Getattr vp 0xc2fc3040 len (0x0, 0x1c) 
time 956.767036, pid 20043: Access vp 0xc2fc3c40 mode 0x40 len (0x0, 0x3800) 
time 956.767539, pid 20043: Access vp 0xc2fc3c40 mode 0x40 len (0x0, 0x3800) 
time 956.767543, pid 20043: Access vp 0xc2fc3040 mode 0x100 len (0x0, 0x1c) 
time 956.767554, pid 20043: Open 0xc2fc3040 flags 0x18800 
time 956.767557, pid 20043: Open 0xc2fc3240 flags 0xf423f 
time 956.767560, pid 20043: Getattr vp 0xc2fc3040 len (0x0, 0x1c) 
time 956.767576, pid 20043: GetdCache vp 0xc2fc3240 dcache 0xf9c83b60 dcache low-version 0xe, vcache low-version 0xe 
time 956.767577, pid 20043: GetdCache tlen 0x800 flags 0x1 abyte (0x0, 0x0) Position (0x0, 0x0) 
time 956.767597, pid 20043: Access vp 0xc2fc3c40 mode 0x40 len (0x0, 0x3800) 
time 956.767599, pid 20043: Access vp 0xc2fc3040 mode 0x40 len (0x0, 0x1c) 
time 956.767606, pid 20043: GetdCache vp 0xc2fc3240 dcache 0xf9c83b60 dcache low-version 0xe, vcache low-version 0xe 
time 956.767607, pid 20043: GetdCache tlen 0x800 flags 0x1 abyte (0x0, 0x0) Position (0x0, 0x0) 
time 956.767611, pid 20043: Lookup adp 0xc2fc3240 name archive fid (174:536870913.2.2), code=0 
time 956.767616, pid 20043: Mount point is to vp 0xc2fc3440 fid (174:536870913.2.2) 
time 956.767620, pid 20043: Getattr vp 0xd176e280 len (0x0, 0x800) 
time 956.767623, pid 20043: Access vp 0xc2fc3c40 mode 0x40 len (0x0, 0x3800) 
time 956.767625, pid 20043: Access vp 0xc2fc3040 mode 0x40 len (0x0, 0x1c) 
time 956.767630, pid 20043: GetdCache vp 0xc2fc3240 dcache 0xf9c83b60 dcache low-version 0xe, vcache low-version 0xe 
time 956.767631, pid 20043: GetdCache tlen 0x800 flags 0x1 abyte (0x0, 0x0) Position (0x0, 0x0) 
time 956.767632, pid 20043: Lookup adp 0xc2fc3240 name archive fid (174:536870913.2.2), code=0 
time 956.767635, pid 20043: Mount point is to vp 0xc2fc3440 fid (174:536870913.2.2) 
time 956.767642, pid 20043: Access vp 0xc2fc3c40 mode 0x40 len (0x0, 0x3800) 
time 956.767644, pid 20043: Access vp 0xc2fc3040 mode 0x40 len (0x0, 0x1c) 
time 956.767651, pid 20043: GetdCache vp 0xc2fc3240 dcache 0xf9c83b60 dcache low-version 0xe, vcache low-version 0xe 
time 956.767652, pid 20043: GetdCache tlen 0x800 flags 0x1 abyte (0x0, 0x0) Position (0x0, 0x0) 
time 956.767655, pid 20043: Lookup adp 0xc2fc3240 name local fid (174:536870913.587202568.0), code=2 
time 956.767656, pid 20043: Returning code 2 from 19 
time 956.767707, pid 20043: Access vp 0xc2fc3c40 mode 0x40 len (0x0, 0x3800) 
time 956.767709, pid 20043: Access vp 0xc2fc3040 mode 0x40 len (0x0, 0x1c) 
time 956.767728, pid 20043: GetdCache vp 0xc2fc3240 dcache 0xf9c83b60 dcache low-version 0xe, vcache low-version 0xe 
time 956.767729, pid 20043: GetdCache tlen 0x800 flags 0x1 abyte (0x0, 0x0) Position (0x0, 0x0) 
time 956.767731, pid 20043: Lookup adp 0xc2fc3240 name doc fid (174:536870913.6.4), code=0 
time 956.767734, pid 20043: Mount point is to vp 0xc2fc3840 fid (174:536870913.6.4) 
time 956.767737, pid 20043: Getattr vp 0xd176e080 len (0x0, 0x800) 
time 956.767740, pid 20043: Access vp 0xc2fc3c40 mode 0x40 len (0x0, 0x3800) 
time 956.767742, pid 20043: Access vp 0xc2fc3040 mode 0x40 len (0x0, 0x1c) 
time 956.767746, pid 20043: GetdCache vp 0xc2fc3240 dcache 0xf9c83b60 dcache low-version 0xe, vcache low-version 0xe 
time 956.767748, pid 20043: GetdCache tlen 0x800 flags 0x1 abyte (0x0, 0x0) Position (0x0, 0x0) 
time 956.767749, pid 20043: Lookup adp 0xc2fc3240 name doc fid (174:536870913.6.4), code=0 
time 956.76775

Re: [OpenAFS] Strange access problems on one client

[Frank Burkhardt]

Hi,

On Mon, Sep 24, 2007 at 10:31:35PM -0700, Russ Allbery wrote:

[snip]

> It looks like this is Linux kernel breakage.  According to a Debian bug
> reporter with the same problem, it appears to reliably trigger on x86 with
> 2.6.22.6, and reliably not trigger with 2.6.22.5.

I tested with 2.6.22.5 (+ xen-patches) and the problem is the same.

Regards,

Frank
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Russ Allbery]

Dirk Heinrichs <[EMAIL PROTECTED]> writes:

> It's neither in the src nor in the doc tarball, so it's no wonder that
> Gentoo doesn't install it. Where can I find it?

It's generated during the build process in src/afs/afszcm.cat and
installed when you do a make dest, but it looks like it was never added to
make install (probably for lack of a good location in which to put it).  I
fixed that for the Debian packages, but didn't come up with a clean patch
and hence haven't found a way to merge it upstream yet.

-- 
Russ Allbery ([EMAIL PROTECTED]) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Dirk Heinrichs]

Am Dienstag, 25. September 2007 schrieb Dirk Heinrichs:
> Am Dienstag, 25. September 2007 schrieb Russ Allbery:
> > Dirk Heinrichs <[EMAIL PROTECTED]> writes:
> > > Am Dienstag, 25. September 2007 schrieb Derrick Brashear:
> > >> Having fstrace output might help here.
> > >
> > > Find it attached.
> >
> > It looks like you don't have afszcm.cat installed where fstrace expects
> > to find it, so you're not getting translation of operations into what the
> > operation actually is.
>
> # locate afszcm.cat
> /usr/share/doc/openafs-1.4.4_p20070724-r1/man-pages/man5/afszcm.cat.5
> /usr/share/doc/openafs-1.4.4_p20070724-r1/man-pages/pod5/afszcm.cat.pod
> /usr/share/man/man5/afszcm.cat.5
>
> Hmm, seems like the Gentoo package only installs its documentation.

It's neither in the src nor in the doc tarball, so it's no wonder that Gentoo 
doesn't install it. Where can I find it?

Bye...

Dirk


signature.asc
Description: This is a digitally signed message part.

Re: [OpenAFS] Strange access problems on one client

[Dirk Heinrichs]

Am Dienstag, 25. September 2007 schrieb Russ Allbery:
> Dirk Heinrichs <[EMAIL PROTECTED]> writes:
> > Am Dienstag, 25. September 2007 schrieb Derrick Brashear:
> >> Having fstrace output might help here.
> >
> > Find it attached.
>
> It looks like you don't have afszcm.cat installed where fstrace expects to
> find it, so you're not getting translation of operations into what the
> operation actually is.

# locate afszcm.cat
/usr/share/doc/openafs-1.4.4_p20070724-r1/man-pages/man5/afszcm.cat.5
/usr/share/doc/openafs-1.4.4_p20070724-r1/man-pages/pod5/afszcm.cat.pod
/usr/share/man/man5/afszcm.cat.5

Hmm, seems like the Gentoo package only installs its documentation. Need to 
file a bug...

Bye...

Dirk


signature.asc
Description: This is a digitally signed message part.

Re: [OpenAFS] Strange access problems on one client

[Russ Allbery]

Dirk Heinrichs <[EMAIL PROTECTED]> writes:
> Am Dienstag, 25. September 2007 schrieb Derrick Brashear:

>> Having fstrace output might help here.

> Find it attached.

It looks like you don't have afszcm.cat installed where fstrace expects to
find it, so you're not getting translation of operations into what the
operation actually is.

-- 
Russ Allbery ([EMAIL PROTECTED]) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Dirk Heinrichs]

Am Dienstag, 25. September 2007 schrieb Derrick Brashear:

> Having fstrace output might help here.

Find it attached.

Bye...

Dirk
AFS Trace Dump -

   Date: Tue Sep 25 21:55:33 2007

Found 1 logs.

Contents of log cmfx:
time 888.201037, pid 0: Tue Sep 25 21:54:32 2007


raw op 701087822, time 888.201037, pid 31983
p0:0xda82cc40 p1:64 p2:0.3800 
raw op 701087790, time 888.201060, pid 31983
p0:0xda82cc40 p1:0xf9c83c00 p2:176 p3:176 
raw op 701087791, time 888.201063, pid 31983
p0:14336 p1:1 p2:0.0 p3:0.0 
raw op 701087758, time 888.201085, pid 31983
p0:0xda82cc40 p1:1.1.1.1 p2:0.0 p3:9 
raw op 701087823, time 888.219916, pid 31983
p0:0xda82cc40 p1:grand.central.org p2:1.1.16777908.1 p3:0 
raw op 701087760, time 888.219952, pid 31983
p0:0xda82c040 p1:0.0 p2:0.1c 
raw op 701087820, time 888.219958, pid 31983
p0:0xda82c040 p1:0.1c 
raw op 701087820, time 888.219976, pid 31983
p0:0xda82c040 p1:0.1c 
raw op 701087822, time 888.220029, pid 31983
p0:0xda82cc40 p1:64 p2:0.3800 
raw op 701087822, time 888.221205, pid 31983
p0:0xda82cc40 p1:64 p2:0.3800 
raw op 701087822, time 888.221213, pid 31983
p0:0xda82c040 p1:256 p2:0.1c 
raw op 701087812, time 888.221221, pid 31983
p0:root.cell p1:0xf64cd493 
raw op 701087813, time 888.344912, pid 31983
p0:-1 p1:0xddb9aee0 p2:0 p3:0 
raw op 701087813, time 888.466329, pid 31983
p0:-1 p1:0xe6374a20 p2:0 p3:1001 
raw op 701087813, time 888.586735, pid 31983
p0:-1 p1:0xe6374a20 p2:0 p3:1001 
raw op 701087813, time 888.707222, pid 31983
p0:-1 p1:0xe6374a20 p2:0 p3:1001 
raw op 701087813, time 888.846231, pid 31983
p0:2 p1:0xe6374420 p2:0 p3:1001 
raw op 701087760, time 888.846235, pid 31983
p0:0xda82c240 p1:0.0 p2:0.800 
raw op 701087812, time 888.846269, pid 31983
p0:536870913 p1:0xdf741d0a 
raw op 701087813, time 888.969667, pid 31983
p0:-1 p1:0xddb9aee0 p2:0 p3:0 
raw op 701087813, time 889.003692, pid 31983
p0:2 p1:0xe6374420 p2:0 p3:1001 
raw op 701087760, time 889.003695, pid 31983
p0:0xda82c240 p1:0.800 p2:0.800 
raw op 701087815, time 889.003737, pid 31983
p0:0xda82c040 p1:100352 
raw op 701087815, time 889.003747, pid 31983
p0:0xda82c240 p1:99 
raw op 701087820, time 889.003754, pid 31983
p0:0xda82c040 p1:0.1c 
raw op 701087790, time 889.003801, pid 31983
p0:0xda82c240 p1:0xf9c83b60 p2:14 p3:14 
raw op 701087791, time 889.003803, pid 31983
p0:2048 p1:1 p2:0.0 p3:0.0 
raw op 701087822, time 889.007535, pid 31983
p0:0xda82cc40 p1:64 p2:0.3800 
raw op 701087822, time 889.007542, pid 31983
p0:0xda82c040 p1:64 p2:0.1c 
raw op 701087790, time 889.007557, pid 31983
p0:0xda82c240 p1:0xf9c83b60 p2:14 p3:14 
raw op 701087791, time 889.007559, pid 31983
p0:2048 p1:1 p2:0.0 p3:0.0 
raw op 701087823, time 889.007564, pid 31983
p0:0xda82c240 p1:archive p2:174.536870913.2.2 p3:0 
raw op 701087790, time 889.007568, pid 31983
p0:0xda82c240 p1:0xf9c83b60 p2:14 p3:14 
raw op 701087791, time 889.007570, pid 31983
p0:2048 p1:1 p2:0.0 p3:0.0 
raw op 701087813, time 889.042305, pid 31983
p0:25 p1:0xe6374420 p2:0 p3:1001 
raw op 701087760, time 889.042340, pid 31983
p0:0xda82c440 p1:0.0 p2:0.e 
raw op 701087760, time 889.042344, pid 31983
p0:0xda82c640 p1:0.0 p2:0.c 
raw op 701087760, time 889.042346, pid 31983
p0:0xda82c840 p1:0.0 p2:0.a 
raw op 701087760, time 889.042349, pid 31983
p0:0xda82ca40 p1:0.0 p2:0.e 
raw op 701087760, time 889.042350, pid 31983
p0:0xd9990c80 p1:0.0 p2:0.e 
raw op 701087760, time 889.042352, pid 31983
p0:0xd9990a80 p1:0.0 p2:0.f 
raw op 701087760, time 889.042354, pid 31983
p0:0xd9990880 p1:0.0 p2:0.b 
raw op 701087760, time 889.042356, pid 31983
p0:0xd9990680 p1:0.0 p2:0.a 
raw op 701087760, time 889.042359, pid 31983
p0:0xd9990480 p1:0.0 p2:0.a 
raw op 701087790, time 889.042365, pid 31983
p0:0xda82c440 p1:0xf9c837a0 p2:1 p3:1 
raw op 701087791, time 889.042367, pid 31983
p0:14 p1:0 p2:0.0 p3:0.0 
raw op 701087862, time 889.042370, pid 31983
p0:0xda82c440 p1:0xf9c837a0 p2:0.e 
raw op 701087812, time 889.050126, pid 31983
p0:root.archive p1:0xf31bff01 
raw op 701087813, time 889.172305, pid 31983
p0:-1 p1:0xddb9aee0 p2:0 p3:0 
raw op 701087824, time 889.172350, pid 31983
p0:0xda82c440 p1:174.536870913.2.2 
raw op 701087813, time 889.206696, pid 31983
p0:2 p1:0xe6374420 p2:0 p3:1001 
raw op 701087760, time 889.206698, pid 31983
p0:0xd9990280 p1:969bc40f.9959d18c p2:0.800 
raw op 701087820, time 889.206733, pid 31983
p0:0xd9990280 p1:0.800 
raw op 701087820, time 889.206741, pid 31983
p0:0xd9990280 p1:0.800 
raw op 701087822, time 889.206757, pid 31983
p0:0xda82cc40 p1:64 p2:0.3800 
raw op 701087822, time 889.206765, pid 31983
p0:0xda82c040 p1:64 p2:0.1c 
raw op 701087790, time 889.206781, pid 31983
p0:0xda82c240 p1:0xf9c83b60 p2:14 p3:14 
raw op 701087791, time 889.206782, pid 31983
p0:2048 p1:1 p2:0.0 p3:0.0 
raw op 701087823, time 889.206788, pid 31983
p0:0xda82c240 p1:archive p2:174.536870913.2.2 p3:0 
raw op 701087824, time 889.206794, pid 31983
p0:0xda82c440 p1:174.536870913.2.2 
raw op 701087822, time 889.206824, pid 31983
p0:0xda82cc40 p1:

Re: [OpenAFS] Strange access problems on one client

[Derrick Brashear]

On 9/25/07, Russ Allbery <[EMAIL PROTECTED]> wrote:
>
> Dirk Heinrichs <[EMAIL PROTECTED]> writes:
>
> > since I got a mail from another person who had this same problem, I
> > would like to follow up on this. Here's what I wrote back in august:
>
> [...]
>
> > The problem seems to be independent of the server(s) or cell, because it
> > also happens when I try to access public cells on the internet, running
> > completely unauthenticated, like:
>
> > [EMAIL PROTECTED] ~ % LANG="" ll /afs/grand.central.org/
> > ls: cannot access /afs/grand.central.org/local: No such file or
> directory
> > ls: cannot access /afs/grand.central.org/software: No such file or
> directory
> > total 14K
> > drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
> > drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
> > drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
> > ?? ? ??   ?? local
> > drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
> > drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
> > ?? ? ??   ?? software
> > drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
> > drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/
>
> [...]
>
> > Kernel: Vanilla 2.6.22.7
> > OpenAFS: Gentoo Package openafs-kernel-1.4.4_p20070724-r2
>
> It looks like this is Linux kernel breakage.  According to a Debian bug
> reporter with the same problem, it appears to reliably trigger on x86 with
> 2.6.22.6, and reliably not trigger with 2.6.22.5.  He's seeing the problem
> on x86_64 on both 2.6.22.5 and 2.6.22.7, but this wouldn't be the first
> time that something changed on x86_64 first.
>
> I haven't had a chance to double-check that I'm *not* seeing this on my
> x86_64 system with an older kernel, but I know I wasn't earlier.
>
> I have no idea what might have broken.


Having fstrace output might help here.

Re: [OpenAFS] Strange access problems on one client

[Dale Ghent]

On Sep 25, 2007, at 1:31 AM, Russ Allbery wrote:



It looks like this is Linux kernel breakage.  According to a Debian  
bug
reporter with the same problem, it appears to reliably trigger on  
x86 with
2.6.22.6, and reliably not trigger with 2.6.22.5.  He's seeing the  
problem
on x86_64 on both 2.6.22.5 and 2.6.22.7, but this wouldn't be the  
first

time that something changed on x86_64 first.


FWIW, we've had a report or two come in about this same and  
apparently highly intermittent problem, only on RHEL5 (2.6.18-8.1.8.el5)


/dale

--
Dale Ghent
Specialist, Storage and UNIX Systems
UMBC - Office of Information Technology
ECS 201 - x51705



___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Russ Allbery]

Dirk Heinrichs <[EMAIL PROTECTED]> writes:

> since I got a mail from another person who had this same problem, I
> would like to follow up on this. Here's what I wrote back in august:

[...]

> The problem seems to be independent of the server(s) or cell, because it
> also happens when I try to access public cells on the internet, running
> completely unauthenticated, like:

> [EMAIL PROTECTED] ~ % LANG="" ll /afs/grand.central.org/
> ls: cannot access /afs/grand.central.org/local: No such file or directory
> ls: cannot access /afs/grand.central.org/software: No such file or directory
> total 14K
> drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
> drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
> drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
> ?? ? ??   ?? local
> drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
> drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
> ?? ? ??   ?? software
> drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
> drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/

[...]

> Kernel: Vanilla 2.6.22.7
> OpenAFS: Gentoo Package openafs-kernel-1.4.4_p20070724-r2

It looks like this is Linux kernel breakage.  According to a Debian bug
reporter with the same problem, it appears to reliably trigger on x86 with
2.6.22.6, and reliably not trigger with 2.6.22.5.  He's seeing the problem
on x86_64 on both 2.6.22.5 and 2.6.22.7, but this wouldn't be the first
time that something changed on x86_64 first.

I haven't had a chance to double-check that I'm *not* seeing this on my
x86_64 system with an older kernel, but I know I wasn't earlier.

I have no idea what might have broken.

-- 
Russ Allbery ([EMAIL PROTECTED]) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Jeffrey Altman]

Todd M. Lewis wrote:
> 
> 
> Harald Barth wrote:
>>> [EMAIL PROTECTED] ~ % LANG="" ll /afs/grand.central.org/
>>> ls: cannot access /afs/grand.central.org/local: No such file or
>>> directory
>>> ls: cannot access /afs/grand.central.org/software: No such file or
>>> directory
>>> total 14K
>>> drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
>>> drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
>>> drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
>>> ?? ? ??   ?? local
>>> drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
>>> drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
>>> ?? ? ??   ?? software
>>> drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
>>> drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/
>>
>> That is really strange because I can't see why doc should differ from
>> software. Both are mountpoints with similar ACL and permissions.
> 
> If I had to take a wild guess, I'd say clock drift. Your client's clock
> is far enough off that your token is seen as valid for some servers, but
> invalid for others. I'm guessing that your servers are not totally in
> sync either, maybe just a few seconds or a couple of minutes off, but
> your client's clock is probably right at the edge of too far off.
> 
> You may not have access to the servers themselves, but before you go
> fixing anything else it would be interesting to know what servers "doc"
> and "software" are on vs. the other mountpoints that listed okay.

I'm not experiencing this problem but based upon the previous reports
the problems occur when there are no tokens involved for the cell.

The cell described above is grand.central.org.  The volumes are
root.cell.readonly, root.doc.readonly, root.local.readonly and
root.software.readonly.

All of the volumes except root.doc.readonly are replicated across three
machines: andrew.e.kth.se PENN.CENTRAL.ORG GRAND-OPENING.MIT.EDU.
root.doc.readonly is replicated across two servers: PENN.CENTRAL.ORG
GRAND-OPENING.MIT.EDU

I do not see how clock drift would be involved.

Jeffrey Altman





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OpenAFS] Strange access problems on one client

[Todd M. Lewis]

Harald Barth wrote:

[EMAIL PROTECTED] ~ % LANG="" ll /afs/grand.central.org/
ls: cannot access /afs/grand.central.org/local: No such file or directory
ls: cannot access /afs/grand.central.org/software: No such file or directory
total 14K
drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
?? ? ??   ?? local
drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
?? ? ??   ?? software
drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/


That is really strange because I can't see why doc should differ from
software. Both are mountpoints with similar ACL and permissions.


If I had to take a wild guess, I'd say clock drift. Your client's clock is 
far enough off that your token is seen as valid for some servers, but 
invalid for others. I'm guessing that your servers are not totally in sync 
either, maybe just a few seconds or a couple of minutes off, but your 
client's clock is probably right at the edge of too far off.


You may not have access to the servers themselves, but before you go 
fixing anything else it would be interesting to know what servers "doc" 
and "software" are on vs. the other mountpoints that listed okay.

--
+--+
   / [EMAIL PROTECTED]  919-445-9302  http://www.unc.edu/~utoddl /
  /   "I have never killed a man, but I have read many   /
 /  obituaries with great pleasure." - Clarence Darrow  /
+--+
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Dirk Heinrichs]

Am Montag, 24. September 2007 schrieb ext Frank Burkhardt:

> On Mon, Sep 24, 2007 at 06:41:31AM +0200, Harald Barth wrote:
> > > [EMAIL PROTECTED] ~ % LANG="" ll /afs/grand.central.org/
> > > ls: cannot access /afs/grand.central.org/local: No such file or
> > > directory ls: cannot access /afs/grand.central.org/software: No such
> > > file or directory total 14K
> > > drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
> > > drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
> > > drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
> > > ?? ? ??   ?? local
> > > drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
> > > drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
> > > ?? ? ??   ?? software
> > > drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
> > > drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/
> >
> > That is really strange because I can't see why doc should differ from
> > software. Both are mountpoints with similar ACL and permissions.
>
> I'd like to point out that on my machine not only mountpoints are
> affected but directories and files as well.
>
> Is this the same on your's, Dirk?

Yes, it is.

Bye...

Dirk
-- 
Dirk Heinrichs  | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: [EMAIL PROTECTED]
Wanheimerstraße 68  | Web:  http://www.capgemini.com
D-40468 Düsseldorf  | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net


signature.asc
Description: This is a digitally signed message part.

Re: [OpenAFS] Strange access problems on one client

[Frank Burkhardt]

Hi,

On Mon, Sep 24, 2007 at 06:41:31AM +0200, Harald Barth wrote:
> 
> > [EMAIL PROTECTED] ~ % LANG="" ll /afs/grand.central.org/
> > ls: cannot access /afs/grand.central.org/local: No such file or directory
> > ls: cannot access /afs/grand.central.org/software: No such file or directory
> > total 14K
> > drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
> > drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
> > drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
> > ?? ? ??   ?? local
> > drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
> > drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
> > ?? ? ??   ?? software
> > drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
> > drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/
> 
> That is really strange because I can't see why doc should differ from
> software. Both are mountpoints with similar ACL and permissions.

I'd like to point out that on my machine not only mountpoints are
affected but directories and files as well.

Is this the same on your's, Dirk?

Regards,

Frank
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Dirk Heinrichs]

Am Montag, 24. September 2007 schrieb ext Harald Barth:
> > [EMAIL PROTECTED] ~ % LANG="" ll /afs/grand.central.org/
> > ls: cannot access /afs/grand.central.org/local: No such file or
> > directory ls: cannot access /afs/grand.central.org/software: No such
> > file or directory total 14K
> > drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
> > drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
> > drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
> > ?? ? ??   ?? local
> > drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
> > drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
> > ?? ? ??   ?? software
> > drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
> > drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/
>
> That is really strange because I can't see why doc should differ from
> software. Both are mountpoints with similar ACL and permissions.
>
> > Kernel: Vanilla 2.6.22.7
> > OpenAFS: Gentoo Package openafs-kernel-1.4.4_p20070724-r2
>
> My most up to date gentoo box is at
>2.6.21-gentoo-r2
>1.4.4
> And I'm _not_ seeing this.

Hmm, whould be nice to know what the others who see this problem are 
running.

> I have not figured out the diff between 1.4.4 and 1.4.4_p20070724, is
> there an easy way to do that without emerging first one ans then the
> other?

By comparing the ebuilds, one can see that 1.4.4_p20070724-r2 adds thre more 
patches. Two are architecture related (sparc and ppc), the third one seems 
to add CVS stuff.

Bye...

Dirk
-- 
Dirk Heinrichs  | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: [EMAIL PROTECTED]
Wanheimerstraße 68  | Web:  http://www.capgemini.com
D-40468 Düsseldorf  | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net


signature.asc
Description: This is a digitally signed message part.

Re: [OpenAFS] Strange access problems on one client

[Harald Barth]

> [EMAIL PROTECTED] ~ % LANG="" ll /afs/grand.central.org/
> ls: cannot access /afs/grand.central.org/local: No such file or directory
> ls: cannot access /afs/grand.central.org/software: No such file or directory
> total 14K
> drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
> drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
> drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
> ?? ? ??   ?? local
> drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
> drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
> ?? ? ??   ?? software
> drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
> drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/

That is really strange because I can't see why doc should differ from
software. Both are mountpoints with similar ACL and permissions.

> Kernel: Vanilla 2.6.22.7
> OpenAFS: Gentoo Package openafs-kernel-1.4.4_p20070724-r2

My most up to date gentoo box is at
   2.6.21-gentoo-r2
   1.4.4
And I'm _not_ seeing this.

I have not figured out the diff between 1.4.4 and 1.4.4_p20070724, is
there an easy way to do that without emerging first one ans then the
other?

Harald.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Frank Burkhardt]

Hi,

I'm having a similiar problem.

On Sun, Sep 23, 2007 at 09:54:31AM +0200, Dirk Heinrichs wrote:
> Hello,
> 
> since I got a mail from another person who had this same problem, I would 
> like 
> to follow up on this. Here's what I wrote back in august:

[snip]

> > [EMAIL PROTECTED] ~ % LANG="" ll /afs/altum.de
> > ls: cannot access /afs/altum.de/music: No such file or directory
> > ls: cannot access /afs/altum.de/cells: No such file or directory
> > total 4.0K
> > d? ? ? ??? cells/
> > drwx-- 2 heini users 2.0K Jun 29 20:10 data/
> > drwx-- 2 root  root  2.0K Sep  1  2006 home/
> > d? ? ? ??? music/

Same here: some directories _and files_ are un-stat()-able although they're
listed by readdir() - i can't see a pattern. It's not a permission problem:
the problem includes files and directories with system:anyuser=rl .

I had a similiar problem some years ago when I used XFS as cache-partition
but this time it's ext2 - I swear.

This is what I use:
   * Debian Unstable (Sid)
   * in a Xen domain (domU)
   * Openafs 1.4.4 (exact debian version is 1.4.4.dfsg1-7) (*1)
   * Vanilla kernel 2.6.22.7 + Xen Patch (*2)
   * afsd options automatically chosen

(*1) The debian-openafs-package afaik contains several patches but it
 runs fine on a non-xenified (vanilla) kernel 2.6.22.2.
(*2) The xen patch was "stolen" from ubuntu gutsy's linux-kernel-2.6.22 package.
 It's available at ftp://fbo.no-ip.org/t/xen-2.6.22.diff.gz .

I had the same problem with kernel 2.6.18 which was downloaded and patched
automatically during the xen-3.1 build process.

First I though of xen as the guilty piece of software, until I read Dirk's
post.

Does anyone have a clue, what this might be? How can help debugging this?

Regards,

Frank

-- 
Frank Burkhardt <[EMAIL PROTECTED]>   phone: +49 341 9940-142
Max Planck Institute for Human /"\
Cognitive and Brain Sciences   \ / ASCII Ribbon Campain
Leipzig, GermanyX  against HTML Mail
+- / \ ---+
| GPG: 6DCA A8BA 4DBD 14EE 7D4C  3F0C A015 6284 7146 EC5F |
+-+
 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Strange access problems on one client

[Dirk Heinrichs]

Hello,

since I got a mail from another person who had this same problem, I would like 
to follow up on this. Here's what I wrote back in august:

> I'm currently facing strange behaviour on one client machine, which
> looks like:
>
> [EMAIL PROTECTED] ~ % kinit
> Password for [EMAIL PROTECTED]:
> [EMAIL PROTECTED] ~ % aklog
> [EMAIL PROTECTED] ~ % tokens
>
> Tokens held by the Cache Manager:
>
> User's (AFS ID 1001) tokens for [EMAIL PROTECTED] [Expires Aug 13 16:42]
>--End of list--
> [EMAIL PROTECTED] ~ % id
> uid=3D1001(heini) gid=3D100(users)
> Gruppen=3D10(wheel),12(mail),14(uucp),16= (cron),18
> (audio),19(cdrom),35(games),80(cdrw),100(users),441(plugdev),442(camera),45
>3 (hibernate)
> [EMAIL PROTECTED] ~ % LANG="" ll /afs/altum.de
> ls: cannot access /afs/altum.de/music: No such file or directory
> ls: cannot access /afs/altum.de/cells: No such file or directory
> total 4.0K
> d? ? ? ??? cells/
> drwx-- 2 heini users 2.0K Jun 29 20:10 data/
> drwx-- 2 root  root  2.0K Sep  1  2006 home/
> d? ? ? ??? music/
> [EMAIL PROTECTED] ~ % LANG="" ll /afs/altum.de/home
> ls: cannot access /afs/altum.de/home/heini: No such file or directory
> ls: cannot access /afs/altum.de/home/heike: No such file or directory
> ls: cannot access /afs/altum.de/home/chris: No such file or directory
> total 2.0K
> ??  ? ???? chris
> ??  ? ???? heike
> ??  ? ???? heini
> drwx-- 12 niki users 2.0K May 17 13:38 niki/
>
> When I login to another machine, everything is just fine:
>
> [EMAIL PROTECTED] ~ % slogin rohan
> [EMAIL PROTECTED]'s password:
> Linux rohan 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i586
>
> The programs included with the Ubuntu system are free software;
> the exact distribution terms for each program are described in the
> individual files in /usr/share/doc/*/copyright.
>
> Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
> applicable law.
> Last login: Sun Aug 12 11:24:54 2007
>
> rohan% tokens
>
> Tokens held by the Cache Manager:
>
> User's (AFS ID 1001) tokens for [EMAIL PROTECTED] [Expires Aug 13 16:45]
>--End of list--
> rohan% pwd
> /afs/altum.de/home/heini
> rohan% ll ..
> insgesamt 36K
> drwx--  12 chris users 2,0K 2007-05-17 13:43 chris/
> drwx--  21 heike users 4,0K 2006-09-01 20:08 heike/
> drwxr-xr-x 139 heini users  28K 2007-08-12 11:45 heini/
> drwx--  12 niki  users 2,0K 2007-05-17 13:38 niki/
> rohan% fs la .
> Access list for . is
> Normal rights:
>   heini rlidwka
> rohan% ll /afs/altum.de
> insgesamt 8,0K
> drwx-- 2 root  root  2,0K 2006-08-27 14:10 cells/
> drwx-- 2 heini users 2,0K 2007-06-29 20:10 data/
> drwx-- 2 root  root  2,0K 2006-09-01 17:41 home/
> drwx-- 3 heini users 2,0K 2007-03-24 16:08 music/
> rohan% id
> uid=1001(heini) gid=100(users)
> Gruppen=4(adm),20(dialout),24(cdrom),25
> (floppy),29(audio),30(dip),44(video),46(plugdev),100(users),104(scanner),11
>2 (netdev),113(lpadmin),115(powerdev),117(admin),1103024598
>
> OpenAFS version is 1.4.4 on both, Linux kernel version on gondolin is
> 2.6.22.1. I already tried to recreate the cache by creating a new
> filesystem on the cache manager partition, but that didn't help.

The problem seems to be independent of the server(s) or cell, because it also 
happens when I try to access public cells on the internet, running completely 
unauthenticated, like:

[EMAIL PROTECTED] ~ % LANG="" ll /afs/grand.central.org/
ls: cannot access /afs/grand.central.org/local: No such file or directory
ls: cannot access /afs/grand.central.org/software: No such file or directory
total 14K
drwxrwxrwx 3 root root 2.0K Jun 17  2004 archive/
drwxrwxrwx 2 root root 2.0K May  7  2006 cvs/
drwxrwxrwx 3 root root 2.0K Mar 21  2003 doc/
?? ? ??   ?? local
drwxrwxrwx 2 root root 2.0K Jun 17  2005 project/
drwxrwxrwx 5 root root 2.0K Jan 30  2007 service/
?? ? ??   ?? software
drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/
drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/

The client has been started like this:

/usr/sbin/afsd -fakestat -stat 2000 -dcache 800 -daemons 3 -volumes 
70 -verbose -debug -dynroot

Which, except for -verbose and -debug, is the default I get from the Gentoo 
init script, which sets the values based on the cache size.

Version info:

Kernel: Vanilla 2.6.22.7
OpenAFS: Gentoo Package openafs-kernel-1.4.4_p20070724-r2

Bye...

Dirk


signature.asc
Description: This is a digitally signed message part.

Re: [OpenAFS] Strange access problems on one client

[Dirk Heinrichs]

Am Sonntag, 12. August 2007 schrieb Jeffrey Altman:
> What version of AFS is on the file servers?

It's also 1.4.4, Ubuntu Feisty.

> How are tokens being obtained on rohan?

Via PAM at login time (pam_krb5 + pam_openafs_session).

> Do you have the same issues if 
> you using kinit / aklog ?

You mean on rohan? No.

Bye...

Dirk


signature.asc
Description: This is a digitally signed message part.

Re: [OpenAFS] Strange access problems on one client

[Jeffrey Altman]

What version of AFS is on the file servers?

How are tokens being obtained on rohan?   Do you have the same issues if
you using kinit / aklog ?



Dirk Heinrichs wrote:
> Hi,
> 
> I'm currently facing strange behaviour on one client machine, which looks 
> like:

...

> OpenAFS version is 1.4.4 on both, Linux kernel version on gondolin is 
> 2.6.22.1. I already tried to recreate the cache by creating a new filesystem 
> on the cache manager partition, but that didn't help.
> 
> Any ideas what can be wrong?
> 
> Thanks...
> 
>   Dirk


smime.p7s
Description: S/MIME Cryptographic Signature