On Fri, Oct 12, 2007 at 12:36:01PM +0100, Andrew Clayton wrote:
> On Fri, 12 Oct 2007 10:26:13 +1000, David Chinner wrote:
>
> > You can breath again. Here's a test patch (warning - may harm
>
> heh
>
> > kittens - not fully tested or verified) that solves both
> > the use-after-free issue (by avoiding it altogether) as well the
> > unlink/create latency because the log force is no longer there.
> >
> > (yay! xfsqa test 016 passes again ;)
> >
> > It does have other possible side effects triggering extra
> > log forces elsewhere on inode writeback and affects sync behaviour
> > so it's only a proof of concept at this point.
>
> What kernel is that against?. I got rejects with 2.6.23
The xfs-dev tree - i.e. the XFS that will be in 2.6.25 ;)
> However I tried a 2.6.18 on the file server and ran my test, it didn't
> show the problem. I then made a 2.6.23 but with the patch from my git
> bisect reverted.
>
> Doing the test with that kernel, while writing a 1GB file I saw only
> one > 1 second latency (1.2) and only a few ~ 0.5 second latencies.
>
> However over the longer term I'm still seeing latencies > 1 second.
Sure - you've got a busy disk. If the truncate has to flush the log
and wait for space, then it's going to take some time for I/Os
to complete. Full queue + busy disk == unpredictable latency for all
operations.
> Just leaving my strace test running (no dd) on the raid filesystem I see
> the
> latencies come when the raid5 stripe cache fills up. So I think I'm
> perhaps seeing another problem here.
Software raid isn't good for latency, either ;)
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
|