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

[Mark Tinguely]

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 at oss.sgi.com
> 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 at sgi.com>