On Mon, Feb 25, 2013 at 09:50:12AM -0600, Eric Sandeen wrote:
> On 8/23/12 12:00 PM, Ben Myers wrote:
> > On Thu, Aug 23, 2012 at 09:42:19AM +1000, Dave Chinner wrote:
> >> Sure, but you need to justify your arguments for keeping something
> >> with evidence and logic - handwaving about wanting something is, and
> >> always has been, insufficient justification. That's the part of the
> >> process I'm talking about - that statements of need require
> >> evidence, especially when you agreed to the removal at LSF in San
> >> Fransisco a few months ago. My arguments at the time were:
> >> a) nobody is actually using it,
> >> b) it has effectively been unmaintained since 2003
> >> c) it has no regression analysis or detection capability
> >> d) it shares *very little* of xfstests
> >> e) it gets in the way of cleaning up xfstests
> >> f) there are far better workload generators that are being
> >> actively maintained.
> >> And AFAIA, nothing has changed in the past few months.
> > "In this case, SGI would like to keep the benchmark capability in xfstests
> > in
> > order have a better chance of catching performance regressions." There has
> > been a been performance regression in the past few months (and there will be
> > more in the future), we have had performance regressions internally too, and
> > this has brought the value of having benchmarks in xfstests into sharp
> > focus.
> "xfs has had performance regressions; xfstests contains bitrotted perf code"
> But that's not a justification for keeping bitrotted code.
> I think you finally answered the basic question Dave asked, and we learned
> that SGI is not using the code which he proposes removing.
> > I understand that bench is bitrotted, but it still has some value even
> > today.
> Not if nobody uses it. If it really had value it would be in use.
> > Phil has agreed to take this on as a project so the bitrot will be
> > addressed.
> How's that been going in the 6 months since this patchset stalled?
> Can we get it moving again? Ext4 folks would like to see these changes
> proceed as well. What issues remain, if any?
AFAIC, none. But it will take me some time to rebase the patchsets
on a current TOT as there are a bunch more tests and infrastructure
changes since then, and I currently have my plate full.
Eric (or anyone else), seeing as I'm not going to get back to this
for a while yet, I'm happy for you to take over this patchset (and
the --largefs patch set it is based on and rebase them on a current