From: Dave Chinner <david@fromorbit.com>
To: Alex Lyakas <alex@zadarastorage.com>
Cc: hch@infradead.org, Danny Shavit <danny@zadarastorage.com>,
xfs@oss.sgi.com
Subject: Re: xfs resize: primary superblock is not updated immediately
Date: Tue, 23 Feb 2016 08:20:19 +1100 [thread overview]
Message-ID: <20160222212019.GI25832@dastard> (raw)
In-Reply-To: <3685DFAD20214109878873CF81232704@alyakaslap>
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@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next parent reply other threads:[~2016-02-22 21:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3685DFAD20214109878873CF81232704@alyakaslap>
2016-02-22 21:20 ` Dave Chinner [this message]
2016-02-22 22:38 ` xfs resize: primary superblock is not updated immediately Alex Lyakas
2016-02-22 23:56 ` Dave Chinner
2016-02-23 12:25 ` Alex Lyakas
2016-02-23 22:59 ` Dave Chinner
2016-02-29 9:47 ` Alex Lyakas
2016-02-29 21:16 ` Dave Chinner
2016-03-01 7:20 ` Dave Chinner
2016-03-02 13:14 ` Fanael Linithien
2016-03-03 9:18 ` Alex Lyakas
2016-03-03 21:31 ` Dave Chinner
2016-03-06 9:46 ` Alex Lyakas
2016-03-06 15:46 ` Eric Sandeen
2016-03-06 20:49 ` Dave Chinner
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=20160222212019.GI25832@dastard \
--to=david@fromorbit.com \
--cc=alex@zadarastorage.com \
--cc=danny@zadarastorage.com \
--cc=hch@infradead.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