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