From: Thor Kristoffersen <thorkr@gmail.com>
To: Timothy Shimmin <tes@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: Does XFS prevent disk spindown?
Date: Mon, 07 Apr 2008 22:33:19 +0200 [thread overview]
Message-ID: <m2wsn9qub4.fsf@getmail.no> (raw)
In-Reply-To: <47F9735E.8020900@sgi.com>
Timothy Shimmin <tes@sgi.com> writes:
> Thor Kristoffersen wrote:
>>> Use blktrace, or echo 1 > /proc/sys/vm/block_dump to see what block and
>>> who's writing it... it's probably the superblock? what kernel?
>>
>> This is kernel version 2.6.24. More specifically it's a Debian kernel from
>> package linux-image-2.6.24-1-686 (2.6.24-4).
>>
>> I put the system in runlevel 1 and executed the test as you suggested. On
>> /dev/sda3 I have mounted (with noatime) an XFS filesystem that contains
>> data that is not supposed to be accessed by any process. In the output
>> below I have filtered out all accesses to other partitions. (BTW, this is
>> not actually the disk that I wanted to spin down, but I think the log
>> proves my point.)
>>
>>
> I'm wondering if that is writing to the xfs ondisk log/journal in those cases.
> 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?
Thor
----------------------------------------------------------------
xfs_logprint:
data device: 0x803
log device: 0x803 daddr: 682818768 length: 262144
log tail: 157103 head: 157107 state: <DIRTY>
LOG REC AT LSN cycle 1 block 157103 (0x1, 0x265af)
============================================================================
TRANS: tid:0xf2fcd6e0 type:SB_COUNT #items:1 trans:0x0 q:0x80b4c08
BUF: cnt:2 total:2 a:0x8099140 len:24 a:0x80ac748 len:128
BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0
SUPER Block Buffer:
LOG REC AT LSN cycle 1 block 157105 (0x1, 0x265b1)
============================================================================
TRANS: tid:0xf2fcd790 type:SB_COUNT #items:1 trans:0x0 q:0x80b4c08
BUF: cnt:2 total:2 a:0x8099140 len:24 a:0x80ac748 len:128
BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0
SUPER Block Buffer:
next prev parent reply other threads:[~2008-04-07 21:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-31 18:26 Does XFS prevent disk spindown? Thor Kristoffersen
2008-04-01 0:30 ` David Chinner
2008-04-01 6:00 ` Eric Sandeen
2008-04-01 18:20 ` Thor Kristoffersen
2008-04-05 14:01 ` Thor Kristoffersen
2008-04-07 1:05 ` Timothy Shimmin
2008-04-07 20:33 ` Thor Kristoffersen [this message]
2008-04-07 21:58 ` David Chinner
2008-04-08 5:53 ` Thor Kristoffersen
2008-04-09 4:11 ` [patch] " David Chinner
2008-04-09 21:32 ` Thor Kristoffersen
2008-04-09 23:02 ` David Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2wsn9qub4.fsf@getmail.no \
--to=thorkr@gmail.com \
--cc=tes@sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox