xfs
[Top] [All Lists]

Re: [RFC, PATCH 0/102]: xfs: 3.0.x stable kernel update

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [RFC, PATCH 0/102]: xfs: 3.0.x stable kernel update
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Tue, 18 Sep 2012 08:59:04 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1345698180-13612-1-git-send-email-david@xxxxxxxxxxxxx>
References: <1345698180-13612-1-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 08/23/12 00:01, Dave Chinner wrote:
This series is a backport of all the major bug fixes in the current
TOT kernel to the current 3.0.x stable tree.

I won't make any secret of this - the fixes and supporting patches
have been selected as a result of the issues reported in the current
RHEL XFS codebase which currently is 2 commits short of the 3.0 code
base.  With that said, it doesn't take a brain surgeon to work out
the motivations behind this work and eventual destination of the
patch set. ;)

There's no guarantee I have caught every single bug fix that has
been made since 3.0, but I've tried to grab all the bug fix commits
as indicated by the commit headers (hence the importance of good one
line bug summaries).

Over the past couple of weeks of testing and refining, I've had only
three significant problems arise from QA and load testing:

        1) An unreproducable log space hang
        2) An unmount panic due to buffers not being cleaned up
        before tearing down the perag tree
        3) A forced shutdown panic in block_invalidatepage()
        via xfs_aops_discard_page()

It's entirely possible that #1 was due to the CIL space hang we
still haven't got to the bottom of, so i'm not not greatly concerned
by that. #2 implies I haven't quite backported the shutdown ordering
fixes correctly (or I missed one), so I have a bit more work to do
there. And for #3 - I've never seen that before and I haven't been
able to reproduce it, so I really don't know what potential cause or
impact it has.

I've been beating on the series with xfstests, dbench, fsmark,
postmark, compilebench and a few other load scripts that I've got,
and it seems fairly resilient.  Hence, it's time to give the series
wider testing and review to flush out any remaining issues.

For all the folks that run 3.0.x stable kernels, I'd appreciate it if
you could give this a whirl on your test systems to see if there are
any obvious, glaring problems that show up under your particular
workloads. This woul dbe of great benefit to me before I submit the
series to the stable kernel gurus - I'd prefer it there's more
substantial testing than "i've done what I can" when sending them
the series.

For all the XFS developers that have copious amounts of free time
available, I'd appreciate an eye run over the patch list to see if
there's any potential bug fixes that I missed or have made glaring
errors in backporting. Some of the fixes are dependent on cleanups I
haven't included, so some of the patches are a bit different to what
is in mainline (e.g. anything that touches setattr). Most important
to look at is probably the inode i_size changes and the logging of
all metadata changes.

Enjoy!

Cheers,

Dave.

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

This looks great. Like I said earlier, I did not find Brian Foster's log patch:
  xfs: check for stale inode before acquiring iflock on push
  Upstream commit: 9a3a5dab63461b84213052888bf38a962b22d035
sample implementation listed on:
  http://oss.sgi.com/archives/xfs/2012-09/msg00188.html

Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>

<Prev in Thread] Current Thread [Next in Thread>