xfs
[Top] [All Lists]

Re: xfs and openafs problem

To: Willi Langenberger <wlang@xxxxxxxxxxxxx>
Subject: Re: xfs and openafs problem
From: Eric Sandeen <sandeen@xxxxxxx>
Date: Tue, 23 Jul 2002 11:50:07 -0500 (CDT)
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <15677.25943.919190.769477@slime.wu-wien.ac.at>
Sender: owner-linux-xfs@xxxxxxxxxxx
Willi - 

We're not ignoring you, but we just haven't gotten to this one yet.

If you have kdb enabled, you might check to see what it shows you
for stacks on the hung process; compiling with egcs/kgcc usually
gives you better stacks.

-Eric

On Tue, 23 Jul 2002, Willi Langenberger wrote:

> Hi!
> 
> A few days ago, Jeffrey E. Hundstad wrote:
> > It's too bad that XFS is losing people.
> 
> I agree with that! However, we could be in a situation, where nothing
> else remains... :-(
> 
> As Alexander Bergolth wrote on July 15, we found a problem creating
> large files when using OpenAFS (no answeres yet):
> 
>   http://marc.theaimsgroup.com/?l=linux-xfs&m=102675120214280&w=2
> 
> In short: When using
> 
>   Distribution: XFS-RH 7.3
>   Kernel:       kernel-2.4.18-4SGI_XFS_1.1
>   AFS:          openafs-1.2.5-rh7.3.1
> 
> writing largs files (ie the following command) hangs in the "close" syscall:
> 
>   head -c 700000000 /dev/zero > testfile
> 
> We tried 3 differnt boxes, everyone showed the same.
> 
> strace of the file writing process yields:
> 
>   [<c0128796>] truncate_list_pages [kernel] 0x1f6
>   [<c01287db>] truncate_inode_pages [kernel] 0x3b
>   [<c01a6ec4>] xfs_itruncate_start [kernel] 0x74
>   [<c01bd894>] xfs_inactive_free_eofblocks [kernel] 0x1c4
>   [<c01bdf17>] xfs_release [kernel] 0x97
>   [<c01c8b40>] linvfs_release [kernel] 0x20
>   [<c0139e4d>] fput [kernel] 0x4d
>   [<c0138d73>] filp_close [kernel] 0x53
>   [<c0138dc3>] sys_close [kernel] 0x43
>   [<c0108923>] system_call [kernel] 0x33
> 
> strace of the AFS daemon:
> 
>   [<c011f8e4>] schedule_timeout [kernel] 0x14
>   [<c0116338>] ll_copy_to_user [kernel] 0x38
>   [<c0232f86>] wait_for_packet [kernel] 0xe6
>   [<c0233090>] skb_recv_datagram [kernel] 0xb0
>   [<c0262499>] udp_recvmsg [kernel] 0x59
>   [<c01f19fc>] __make_request [kernel] 0x25c
>   [<c0268059>] inet_recvmsg [kernel] 0x39
>   [<c022df71>] sock_recvmsg [kernel] 0x31
>   [<c018a835>] xfs_bmbt_get_state [kernel] 0x25
>   [<c01826b8>] xfs_bmap_do_search_extents [kernel] 0x348
>   [<f8987b01>] osi_NetReceive [libafs-2.4.18-4SGI_XFS_1.1-i686] 0xbd
>   [<c0182738>] xfs_bmap_search_extents [kernel] 0x48
>   [<c01152a2>] __wake_up [kernel] 0x32
>   [<f89916fe>] afs_osi_Wakeup [libafs-2.4.18-4SGI_XFS_1.1-i686] 0xe
>   [<f89889f9>] rxi_AllocDataBuf [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x2d
>   [<f898841d>] rxk_ReadPacket [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x95
>   [<f8988546>] rxk_Listener [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x6e
>   [<f8993a06>] afs_syscall_call [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x15e
>   [<f89b4dcc>] afs_RX_Running [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x0
>   [<c018a835>] xfs_bmbt_get_state [kernel] 0x25
>   [<c0182626>] xfs_bmap_do_search_extents [kernel] 0x2b6
>   [<c0182738>] xfs_bmap_search_extents [kernel] 0x48
>   [<c0183c8b>] xfs_bmapi [kernel] 0x34b
>   [<c0208a2c>] ide_dmaproc [kernel] 0x1ec
>   [<c01f10fe>] generic_unplug_device [kernel] 0x1e
>   [<c012a4dc>] filemap_nopage [kernel] 0xbc
>   [<c0132135>] __alloc_pages [kernel] 0x75
>   [<c0136aed>] page_remove_rmap [kernel] 0x5d
>   [<c01260c9>] do_wp_page [kernel] 0x229
>   [<c0126886>] handle_mm_fault [kernel] 0x106
>   [<c01143aa>] do_page_fault [kernel] 0x12a
>   [<f8994823>] afs_syscall [libafs-2.4.18-4SGI_XFS_1.1-i686] 0x10b
>   [<c01218c0>] sys_setpriority [kernel] 0x60
>   [<c0108923>] system_call [kernel] 0x33
> 
> Kernel 2.4.9-21SGI_XFS_1.0.2 seems to work fine with AFS (no hangs).
> 
> Also, any other filesystem we tried (ext2, ext3) didn't show this
> effect.
> 
> Has anybody an idea what this could be? What can we do to find out? We
> are willing to make any test in that matter, but we don't know how to
> start.
> 
> AFS is a requirement on our campus, so we cannot abandon it.
> 
> We would be very unhappy if we had to abandon xfs, becaus we think
> it's the best filesystem for linux!
> 
> In any case, thank you _very_ much for your work on xfs!
> 
> 
> \wlang{}
> 
> -- 
> Willi.Langenberger@xxxxxxxxxxxxx                Fax: +43/1/31336/9207
> Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria
> 


<Prev in Thread] Current Thread [Next in Thread>