From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/3] xfs: move kernel-specific superblock validation out of libxfs
Date: Fri, 4 Dec 2020 15:02:30 -0800 [thread overview]
Message-ID: <20201204230230.GH629293@magnolia> (raw)
In-Reply-To: <3123a8c7-9afe-fd73-ae6d-d8c9cd2188ad@sandeen.net>
On Fri, Dec 04, 2020 at 03:46:19PM -0600, Eric Sandeen wrote:
> On 12/4/20 3:12 PM, Darrick J. Wong wrote:
> > On Fri, Dec 04, 2020 at 02:35:45PM -0600, Eric Sandeen wrote:
> >> On 11/30/20 9:37 PM, Darrick J. Wong wrote:
> >>> From: Darrick J. Wong <darrick.wong@oracle.com>
> >>>
> >>> A couple of the superblock validation checks apply only to the kernel,
> >>> so move them to xfs_mount.c before we start changing sb_inprogress.
>
> oh also, you're not changing sb_inprogress anymore, right? ;)
Fixed.
> >>> This also reduces the diff between kernel and userspace libxfs.
> >>
> >> My only complaint is that "xfs_sb_validate_mount" isn't really descriptive
> >> at all, and nobody reading the code or comments will know why we've chosen
> >> to move just these two checks out of the common validator...
> >>
> >> What does "compatible with this mount" mean?
> >
> > Compatible with this implementation?
>
> Hm.
>
> So most of xfs_validate_sb_common is doing internal consistency checking
> that has nothing at all to do with the host's core capabilities or filesystem
> "state" (other than version/features I guess).
>
> You've moved out the PAGE_SIZE check, which depends on the host.
>
> You've also moved the inprogress check, which depends on state.
> (and that's not really "kernel-specific" is it?)
>
> You'll later move the NEEDSREPAIR check, which I guess is state.
>
> But you haven't moved the fsb_count-vs-host check, which depends on the host.
>
> (and ... I think that one may actually be kernel-specific,
> because it depends on pagecache limitations in the kernel, so maybe it
> should be moved out as well?)
Aha, yes, I missed that.
> So maybe the distinction is internal consistency checks, vs
> host-compatibility-and-filesystem-state checks.
>
> How about ultimately:
>
> /*
> * Do host compatibility and filesystem state checks here; these are unique
> * to the kernel, and may differ in userspace.
> */
> xfs_validate_sb_host(
> struct xfs_mount *mp,
> struct xfs_buf *bp,
> struct xfs_sb *sbp)
> {
> /*
> * Don't touch the filesystem if a user tool thinks it owns the primary
> * superblock. mkfs doesn't clear the flag from secondary supers, so
> * we don't check them at all.
> */
> if (XFS_BUF_ADDR(bp) == XFS_SB_DADDR && sbp->sb_inprogress) {
> xfs_warn(mp, "Offline file system operation in progress!");
> return -EFSCORRUPTED;
> }
>
> /* Filesystem claims it needs repair, so refuse the mount. */
> if (xfs_sb_version_needsrepair(&mp->m_sb)) {
> xfs_warn(mp, "Filesystem needs repair. Please run xfs_repair.");
> return -EFSCORRUPTED;
> }
>
> /*
> * Until this is fixed only page-sized or smaller data blocks work.
> */
> if (unlikely(sbp->sb_blocksize > PAGE_SIZE)) {
> xfs_warn(mp,
> "File system with blocksize %d bytes. "
> "Only pagesize (%ld) or less will currently work.",
> sbp->sb_blocksize, PAGE_SIZE);
> return -ENOSYS;
> }
>
> /* Ensure this filesystem fits in the page cache limits */
> if (xfs_sb_validate_fsb_count(sbp, sbp->sb_dblocks) ||
> xfs_sb_validate_fsb_count(sbp, sbp->sb_rblocks)) {
> xfs_warn(mp,
> "file system too large to be mounted on this system.");
> return -EFBIG;
Sounds good to me.
--D
> }
>
> return 0;
> }
>
> >> Maybe just fess up in the comment, and say "these checks are different
> >> for kernel vs. userspace so we keep them over here" - and as for the
> >> function name, *shrug* not sure I have anything better...
> >
> > _validate_implementation? I don't have a better suggestion either.
> >
> > --D
> >
> >> -Eric
> >>
> >
next prev parent reply other threads:[~2020-12-04 23:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-01 3:37 [PATCH 0/3] xfs: add the ability to flag a fs for repair Darrick J. Wong
2020-12-01 3:37 ` [PATCH 1/3] xfs: move kernel-specific superblock validation out of libxfs Darrick J. Wong
2020-12-01 16:17 ` Brian Foster
2020-12-04 20:35 ` Eric Sandeen
2020-12-04 21:12 ` Darrick J. Wong
2020-12-04 21:46 ` Eric Sandeen
2020-12-04 23:02 ` Darrick J. Wong [this message]
2020-12-04 23:29 ` Dave Chinner
2020-12-01 3:37 ` [PATCH 2/3] xfs: define a new "needrepair" feature Darrick J. Wong
2020-12-01 16:18 ` Brian Foster
2020-12-01 16:25 ` Darrick J. Wong
2020-12-01 17:09 ` Brian Foster
2020-12-04 20:07 ` Eric Sandeen
2020-12-04 21:36 ` Darrick J. Wong
2020-12-01 3:37 ` [PATCH 3/3] xfs: enable the needsrepair feature Darrick J. Wong
2020-12-01 16:18 ` Brian Foster
2020-12-04 20:35 ` Eric Sandeen
2020-12-04 1:13 ` [PATCH 4/3] xfs_db: support the needsrepair feature flag in the version command Darrick J. Wong
2020-12-04 20:32 ` Eric Sandeen
2020-12-04 21:09 ` Darrick J. Wong
2020-12-04 21:16 ` Eric Sandeen
2020-12-04 1:13 ` [PATCH 5/3] xfs_repair: clear the needsrepair flag Darrick J. Wong
2020-12-06 23:09 [PATCH v2 0/3] xfs: add the ability to flag a fs for repair Darrick J. Wong
2020-12-06 23:09 ` [PATCH 1/3] xfs: move kernel-specific superblock validation out of libxfs Darrick J. Wong
2020-12-06 23:47 ` Dave Chinner
2020-12-07 17:17 ` Brian Foster
2020-12-09 17:08 ` Eric Sandeen
2020-12-09 18:03 ` Christoph Hellwig
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=20201204230230.GH629293@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;
as well as URLs for NNTP newsgroup(s).