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

[Lars Schimmer]

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

On 2012-07-26 21:30, Andrew Deason wrote:

> 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?

A few seconds.

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

No, complete new.

>> Any idea?

Got another incident:
fs mkmount extern user.extern
fs:'extern': No such device



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

Ok, no entries syslog on local client, on fileserver only a line
Tue Jul 31 11:38:38 2012 1 Volser: CreateVolume: volume 1702200769
(user.extern) created

does appear aboiut this new volume.
It was in between a:
Tue Jul 31 11:37:14 2012 trans 23047 on volume 1702195000 is older
than 720 seconds
Tue Jul 31 11:37:44 2012 trans 23047 on volume 1702195000 is older
than 750 seconds
Tue Jul 31 11:38:14 2012 trans 23047 on volume 1702195000 is older
than 780 seconds
Tue Jul 31 11:38:38 2012 1 Volser: CreateVolume: volume 1702200769
(user.extern) created
Tue Jul 31 11:38:44 2012 trans 23047 on volume 1702195000 is older
than 810 seconds
Tue Jul 31 11:39:14 2012 trans 23047 on volume 1702195000 is older
than 840 seconds
Tue Jul 31 11:39:44 2012 trans 23047 on volume 1702195000 is older
than 870 seconds




> 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.

Ok, fstrace made with that problem occuring:
http://tetris.cgv.tugraz.at/afs/fstrace.31.07.2012.txt

> 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.

A fs flush did not help.
A fs flushv did helped and I can access the new mounted volume.

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/

iEYEARECAAYFAlAXqlQACgkQmWhuE0qbFyOSngCdF2BYIyl3vdhSU2DMotZAK6OS
S5YAnjJ8kR1ZMF8ZyMOo3HssNF6gAjUS
=3DOmV9
-----END PGP SIGNATURE-----