[25] in arla-drinkers

home help back first fref pref prev next nref lref last post

Re: with_krbafs broken

daemon@ATHENA.MIT.EDU (Mark W. Eichin)
Mon Jun 22 22:34:44 1998

From arla-drinkers-request@sundance.stacken.kth.se Tue Jun 23 02:34:44 1998
Return-Path: <arla-drinkers-request@sundance.stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 7676 invoked from network); 23 Jun 1998 02:34:43 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
  by bloom-picayune.mit.edu with SMTP; 23 Jun 1998 02:34:43 -0000
Received: from kitten.gen.ma.us (paycheck.thok.org [199.103.225.1])
	by sundance.stacken.kth.se (8.8.8/8.8.8) with SMTP id EAA14359
	for <arla-drinkers@stacken.kth.se>; Tue, 23 Jun 1998 04:29:59 +0200 (MET DST)
Received: (qmail 10428 invoked by uid 3382); 23 Jun 1998 02:29:55 -0000
To: Assar Westerlund <assar@sics.se>
Cc: arla-drinkers@stacken.kth.se
Subject: Re: with_krbafs broken
References: <E0yn3ba-0004cN-00@swat.thok.org> <5llnqqh8xf.fsf@dhcp219.conference.usenix.org>
From: eichin@kitten.gen.ma.us (Mark W. Eichin)
Date: 22 Jun 1998 22:29:55 -0400
In-Reply-To: Assar Westerlund's message of "21 Jun 1998 21:05:48 +0200"
Message-ID: <xe1lnqoalzw.fsf@paycheck.thok.org>
Lines: 40
X-Mailer: Gnus v5.4.56/Emacs 19.34


> BTW, did you have any success with the xfs problems?

Not yet, though I've made several more attempts.  Looking at xfs.o
with gdb and "ptype" shows reasonable looking values for the fields of
struct xfs_attr and some others I spot checked, so that appears to be
in sync (I did switch to 0.7.2 as well, with the same results.)  I've
added some additional logging, and read more code, which taught me
that internally the XFS layer is using addresses of struct xfs_nodes
as inode numbers, but that this looks to be intentional.  (Are there
any "internals" or program flow docs, or do I just have to interrogate
you mercilessly when you get to Boston? :-)

Don't know if I mentioned before but after installing xfs, running
arlad, mounting, stat'ing /afs, unmounting, killing arlad, and
rmmod'ing xfs,  amd (user space amd, not the kernel autofs) is no
longer reacting to requests, though existing NFS mounts are still
up... 

Still, a "stat /afs" does show signs of possible structure size
problems; the device and inode value matches what xfs logs, but the
times and uid are odd...

swat+% stat /afs
  File: "/afs"
  Size: 2          Blocks: 0         Directory
Access: (0777/drwxrwxrwx)         Uid: ( 8192/ UNKNOWN)  Gid: (    0/  root)
Device: 3          Inode: 33211672   Links: 0    
Access: Wed Dec 31 19:00:00 1969
Modify: Wed Dec 31 19:00:00 1969
Change: Sun Sep  6 23:45:55 1992

though the Change time doesn't look particularly serendipitous:
swat+% date +%s --date "1992-09-06 23:45:55"
715837555
swat+% printf "%x\n" 715837555
2aaad073

			_Mark_ <eichin@kitten.gen.ma.us>
			The Herd of Kittens

home help back first fref pref prev next nref lref last post