From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 0/6] xfs: discombobulate sb updates and kill xfs_vnode.h
Date: Fri, 1 Aug 2014 09:01:36 +1000 [thread overview]
Message-ID: <20140731230136.GS26465@dastard> (raw)
In-Reply-To: <20140731171655.GA30301@infradead.org>
On Thu, Jul 31, 2014 at 10:16:55AM -0700, Christoph Hellwig wrote:
> On Thu, Jul 31, 2014 at 05:33:09PM +1000, Dave Chinner wrote:
> > Hi folks,
> >
> > Really two patch series in one. The first two patches remove the
> > bitfield based superblock update method and replace it with a simple
> > "update and log everything" operation. Superblock updates are
> > now relatively rare so there's no need to optimise for single field
> > updates. This patchset removes all that complex code and makes
> > everything nice and simple.
>
> Is there any deeper rationale why you want to get rid of it?
Tangential - cleaning up the mess of separate project quota inode
support. We do lots of dancing around with bit flags and updates in
different functions, and it really just complicates the code.
The recent problems with the quota flags getting
screwed up by repair due not using the sb-to-disk code properly
in userspace was the initial source of the problem - it's just an
unmaintainable PITA that leads to bugs. So the first step to fixing
that is removing all of the unnecessary obfuscation and complexity
from the kernel code, then port it over to userspace(*).
Besides, when we log a single field in the superblock, we're really
logging the surrounding 128 byte chunk, so we really are logging
most of the superbock on every change right now. And if we want to
move to single regions for logged buffers, then we'll be logging the
entire sb every time anyway. So, really, it makes no sense to do
this special bitfield based update and logging stuff anymore.
Cheers,
Dave.
(*) I haven't posted the "trash all quota state" patch set for
repair yet - given that repair doesn't validate the quota inode
contents, and we quotacheck unconditionally after a repair
run, there's no point trying to check or repair quota state or
inodes at all - just trash them and let the kernel rebuild it from
scratch on the next mount....
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2014-07-31 23:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 7:33 [PATCH 0/6] xfs: discombobulate sb updates and kill xfs_vnode.h Dave Chinner
2014-07-31 7:33 ` [PATCH 1/6] xfs: remove bitfield based superblock updates Dave Chinner
2014-08-01 14:37 ` Brian Foster
2014-08-04 7:34 ` Dave Chinner
2014-07-31 7:33 ` [PATCH 2/6] xfs: consolidate superblock logging functions Dave Chinner
2014-08-01 14:39 ` Brian Foster
2014-08-04 8:09 ` Dave Chinner
2014-08-04 12:48 ` Brian Foster
2014-08-04 22:15 ` Dave Chinner
2014-08-05 0:03 ` Brian Foster
2014-08-05 0:34 ` Dave Chinner
2014-08-05 12:30 ` Brian Foster
2014-08-05 19:59 ` Dave Chinner
2014-08-06 11:41 ` Brian Foster
2014-07-31 7:33 ` [PATCH 3/6] xfs: kill VN_DIRTY() Dave Chinner
2014-07-31 17:13 ` Christoph Hellwig
2014-08-04 3:20 ` [PATCH 3/6 V2] " Dave Chinner
2014-08-04 13:14 ` Christoph Hellwig
2014-07-31 7:33 ` [PATCH 4/6] xfs: kill VN_CACHED Dave Chinner
2014-07-31 17:13 ` Christoph Hellwig
2014-07-31 7:33 ` [PATCH 5/6] xfs: kill VN_MAPPED Dave Chinner
2014-07-31 17:14 ` Christoph Hellwig
2014-07-31 7:33 ` [PATCH 6/6] xfs: kill xfs_vnode.h Dave Chinner
2014-07-31 17:14 ` Christoph Hellwig
2014-07-31 17:16 ` [PATCH 0/6] xfs: discombobulate sb updates and " Christoph Hellwig
2014-07-31 23:01 ` Dave Chinner [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=20140731230136.GS26465@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