[OpenAFS] copying files to /afs filesystem hangs on system call close(4)

[Jaime Fournier]

Can you run a tcpdump, or tethereal to see if it's
sending packets?
Maybe committing.
See what packets are being set etc.
I am willing to bet it's the commit on close.
DFS semantics are going to be a lot different.

--- Jamal Green <mgreen@odu.edu> wrote:
> Another Sys Admin and I have the privilege of
> migrating our DCE/DFS 3.1 cell to an AFS cell. We're
> new to AFS and we cant
> seem to figure this one out.
> 
> Currently we're experiencing strange behaviour with
> Redhat LINUX AFS
> clients
> using openafs 1.2.9. We do not seem to have this
> problem with Debian.
> 
> The Redhat client is using Redhat 8.0, kernel
> 2.4.18-27 and openafs 1.2.9.
> We ran an strace while copying a 12MB file (a
> tarred/gzipped file) from a
> directory on an ext2 filesystem
> and we see the file being copied and written without
> a problem (and very
> quickly I
> might add)...then this happens:
> 
> [420d6948] read(3,
>
"\255\6\3602\211\35\r\216qB4\206\'\23#\21\245G\215\266N"...,
> 4096) = 4096
> [420d69c8] write(4,
>
"\255\6\3602\211\35\r\216qB4\206\'\23#\21\245G\215\266N"...,
> 4096) = 4096
> [420d6948] read(3,
>
"\201q\\.\312\31\233*r\10+\306\253\5(\324\363\353\346\n"...,
> 4096) = 4096
> [420d69c8] write(4,
>
"\201q\\.\312\31\233*r\10+\306\253\5(\324\363\353\346\n"...,
> 4096) = 4096
> [420d6948] read(3,
>
"2\235U\332\351\33\315\261\27\230Y\f*w\2\3016\353t\314k"...,
> 4096) = 1129
> [420d69c8] write(4,
>
"2\235U\332\351\33\315\261\27\230Y\f*w\2\3016\353t\314k"...,
> 1129) = 1129
> [420d6948] read(3, "", 4096)            = 0
> [420d68c1] close(4
> 
> It hangs at the close(4). We have to wait over 10
> minutes for the close to
> complete. We've searched but we can't seem to find a
> solution to this
> particular problem. Anybody else experienced this
> and found a work around?
> 
> We initially thought it was a caching problem
> because the cache wound up on
> an
> ext3 filesystem. We rebuilt the workstation to use
> ext2 only but that
> hasn't
> fixed it. We also think it's a timeout of some type,
> but again we're not
> experienced
> enough with AFS to know for sure.
> 
> Any help or pointing in the right direction would be
> GREATLY appreciated as
> we
> are under the gun to migrate our entire cell by the
> end of the summer.
> 
> Thanks!
> 
> M. Jamal Green
> UNIX Systems Administrator
> Office of Computing and Communications Services
> UNIX Support Group
> [phone]:757-683-3678
> [fax]:757-683-5155
> http://www.lions.odu.edu
> 
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

=====
Jaime Fournier

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com