Hi Chris -
Want to try this?
--- /usr/tmp/TmpDir.12545-0/linux/fs/xfs/xfs_fsops.c_1.72 Fri Feb 1
15:33:39 2002
+++ linux/fs/xfs/xfs_fsops.c Fri Feb 1 15:33:51 2002
@@ -563,9 +563,6 @@
/* Flush delalloc and delwri data */
VFS_SYNC(vfsp, SYNC_DELWRI|SYNC_WAIT, sys_cred, error);
- /* Flush inactive inodes */
- xfs_iflush_all(mp, XFS_FLUSH_ALL);
-
/* Pause transaction subsystem */
xfs_start_freeze(mp, XFS_FREEZE_TRANS);
It certainly speeds up freeze. And it looks like it still does what
it's supposed to do. :)
The theory (I think) is that xfs_iflush_all was racing around like mad,
waiting for inodes to un-busy, but it was working so hard that the
things trying to un-busy the inodes couldn't get in... lather, rinse,
repeat.
Incidentally, I think that after your 7 hour freeze, things were not in
good shape. If I froze, unfroze, then tried to do a "find" through the
filesystem, it would blow up - apparently xfs_iflush_all was
disconnecting xfs inodes from the linux inodes, and we wound up with
null pointer dereferences & oopses.
-Eric
On Wed, 2002-01-30 at 00:03, Chris Pascoe wrote:
> Hi,
>
> I'm guessing an xfs_freeze shouldn't take this long, am I correct?
>
> # time xfs_freeze -f /tst1
>
> real 344m40.434s
> user 0m0.000s
> sys 340m40.810s
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@xxxxxxx SGI, Inc.
|