[OpenAFS] Re: Directories not reachable direct after creation - linux 1.6.1

[Lars Schimmer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-07-26 21:30, Andrew Deason wrote:
> On Tue, 17 Jul 2012 13:51:41 +0200 Lars Schimmer
> <l.schimmer@cgv.tugraz.at> wrote:
>=20
>> I got a more or less peristant problem on my debian linux system
>> with OpenAFS 1.6.1 64bit:
>>=20
>> 127 schimmer@tetris /afs/.cgv.tugraz.at/archive/templates %
>> mkdir TUGraz.Formulare
>>=20
>> mkdir: kann Verzeichnis ?TUGraz.Formulare? nicht anlegen: Kein=20
>> passendes Ger=C3=A4t gefunden
>=20
> I assume 'No such device' is a suitable English translation for
> this, yes? Does this take a while (at least a few seconds) to
> execute?

Correct and correct.

> I also assume that the specified name did not already exist (as a
> dir, or file, or mountpoint, or anything).

Correct. All new.

>> Any idea?
>=20
> If there were any messages in the client syslog or the server
> FileLog at around the same time, that information would be
> helpful.

Ok, will see on new event... Does happen from time to time.

> 1.6.1 should contain the client behavior where we invalidate cache=20
> information for a timed-out write op, so it's probably not just
> that (although it's not perfect). If you can get this to happen
> while 'fstrace' tracing is on, that should say exactly what was
> going on at the time. (Something like: fstrace clear cm ; fstrace
> setlog cmfx -buffers 100 ; fstrace sets cm -active ; mkdir whatever
> & echo $! ; wait ; fstrace dump cm > /tmp/fstrace.log ; fstrace
> sets cm -inactive) Note that that traces all client activity, so if
> you've got other AFS-interacting stuff running on the box that you
> don't want to be public information, don't upload that somewhere
> public.
>=20
> And it doesn't really "solve" the problem, but if you see a client
> in that state, you may be able to get it out with a 'fs flush .' in
> the problematic directory (or 'fs flushv' to just flush everyting
> in the vol). 'fs checks' and 'fs checkv' can also be tried, though
> it doesn't seem like that would be the problem here.

I will see at next event.


MfG,
Lars Schimmer
- --=20
- -------------------------------------------------------------
TU Graz, Institut f=C3=BCr ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405       E-Mail: l.schimmer@cgv.tugraz.at
Fax: +43 316 873-5402       PGP-Key-ID: 0x4A9B1723


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

iEYEARECAAYFAlASWMcACgkQmWhuE0qbFyOdyQCeNUOIg7YUbYSJVneWKKgGtjp6
MG0AnjvcD6Z/wbEERLrLX1L81XyQIsYR
=3Dg6k4
-----END PGP SIGNATURE-----