review: change default realtime extsize

review: change default realtime extsize

[Nathan Scott]

Hi,

While testing something else recently, I noticed we were always
creating a large number of unwritten extents during page cache
writout to the realtime subvolume.  It turned out to be because
of the way we are typically called with page sized allocation
requests, but we always allocate much more than a page.  Back
when realtime subvols could only use direct I/O this was fine
(apps typically used larger IO sizes) but now its not so good.

These larger allocations are ending up meaning we need to do many
additional unwritten extent conversions (i.e. more transactions,
and more log traffic), which we can easily avoid.  Since we have
a default 4K filesystem blocksize on the data device, there would
seem to be no harm in matching that on the realtime subvolume, by
default.  This simple mkfs tweak does just that...

cheers.

-- 
Nathan


Index: xfsprogs/include/xfs_rtalloc.h
===================================================================
--- xfsprogs.orig/include/xfs_rtalloc.h	2006-08-18 11:50:35.916857000 +1000
+++ xfsprogs/include/xfs_rtalloc.h	2006-08-18 11:55:44.820162250 +1000
@@ -25,7 +25,7 @@ struct xfs_trans;
 
 /* Min and max rt extent sizes, specified in bytes */
 #define	XFS_MAX_RTEXTSIZE	(1024 * 1024 * 1024)	/* 1GB */
-#define	XFS_DFL_RTEXTSIZE	(64 * 1024)	        /* 64KB */
+#define	XFS_DFL_RTEXTSIZE	(4 * 1024)	        /* 4KB */
 #define	XFS_MIN_RTEXTSIZE	(4 * 1024)		/* 4KB */
 
 /*

Re: review: change default realtime extsize

[Christoph Hellwig]

On Mon, Aug 28, 2006 at 01:31:32PM +1000, Nathan Scott wrote:
> Hi,
> 
> While testing something else recently, I noticed we were always
> creating a large number of unwritten extents during page cache
> writout to the realtime subvolume.  It turned out to be because
> of the way we are typically called with page sized allocation
> requests, but we always allocate much more than a page.  Back
> when realtime subvols could only use direct I/O this was fine
> (apps typically used larger IO sizes) but now its not so good.
> 
> These larger allocations are ending up meaning we need to do many
> additional unwritten extent conversions (i.e. more transactions,
> and more log traffic), which we can easily avoid.  Since we have
> a default 4K filesystem blocksize on the data device, there would
> seem to be no harm in matching that on the realtime subvolume, by
> default.  This simple mkfs tweak does just that...

That description makes sense, and given that the one-liner diff is
obviously correct.  ACK from me.