I have been talking to Christoph Hellwig <[EMAIL PROTECTED]> 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 ---
signature.asc
Description: Digital signature
