public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: xfs@oss.sgi.com, akpm@linux-foundation.org,
	torvalds@linux-foundation.org, stable-review@kernel.org,
	alan@lxorguk.ukuu.org.uk
Subject: [024/197] xfs: dont hold onto reserved blocks on remount, ro
Date: Thu, 22 Apr 2010 12:07:55 -0700	[thread overview]
Message-ID: <20100422190909.551446158@kvm.kroah.org> (raw)
In-Reply-To: <20100422191857.GA13268@kroah.com>

2.6.32-stable review patch.  If anyone has any objections, please let us know.

------------------

From: Dave Chinner <david@fromorbit.com>

commit cbe132a8bdcff0f9afd9060948fb50597c7400b8 upstream

If we hold onto reserved blocks when doing a remount,ro we end
up writing the blocks used count to disk that includes the reserved
blocks. Reserved blocks are not actually used, so this results in
the values in the superblock being incorrect.

Hence if we run xfs_check or xfs_repair -n while the filesystem is
mounted remount,ro we end up with an inconsistent filesystem being
reported. Also, running xfs_copy on the remount,ro filesystem will
result in an inconsistent image being generated.

To fix this, unreserve the blocks when doing the remount,ro, and
reserved them again on remount,rw. This way a remount,ro filesystem
will appear consistent on disk to all utilities.

Signed-off-by: Dave Chinner <david@fromorbit.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/xfs/linux-2.6/xfs_super.c |   28 ++++++++++++++++++++++++++++
 fs/xfs/xfs_mount.h           |    1 +
 2 files changed, 29 insertions(+)

--- a/fs/xfs/linux-2.6/xfs_super.c
+++ b/fs/xfs/linux-2.6/xfs_super.c
@@ -1323,6 +1323,8 @@ xfs_fs_remount(
 
 	/* ro -> rw */
 	if ((mp->m_flags & XFS_MOUNT_RDONLY) && !(*flags & MS_RDONLY)) {
+		__uint64_t resblks;
+
 		mp->m_flags &= ~XFS_MOUNT_RDONLY;
 		if (mp->m_flags & XFS_MOUNT_BARRIER)
 			xfs_mountfs_check_barriers(mp);
@@ -1340,11 +1342,37 @@ xfs_fs_remount(
 			}
 			mp->m_update_flags = 0;
 		}
+
+		/*
+		 * Fill out the reserve pool if it is empty. Use the stashed
+		 * value if it is non-zero, otherwise go with the default.
+		 */
+		if (mp->m_resblks_save) {
+			resblks = mp->m_resblks_save;
+			mp->m_resblks_save = 0;
+		} else {
+			resblks = mp->m_sb.sb_dblocks;
+			do_div(resblks, 20);
+			resblks = min_t(__uint64_t, resblks, 1024);
+		}
+		xfs_reserve_blocks(mp, &resblks, NULL);
 	}
 
 	/* rw -> ro */
 	if (!(mp->m_flags & XFS_MOUNT_RDONLY) && (*flags & MS_RDONLY)) {
+		/*
+		 * After we have synced the data but before we sync the
+		 * metadata, we need to free up the reserve block pool so that
+		 * the used block count in the superblock on disk is correct at
+		 * the end of the remount. Stash the current reserve pool size
+		 * so that if we get remounted rw, we can return it to the same
+		 * size.
+		 */
+		__uint64_t resblks = 0;
+
 		xfs_quiesce_data(mp);
+		mp->m_resblks_save = mp->m_resblks;
+		xfs_reserve_blocks(mp, &resblks, NULL);
 		xfs_quiesce_attr(mp);
 		mp->m_flags |= XFS_MOUNT_RDONLY;
 	}
--- a/fs/xfs/xfs_mount.h
+++ b/fs/xfs/xfs_mount.h
@@ -209,6 +209,7 @@ typedef struct xfs_mount {
 	__uint64_t		m_maxioffset;	/* maximum inode offset */
 	__uint64_t		m_resblks;	/* total reserved blocks */
 	__uint64_t		m_resblks_avail;/* available reserved blocks */
+	__uint64_t		m_resblks_save;	/* reserved blks @ remount,ro */
 	int			m_dalign;	/* stripe unit */
 	int			m_swidth;	/* stripe width */
 	int			m_sinoalign;	/* stripe unit inode alignment */


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2010-04-22 19:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20100422191857.GA13268@kroah.com>
2010-04-22 19:07 ` [009/197] xfs: simplify inode teardown Greg KH
2010-04-22 19:07 ` [010/197] xfs: fix mmap_sem/iolock inversion in xfs_free_eofblocks Greg KH
2010-04-22 19:07 ` [011/197] xfs: I/O completion handlers must use NOFS allocations Greg KH
2010-04-22 19:07 ` [012/197] xfs: Wrapped journal record corruption on read at recovery Greg KH
2010-04-22 19:07 ` [013/197] xfs: Fix error return for fallocate() on XFS Greg KH
2010-04-22 19:07 ` [014/197] xfs: check for not fully initialized inodes in xfs_ireclaim Greg KH
2010-04-22 19:07 ` [015/197] xfs: fix timestamp handling in xfs_setattr Greg KH
2010-04-22 19:07 ` [016/197] xfs: Dont flush stale inodes Greg KH
2010-04-22 19:07 ` [017/197] xfs: Ensure we force all busy extents in range to disk Greg KH
2010-04-22 19:07 ` [018/197] xfs: reclaim inodes under a write lock Greg KH
2010-04-22 19:07 ` [019/197] xfs: Avoid inodes in reclaim when flushing from inode cache Greg KH
2010-04-22 19:07 ` [020/197] xfs: reclaim all inodes by background tree walks Greg KH
2010-04-22 19:07 ` [021/197] xfs: fix stale inode flush avoidance Greg KH
2010-04-22 19:07 ` [022/197] xfs: xfs_swap_extents needs to handle dynamic fork offsets Greg KH
2010-04-22 19:07 ` [023/197] xfs: quota limit statvfs available blocks Greg KH
2010-04-22 19:07 ` Greg KH [this message]
2010-04-22 19:07 ` [025/197] xfs: remove invalid barrier optimization from xfs_fsync Greg KH
2010-04-22 19:07 ` [026/197] xfs: Non-blocking inode locking in IO completion Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100422190909.551446158@kvm.kroah.org \
    --to=gregkh@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable-review@kernel.org \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox