Hi Dave, On Fri, Aug 24, 2012 at 07:54:09AM +1000, Dave Chinner wrote: > Can please tell me if you did or didn't get the entire series. I > didn't receive the entire series back in my inbox - about 20 are > missing from my inbox. A quick check of the archives shows that all > 102 patches reached the server and entered the archive, so I'm > curious to know how many people had delivery failures.... I got the whole series. Pretty excellent FWICS so far. Regards, Ben > Cheers, > > Dave. > > On Thu, Aug 23, 2012 at 03:01:18PM +1000, 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 message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > -- > Dave Chinner > david@xxxxxxxxxxxxx > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
