xfs
[Top] [All Lists]

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

To: Peter Grandi <pg_xf2@xxxxxxxxxxxxxxxxxx>
Subject: Re: I/O hang, possibly XFS, possibly general
From: Phil Karn <karn@xxxxxxxxxxxx>
Date: Thu, 02 Jun 2011 17:06:04 -0700
Cc: Linux fs XFS <xfs@xxxxxxxxxxx>
In-reply-to: <19943.56524.969126.59978@xxxxxxxxxxxxxxxxxx>
References: <BANLkTim_BCiKeqi5gY_gXAcmg7JgrgJCxQ@xxxxxxxxxxxxxx> <19943.56524.969126.59978@xxxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
On 6/2/11 11:56 AM, Peter Grandi wrote:

> Disclaimer: some smart people I know built knowingly a similar
> and fortunately much smaller collection of RAID6 sets because
> that was the least worst option for them, and since they know
> that it will not fill up before they can replace it, they are
> effectively short-stroking all those 2TB drives (I still would
> have bought ERC ones if possible) so it's cooler than it looks.

What do you mean by "short stroking"? That the data (and head motions)
stay in one part of the disk? I haven't been using XFS that long and I'm
no expert on it, but I've noticed that it seems to distribute files
pretty evenly across an entire disk. Even without the inode64 option,
only the inodes are kept at the beginning; the data can be anywhere.

The only way I can think of to confine the activity on a lightly-loaded
XFS file system to one part of a disk (e.g., to reduce average seek
times and to stay in the faster outer area of the drive) is to create
partitions that initially span only part of the disk, then grow them
later as needed. Is that what you mean?

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