On Tue, Jul 31, 2012 at 5:50 AM, Lars Schimmer <[email protected]> wrote: > -----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ür ComputerGraphik & WissensVisualisierung > Tel: +43 316 873-5405 E-Mail: [email protected] > 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 > =OmV9 > -----END PGP SIGNATURE----- > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info -- Derrick _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
