[Top] [All Lists]

Re: I/O hang, possibly XFS, possibly general

To: Paul Anderson <pha@xxxxxxxxx>
Subject: Re: I/O hang, possibly XFS, possibly general
From: Phil Karn <karn@xxxxxxxxxxxx>
Date: Thu, 02 Jun 2011 16:59:25 -0700
Cc: Peter Grandi <pg_xf2@xxxxxxxxxxxxxxxxxx>, Linux fs XFS <xfs@xxxxxxxxxxx>
In-reply-to: <BANLkTim978GhfamN=TEFULP5GdfMu02-7w@xxxxxxxxxxxxxx>
References: <BANLkTim_BCiKeqi5gY_gXAcmg7JgrgJCxQ@xxxxxxxxxxxxxx> <19943.56524.969126.59978@xxxxxxxxxxxxxxxxxx> <BANLkTim978GhfamN=TEFULP5GdfMu02-7w@xxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20110414 Thunderbird/3.1.10
On 6/2/11 2:24 PM, Paul Anderson wrote:

> The data itself has very odd lifecycle behavior, as well - since it is
> research, the different stages are still being sorted out, but some
> stages are essentially write once, read once, maybe keep, maybe
> discard, depending on the research scenario.
> The bulk of the work is not small-file - almost all is large files.

Out of curiosity, do your writers use the fallocate() call? If not, how
fragmented do your filesystems get?

Even if most of your data isn't read very often, it seems like a good
idea to minimize its fragmentation because that also reduces
fragmentation of the free list, which makes it easier to keep contiguous
other files that *are* heavily read. Also, fewer extents per file means
less metadata per file, ergo less metadata and log I/O, etc.

When a writer knows in advance how big a file will be, I can't see any
downside to having it call fallocate() to let the file system know. Soon
after I switched to XFS six months ago I've been running locally patched
versions of rsync/tar/cp and so on, and they really do minimize
fragmentation with very little effort.

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