| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: XFS blocked task in xlog_cil_force_lsn, Dave Chinner |
|---|---|
| Next by Date: | Re: XFS blocked task in xlog_cil_force_lsn, Stefan Priebe - Profihost AG |
| Previous by Thread: | Re: Fragmentation Issue We Are Having, Dave Chinner |
| Next by Thread: | Re: Fragmentation Issue We Are Having, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |