From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [RFC, PATCH] xfs: make superblock version checks reflect reality
Date: Thu, 6 Mar 2014 10:05:34 -0800 [thread overview]
Message-ID: <20140306180534.GA305@infradead.org> (raw)
In-Reply-To: <1394088890-10713-1-git-send-email-david@fromorbit.com>
On Thu, Mar 06, 2014 at 05:54:50PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> We only support filesystems that have v2 directory support, and than
> means all the checking and handling of superblock versions prior to
> this support being added is completely unnecessary overhead.
>
> Strip out all the version 1-3 support, sanitise the good version
> checking to reflect the supported versions, update all the feature
> supported functions and clean up all the support bit definitions to
> reflect the fact that we no longer care about Irix bootloader flag
> regions for v4 feature bits.
Good idea in general, I like it.
> Because the feature bit checking is all inline code, this relatively
> small cleanup has a noticable impact on code size:
I initially though moving it out of line might not be a bad idea,
but it seems after your diet it's lean enough to not bother.
> +/*
> + * We only support superblocks that have at least V2 Dir capability. Any feature
> + * bit added after v2 dir capability is also indicates a supported superblock
> + * format.
> + */
> +#define XFS_SB_NEEDED_FEATURES \
> + (XFS_SB_VERSION_DIRV2BIT | \
> + XFS_SB_VERSION_LOGV2BIT | \
> + XFS_SB_VERSION_SECTORBIT | \
> + XFS_SB_VERSION_BORGBIT | \
> XFS_SB_VERSION_MOREBITSBIT)
This seems a bit odd. Shouldn't we simply check for
XFS_SB_VERSION_DIRV2BIT as we actually rely on that? What if SGI had
backported any of those other features to some IRIX branch?
I'd vote to kill XFS_SB_NEEDED_FEATURES and just check the dirv2 bit
explicitly.
> +/*
> + * Supported feature bit list is just all bits in the versionnum field because
> + * we've used them all up and understand them all.
> + */
> +#define XFS_SB_VERSION_OKBITS \
> + (XFS_SB_VERSION_NUMBITS | \
> + XFS_SB_VERSION_ALLFBITS)
>
> +#define XFS_SB_VERSION2_OKBITS \
> (XFS_SB_VERSION2_LAZYSBCOUNTBIT | \
> XFS_SB_VERSION2_ATTR2BIT | \
> XFS_SB_VERSION2_PROJID32BIT | \
> XFS_SB_VERSION2_FTYPE)
> +/*
> + * The first XFS version we support is filesytsems with V2 directories.
> + */
is a v4 superblock with v2 directories?
Also filesystem is mis-spelled.
> static inline int xfs_sb_good_version(xfs_sb_t *sbp)
> {
> + /* We only support v4 and v5 */
> + if (XFS_SB_VERSION_NUM(sbp) < XFS_SB_VERSION_4 ||
> + XFS_SB_VERSION_NUM(sbp) > XFS_SB_VERSION_5)
> + return 0;
> +
> + /*
> + * Version 5 feature checks are done separately.
> + */
> + if (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_5)
> return 1;
How about doing this a little different?
static inline int xfs_sb_good_version(struct xfs_sb *sbp)
{
if (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_5)
return 1;
if (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4)
return xfs_sb_good_v4_features(sbp);
return 0;
}
then move the bulk of the function into xfs_sb_good_v4_features?
> + if ((sbp->sb_versionnum & ~XFS_SB_VERSION_OKBITS) ||
> + ((sbp->sb_versionnum & XFS_SB_VERSION_MOREBITSBIT) &&
> + (sbp->sb_features2 & ~XFS_SB_VERSION2_OKBITS)))
> return 0;
> + if (sbp->sb_shared_vn > XFS_SB_MAX_SHARED_VN)
> + return 0;
Given that XFS_SB_MAX_SHARED_VN we might as well make that and != 0
check and document that we don't support any shared superblocks.
> static inline int xfs_sb_version_hasattr(xfs_sb_t *sbp)
> {
> + return !!(sbp->sb_versionnum & XFS_SB_VERSION_ATTRBIT);
> }
Should this become a bool?
>
> static inline void xfs_sb_version_addattr(xfs_sb_t *sbp)
> {
> + sbp->sb_versionnum |= XFS_SB_VERSION_ATTRBIT;
> }
I'd rather not keep the wrappers for adding these flags - the callers
already know sb internals, might as well not keep a false abstraction
here.
> static inline int xfs_sb_version_hasnlink(xfs_sb_t *sbp)
> {
> - return sbp->sb_versionnum == XFS_SB_VERSION_3 ||
> - (XFS_SB_VERSION_NUM(sbp) >= XFS_SB_VERSION_4 &&
> - (sbp->sb_versionnum & XFS_SB_VERSION_NLINKBIT));
> + return !!(sbp->sb_versionnum & XFS_SB_VERSION_NLINKBIT);
> }
As we reject filesystems without the nlink bit we should just be able
to kill all code protected by xfs_sb_version_hasnlink checks, shouldn't
we?
> static inline void xfs_sb_version_addnlink(xfs_sb_t *sbp)
> {
> + sbp->sb_versionnum |= XFS_SB_VERSION_NLINKBIT;
> }
Same for addnlink.
> static inline int xfs_sb_version_hasdirv2(xfs_sb_t *sbp)
> {
> - return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_5) ||
> - (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4 &&
> - (sbp->sb_versionnum & XFS_SB_VERSION_DIRV2BIT));
> + return XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_5 ||
> + (sbp->sb_versionnum & XFS_SB_VERSION_DIRV2BIT);
> }
dirv2 is another candidate.
> @@ -536,11 +493,13 @@ static inline void xfs_sb_version_addattr2(xfs_sb_t *sbp)
> {
> sbp->sb_versionnum |= XFS_SB_VERSION_MOREBITSBIT;
> sbp->sb_features2 |= XFS_SB_VERSION2_ATTR2BIT;
> + sbp->sb_bad_features2 |= XFS_SB_VERSION2_ATTR2BIT;
> }
>
> static inline void xfs_sb_version_removeattr2(xfs_sb_t *sbp)
> {
> sbp->sb_features2 &= ~XFS_SB_VERSION2_ATTR2BIT;
> + sbp->sb_bad_features2 &= ~XFS_SB_VERSION2_ATTR2BIT;
Where is this coming from? Seems unrelated to the other changes.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-03-06 18:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 6:54 [RFC, PATCH] xfs: make superblock version checks reflect reality Dave Chinner
2014-03-06 18:05 ` Christoph Hellwig [this message]
2014-03-06 22:55 ` Dave Chinner
2014-03-07 8:34 ` Dave Chinner
2014-03-07 10:16 ` Christoph Hellwig
2014-03-07 10:15 ` Christoph Hellwig
2014-03-09 0:32 ` 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=20140306180534.GA305@infradead.org \
--to=hch@infradead.org \
--cc=david@fromorbit.com \
--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;
as well as URLs for NNTP newsgroup(s).