Does XFS prevent disk spindown?

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

Turn on laptop mode?

Cheers,

Dave.

Dave Chinner
Principal Engineer
SGI Australian Software Group

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

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

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

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

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

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

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:

Are you using lazy-count=1? (i.e. output of 'xfs_info <mtpt>', please).

Cheers,

Dave.

Dave Chinner
Principal Engineer
SGI Australian Software Group

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

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 <[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;

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

Cool. I'll get that patch reviewed and checked in, then.

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