xfsprogs patches pw 2883, 2986-2997

xfsprogs patches pw 2883, 2986-2997

[Mark Tinguely]

Just a FYI to let you know that I testing your xfsprog patches that you 
submitted on Dec 2. I looked at the comments and the patches. The 
xfstests running now.

Dave Chinner had feedback requests on a couple items.

Below is my summary of the patches:

repair-avoid-ABBA-deadlocks-on-prefetched-buffers.patch
         patchworks 2883
          I believe this is required for patchworks 2997.
          feedback says that there are still deadlock, but I believe
          that it is addressed in patchworks 2986 and 2989.

01-12-repair-do-not-walk-the-unlinked-inode-list.patch
         patchworks 2987
          removed the walk_unlink_list code.

02-12-repair-allocate-and-free-inode-records-individually.patch
         patchworks 2988
          use malloc to allocate inodes rather than managing chucks.

03-12-repair-allocate-and-free-extent-records-individually.patch
         patchworks 2994
          use malloc to allocate extents rather than managing chucks.

04-12-xfsprogs-allow-linking-against-libtcmalloc.patch
         patchworks 2994
          use malloc to allocate extents rather than managing chucks.

05-12-repair-update-extent-count-after-zapping-duplicate-blocks.patch
         patchworks 2991
          configuration file changes to use Google performance tools.
          Dave had comments on the location of the change.
	 I had problems with installing the x64 Google tools with libunwind.
          This could be addressed separately.

06-12-repair-use-recursive-buffer-locking.patch
         patchworks 2989
          Use a recursion counter to avoid deadlock.
           Dave want a block number printed and add a return after the
           recursion count.(also ABBA pw 2925).
	  We could mark pw 2925 as superseded.

07-12-repair-fix-another-ABBA-deadlock-in-inode-prefetching.patch
         patchworks 2986
          additional patch for the ABBA deadlock.

08-12-repair-handle-filesystems-with-the-log-in-allocation-group-0.patch
         patchworks 2990
          Log allocation fix

09-12-repair-kill-check_inode_block.patch
         patchworks 2995
          Code clean up

10-12-repair-mark-local-functions-static.patch
         patchworks 2992
          Code clean up

11-12-repair-move-extern-declarations-to-headers.patch
         patchworks 2996
          Code clean up

12-12-repair-cleanup-inode-record-macros.patch
         patchworks 2993
          Code clean up

--Mark Tinguely
   tinguely@sgi.com
   SGI XFS.

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

Re: xfsprogs patches pw 2883, 2986-2997

[Dave Chinner]

On Mon, Dec 19, 2011 at 04:58:23PM -0600, Mark Tinguely wrote:
> Just a FYI to let you know that I testing your xfsprog patches that
> you submitted on Dec 2. I looked at the comments and the patches.
> The xfstests running now.
> 
> Dave Chinner had feedback requests on a couple items.

Yes, but Christoph has already replied so all I'm waiting on is a
repost of the series from him addressing those comments. He did say
it might take a while as he had other more critical stuff to do.

> Below is my summary of the patches:

I'd prefer it if you don't send emails this way - there's no context
to your comments about each patch. I'd have to go to a web browser
to start patchworks and look up some random index number and read
stuff before coming back to my email to comment sanely. That's way
to much stuffing about for me to bother - there's no way I can chew
through a couple of thousand emails a day with that sort of
workflow.

It is much better to reply in line to each of the patch emails with
your comments.  It is easy to understand the context of your
comments, you don't need to summarise all the patches (just reply to
ones you have comments about), and it fits the workflow we use for
tracking such comments (like patchworks). It also helps finding all
the discussion about a patch series in the mail archives. If you've
got a general comment about a series (like this email), reply to the
zero patch (the summary email).

Realistically, patchworks is just a tool to help the maintainer -
Ben - keep track of stuff if he requires help. It was set up because
Alex found it useful for this purpose, but if Ben doesn't need it
then it's probably not going to be maintained. Ben can weigh in on
this, though.....

FWIW, we talk quite a bit about bugs, patches, review and dev work
in #xfs (there's 50 people in the channel at the moment), so what
you see on the mailing list is often not the entire picture. There's
a lot more day to day dev stuff go on there -  what you see on the
mailing list is often the end result of something that was first
discussed on #xfs. :)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: xfsprogs patches pw 2883, 2986-2997

[Christoph Hellwig]

On Tue, Dec 20, 2011 at 01:33:43PM +1100, Dave Chinner wrote:
> > Dave Chinner had feedback requests on a couple items.
> 
> Yes, but Christoph has already replied so all I'm waiting on is a
> repost of the series from him addressing those comments. He did say
> it might take a while as he had other more critical stuff to do.

I'll plan to commit the patches that got an uncodintional positive
review this week, and then try to find time to implement more
complicated feedback

And nod to the mail format comments - please try to reply in-line or
just irc for quick questions.

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