[Top] [All Lists]


To: "Nathan Scott" <nathans@xxxxxxx>, "Steve Lord" <lord@xxxxxxx>
Subject: Re: XFS Writes: IOLOCK_EXCL
From: "Alex Wun" <alexwun@xxxxxxxxxxxxx>
Date: Thu, 26 Feb 2004 10:09:57 -0500
Cc: <linux-xfs@xxxxxxxxxxx>
References: <Pine.LNX.4.44.0402240914430.12803-100000@stout.americas.sgi.com> <01fa01c3fafa$7c3482d0$9002a8c0@consensys.com> <20040225062907.GB1832@frodo> <403CAA00.20502@xfs.org> <20040226040651.GC1177@frodo>
Sender: linux-xfs-bounce@xxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>