From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [RFC, PATCH] xfs: make superblock version checks reflect reality
Date: Fri, 7 Mar 2014 19:34:30 +1100 [thread overview]
Message-ID: <20140307083430.GQ6851@dastard> (raw)
In-Reply-To: <20140306225541.GL6851@dastard>
On Fri, Mar 07, 2014 at 09:55:41AM +1100, Dave Chinner wrote:
> On Thu, Mar 06, 2014 at 10:05:34AM -0800, Christoph Hellwig wrote:
> > 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.
.....
> > > 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?
> > Same for addnlink.
> > dirv2 is another candidate.
>
> Yes, that's true - but I think those are good candidates for
> separate patches that follow up on this one.
Ok, we don't reject filesystems that don't have the NLINK bit set.
Older filesystems that have only v1 inodes won't have that bit
set, and we didn't set NLINK by default in mkfs until late 2007.
Hence we need to keep some form of NLINK support around.
The alternative is to simply set the bit in the superblock if it is
not set, and then just assume everywhere that it is set and we are
using v2 inodes. That will get rid of the hasnlink/addnlink code
needed to modify the superblock when the link count goes above
MAX_NLINK_1, and will result in filesystems always converting v1
inodes to v2 inodes on writeback of dirty inodes. I don't see a
problem with taking this approach, bt maybe I'm missing something?
For the dirv2 function, it's only used for checking at mount time,
so if that is handled bu xfs_sb_good_version() we no longer need
it....
Your thoughts?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-03-07 8:34 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
2014-03-06 22:55 ` Dave Chinner
2014-03-07 8:34 ` Dave Chinner [this message]
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=20140307083430.GQ6851@dastard \
--to=david@fromorbit.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