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