xfs
[Top] [All Lists]

Re: Impact of atime updates on XFS

To: Martin Steigerwald <Martin@xxxxxxxxxxxx>
Subject: Re: Impact of atime updates on XFS
From: David Chinner <dgc@xxxxxxx>
Date: Fri, 10 Aug 2007 16:24:02 +1000
Cc: linux-xfs@xxxxxxxxxxx, David Chinner <dgc@xxxxxxx>
In-reply-to: <200708091306.13011.Martin@lichtvoll.de>
References: <200708081408.01817.ms@teamix.de> <200708090820.55509.Martin@Lichtvoll.de> <20070809101544.GZ12413810@sgi.com> <200708091306.13011.Martin@lichtvoll.de>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Thu, Aug 09, 2007 at 01:06:12PM +0200, Martin Steigerwald wrote:
> Am Donnerstag 09 August 2007 schrieb David Chinner:
> > On Thu, Aug 09, 2007 at 08:20:55AM +0200, Martin Steigerwald wrote:
> > > Am Donnerstag 09 August 2007 schrieb David Chinner:
> > > > > What would be the impact of atime versus noatime on XFS? What is
> > > > > the recommended setting for XFS? Are there any plans to implement
> > > > > relatime logic - maybe even the improved one by Ingo Molnar -
> > > > > into XFS?
> > > >
> > > > relatime is a VFS layer construct - it should work with XFS right
> > > > now.
> > >
> > > Thanks for your answer.
> > >
> > > XFS says:
> > >
> > > XFS: unknown mount option [relatime].
> >
> > That's because it's supposed to be encoded in the mount flags (i.e.
> > intercepted by the mount binary and not passed to the kernel
> > directly). I think you need a more recent mount binary....
> 
> Exactly. After I upgraded mount debian package 2.12r-19 to 2.13~rc3-1 
> mount -o remount,relatime works.

Cool.

> I got a response back from Ingo and he said, that on ext3 atime updates 
> are very visible while XFS does some journalling tricks to mitigate it. 

Sure. If we can do it with XFS, why can't ext3? Doesn't this point out
to you that Ingo is really complaining aout a design deficiency with
ext3, not a generic "atime is bad" problem?

> He doubts that I will see much difference on XFS as it has less strict 
> synchronisation rules than ext3.

Ah, yes. That would be a reference to ext3 ordered mode where data
and metadata I/O is strictly ordered. XFS uses the equivalent of
ext3 writeback mode and so doesn't provide this strict ordering.

This has long been XFS's main weakness e.g. data I/Os vs file size
updates resulting in files full of NULLs. However, we've fixed that
particular problem without requiring strict ordering across the
entire filesystem and without introducing new performance
regressions or quirks.

We're solving these issues on a case by case basis via a different
mechanisms to provide efficient data/metadata ordering where it is
needed rather than enforcing it globally through the journal.

I think that we are starting to see the problems with the global
ordered mode model that is implemented in ext3 - fsync, flush
latency, atime updates, etc. I don't see how they can be easily
fixed without compromising the model and its guarantees.

IOWs, XFS's less strict synchronisation rules can be seen as a
distinct advantage over ext3 ordered mode due to the flexibility
they allow us in solving I/O ordering issues without needing to
compromise performance.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group


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