----- Original Message -----
From: "Nathan Scott" <nathans@xxxxxxx>
To: "Steve Lord" <lord@xxxxxxx>
Cc: "Alex Wun" <alexwun@xxxxxxxxxxxxx>; <linux-xfs@xxxxxxxxxxx>
Sent: Wednesday, February 25, 2004 11:06 PM
Subject: Re: XFS Writes: IOLOCK_EXCL
> Thanks Steve.
>
> On Wed, Feb 25, 2004 at 07:58:24AM -0600, Steve Lord wrote:
> >
> > Only speaking for 2.6 here, so take that under advisement.
>
> After an audit, this seems to be valid for both 2.4 and 2.6.
>
> > There are very few callers of fsync in the kernel, and they all do the
> > data flush and wait for data themselves, the filesystem fsync code is
> > not involved in the data flush at all for most filesystems, just the
> > metadata for the file. The callers hold the i_sem, but not the nfs
> > commit case.
>
> Mmmm? seems to me that i_sem is also held for nfs commit, both
> in 2.4 and 2.6 (nfsd_commit -> nfsd_sync -> down(i_sem) ->
> nfsd_dosync -> fop->fsync).
>
> > As for flushing data without the IO lock, I think this is OK in general,
> > if a new read comes along there is no problem, if a new write modifies
> > the page then it will get redirtied and flushed again later. If a
> > truncate removes the page then it will delete the page before after
> > it is flushed. The holding of the IO lock is partially a hold over
> > from Irix where it is required around the VOP_FLUSH..... calls.
>
> Yep, OK, thanks.
>
> > The tosspages and flushinval pages cases do need the lock though.
> >
> > This is untested, but should generally speed things up in 2.6. A very
> > quick scan of 2.4 seems to suggest a similar change will work there
> > too.
>
> I think its always valid to do this (after auditing the callers),
> but doesn't seem to do "general speedup" - the "usual suspects"
> benchmarks don't show any improvements anyway. Alex, what was
> your workload? (you didn't get back to me yet).
>
Sorry that I haven't gotten back to you in response to your question about
the workload. Prior to your suggestion I had only tested a single
application running on a single client over synchronous NFS v3. The
application performs sequential writing of 4GB files to fill up the
partition and then turns around and does sequential reading of those files
to verify the their contents. I am now trying multiple clients running
multiple instances of the app. This has led to some issues on the client
side.
After conferring with the lead developer, we have decided to produce a set
of patches that reflect the work that we have done so far. The overall
objective has been to improve NFS synchronous write performance. To
accomplish this we have had to make changes to the Linux NFS client code,
the Linux NFS server code and the XFS file system code on the server. We
intend to submit these patches to the net shortly.
Alex Wun
|