Re: [PATCH 0/28] XFS: sync and reclaim rework

[Dave Chinner <david@fromorbit.com>]

On Wed, Aug 20, 2008 at 09:11:49AM +1000, Mark Goodwin wrote:
> Thanks Dave - this is queued behind the btree factoring series;
> both need to be QA'd and stress/perf tested independently, which
> leads me to ask: how much QA has the sync/reclaim rework received?

It passes xfsqa. I've only been caring about correctness and getting
the code into a decent shape right now. Performance should not
change significantly for most workloads. The workload that
might benefit the most (cached lookups on a SMP NFS server) I
can't test myself anyway...

> (and could you make use of the machine Christoph has been using,
> since you're in non-overlapping TZs?)
> Also, if we were to change the inode / block offset direct mapping
> to an indirect method (e.g. inode32+), would this grossly affect
> the ascending inode number traversal optimization? If so, could that
> mechanism be made conditional?

Depends on the indirection mechanism. with inode32+, it was making
the AG number indirect. The per-ag radix trees only index the offset
of the inode into the AG, so such a change would not adversely
impact the new algorithm.

If we move to full location independence for inode numbers (not that
this will ever happen) then we'd fall back to the current situation
of effectively random order reclaim.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com