[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#306966: [hch@lst.de: Re: xfs_freeze returns before sync is complete]

I have been talking to Christoph Hellwig <hch@lst.de> on this and he has
provided a patch that fixes this under my test scenarios (attached).

Under the topic of severity I am wondering if this isn't possibly an
issue for certain backup scenarios and utilities?  When I search google
for:

   xfs_freeze backup

I get a number of pages explaining that xfs_freeze will flush so that
a sane backup is achieved for the particular tool or utility.

But if one cannot predict when the flush is complete, then it seems to
me that a sane snapshot or backup may in fact not be achieved (ever a
student, I'm open to new and better information on this).

Incidentally, I have verified that this bug is not limited to the
current Testing kernel, but also the latest 2.6 kernel in Unstable.

-- 
Encrypted Mail Preferred:
    Key ID:  8527B9AF
    Key Fingerprint:  E1B6 40B6 B73F 695E 0D3B  644E 6427 DD74 8527 B9AF
    Information:  http://www.gnupg.org/
                                                                                
ASCII ribbon campaign:
()  against HTML email
/\  against Microsoft attachments
    Information:  http://www.expita.com/nomime.html
--- Begin Message --- 
On Thu, May 12, 2005 at 02:41:15PM -0600, David Everly wrote:
> Looks like my email was messed up and some messages got frozen, but you
> should by now have my earlier message which I thought you had read
> before sending me this.  It should be dated May 9.
> 
> Sorry for the confusion.  And thanks again for looking at this.

Soem more testing today.  When I rm -rf /boot/grub before calling
grub-install I can reproduce the issue pretty reliably.  The two
patches below (against 2.6.12-rc4) make flushing stronger and make
freeze do exactly the same flushing as a mount -o ro.  Can you
give them a try?

Index: linux-2.6/fs/xfs/linux-2.6/xfs_buf.c
===================================================================
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_buf.c	2005-05-09 18:34:39.801794184 +0200
+++ linux-2.6/fs/xfs/linux-2.6/xfs_buf.c	2005-05-13 18:22:56.215234608 +0200
@@ -1891,8 +1891,12 @@
 		xfs_buf_relse(pb);
 	}
 
-	if (wait)
+	filemap_fdatawrite(target->pbr_mapping);
+
+	if (wait) {
 		blk_run_address_space(target->pbr_mapping);
+		filemap_fdatawait(target->pbr_mapping);
+	}
 
 	return pincount;
 }

Index: linux-2.6/fs/xfs/xfs_vfsops.c
===================================================================
--- linux-2.6.orig/fs/xfs/xfs_vfsops.c	2005-05-12 12:14:46.037011184 +0200
+++ linux-2.6/fs/xfs/xfs_vfsops.c	2005-05-13 18:51:34.837829256 +0200
@@ -879,10 +879,35 @@
 	int		flags,
 	cred_t		*credp)
 {
-	xfs_mount_t	*mp;
+	xfs_mount_t	*mp = XFS_BHVTOM(bdp);
+	struct vfs	*vfsp = bhvtovfs(bdp);
+
+	if (vfsp->vfs_super->s_frozen == SB_FREEZE_WRITE) {
+		int pincount = 0, count = 0;
 
-	mp = XFS_BHVTOM(bdp);
-	return (xfs_syncsub(mp, flags, 0, NULL));
+		xfs_refcache_purge_mp(mp);
+		xfs_flush_buftarg(mp->m_ddev_targp, 0);
+		xfs_finish_reclaim_all(mp, 0);
+
+		/* This loop must run at least twice.
+		 * The first instance of the loop will flush
+		 * most meta data but that will generate more
+		 * meta data (typically directory updates).
+		 * Which then must be flushed and logged before
+		 * we can write the unmount record.
+		 */ 
+		do {
+			xfs_syncsub(mp, REMOUNT_READONLY_FLAGS, 0, NULL);
+			pincount = xfs_flush_buftarg(mp->m_ddev_targp, 1);
+			if (!pincount) {
+				delay(50);
+				count++;
+			}
+		} while (count < 2);
+
+		return 0;
+	} else
+		return (xfs_syncsub(mp, flags, 0, NULL));
 }
 
 /*
@@ -1939,7 +1964,7 @@
 	while (atomic_read(&mp->m_active_trans) > 0)
 		delay(100);
 
-	/* Push the superblock and write an unmount record */
+	/* Ok now write out an unmount record */
 	xfs_log_unmount_write(mp);
 	xfs_unmountfs_writesb(mp);
 }

--- End Message ---

Attachment: signature.asc
Description: Digital signature

Reply to: