From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs: don't skip rtmount when there's a realtime device
Date: Thu, 13 Dec 2018 15:46:51 -0800 [thread overview]
Message-ID: <20181213234651.GE24487@magnolia> (raw)
In-Reply-To: <d33a0150-e412-5089-5c60-333b3d9ae9a1@sandeen.net>
On Thu, Dec 13, 2018 at 03:29:54PM -0600, Eric Sandeen wrote:
>
>
> On 12/12/18 7:24 PM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> >
> > Don't ever skip the realtime bitmap / summary inode initialization if
> > there's a realtime device attached, because we'd rather fail the mount
> > if iget declines to retrieve a NULL inode pointer. Right now, if
> > someone sets rbmino to NULLFSINO on a rt-capable filesystem, mounts it,
> > and writes a file to the rt device, we'll blow up.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> > fs/xfs/xfs_rtalloc.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c
> > index aefd63d46397..18ad31ded0bf 100644
> > --- a/fs/xfs/xfs_rtalloc.c
> > +++ b/fs/xfs/xfs_rtalloc.c
> > @@ -1206,7 +1206,8 @@ xfs_rtmount_inodes(
> > xfs_sb_t *sbp;
> >
> > sbp = &mp->m_sb;
> > - if (sbp->sb_rbmino == NULLFSINO)
> > + if (!xfs_sb_version_hasrealtime(&mp->m_sb) &&
> > + sbp->sb_rbmino == NULLFSINO)
> > return 0;
> > error = xfs_iget(mp, NULL, sbp->sb_rbmino, 0, 0, &mp->m_rbmip);
> > if (error)
> >
>
> Seems fine as far as it goes, but now we have this weird situation where for
> a filesystem without the realtime feature, we'll just skip this part and
> mount if sb_rbmino is NULL, but if sb_rsumino is NULL, we'll fail the iget
> and fail the mount.
>
> So while there's noting really wrong with the fix, it seems like it could all
> be made a bit more consistent while you're here. (classic move by me!) ;)
Hmm. Well if there /aren't supposed/ to be any XFSes out there with
garbage/null realtime bitmap / summary inodes, then I'm happy to get rid
of the "if (sbp->sb_rbmino == NULLFSINO) return 0;" logic. The current
logic is sorta weird, but I don't know if that was a deliberate design
decision or just a logic bug that needs to go away.
Though now that I see that we can indeed add a realtime section to a
filesystem that didn't previously have one, I guess I should go look at
the rtrmapbt growfs code a little more closely.
--D
> -Eric
prev parent reply other threads:[~2018-12-13 23:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 1:24 [PATCH] xfs: don't skip rtmount when there's a realtime device Darrick J. Wong
2018-12-13 19:06 ` Bill O'Donnell
2018-12-13 21:29 ` Eric Sandeen
2018-12-13 23:46 ` Darrick J. Wong [this message]
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=20181213234651.GE24487@magnolia \
--to=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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