chas williams - CONTRACTOR wrote:
not a problem. we are not a small shop. btw, you said this test
"fails" but didnt indicate what the failure mode is.
fails in the sense that the file just copied no longer equals the
original file, i.e. the compare fails. The data at the place where it
starts to differ is data of the same file (or one of its other
copies), meaning this is not a question of unallocated buffers or such.
Anyway, I'm knocking at various portions of the client code and listen
if it sounds hollow. The setup described seems to look artificial but
we've got enough traffic and reported oddities to suspect that it is
also triggered by normal use. At what frequency - no idea.
it should be safe to add an i_sem around the truncate_inodes_pages()
in osi_VM_FlushPages(). there is only one path to osi_VM_FlushPages()
via osi_FlushPages().
...just this handful of calls to osi_FlushPages()...
... Similar suspects like osi_VM_Truncate and
osi_VM_FlushVCache have the same problem - a fast growing tree to
trace back.
osi_VM_FlushVCache() is called as part of recycling an inode for
use. so its typically called in the afs_lookup/afs_create/afs_mkdir
code paths. it also happens to get called during inode and dentry
revalidation. the parent dir's i_sem is held during this operations,
so the new inode's i_sem can probably be taken safely.
osi_VM_Truncate() typically happens when an inode's size changes.
again, very likely safe to just take i_sem here.
it would be pretty easy to just down_trylock() to catch any paths
that might have a double lock and then fix these broken code paths.
I already have a osi_Assert(down_trylock(&ip->i_sem) == 0) in
osi_VM_FlushPages(). So far no smoke. Not a surprise actually.
For the others I was about to try to find out what they're about,
thanks for the hints.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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
