On Thursday 8 October 2020 9:26:12 AM IST Darrick J. Wong wrote: > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > When we call growfs on the data device, we update the secondary > superblocks to reflect the updated filesystem geometry. We need to do > this for growfs on the realtime volume too, because a future xfs_repair > run could try to fix the filesystem using a backup superblock. > > This was observed by the online superblock scrubbers while running > xfs/233. One can also trigger this by growing an rt volume, cycling the > mount, and creating new rt files. > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > --- > fs/xfs/xfs_rtalloc.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > > diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c > index 1c3969807fb9..5b2e68d9face 100644 > --- a/fs/xfs/xfs_rtalloc.c > +++ b/fs/xfs/xfs_rtalloc.c > @@ -18,7 +18,7 @@ > #include "xfs_trans_space.h" > #include "xfs_icache.h" > #include "xfs_rtalloc.h" > - > +#include "xfs_sb.h" > > /* > * Read and return the summary information for a given extent size, > @@ -1108,6 +1108,11 @@ xfs_growfs_rt( > */ > kmem_free(nmp); > > + /* Update secondary superblocks now the physical grow has completed */ > + error = xfs_update_secondary_sbs(mp); > + if (error) > + return error; > + If any of the operations in the previous "for" loop causes "error" to be set and the loop to be exited, the call to xfs_update_secondary_sbs() would overwrite this error value. In the worst case it might set error to 0 and hence return a success status to the caller when the growfs operation had actually failed. -- chandan
