On Mon, Feb 22, 2016 at 09:08:06PM +0200, Alex Lyakas wrote: > Greetings XFS developers, > > I am seeing the following issue with XFS on kernel 3.18.19. > > When resizing, XFS adds new AGs and eventually updates the primary > superblock with the new “sb_agcount” value. However, it happens few > seconds after the resize operation completes back to user-space. As > a result, if a block-level snapshot is taken off the underlying > block device, while “sb_agcount” still has the old value, then > subsequent XFS mount crashes with stack like[1]. The primary superblock change is logged, so it doesn't need to be written back immediately. That means it is in the journal... > Some debugging shows that _xfs_buf_find is called with agno that has > been added during the resize, but appropriate "pag" has not been > created for this agno during mount. The new per-ag structures are created during growfs, after the growfs transaction has committed. if you are mounting a snapshot that has the wrong agcount in it, then lots of things will go wrong if there is metadata that already uses the expanded space. > I have found the patch by Christoph Hellwig: > http://oss.sgi.com/archives/xfs/2015-01/msg00391.html > which sets the resize transaction to be synchronous, and applied it, > but it still doesn’t help. > > Right after the resize completes, I am issuing: > xfs_db -r -c "sb 0" -c "p" <device> > and for a few seconds still get the old value of “sb_agcount”. > > Can anybody advise what am I missing? What needs to be done so that > the primary superblock will get the new value of “sb_agount” > promptly? Are you freezing the filesystem before taking a block level snapshot? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
