* 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