xfs
[Top] [All Lists]

Re: Fragmentation Issue We Are Having

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Fragmentation Issue We Are Having
From: Brian Candler <B.Candler@xxxxxxxxx>
Date: Tue, 17 Apr 2012 09:58:28 +0100
Cc: David Fuller <dfuller@xxxxxxxxx>, xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=sasl; bh=D4pc7qo6GHRA4FgXxmf0+klNXzo=; b=dD2zq6l FJ8B7ru5OcvwB8Dh7QME3L7uCtIvPZK4F7HD5/C0AGsNIFM3SrzPx8DUvQ2ORewY eSFu8yI+r6+LOvvlbrEauL8woAqXHF21iV3SXO7ZY7SP2WDx52KCPsfm73uE1FEz vcDWZNLeTu/TzYeMvH28bhlYzIjPdxKitYEg=
Domainkey-signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to:cc :subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sasl; b=K+F0jzlUSarlmqSvnYVEdPodg91cZpHec J7bHk33NBZw2UGIO5CTUtctR5Svrei5u1fKnnCbpYsBSXowMysVa8LtheiuVQS4c BKj7caQGUNQFVLfe4QzxGB0d6pORgNv/VTUgabLxYdD4js3dYxDQp7f++pG7iXKO PRKLaurXXM=
In-reply-to: <20120417002610.GC6734@dastard>
References: <CADrkzimg891ZBGK7-UzhGeey16KwH-ZXpEqFr=O3KwD3qA9LwQ@xxxxxxxxxxxxxx> <20120412075747.GB30891@xxxxxxxx> <CADrkzi=JNsbXJHkcb=oOZHLEYMBDUkNHu9O8JFT9h+kSArL47A@xxxxxxxxxxxxxx> <20120413071905.GA823@xxxxxxxx> <20120413075634.GD6734@dastard> <20120413081725.GA3640@xxxxxxxx> <20120417002610.GC6734@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Apr 17, 2012 at 10:26:10AM +1000, Dave Chinner wrote:
> > > You can't just blindly assert that something is needed purely on
> > > the size of the filesystem.
> > 
> > Thanks, but then perhaps the XFS FAQ needs updating. It warns that you might
> > have compatibility problems with old clients (NFS) and inode64, but it
> > doesn't say "for some workloads inode32 may perform better than inode64 on
> > large filesystems".
> 
> The FAQ doesn't say anything about whether inode32 performs better
> than inode64 or vice versa.

With respect it does, although in only three words:
"Also, performance sucks".

Maybe it would be useful to expand this. How about:

"Also, performance sucks for many common workloads and benchmarks, such as
sequentially extracting or reading a large hierarchy of files.  This is
because in filesystems >1TB without inode64, files created within the same
parent directory are not created in the same allocation group with adjacent
extents."

If as you say inode32 was just a hack for broken NFS clients, then it seems
to me that the *intended* default performance characteristics are those of
inode64?  That is, the designers considered this to be the most appropriate
performance compromise for typical users?

Regards,

Brian.

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