Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Apr 2008 22:53:12 -0700 (PDT)
X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-r574664
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29])
	by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m385r3H3015566
	for <xfs@oss.sgi.com>; Mon, 7 Apr 2008 22:53:05 -0700
X-ASG-Debug-ID: 1207634021-640401480000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from smtp.getmail.no (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id D1C2A75DF69
	for <xfs@oss.sgi.com>; Mon,  7 Apr 2008 22:53:41 -0700 (PDT)
Received: from smtp.getmail.no (smtp.getmail.no [84.208.20.33]) by cuda.sgi.com with ESMTP id HIWtfuTHmUJsgaPp for <xfs@oss.sgi.com>; Mon, 07 Apr 2008 22:53:41 -0700 (PDT)
Received: from pmxchannel-daemon.no-osl-m323-srv-009-z2.isp.get.no by
 no-osl-m323-srv-009-z2.isp.get.no
 (Sun Java System Messaging Server 6.2-7.05 (built Sep  5 2006))
 id <0JYZ0070FSDGF000@no-osl-m323-srv-009-z2.isp.get.no> for xfs@oss.sgi.com;
 Tue, 08 Apr 2008 07:53:40 +0200 (CEST)
Received: from smtp.getmail.no ([10.5.16.1])
 by no-osl-m323-srv-009-z2.isp.get.no
 (Sun Java System Messaging Server 6.2-7.05 (built Sep  5 2006))
 with ESMTP id <0JYZ00AWNSCPDD90@no-osl-m323-srv-009-z2.isp.get.no> for
 xfs@oss.sgi.com; Tue, 08 Apr 2008 07:53:13 +0200 (CEST)
Received: from localhost ([84.215.109.218])
 by no-osl-m323-srv-009-z1.isp.get.no
 (Sun Java System Messaging Server 6.2-7.05 (built Sep  5 2006))
 with ESMTP id <0JYZ002KFSCP8RA0@no-osl-m323-srv-009-z1.isp.get.no> for
 xfs@oss.sgi.com; Tue, 08 Apr 2008 07:53:13 +0200 (CEST)
Received: from thor by localhost with local (Exim 4.69 #1 (Debian))
	id 1Jj6ld-0007qI-9W; Tue, 08 Apr 2008 07:53:13 +0200
Date: Tue, 08 Apr 2008 07:53:13 +0200
From: Thor Kristoffersen <thorkr@gmail.com>
X-ASG-Orig-Subj: Re: Does XFS prevent disk spindown?
Subject: Re: Does XFS prevent disk spindown?
In-reply-to: <20080407215855.GE108924158@sgi.com>
To: David Chinner <dgc@sgi.com>
Cc: Timothy Shimmin <tes@sgi.com>, xfs@oss.sgi.com
Message-id: <m2skxwriye.fsf@getmail.no>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <m2tzimbvif.fsf@getmail.no> <20080401003005.GJ103491721@sgi.com>
 <47F1CF6D.2040103@sandeen.net> <m2d4p9o2sc.fsf@getmail.no>
 <m2y77smmdj.fsf@getmail.no> <47F9735E.8020900@sgi.com>
 <m2wsn9qub4.fsf@getmail.no> <20080407215855.GE108924158@sgi.com>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
X-Barracuda-Connect: smtp.getmail.no[84.208.20.33]
X-Barracuda-Start-Time: 1207634021
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -2.02
X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=UNPARSEABLE_RELAY
X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.47165
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
	0.00 UNPARSEABLE_RELAY      Informational: message has unparseable relay lines
X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com
X-Virus-Status: Clean
X-archive-position: 15255
X-ecartis-version: Ecartis v1.0.0
Sender: xfs-bounce@oss.sgi.com
Errors-to: xfs-bounce@oss.sgi.com
X-original-sender: thorkr@gmail.com
Precedence: bulk
X-list: xfs

David Chinner <dgc@sgi.com> writes:
>> > What does 'xfs_logprint -t' show in these "idle" states
>> > after these writes?
>> 
>> xfs_logprint produces output like the one shown below, so it does indeed
>> look like it's writing to the journal.  But why should it need to keep
>> writing to the journal when there have been no updates to any files on that
>> partition recently?
>
> Are you using lazy-count=1? (i.e. output of 'xfs_info <mtpt>', please).

Looks like I am:

meta-data=/dev/sda3              isize=256    agcount=4, agsize=42676171 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=170704681, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Is that what's causing it?  I have never specified any lazy-count option
when I created or mounted the filesystem.  I didn't even know it existed.


Thor