public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Ben Myers <bpm@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 2/9] xfs: add support for large btree blocks
Date: Sat, 23 Feb 2013 13:27:22 +1100	[thread overview]
Message-ID: <20130223022722.GI26081@dastard> (raw)
In-Reply-To: <20130222013456.GN26694@dastard>

On Fri, Feb 22, 2013 at 12:34:56PM +1100, Dave Chinner wrote:
> On Fri, Feb 15, 2013 at 03:20:15PM -0600, Ben Myers wrote:
> > On Tue, Jan 22, 2013 at 12:25:53AM +1100, Dave Chinner wrote:
> > > From: Christoph Hellwig <hch@lst.de>
> > > 
> > > Add support for larger btree blocks that contains a CRC32C checksum,
> > > a filesystem uuid and block number for detecting filesystem
> > > consistency and out of place writes.
> > > 
> > > [dchinner@redhat.com] Also include an owner field to allow reverse
> > > mappings to be implemented for improved repairability and a LSN
> > > field to so that log recovery can easily determine the last
> > > modification that made it to disk for each buffer.
> > > 
> > > [dchinner@redhat.com] Add buffer log format flags to indicate the
> > > type of buffer to recovery so that we don't have to do blind magic
> > > number tests to determine what the buffer is.
> > > 
> > > [dchinner@redhat.com] Modified to fit into the verifier structure.
> > 
> > This patch is far too large for a good review.  It needs to be split up into
> > it's various ideas which you outlined in patch 0.  If you need to add dead code
> > in each piece and then enable it at the end, that's fine with me.
> 
> You want it broken up into 7 or 8 separate patches - what does it
> gain us? It'll take a week for me to do the patch monkeying and to
> retest and validate the resulting stack (i.e. it is bisectable, each
> patch passes xfstests, etc), and in the end the code will be
> identical.
> 
> As I've said before, there's a point where the tradeoff for
> splitting patches up doesn't make sense. Asking a developer to do
> days of work to end up with exactly the same code to save the
> reviewer an hour or two is *not* a good tradeoff. Especially for the
> first patch of a much larger 15-20 patch series which contains
> several larger and more complex patches....

Ben, reading this back it comes across as unnecessarily negative and
narky. I was just about at the end of the attribute leaf changes and
it's been a mind-numbing slog making mechanical changes to lots of
code.

This is after having to do the same slog through all the directory
code. The block, leaf, node, freespace and da_btree code all had to
get the same treatment, and it's worn me down.  My wrists are
starting to hurt from the last three months of slogging through this
stuff (roughly +20,000/-10,000 lines modified according to a quick
diffstat) and that doesn't make me a happy camper.

So I'm not meaning to be narky or nasty - I just want to get this
stuff done ASAP before it burns me out. Hence the prospect of having
to go back and redo significant chunks to split out trivial pieces
of code (i.e. a mind-numbing slog making mechanical changes) hit a
bit of a raw nerve.

All I'm asking is that you take into account the extra load that the
rework you ask me to do adds and whether it is absolutely necessary
to be able to review the code. The last thing I want is be burnt out
by this stuff....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-02-23  2:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1358774760-21841-1-git-send-email-david@fromorbit.com>
     [not found] ` <1358774760-21841-2-git-send-email-david@fromorbit.com>
2013-02-14 21:25   ` [PATCH 1/9] xfs: take inode version into account in XFS_LITINO Ben Myers
     [not found] ` <1358774760-21841-3-git-send-email-david@fromorbit.com>
2013-02-15 21:20   ` [PATCH 2/9] xfs: add support for large btree blocks Ben Myers
2013-02-22  1:34     ` Dave Chinner
2013-02-23  2:27       ` Dave Chinner [this message]
2013-03-04 16:31         ` Ben Myers
     [not found] ` <1358774760-21841-4-git-send-email-david@fromorbit.com>
2013-02-21 22:53   ` [PATCH 3/9] xfs: add CRC checks to the AGF Ben Myers
2013-02-22  1:41     ` Dave Chinner
2013-02-22 15:19 ` [PATCH 0/9] xfs: metadata CRCs, kernel, first batch Ben Myers
2013-02-22 23:12   ` Dave Chinner
2013-02-22 23:50     ` Ben Myers
2013-02-23  2:38       ` Dave Chinner
2013-03-04 16:33         ` Ben Myers
     [not found] ` <1358774760-21841-5-git-send-email-david@fromorbit.com>
2013-02-27 22:37   ` [PATCH 4/9] xfs: add CRC checks to the AGFL Ben Myers
2013-02-27 23:20     ` Dave Chinner
2013-02-27 23:31       ` Dave Chinner
2013-02-27 23:35         ` Ben Myers
2013-02-27 23:32       ` Ben Myers
     [not found] ` <1358774760-21841-6-git-send-email-david@fromorbit.com>
2013-03-04 17:40   ` [PATCH 5/9] xfs: add CRC checks to the AGI Ben Myers
2013-03-04 17:41     ` Ben Myers

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=20130223022722.GI26081@dastard \
    --to=david@fromorbit.com \
    --cc=bpm@sgi.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