xfs: don't hold onto reserved blocks on remount,ro
PATCH 1/1 xfs: don't hold onto reserved blocks on remount,ro
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.
--- fs/xfs/linux-2.6/xfs_super.c | 28 ++++++++++++++++++++++++++++ fs/xfs/xfs_mount.h | 1 + 2 files changed, 29 insertions(+), 0 deletions(-)
fs/xfs/linux-2.6/xfs_super.c +28 -0
@@ -1318,6 +1318,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);
@@ -1335,11 +1337,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_ro) { + resblks = mp->m_resblks_ro; + mp->m_resblks_ro =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_ro = mp->m_resblks; +xfs_reserve_blocks (mp, &resblks,NULL );xfs_quiesce_attr (mp); mp->m_flags |=XFS_MOUNT_RDONLY ; }
fs/xfs/xfs_mount.h +1 -0
@@ -225,6 +225,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_ro;/* reserved blks @ remount,ro */ int m_dalign;/* stripe unit */ int m_swidth;/* stripe width */ int m_sinoalign;/* stripe unit inode alignment */
Signature · 6 lines
1.6.5 _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 5 lines · Dave Chinner
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.
Quoted 8 lines
Hence if we run
xfs_checkorxfs_repair-n while the filesystem is mounted remount,ro we end up with an inconsistent filesystem being reported. Also, runningxfs_copyon 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.
Looks good to me, the only thing that was rather confusing when trying to read the patch is the m_resblks_ro field in struct xfs_mount, it's more a m_resblks_save, as in the saved value before we modified the block count during remount,ro.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 11 lines · Christoph Hellwig
Quoted 10 lines · Dave Chinner
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_checkorxfs_repair-n while the filesystem is mounted remount,ro we end up with an inconsistent filesystem being reported. Also, runningxfs_copyon the remount,ro filesystem will result in an inconsistent image being generated.
Quoted 8 lines
Quoted 3 lines
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.
Looks good to me, the only thing that was rather confusing when trying to read the patch is the
m_resblks_rofield in structxfs_mount, it's more am_resblks_save, as in the saved value before we modified the block count during remount,ro.
Ok, I changed the variable name.
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs