I've reproduced the freeze and figured out where xfs_freeze is stuck, though
I still don't understand why.
xfs_freeze and kupdated seem to be accessing the same pagebuf structure, but
seem to be stuck on different locks.
kupdated is stopped after calling down() inside pagebuf_lock(), presumably
from _pagebuf_find_lockable_buffer(). From the comment in
fs/xfs/pagebuf/page_buf_locking.c, it is waiting for buffer ownership.
xfs_freeze is stopped in pagebuf_iorequest(), specifically inside the inline
_pagebuf_wait_unpin(). From the comment in fs/xfs/pagebuf/pagebuf.c, it
waits until all the memory associated with the buffer is unlocked.
pb_pin_count for the pagebuf structure is 1.
So kupdated can't get a lock, and xfs_freeze is waiting because somebody's
locked the buffer. I don't see the pagebuf address in any other processes'
call stack. The kernel I'm using is rather old code, but the functions
involved don't seem to have changed over the last few months.
Is there a way to tell which process these two are waiting for?
Dale Stephenson
steph@xxxxxxxxxxxxxx
> -----Original Message-----
> From: Dale Stephenson
> Sent: Tuesday, May 21, 2002 12:10 PM
> To: 'linux-xfs@xxxxxxxxxxx'
> Subject: xfs_freeze stuck on filesystem with several snapshots.
>
>
> I'm looking at a machine where xfs_freeze -f is stuck in D
> state. The freeze is done on a filesystem that already has
> three LVM snapshots, and has writes streamed to it over both
> nfs and samba. I have some backtraces from kdb (attached),
> but I'm not quite sure what to make of them. After
> xfs_freeze -f stuck, xfs_freeze -u was tried from the command
> line, and also stuck.
>
> The kernel is from the XFS CVS tree of Mar 19th, using LVM's
> VFS lock patch. It has been patched to exempt certain
> processes coming from being stopped by xfs_check_frozen,
> specifically kupdated and xfs_freeze. knfsd and many smbd
> processes are stopped by xfs_check_frozen, which is fine.
|