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

[Derrick Brashear]

On Tue, Jul 31, 2012 at 5:50 AM, Lars Schimmer <l.schimmer@cgv.tugraz.at> w=
rote:
> -----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
>> 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

the trace shows ENOENT for extern, and later symlink succeeds for extern2
we never see 1702200769 via a GetVolumeByName nor indeed anything.
when did the fstrace run from and to (did your mount point succeed
while it was running?)
what existed before and what commands were run, where?

>> 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
> - --
> - -------------------------------------------------------------
> TU Graz, Institut f=FCr 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-----
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info



--=20
Derrick