* Does XFS prevent disk spindown?
@ 2008-03-31 18:26 Thor Kristoffersen
2008-04-01 0:30 ` David Chinner
0 siblings, 1 reply; 12+ messages in thread
From: Thor Kristoffersen @ 2008-03-31 18:26 UTC (permalink / raw)
To: xfs
I've noticed that when I spin down XFS-mounted disks they spin up again
shortly afterwards. I used iostat to monitor disk accesses to a mounted
partition (with noatime) in single user mode. Apparently there is a write
access to the partition approximately every 35 seconds, even if the
partition is idle. As far as I can understand, since there is no data that
needs to be flushed this must be done by an XFS daemon for some purpose.
Is there any setting or mount option I can use to get rid of this behavior?
I know I can freeze the filesystem, but then I have to remember to unfreeze
it every time I need to write to it, so it's not an ideal solution.
Thor
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Does XFS prevent disk spindown?
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
0 siblings, 1 reply; 12+ messages in thread
From: David Chinner @ 2008-04-01 0:30 UTC (permalink / raw)
To: Thor Kristoffersen; +Cc: xfs
On Mon, Mar 31, 2008 at 08:26:00PM +0200, Thor Kristoffersen wrote:
> I've noticed that when I spin down XFS-mounted disks they spin up again
> shortly afterwards. I used iostat to monitor disk accesses to a mounted
> partition (with noatime) in single user mode. Apparently there is a write
> access to the partition approximately every 35 seconds, even if the
> partition is idle. As far as I can understand, since there is no data that
> needs to be flushed this must be done by an XFS daemon for some purpose.
>
> Is there any setting or mount option I can use to get rid of this behavior?
> I know I can freeze the filesystem, but then I have to remember to unfreeze
> it every time I need to write to it, so it's not an ideal solution.
Turn on laptop mode?
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Does XFS prevent disk spindown?
2008-04-01 0:30 ` David Chinner
@ 2008-04-01 6:00 ` Eric Sandeen
2008-04-01 18:20 ` Thor Kristoffersen
0 siblings, 1 reply; 12+ messages in thread
From: Eric Sandeen @ 2008-04-01 6:00 UTC (permalink / raw)
To: David Chinner; +Cc: Thor Kristoffersen, xfs
David Chinner wrote:
> On Mon, Mar 31, 2008 at 08:26:00PM +0200, Thor Kristoffersen wrote:
>> I've noticed that when I spin down XFS-mounted disks they spin up again
>> shortly afterwards. I used iostat to monitor disk accesses to a mounted
>> partition (with noatime) in single user mode. Apparently there is a write
>> access to the partition approximately every 35 seconds, even if the
>> partition is idle. As far as I can understand, since there is no data that
>> needs to be flushed this must be done by an XFS daemon for some purpose.
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?
On an idle-in-gdm 2.6.25 system, xfs root, I see something like this
from block_dump... it does settle out after a while:
# while true
> do
> date
> sleep 5
> dmesg -c
> done
bash(2986): READ block 448128 on sda2
bash(2986): dirtied inode 820453 (date) on sda2
date(2986): READ block 448160 on sda2
bash(2987): READ block 449736 on sda2
bash(2987): dirtied inode 820470 (sleep) on sda2
sleep(2987): READ block 449768 on sda2
Tue Apr 1 00:24:12 CDT 2008
xfssyncd(465): dirtied inode 128 (/) on sda2
xfssyncd(465): WRITE block 10246607 on sda2
Tue Apr 1 00:24:17 CDT 2008
Tue Apr 1 00:24:22 CDT 2008
Tue Apr 1 00:24:27 CDT 2008
Tue Apr 1 00:24:32 CDT 2008
Tue Apr 1 00:24:37 CDT 2008
Tue Apr 1 00:24:42 CDT 2008
pdflush(178): WRITE block 64 on sda2
Tue Apr 1 00:24:47 CDT 2008
Tue Apr 1 00:24:52 CDT 2008
Tue Apr 1 00:24:57 CDT 2008
Tue Apr 1 00:25:02 CDT 2008
Tue Apr 1 00:25:07 CDT 2008
Tue Apr 1 00:25:12 CDT 2008
xfssyncd(465): dirtied inode 128 (/) on sda2
xfssyncd(465): WRITE block 10246609 on sda2
Tue Apr 1 00:25:17 CDT 2008
Tue Apr 1 00:25:22 CDT 2008
Tue Apr 1 00:25:27 CDT 2008
Tue Apr 1 00:25:32 CDT 2008
Tue Apr 1 00:25:37 CDT 2008
Tue Apr 1 00:25:42 CDT 2008
pdflush(178): WRITE block 64 on sda2
Tue Apr 1 00:25:47 CDT 2008
Tue Apr 1 00:25:52 CDT 2008
Tue Apr 1 00:25:57 CDT 2008
Tue Apr 1 00:26:02 CDT 2008
Tue Apr 1 00:26:07 CDT 2008
Tue Apr 1 00:26:12 CDT 2008
Tue Apr 1 00:26:17 CDT 2008
Tue Apr 1 00:26:22 CDT 2008
Tue Apr 1 00:26:27 CDT 2008
Tue Apr 1 00:26:32 CDT 2008
Tue Apr 1 00:26:37 CDT 2008
Tue Apr 1 00:26:42 CDT 2008
Tue Apr 1 00:26:47 CDT 2008
Tue Apr 1 00:26:52 CDT 2008
Tue Apr 1 00:26:57 CDT 2008
Tue Apr 1 00:27:02 CDT 2008
Tue Apr 1 00:27:07 CDT 2008
Tue Apr 1 00:27:12 CDT 2008
Tue Apr 1 00:27:17 CDT 2008
Tue Apr 1 00:27:22 CDT 2008
Tue Apr 1 00:27:27 CDT 2008
Tue Apr 1 00:27:32 CDT 2008
Tue Apr 1 00:27:37 CDT 2008
Tue Apr 1 00:27:42 CDT 2008
Tue Apr 1 00:27:47 CDT 2008
Tue Apr 1 00:27:52 CDT 2008
Tue Apr 1 00:27:57 CDT 2008
Tue Apr 1 00:28:02 CDT 2008
Tue Apr 1 00:28:07 CDT 2008
Tue Apr 1 00:28:12 CDT 2008
Tue Apr 1 00:28:17 CDT 2008
Tue Apr 1 00:28:22 CDT 2008
Tue Apr 1 00:28:27 CDT 2008
Tue Apr 1 00:28:32 CDT 2008
Tue Apr 1 00:28:37 CDT 2008
Tue Apr 1 00:28:42 CDT 2008
Tue Apr 1 00:28:47 CDT 2008
Tue Apr 1 00:28:52 CDT 2008
Tue Apr 1 00:28:57 CDT 2008
Tue Apr 1 00:29:02 CDT 2008
Tue Apr 1 00:29:07 CDT 2008
Tue Apr 1 00:29:12 CDT 2008
Tue Apr 1 00:29:17 CDT 2008
Tue Apr 1 00:29:22 CDT 2008
Tue Apr 1 00:29:27 CDT 2008
Tue Apr 1 00:29:32 CDT 2008
Tue Apr 1 00:29:37 CDT 2008
Tue Apr 1 00:29:42 CDT 2008
Tue Apr 1 00:29:47 CDT 2008
Tue Apr 1 00:29:52 CDT 2008
Tue Apr 1 00:29:57 CDT 2008
....
-Eric
>> Is there any setting or mount option I can use to get rid of this behavior?
>> I know I can freeze the filesystem, but then I have to remember to unfreeze
>> it every time I need to write to it, so it's not an ideal solution.
>
> Turn on laptop mode?
>
> Cheers,
>
> Dave.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Does XFS prevent disk spindown?
2008-04-01 6:00 ` Eric Sandeen
@ 2008-04-01 18:20 ` Thor Kristoffersen
2008-04-05 14:01 ` Thor Kristoffersen
0 siblings, 1 reply; 12+ messages in thread
From: Thor Kristoffersen @ 2008-04-01 18:20 UTC (permalink / raw)
To: Eric Sandeen; +Cc: David Chinner, xfs
Eric Sandeen <sandeen@sandeen.net> writes:
> David Chinner wrote:
>> On Mon, Mar 31, 2008 at 08:26:00PM +0200, Thor Kristoffersen wrote:
>>> I've noticed that when I spin down XFS-mounted disks they spin up again
>>> shortly afterwards. I used iostat to monitor disk accesses to a mounted
>>> partition (with noatime) in single user mode. Apparently there is a write
>>> access to the partition approximately every 35 seconds, even if the
>>> partition is idle. As far as I can understand, since there is no data that
>>> needs to be flushed this must be done by an XFS daemon for some purpose.
>
> 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.)
Thor
------------------------------------------------------
Tue Apr 1 18:51:27 CEST 2008
xfssyncd(3426): WRITE block 682946473 on sda3
Tue Apr 1 18:51:32 CEST 2008
Tue Apr 1 18:51:37 CEST 2008
Tue Apr 1 18:51:42 CEST 2008
Tue Apr 1 18:51:47 CEST 2008
Tue Apr 1 18:51:52 CEST 2008
Tue Apr 1 18:51:57 CEST 2008
Tue Apr 1 18:52:02 CEST 2008
xfssyncd(3426): WRITE block 682946475 on sda3
Tue Apr 1 18:52:07 CEST 2008
Tue Apr 1 18:52:12 CEST 2008
Tue Apr 1 18:52:17 CEST 2008
Tue Apr 1 18:52:22 CEST 2008
Tue Apr 1 18:52:27 CEST 2008
Tue Apr 1 18:52:32 CEST 2008
Tue Apr 1 18:52:37 CEST 2008
Tue Apr 1 18:52:42 CEST 2008
xfssyncd(3426): WRITE block 682946477 on sda3
Tue Apr 1 18:52:47 CEST 2008
Tue Apr 1 18:52:52 CEST 2008
Tue Apr 1 18:52:57 CEST 2008
Tue Apr 1 18:53:02 CEST 2008
Tue Apr 1 18:53:07 CEST 2008
Tue Apr 1 18:53:12 CEST 2008
Tue Apr 1 18:53:17 CEST 2008
xfssyncd(3426): WRITE block 682946479 on sda3
Tue Apr 1 18:53:22 CEST 2008
Tue Apr 1 18:53:27 CEST 2008
Tue Apr 1 18:53:32 CEST 2008
Tue Apr 1 18:53:37 CEST 2008
Tue Apr 1 18:53:42 CEST 2008
Tue Apr 1 18:53:47 CEST 2008
Tue Apr 1 18:53:52 CEST 2008
xfssyncd(3426): WRITE block 682946481 on sda3
Tue Apr 1 18:53:57 CEST 2008
Tue Apr 1 18:54:02 CEST 2008
Tue Apr 1 18:54:07 CEST 2008
Tue Apr 1 18:54:12 CEST 2008
Tue Apr 1 18:54:17 CEST 2008
Tue Apr 1 18:54:22 CEST 2008
Tue Apr 1 18:54:27 CEST 2008
xfssyncd(3426): WRITE block 682946483 on sda3
Tue Apr 1 18:54:32 CEST 2008
Tue Apr 1 18:54:37 CEST 2008
Tue Apr 1 18:54:42 CEST 2008
Tue Apr 1 18:54:47 CEST 2008
Tue Apr 1 18:54:52 CEST 2008
Tue Apr 1 18:54:57 CEST 2008
Tue Apr 1 18:55:02 CEST 2008
xfssyncd(3426): WRITE block 682946485 on sda3
Tue Apr 1 18:55:07 CEST 2008
Tue Apr 1 18:55:12 CEST 2008
Tue Apr 1 18:55:17 CEST 2008
Tue Apr 1 18:55:22 CEST 2008
Tue Apr 1 18:55:27 CEST 2008
Tue Apr 1 18:55:32 CEST 2008
Tue Apr 1 18:55:37 CEST 2008
xfssyncd(3426): WRITE block 682946487 on sda3
Tue Apr 1 18:55:42 CEST 2008
Tue Apr 1 18:55:47 CEST 2008
Tue Apr 1 18:55:52 CEST 2008
Tue Apr 1 18:55:57 CEST 2008
Tue Apr 1 18:56:02 CEST 2008
Tue Apr 1 18:56:07 CEST 2008
Tue Apr 1 18:56:12 CEST 2008
Tue Apr 1 18:56:17 CEST 2008
xfssyncd(3426): WRITE block 682946489 on sda3
Tue Apr 1 18:56:22 CEST 2008
Tue Apr 1 18:56:27 CEST 2008
Tue Apr 1 18:56:32 CEST 2008
Tue Apr 1 18:56:37 CEST 2008
Tue Apr 1 18:56:42 CEST 2008
Tue Apr 1 18:56:47 CEST 2008
Tue Apr 1 18:56:52 CEST 2008
xfssyncd(3426): WRITE block 682946491 on sda3
Tue Apr 1 18:56:57 CEST 2008
Tue Apr 1 18:57:02 CEST 2008
Tue Apr 1 18:57:07 CEST 2008
Tue Apr 1 18:57:12 CEST 2008
Tue Apr 1 18:57:17 CEST 2008
Tue Apr 1 18:57:22 CEST 2008
Tue Apr 1 18:57:27 CEST 2008
xfssyncd(3426): WRITE block 682946493 on sda3
Tue Apr 1 18:57:32 CEST 2008
Tue Apr 1 18:57:37 CEST 2008
Tue Apr 1 18:57:42 CEST 2008
Tue Apr 1 18:57:47 CEST 2008
Tue Apr 1 18:57:52 CEST 2008
Tue Apr 1 18:57:57 CEST 2008
Tue Apr 1 18:58:02 CEST 2008
xfssyncd(3426): WRITE block 682946495 on sda3
Tue Apr 1 18:58:07 CEST 2008
Tue Apr 1 18:58:12 CEST 2008
Tue Apr 1 18:58:17 CEST 2008
Tue Apr 1 18:58:22 CEST 2008
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Does XFS prevent disk spindown?
2008-04-01 18:20 ` Thor Kristoffersen
@ 2008-04-05 14:01 ` Thor Kristoffersen
2008-04-07 1:05 ` Timothy Shimmin
0 siblings, 1 reply; 12+ messages in thread
From: Thor Kristoffersen @ 2008-04-05 14:01 UTC (permalink / raw)
To: xfs
(It looks like my reply never made it to the list so I'm trying again.)
Eric Sandeen <sandeen@sandeen.net> writes:
> David Chinner wrote:
>> On Mon, Mar 31, 2008 at 08:26:00PM +0200, Thor Kristoffersen wrote:
>>> I've noticed that when I spin down XFS-mounted disks they spin up again
>>> shortly afterwards. I used iostat to monitor disk accesses to a mounted
>>> partition (with noatime) in single user mode. Apparently there is a write
>>> access to the partition approximately every 35 seconds, even if the
>>> partition is idle. As far as I can understand, since there is no data that
>>> needs to be flushed this must be done by an XFS daemon for some purpose.
>
> 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.)
Thor
------------------------------------------------------
Tue Apr 1 18:51:27 CEST 2008
xfssyncd(3426): WRITE block 682946473 on sda3
Tue Apr 1 18:51:32 CEST 2008
Tue Apr 1 18:51:37 CEST 2008
Tue Apr 1 18:51:42 CEST 2008
Tue Apr 1 18:51:47 CEST 2008
Tue Apr 1 18:51:52 CEST 2008
Tue Apr 1 18:51:57 CEST 2008
Tue Apr 1 18:52:02 CEST 2008
xfssyncd(3426): WRITE block 682946475 on sda3
Tue Apr 1 18:52:07 CEST 2008
Tue Apr 1 18:52:12 CEST 2008
Tue Apr 1 18:52:17 CEST 2008
Tue Apr 1 18:52:22 CEST 2008
Tue Apr 1 18:52:27 CEST 2008
Tue Apr 1 18:52:32 CEST 2008
Tue Apr 1 18:52:37 CEST 2008
Tue Apr 1 18:52:42 CEST 2008
xfssyncd(3426): WRITE block 682946477 on sda3
Tue Apr 1 18:52:47 CEST 2008
Tue Apr 1 18:52:52 CEST 2008
Tue Apr 1 18:52:57 CEST 2008
Tue Apr 1 18:53:02 CEST 2008
Tue Apr 1 18:53:07 CEST 2008
Tue Apr 1 18:53:12 CEST 2008
Tue Apr 1 18:53:17 CEST 2008
xfssyncd(3426): WRITE block 682946479 on sda3
Tue Apr 1 18:53:22 CEST 2008
Tue Apr 1 18:53:27 CEST 2008
Tue Apr 1 18:53:32 CEST 2008
Tue Apr 1 18:53:37 CEST 2008
Tue Apr 1 18:53:42 CEST 2008
Tue Apr 1 18:53:47 CEST 2008
Tue Apr 1 18:53:52 CEST 2008
xfssyncd(3426): WRITE block 682946481 on sda3
Tue Apr 1 18:53:57 CEST 2008
Tue Apr 1 18:54:02 CEST 2008
Tue Apr 1 18:54:07 CEST 2008
Tue Apr 1 18:54:12 CEST 2008
Tue Apr 1 18:54:17 CEST 2008
Tue Apr 1 18:54:22 CEST 2008
Tue Apr 1 18:54:27 CEST 2008
xfssyncd(3426): WRITE block 682946483 on sda3
Tue Apr 1 18:54:32 CEST 2008
Tue Apr 1 18:54:37 CEST 2008
Tue Apr 1 18:54:42 CEST 2008
Tue Apr 1 18:54:47 CEST 2008
Tue Apr 1 18:54:52 CEST 2008
Tue Apr 1 18:54:57 CEST 2008
Tue Apr 1 18:55:02 CEST 2008
xfssyncd(3426): WRITE block 682946485 on sda3
Tue Apr 1 18:55:07 CEST 2008
Tue Apr 1 18:55:12 CEST 2008
Tue Apr 1 18:55:17 CEST 2008
Tue Apr 1 18:55:22 CEST 2008
Tue Apr 1 18:55:27 CEST 2008
Tue Apr 1 18:55:32 CEST 2008
Tue Apr 1 18:55:37 CEST 2008
xfssyncd(3426): WRITE block 682946487 on sda3
Tue Apr 1 18:55:42 CEST 2008
Tue Apr 1 18:55:47 CEST 2008
Tue Apr 1 18:55:52 CEST 2008
Tue Apr 1 18:55:57 CEST 2008
Tue Apr 1 18:56:02 CEST 2008
Tue Apr 1 18:56:07 CEST 2008
Tue Apr 1 18:56:12 CEST 2008
Tue Apr 1 18:56:17 CEST 2008
xfssyncd(3426): WRITE block 682946489 on sda3
Tue Apr 1 18:56:22 CEST 2008
Tue Apr 1 18:56:27 CEST 2008
Tue Apr 1 18:56:32 CEST 2008
Tue Apr 1 18:56:37 CEST 2008
Tue Apr 1 18:56:42 CEST 2008
Tue Apr 1 18:56:47 CEST 2008
Tue Apr 1 18:56:52 CEST 2008
xfssyncd(3426): WRITE block 682946491 on sda3
Tue Apr 1 18:56:57 CEST 2008
Tue Apr 1 18:57:02 CEST 2008
Tue Apr 1 18:57:07 CEST 2008
Tue Apr 1 18:57:12 CEST 2008
Tue Apr 1 18:57:17 CEST 2008
Tue Apr 1 18:57:22 CEST 2008
Tue Apr 1 18:57:27 CEST 2008
xfssyncd(3426): WRITE block 682946493 on sda3
Tue Apr 1 18:57:32 CEST 2008
Tue Apr 1 18:57:37 CEST 2008
Tue Apr 1 18:57:42 CEST 2008
Tue Apr 1 18:57:47 CEST 2008
Tue Apr 1 18:57:52 CEST 2008
Tue Apr 1 18:57:57 CEST 2008
Tue Apr 1 18:58:02 CEST 2008
xfssyncd(3426): WRITE block 682946495 on sda3
Tue Apr 1 18:58:07 CEST 2008
Tue Apr 1 18:58:12 CEST 2008
Tue Apr 1 18:58:17 CEST 2008
Tue Apr 1 18:58:22 CEST 2008
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Does XFS prevent disk spindown?
2008-04-05 14:01 ` Thor Kristoffersen
@ 2008-04-07 1:05 ` Timothy Shimmin
2008-04-07 20:33 ` Thor Kristoffersen
0 siblings, 1 reply; 12+ messages in thread
From: Timothy Shimmin @ 2008-04-07 1:05 UTC (permalink / raw)
To: Thor Kristoffersen; +Cc: xfs
Thor Kristoffersen wrote:
> (It looks like my reply never made it to the list so I'm trying again.)
>
> Eric Sandeen <sandeen@sandeen.net> writes:
>> David Chinner wrote:
>>> On Mon, Mar 31, 2008 at 08:26:00PM +0200, Thor Kristoffersen wrote:
>>>> I've noticed that when I spin down XFS-mounted disks they spin up again
>>>> shortly afterwards. I used iostat to monitor disk accesses to a mounted
>>>> partition (with noatime) in single user mode. Apparently there is a write
>>>> access to the partition approximately every 35 seconds, even if the
>>>> partition is idle. As far as I can understand, since there is no data that
>>>> needs to be flushed this must be done by an XFS daemon for some purpose.
>> 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?
--Tim
> Thor
>
> ------------------------------------------------------
>
> Tue Apr 1 18:51:27 CEST 2008
> xfssyncd(3426): WRITE block 682946473 on sda3
> Tue Apr 1 18:51:32 CEST 2008
> Tue Apr 1 18:51:37 CEST 2008
> Tue Apr 1 18:51:42 CEST 2008
> Tue Apr 1 18:51:47 CEST 2008
> Tue Apr 1 18:51:52 CEST 2008
> Tue Apr 1 18:51:57 CEST 2008
> Tue Apr 1 18:52:02 CEST 2008
> xfssyncd(3426): WRITE block 682946475 on sda3
> Tue Apr 1 18:52:07 CEST 2008
> Tue Apr 1 18:52:12 CEST 2008
> Tue Apr 1 18:52:17 CEST 2008
> Tue Apr 1 18:52:22 CEST 2008
> Tue Apr 1 18:52:27 CEST 2008
> Tue Apr 1 18:52:32 CEST 2008
> Tue Apr 1 18:52:37 CEST 2008
> Tue Apr 1 18:52:42 CEST 2008
> xfssyncd(3426): WRITE block 682946477 on sda3
> Tue Apr 1 18:52:47 CEST 2008
> Tue Apr 1 18:52:52 CEST 2008
> Tue Apr 1 18:52:57 CEST 2008
> Tue Apr 1 18:53:02 CEST 2008
> Tue Apr 1 18:53:07 CEST 2008
> Tue Apr 1 18:53:12 CEST 2008
> Tue Apr 1 18:53:17 CEST 2008
> xfssyncd(3426): WRITE block 682946479 on sda3
> Tue Apr 1 18:53:22 CEST 2008
> Tue Apr 1 18:53:27 CEST 2008
> Tue Apr 1 18:53:32 CEST 2008
> Tue Apr 1 18:53:37 CEST 2008
> Tue Apr 1 18:53:42 CEST 2008
> Tue Apr 1 18:53:47 CEST 2008
> Tue Apr 1 18:53:52 CEST 2008
> xfssyncd(3426): WRITE block 682946481 on sda3
> Tue Apr 1 18:53:57 CEST 2008
> Tue Apr 1 18:54:02 CEST 2008
> Tue Apr 1 18:54:07 CEST 2008
> Tue Apr 1 18:54:12 CEST 2008
> Tue Apr 1 18:54:17 CEST 2008
> Tue Apr 1 18:54:22 CEST 2008
> Tue Apr 1 18:54:27 CEST 2008
> xfssyncd(3426): WRITE block 682946483 on sda3
> Tue Apr 1 18:54:32 CEST 2008
> Tue Apr 1 18:54:37 CEST 2008
> Tue Apr 1 18:54:42 CEST 2008
> Tue Apr 1 18:54:47 CEST 2008
> Tue Apr 1 18:54:52 CEST 2008
> Tue Apr 1 18:54:57 CEST 2008
> Tue Apr 1 18:55:02 CEST 2008
> xfssyncd(3426): WRITE block 682946485 on sda3
> Tue Apr 1 18:55:07 CEST 2008
> Tue Apr 1 18:55:12 CEST 2008
> Tue Apr 1 18:55:17 CEST 2008
> Tue Apr 1 18:55:22 CEST 2008
> Tue Apr 1 18:55:27 CEST 2008
> Tue Apr 1 18:55:32 CEST 2008
> Tue Apr 1 18:55:37 CEST 2008
> xfssyncd(3426): WRITE block 682946487 on sda3
> Tue Apr 1 18:55:42 CEST 2008
> Tue Apr 1 18:55:47 CEST 2008
> Tue Apr 1 18:55:52 CEST 2008
> Tue Apr 1 18:55:57 CEST 2008
> Tue Apr 1 18:56:02 CEST 2008
> Tue Apr 1 18:56:07 CEST 2008
> Tue Apr 1 18:56:12 CEST 2008
> Tue Apr 1 18:56:17 CEST 2008
> xfssyncd(3426): WRITE block 682946489 on sda3
> Tue Apr 1 18:56:22 CEST 2008
> Tue Apr 1 18:56:27 CEST 2008
> Tue Apr 1 18:56:32 CEST 2008
> Tue Apr 1 18:56:37 CEST 2008
> Tue Apr 1 18:56:42 CEST 2008
> Tue Apr 1 18:56:47 CEST 2008
> Tue Apr 1 18:56:52 CEST 2008
> xfssyncd(3426): WRITE block 682946491 on sda3
> Tue Apr 1 18:56:57 CEST 2008
> Tue Apr 1 18:57:02 CEST 2008
> Tue Apr 1 18:57:07 CEST 2008
> Tue Apr 1 18:57:12 CEST 2008
> Tue Apr 1 18:57:17 CEST 2008
> Tue Apr 1 18:57:22 CEST 2008
> Tue Apr 1 18:57:27 CEST 2008
> xfssyncd(3426): WRITE block 682946493 on sda3
> Tue Apr 1 18:57:32 CEST 2008
> Tue Apr 1 18:57:37 CEST 2008
> Tue Apr 1 18:57:42 CEST 2008
> Tue Apr 1 18:57:47 CEST 2008
> Tue Apr 1 18:57:52 CEST 2008
> Tue Apr 1 18:57:57 CEST 2008
> Tue Apr 1 18:58:02 CEST 2008
> xfssyncd(3426): WRITE block 682946495 on sda3
> Tue Apr 1 18:58:07 CEST 2008
> Tue Apr 1 18:58:12 CEST 2008
> Tue Apr 1 18:58:17 CEST 2008
> Tue Apr 1 18:58:22 CEST 2008
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Does XFS prevent disk spindown?
2008-04-07 1:05 ` Timothy Shimmin
@ 2008-04-07 20:33 ` Thor Kristoffersen
2008-04-07 21:58 ` David Chinner
0 siblings, 1 reply; 12+ messages in thread
From: Thor Kristoffersen @ 2008-04-07 20:33 UTC (permalink / raw)
To: Timothy Shimmin; +Cc: xfs
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:
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Does XFS prevent disk spindown?
2008-04-07 20:33 ` Thor Kristoffersen
@ 2008-04-07 21:58 ` David Chinner
2008-04-08 5:53 ` Thor Kristoffersen
0 siblings, 1 reply; 12+ messages in thread
From: David Chinner @ 2008-04-07 21:58 UTC (permalink / raw)
To: Thor Kristoffersen; +Cc: Timothy Shimmin, xfs
On Mon, Apr 07, 2008 at 10:33:19PM +0200, Thor Kristoffersen wrote:
> 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?
Are you using lazy-count=1? (i.e. output of 'xfs_info <mtpt>', please).
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Does XFS prevent disk spindown?
2008-04-07 21:58 ` David Chinner
@ 2008-04-08 5:53 ` Thor Kristoffersen
2008-04-09 4:11 ` [patch] " David Chinner
0 siblings, 1 reply; 12+ messages in thread
From: Thor Kristoffersen @ 2008-04-08 5:53 UTC (permalink / raw)
To: David Chinner; +Cc: Timothy Shimmin, 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [patch] Re: Does XFS prevent disk spindown?
2008-04-08 5:53 ` Thor Kristoffersen
@ 2008-04-09 4:11 ` David Chinner
2008-04-09 21:32 ` Thor Kristoffersen
0 siblings, 1 reply; 12+ messages in thread
From: David Chinner @ 2008-04-09 4:11 UTC (permalink / raw)
To: Thor Kristoffersen; +Cc: David Chinner, Timothy Shimmin, xfs
On Tue, Apr 08, 2008 at 07:53:13AM +0200, Thor Kristoffersen wrote:
> 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.
Introduced in 2.6.22, and recently was made the default mkfs config.
Try the patch below.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
Remove periodic logging of in-core superblock counters.
xfssyncd triggers the logging of superblock counters every
30s if the filesystem is made with lazy-count=1. This will
prevent disks from idling and spinning down as there will
be a log write every 30s. With the way counter recovery
works for lazy-count=1, this code is unnecessary and provides
no real benefit, so just remove it.
Signed-off-by: Dave Chinner <dgc@sgi.com>
---
fs/xfs/linux-2.6/xfs_super.c | 3 +--
fs/xfs/linux-2.6/xfs_vfs.h | 1 -
fs/xfs/xfs_vfsops.c | 10 ----------
3 files changed, 1 insertion(+), 13 deletions(-)
Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_super.c
===================================================================
--- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_super.c 2008-04-02 09:25:11.000000000 +1000
+++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_super.c 2008-04-02 10:02:25.391897032 +1000
@@ -1028,8 +1028,7 @@ xfs_sync_worker(
int error;
if (!(mp->m_flags & XFS_MOUNT_RDONLY))
- error = xfs_sync(mp, SYNC_FSDATA | SYNC_BDFLUSH | SYNC_ATTR |
- SYNC_REFCACHE | SYNC_SUPER);
+ error = xfs_sync(mp, SYNC_FSDATA | SYNC_BDFLUSH | SYNC_ATTR);
mp->m_sync_seq++;
wake_up(&mp->m_wait_single_sync_task);
}
Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_vfs.h
===================================================================
--- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_vfs.h 2007-08-24 22:25:22.000000000 +1000
+++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_vfs.h 2008-04-02 10:02:52.596414152 +1000
@@ -49,7 +49,6 @@ typedef struct bhv_vfs_sync_work {
#define SYNC_REFCACHE 0x0040 /* prune some of the nfs ref cache */
#define SYNC_REMOUNT 0x0080 /* remount readonly, no dummy LRs */
#define SYNC_IOWAIT 0x0100 /* wait for all I/O to complete */
-#define SYNC_SUPER 0x0200 /* flush superblock to disk */
/*
* When remounting a filesystem read-only or freezing the filesystem,
Index: 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c
===================================================================
--- 2.6.x-xfs-new.orig/fs/xfs/xfs_vfsops.c 2008-04-02 09:00:55.000000000 +1000
+++ 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c 2008-04-02 10:01:35.534280170 +1000
@@ -1334,18 +1334,8 @@ xfs_syncsub(
}
/*
- * If asked, update the disk superblock with incore counter values if we
- * are using non-persistent counters so that they don't get too far out
- * of sync if we crash or get a forced shutdown. We don't want to force
- * this to disk, just get a transaction into the iclogs....
- */
- if (flags & SYNC_SUPER)
- xfs_log_sbcount(mp, 0);
-
- /*
* Now check to see if the log needs a "dummy" transaction.
*/
-
if (!(flags & SYNC_REMOUNT) && xfs_log_need_covered(mp)) {
xfs_trans_t *tp;
xfs_inode_t *ip;
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch] Re: Does XFS prevent disk spindown?
2008-04-09 4:11 ` [patch] " David Chinner
@ 2008-04-09 21:32 ` Thor Kristoffersen
2008-04-09 23:02 ` David Chinner
0 siblings, 1 reply; 12+ messages in thread
From: Thor Kristoffersen @ 2008-04-09 21:32 UTC (permalink / raw)
To: David Chinner; +Cc: Timothy Shimmin, xfs
David Chinner <dgc@sgi.com> writes:
> On Tue, Apr 08, 2008 at 07:53:13AM +0200, Thor Kristoffersen wrote:
>> 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.
>
> Introduced in 2.6.22, and recently was made the default mkfs config.
>
> Try the patch below.
Thanks a lot, David! Your patch worked perfectly. Also thanks to the
others who helped me track down this issue.
BTW, what are the consequences of setting lazy-count to 0? Less safety?
Reduced performance?
Thor
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [patch] Re: Does XFS prevent disk spindown?
2008-04-09 21:32 ` Thor Kristoffersen
@ 2008-04-09 23:02 ` David Chinner
0 siblings, 0 replies; 12+ messages in thread
From: David Chinner @ 2008-04-09 23:02 UTC (permalink / raw)
To: Thor Kristoffersen; +Cc: David Chinner, Timothy Shimmin, xfs
On Wed, Apr 09, 2008 at 11:32:34PM +0200, Thor Kristoffersen wrote:
> David Chinner <dgc@sgi.com> writes:
> >> = 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.
> >
> > Introduced in 2.6.22, and recently was made the default mkfs config.
> >
> > Try the patch below.
>
> Thanks a lot, David! Your patch worked perfectly. Also thanks to the
> others who helped me track down this issue.
Cool. I'll get that patch reviewed and checked in, then.
> BTW, what are the consequences of setting lazy-count to 0? Less safety?
> Reduced performance?
One a single disk? No difference to performance, but significantly
lower latency on metadata operations is seen when using lazy-count=1.
If you have lots of disks, or low-latency caches in front of your disks,
lazy-count=1 will prevent superblock updates from being the metadata
performance limiting factor.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-04-10 0:33 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox