Does XFS prevent disk spindown?

DISCUSSION Thor Kristoffersen 4 participants 12 messages Mar 31, 2008 – Apr 10, 2008

Share & tools

Thor Kristoffersen

author

2008-03-31 18:27 UTC #0 lore raw

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

David Chinner

2008-04-01 00:29 UTC #1 lore raw

Quoted 10 lines · Thor Kristoffersen

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.

Signature · 3 lines

Dave Chinner
Principal Engineer
SGI Australian Software Group

Eric Sandeen

2008-04-01 06:00 UTC #2 lore raw

Quoted 7 lines · David Chinner

Quoted 6 lines · Thor Kristoffersen
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

Quoted 5 lines

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

Quoted 9 lines

Quoted 3 lines
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.

Thor Kristoffersen

author

2008-04-01 18:20 UTC #3 lore raw

Quoted 11 lines · Eric Sandeen

Quoted 7 lines · David Chinner
Quoted 6 lines · Thor Kristoffersen
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

Thor Kristoffersen

author

2008-04-05 14:02 UTC #4 lore raw

(It looks like my reply never made it to the list so I'm trying again.)

Quoted 11 lines · Eric Sandeen

Quoted 7 lines · David Chinner
Quoted 6 lines · Thor Kristoffersen
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).

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

Timothy Shimmin

2008-04-07 01:05 UTC #5 lore raw

Quoted 17 lines · Thor Kristoffersen

(It looks like my reply never made it to the list so I'm trying again.)
Quoted 10 lines · Eric Sandeen
Quoted 7 lines · David Chinner
Quoted 6 lines · Thor Kristoffersen
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).

Quoted 8 lines

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

Quoted 101 lines

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

Thor Kristoffersen

author

2008-04-07 21:34 UTC #6 lore raw

Quoted 15 lines · Timothy Shimmin

Quoted 6 lines · Thor Kristoffersen
Quoted 2 lines
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).
Quoted 8 lines
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.)

Quoted 3 lines

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:

David Chinner

2008-04-07 21:58 UTC #7 lore raw

Quoted 16 lines · Thor Kristoffersen

Quoted 15 lines · Timothy Shimmin
Quoted 14 lines · Thor Kristoffersen
Quoted 2 lines
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.)

Quoted 8 lines

Quoted 3 lines
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.

Signature · 3 lines

Dave Chinner
Principal Engineer
SGI Australian Software Group

Thor Kristoffersen

author

2008-04-08 05:53 UTC #8 lore raw

Quoted 9 lines · David Chinner

Quoted 7 lines
Quoted 2 lines
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

David Chinner

2008-04-09 04:10 UTC #9 lore raw

Quoted 22 lines · Thor Kristoffersen

Quoted 9 lines · David Chinner
Quoted 7 lines
Quoted 2 lines
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

Quoted 2 lines

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.

Signature · 69 lines

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 <[email protected]>
---
 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;

David Chinner

2008-04-09 23:01 UTC #11 lore raw

In reply to Thor Kristoffersen

Quoted 7 lines · Thor Kristoffersen

Quoted 6 lines · David Chinner
Quoted 5 lines
         =                       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.

Quoted 6 lines

Quoted 3 lines
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.

Quoted 2 lines

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.

Signature · 3 lines

Dave Chinner
Principal Engineer
SGI Australian Software Group

Thor Kristoffersen

author

2008-04-10 00:33 UTC #10 lore raw

In reply to David Chinner

Quoted 23 lines · David Chinner

Quoted 22 lines · Thor Kristoffersen
Quoted 9 lines · David Chinner
Quoted 7 lines
Quoted 2 lines
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

Quoted 6 lines

Quoted 2 lines
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