chas williams - CONTRACTOR wrote:
linux's vfs isnt very much like irix, osf, aix or solaris. it
revolves around the dentry instead of the inode. since most ports
of afs have been to bsd derived vfs filesystems, there are few
alternative filesystems to examine.
Agreed. I just wanted to remark that the various approaches to adapt
the AFS client to other systems all have their share of ad hoc
decisions, a "perhaps"es and are not always crystal clean (think about
whose credentials are used when pages are written out asynchronously).
The fact that in Linux inodes are somehow grafted on dentries doesn't
make things easy of course - e.g. when it comes to running the cache
on tmpfs...
A relatively kernel-unspecific way would be to queue an event that is
handled "later" by somebody running near top level. The question is a)
how to queue without a lock and b) whether sometimes things must
what would be queued? checking the inode to see if its time to go away
or the decrement of the refCount? queuing a .put_inode() probably isnt
a good idea. sleeping in .put_inode() seems to be allowed, but the
documentation for .put_inode() isn't quite right either:
in put_inode (or after your patch in dentry_iput) you need to clean
up, i.e. call afs_InactiveVCache(). For that you need the global lock
- which you cannot always obtain e.g. if you hold it already.
(BTW: I remember one of the comments around afs_InactiveVCache() says
no locks required - that's obviously a lie).
My patch recovers from the failure to acquire the lock - and postpones
the cleanup to better times. It becomes the job of the periodic vcache
sweeper. It could also be handled through a properly managed queue
(with it's own locking), but the sweeper is probably early enough and
that's the easiest solution.
put_inode: called when the VFS inode is removed from the inode
cache. This method is optional
.put_inode() is called for every iput, regardless of whether the
inode is being removed from the cache.
have you tried the patch i sent along in a previous message? hopefully
this should fix the problem (it will certainly take AFS_GLOCK less often).
"less often" is not enough - you'd have to guarantee that you you
never run into it already holding the lock. Or somebody waiting for
"you" holding the lock which can happen in the kmalloc() chain - then
"you" that's "kswapd". I doubt that by moving the call from inode
cleanup to dentry cleanup avoids the scenario altogether.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985 Fax: +41 22 767 7155
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
