I'm just forwarding everything to you. They're kind of on the wrong track
Again. Sorry for the mess I've created.
----- 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).