[PATCH] [RFC] xfs: increase inode cluster size for v5 filesystems

[PATCH] [RFC] xfs: increase inode cluster size for v5 filesystems

[Dave Chinner]

From: Dave Chinner <dchinner@redhat.com>

v5 filesystems use 512 byte inodes as a minimum, so read inodes in
clusters that are effectively half the size of a v4 filesystem with
256 byte inodes. For v5 fielsystems, scale the inode cluster size
with the size of the inode so that we keep a constant 32 inodes per
cluster ratio for all inode IO.

This only works if mkfs.xfs sets the inode alignment appropriately
for larger inode clusters, so this functionality is made conditional
on mkfs doing the right thing. xfs_repair needs to know about
the inode alignment changes, too.

FWIW, results with lookaside cache size of 37 entries with this
patch are (Note: finobt enabled on v5 filesystems, v4 using defaults
including 256 byte inode size):

Wall time:
	create	bulkstat	find+stat	ls -R	unlink
v4	237s	161s		173s		201s	299s
v5	235s	163s		205s		 31s	356s
patched	234s	160s		182s		 29s	317s

System time:
	create	bulkstat	find+stat	ls -R	unlink
v4	2601s	2490s		1653s		1656s	2960s
v5	2637s	2497s		1681s		  20s	3216s
patched	2613s	2451s		1658s		  20s	3007s

Lookaside cache hit rate:
	create	bulkstat	find+stat	ls -R	unlink
v4	0.73	0.91		0.71		0.70	0.71
v5	0.76	0.88		0.68		0.10	0.75
patched	0.81	0.93		0.70		0.08	0.84

So, wall time same or down across the board, system time same or
down across the board, and cache hit rates all improve except for
the ls -R case which is a pure cold cache directory read workload
on v5 filesystems...

So, this patch removes most of the performance and CPU usage
differential between v4 and v5 filesystems on traversal related
workloads.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
 fs/xfs/xfs_mount.c      | 14 ++++++++++++++
 fs/xfs/xfs_mount.h      |  2 +-
 fs/xfs/xfs_trans_resv.c |  3 +--
 3 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 8ac98c7..788d666d 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -722,8 +722,22 @@ xfs_mountfs(
 	 * Set the inode cluster size.
 	 * This may still be overridden by the file system
 	 * block size if it is larger than the chosen cluster size.
+	 *
+	 * For v5 filesystems, scale the cluster size with the inode size to
+	 * keep a constant ratio of inode per cluster buffer, but only if mkfs
+	 * has set the inode alignment value appropriately for larger cluster
+	 * sizes.
 	 */
 	mp->m_inode_cluster_size = XFS_INODE_BIG_CLUSTER_SIZE;
+	if (xfs_sb_version_hascrc(&mp->m_sb)) {
+		int	new_size = mp->m_inode_cluster_size;
+
+		new_size *= mp->m_sb.sb_inodesize / XFS_DINODE_MIN_SIZE;
+		if (mp->m_sb.sb_inoalignmt >= XFS_B_TO_FSBT(mp, new_size))
+			mp->m_inode_cluster_size = new_size;
+		xfs_info(mp, "Using inode cluster size of %d bytes",
+			 mp->m_inode_cluster_size);
+	}
 
 	/*
 	 * Set inode alignment fields
diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
index 2a997dc..a4f7f94 100644
--- a/fs/xfs/xfs_mount.h
+++ b/fs/xfs/xfs_mount.h
@@ -111,7 +111,7 @@ typedef struct xfs_mount {
 	__uint8_t		m_blkbb_log;	/* blocklog - BBSHIFT */
 	__uint8_t		m_agno_log;	/* log #ag's */
 	__uint8_t		m_agino_log;	/* #bits for agino in inum */
-	__uint16_t		m_inode_cluster_size;/* min inode buf size */
+	uint			m_inode_cluster_size;/* min inode buf size */
 	uint			m_blockmask;	/* sb_blocksize-1 */
 	uint			m_blockwsize;	/* sb_blocksize in words */
 	uint			m_blockwmask;	/* blockwsize-1 */
diff --git a/fs/xfs/xfs_trans_resv.c b/fs/xfs/xfs_trans_resv.c
index ae7a185..1494f62 100644
--- a/fs/xfs/xfs_trans_resv.c
+++ b/fs/xfs/xfs_trans_resv.c
@@ -403,8 +403,7 @@ xfs_calc_ifree_reservation(
 		xfs_calc_inode_res(mp, 1) +
 		xfs_calc_buf_res(2, mp->m_sb.sb_sectsize) +
 		xfs_calc_buf_res(2, XFS_FSB_TO_B(mp, 1)) +
-		MAX((__uint16_t)XFS_FSB_TO_B(mp, 1),
-		    XFS_INODE_CLUSTER_SIZE(mp)) +
+		MAX(XFS_FSB_TO_B(mp, 1), XFS_INODE_CLUSTER_SIZE(mp)) +
 		xfs_calc_buf_res(1, 0) +
 		xfs_calc_buf_res(2 + XFS_IALLOC_BLOCKS(mp) +
 				 mp->m_in_maxlevels, 0) +
-- 
1.8.3.2

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] [RFC] xfs: increase inode cluster size for v5 filesystems

[Christoph Hellwig]

I can't see anything v5 format specific here, as 512 byte inodes can be
created with v4 filesystems as well.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] [RFC] xfs: increase inode cluster size for v5 filesystems

[Eric Sandeen]

On 9/9/13 8:32 AM, Christoph Hellwig wrote:
> I can't see anything v5 format specific here, as 512 byte inodes can be
> created with v4 filesystems as well.

Good point - why is this uniquely needed for V5 filesystems?
If it wasn't a problem w/ larger inodes before, why is it now?

This makes the dreaded test matrix go a bit more wonky...

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] [RFC] xfs: increase inode cluster size for v5 filesystems

[Dave Chinner]

On Mon, Sep 09, 2013 at 06:32:54AM -0700, Christoph Hellwig wrote:
> I can't see anything v5 format specific here, as 512 byte inodes can be
> created with v4 filesystems as well.

It's an RFC, and so i've just done the minimum I need to do to
verify it is working corectly. Indeed, I'm not sure it is all there
yet, as I haven't tested increased inode alignments on older
kernels. So I'm not sure whether it will need a feature bit or
not yet.

The test matrix of having to test everything on v4 and v5 is just
nasty, especially if we are talking about prototyping code. I'd much
prefer to bring things to v5 filesytsems where we have much lower
exposure and risk of corruption problems, and then when we know it's
solid because of the QA we've done on it, then we can expose the
majority of the XFS userbase to it by bringing it back to v4
filesystems.

As i've said before - if someone wants to bring new features to v4
filesystems sooner than I do, then they need to step up and do the
work themselves, because I don't have the time and resources to
fully verify new features on v4 filesystem formats...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] [RFC] xfs: increase inode cluster size for v5 filesystems

[Christoph Hellwig]

On Tue, Sep 10, 2013 at 01:35:47AM +1000, Dave Chinner wrote:
> The test matrix of having to test everything on v4 and v5 is just
> nasty, especially if we are talking about prototyping code. I'd much
> prefer to bring things to v5 filesytsems where we have much lower
> exposure and risk of corruption problems, and then when we know it's
> solid because of the QA we've done on it, then we can expose the
> majority of the XFS userbase to it by bringing it back to v4
> filesystems.

I think the test matrix is a reason for not enabling this only on v5
filesystems.  Large inodes are an old and supported use case, although
probably not as heavily tested as it should.  By introducing two
different large inode cases we don't really help increasing test
coverage for a code path that is the same for v4 and v5.

That being said as long as you're still prototyping I'm not going to
interfere.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] [RFC] xfs: increase inode cluster size for v5 filesystems

[Dave Chinner]

On Wed, Sep 11, 2013 at 09:21:59AM -0700, Christoph Hellwig wrote:
> On Tue, Sep 10, 2013 at 01:35:47AM +1000, Dave Chinner wrote:
> > The test matrix of having to test everything on v4 and v5 is just
> > nasty, especially if we are talking about prototyping code. I'd much
> > prefer to bring things to v5 filesytsems where we have much lower
> > exposure and risk of corruption problems, and then when we know it's
> > solid because of the QA we've done on it, then we can expose the
> > majority of the XFS userbase to it by bringing it back to v4
> > filesystems.
> 
> I think the test matrix is a reason for not enabling this only on v5
> filesystems. 

You're assuming that someone is doing lots of QA on v4 filesystems.
Most of my attention is focussed on v5 filesystems and compared to
the amount of v5 QA I'm doing, there is very little v4 QA. All my
development and prototyping is being done on v5 filesystems, and the
code I post indicates that.

I'm not about to propose new features for v4 filesystems if I
haven't tested them robustly. And, in many cases, the new features
I'm proposing require a new filesystem to be made (like this one
does because of the inode alignment requirement) and userspace tool
support, and so it's going to be months (maybe a year) before
userspace support is in the hands of distro-based users.

People testing v5 filesystems right now are handrolling their
userspace code, and so they are following the bleeding edge of both
user and kernel space development. They are not using the bleeding
edge to test new v4 filesystem features. 

Given this, it makes sense to roll the v5 code first, then a
kernel release or 2 later roll in the v4 support once the v5 code
has been exposed and we've flushed out the problems. It minimises
our exposure to filesystem corruption issues, it gets the code into
the hands of early adopters and testers quickly, and it gets rolled
back into v4 filesystems in the same timeframe as distros will be
picking up the feature in v5 filesystems for the first time.

Nobody has yet given a technical reason why such a careful, staged
approach to new feature rollout for v4 filesystems is untenable. All
I'm hearing is people shouting at me for not bringing new features
to v4 filesystems.  Indeed, my reasons and plans to bring the
features to v4 in the near future are being completely ignored to
the point of recklessness...

> Large inodes are an old and supported use case, although
> probably not as heavily tested as it should.  By introducing two
> different large inode cases we don't really help increasing test
> coverage for a code path that is the same for v4 and v5.

I think you've got it wrong - 512 byte inodes have not been
regularly or heavily tested until we introduced v5 filesystems. Now
they are getting tested all the time on v5 filesystems, but AFAICT
there's only one person other than me regularly testing v5
filesystems and reporting bugs (Michael Semon).  Hence, AFAICT there
is very little ongoing test coverage of large inodes on v4
filesystems, and so the expansion of the test matrix to cover large
inodes on v4 filesystem is a very relevant concern.

We will be enabling both d_type and large inode clusters on v5
filesystems at all times - they won't be optional features. Hence
test matrix is simple - enable v5, all new features are enabled and
are tested.

However, for v4 filesystems, we've now got default v4, v4 X dtype,
v4 X dtype X 512 byte inodes, v4 X dtype X 512 byte inodes X inode
alignment (i.e. forwards and backwards compatibility of large inode
cluster configs on old 8k cluster kernels) and finally v4 X dtype X
512 byte inodes X inode alignment X large clusters.

IOWs, every change we make for v4 filesystems adds another
*optional* dimension to the v4 filesystem test matrix. Such an
explosion of feature configurations is not sustainable or
maintainable - ext4 has proven that beyond a doubt.  We have to
consider the cross multiplication of the optional v4 feature matrix,
and consider that everything needs to work correctly for all the
different combinations that can be made.

So, code paths might be shared between v4 and v5 filesystems, but we
don't have an optional feature matrix on v5 (yet), nor do we have
concerns about backwards and forwards compatibility, and so adding
new features to v5 filesystems has a far, far lower testing and QA
burden than adding a new feature to a v4 filesystem.

As I've repeatedly said, if someone wants to do all the v4
validation work I've mentioned above faster than I can do it, then
they can provide the patches for the v4 support in kernel and
userspace and all the tests needed to validate it on v4 filesystems.

[ And even then, the v4 dtype fiasco shows that some people have a
major misunderstanding of what is necessary to enable a feature on a
v4 filesystem. I'm still waiting for all the missing bits I
mentioned in my review of the patch to add the feature bit that were
ignored. e.g. the XFS_IOC_FSGEOM support for the feature bit, the
changes to xfs_info to emit that it's enabled, mkfs to emit that
it's enabled, xfs_db support for the field on v4 filesystems, etc.

IOWs, there is still a significant amount missing from the v4 dtype
support and so, again, I have little confidence that such things
will get done properly until I get around to doing them. I'll be be
pleasently surprised if the patches appear before I write them (the
kernel XFS_IOC_FSGEOM support needs to be in before 3.12 releases),
but I fear that I'm going to be forced to write them soon.... ]

> That being said as long as you're still prototyping I'm not going to
> interfere.

Until I see other people pro-actively fixing regressions, I don't
see that there is any scope for changing my approach. Right now the
only person I can really rely on to proactively fix problems is
myself, and I have limited time and resources...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] [RFC] xfs: increase inode cluster size for v5 filesystems

[Mark Tinguely]

On 09/16/13 20:04, Dave Chinner wrote:
> On Wed, Sep 11, 2013 at 09:21:59AM -0700, Christoph Hellwig wrote:
>> On Tue, Sep 10, 2013 at 01:35:47AM +1000, Dave Chinner wrote:
>>> The test matrix of having to test everything on v4 and v5 is just
>>> nasty, especially if we are talking about prototyping code. I'd much
>>> prefer to bring things to v5 filesytsems where we have much lower
>>> exposure and risk of corruption problems, and then when we know it's
>>> solid because of the QA we've done on it, then we can expose the
>>> majority of the XFS userbase to it by bringing it back to v4
>>> filesystems.
>>
>> I think the test matrix is a reason for not enabling this only on v5
>> filesystems.
>
> You're assuming that someone is doing lots of QA on v4 filesystems.
> Most of my attention is focussed on v5 filesystems and compared to
> the amount of v5 QA I'm doing, there is very little v4 QA. All my
> development and prototyping is being done on v5 filesystems, and the
> code I post indicates that.
>
> I'm not about to propose new features for v4 filesystems if I
> haven't tested them robustly. And, in many cases, the new features
> I'm proposing require a new filesystem to be made (like this one
> does because of the inode alignment requirement) and userspace tool
> support, and so it's going to be months (maybe a year) before
> userspace support is in the hands of distro-based users.
>
> People testing v5 filesystems right now are handrolling their
> userspace code, and so they are following the bleeding edge of both
> user and kernel space development. They are not using the bleeding
> edge to test new v4 filesystem features.
>
> Given this, it makes sense to roll the v5 code first, then a
> kernel release or 2 later roll in the v4 support once the v5 code
> has been exposed and we've flushed out the problems. It minimises
> our exposure to filesystem corruption issues, it gets the code into
> the hands of early adopters and testers quickly, and it gets rolled
> back into v4 filesystems in the same timeframe as distros will be
> picking up the feature in v5 filesystems for the first time.
>
> Nobody has yet given a technical reason why such a careful, staged
> approach to new feature rollout for v4 filesystems is untenable. All
> I'm hearing is people shouting at me for not bringing new features
> to v4 filesystems.  Indeed, my reasons and plans to bring the
> features to v4 in the near future are being completely ignored to
> the point of recklessness...
>
>> Large inodes are an old and supported use case, although
>> probably not as heavily tested as it should.  By introducing two
>> different large inode cases we don't really help increasing test
>> coverage for a code path that is the same for v4 and v5.
>
> I think you've got it wrong - 512 byte inodes have not been
> regularly or heavily tested until we introduced v5 filesystems. Now
> they are getting tested all the time on v5 filesystems, but AFAICT
> there's only one person other than me regularly testing v5
> filesystems and reporting bugs (Michael Semon).  Hence, AFAICT there
> is very little ongoing test coverage of large inodes on v4
> filesystems, and so the expansion of the test matrix to cover large
> inodes on v4 filesystem is a very relevant concern.
>
> We will be enabling both d_type and large inode clusters on v5
> filesystems at all times - they won't be optional features. Hence
> test matrix is simple - enable v5, all new features are enabled and
> are tested.
>
> However, for v4 filesystems, we've now got default v4, v4 X dtype,
> v4 X dtype X 512 byte inodes, v4 X dtype X 512 byte inodes X inode
> alignment (i.e. forwards and backwards compatibility of large inode
> cluster configs on old 8k cluster kernels) and finally v4 X dtype X
> 512 byte inodes X inode alignment X large clusters.
>
> IOWs, every change we make for v4 filesystems adds another
> *optional* dimension to the v4 filesystem test matrix. Such an
> explosion of feature configurations is not sustainable or
> maintainable - ext4 has proven that beyond a doubt.  We have to
> consider the cross multiplication of the optional v4 feature matrix,
> and consider that everything needs to work correctly for all the
> different combinations that can be made.
>
> So, code paths might be shared between v4 and v5 filesystems, but we
> don't have an optional feature matrix on v5 (yet), nor do we have
> concerns about backwards and forwards compatibility, and so adding
> new features to v5 filesystems has a far, far lower testing and QA
> burden than adding a new feature to a v4 filesystem.
>
> As I've repeatedly said, if someone wants to do all the v4
> validation work I've mentioned above faster than I can do it, then
> they can provide the patches for the v4 support in kernel and
> userspace and all the tests needed to validate it on v4 filesystems.
>
> [ And even then, the v4 dtype fiasco shows that some people have a
> major misunderstanding of what is necessary to enable a feature on a
> v4 filesystem. I'm still waiting for all the missing bits I
> mentioned in my review of the patch to add the feature bit that were
> ignored. e.g. the XFS_IOC_FSGEOM support for the feature bit, the
> changes to xfs_info to emit that it's enabled, mkfs to emit that
> it's enabled, xfs_db support for the field on v4 filesystems, etc.
>
> IOWs, there is still a significant amount missing from the v4 dtype
> support and so, again, I have little confidence that such things
> will get done properly until I get around to doing them. I'll be be
> pleasently surprised if the patches appear before I write them (the
> kernel XFS_IOC_FSGEOM support needs to be in before 3.12 releases),
> but I fear that I'm going to be forced to write them soon.... ]
>
>> That being said as long as you're still prototyping I'm not going to
>> interfere.
>
> Until I see other people pro-actively fixing regressions, I don't
> see that there is any scope for changing my approach. Right now the
> only person I can really rely on to proactively fix problems is
> myself, and I have limited time and resources...
>
> Cheers,
>
> Dave.

We are *not* screaming for this on v4. Not screaming for this to be 
mandatory on v5.

It will make inode allocation more difficult as the drive fragments.

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] [RFC] xfs: increase inode cluster size for v5 filesystems

[Eric Sandeen]

On 9/16/13 8:04 PM, Dave Chinner wrote:
> On Wed, Sep 11, 2013 at 09:21:59AM -0700, Christoph Hellwig wrote:
>> On Tue, Sep 10, 2013 at 01:35:47AM +1000, Dave Chinner wrote:
>>> The test matrix of having to test everything on v4 and v5 is just
>>> nasty, especially if we are talking about prototyping code. I'd much
>>> prefer to bring things to v5 filesytsems where we have much lower
>>> exposure and risk of corruption problems, and then when we know it's
>>> solid because of the QA we've done on it, then we can expose the
>>> majority of the XFS userbase to it by bringing it back to v4
>>> filesystems.
>>
>> I think the test matrix is a reason for not enabling this only on v5
>> filesystems. 
> 
> You're assuming that someone is doing lots of QA on v4 filesystems.
> Most of my attention is focussed on v5 filesystems and compared to
> the amount of v5 QA I'm doing, there is very little v4 QA. All my
> development and prototyping is being done on v5 filesystems, and the
> code I post indicates that.

Red Hat QE is doing quite a lot of testing of V4 at this point, although
not on totally bleeding-edge kernels.

> I'm not about to propose new features for v4 filesystems if I
> haven't tested them robustly. And, in many cases, the new features
> I'm proposing require a new filesystem to be made (like this one
> does because of the inode alignment requirement) and userspace tool
> support, and so it's going to be months (maybe a year) before
> userspace support is in the hands of distro-based users.
> 
> People testing v5 filesystems right now are handrolling their
> userspace code, and so they are following the bleeding edge of both
> user and kernel space development. They are not using the bleeding
> edge to test new v4 filesystem features. 
> 
> Given this, it makes sense to roll the v5 code first, then a
> kernel release or 2 later roll in the v4 support once the v5 code
> has been exposed and we've flushed out the problems. It minimises
> our exposure to filesystem corruption issues, it gets the code into
> the hands of early adopters and testers quickly, and it gets rolled
> back into v4 filesystems in the same timeframe as distros will be
> picking up the feature in v5 filesystems for the first time.
> 
> Nobody has yet given a technical reason why such a careful, staged
> approach to new feature rollout for v4 filesystems is untenable. All
> I'm hearing is people shouting at me for not bringing new features
> to v4 filesystems.  Indeed, my reasons and plans to bring the
> features to v4 in the near future are being completely ignored to
> the point of recklessness...

That sounds perfectly reasonable to me; from your original RFC
it wasn't clear to me that that was the plan (stage it & roll it out
for V4 later).

>> Large inodes are an old and supported use case, although
>> probably not as heavily tested as it should.  By introducing two
>> different large inode cases we don't really help increasing test
>> coverage for a code path that is the same for v4 and v5.
> 
> I think you've got it wrong - 512 byte inodes have not been
> regularly or heavily tested until we introduced v5 filesystems.

Gluster users have been advised to use 512-byte inodes for quite
some time, actually.
(http://www.gluster.org/community/documentation/index.php/QuickStart)

So there is some real-world coverage, and presumably QE as well.

I understand your valid concerns (snipped below as well) but let's not
overstate the case either; V4 and 512-byte are both seeing some coverage
even today.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] [RFC] xfs: increase inode cluster size for v5 filesystems

[Dave Chinner]

On Tue, Sep 17, 2013 at 09:46:15AM -0500, Eric Sandeen wrote:
> On 9/16/13 8:04 PM, Dave Chinner wrote:
> > On Wed, Sep 11, 2013 at 09:21:59AM -0700, Christoph Hellwig wrote:
> >> On Tue, Sep 10, 2013 at 01:35:47AM +1000, Dave Chinner wrote:
> >>> The test matrix of having to test everything on v4 and v5 is just
> >>> nasty, especially if we are talking about prototyping code. I'd much
> >>> prefer to bring things to v5 filesytsems where we have much lower
> >>> exposure and risk of corruption problems, and then when we know it's
> >>> solid because of the QA we've done on it, then we can expose the
> >>> majority of the XFS userbase to it by bringing it back to v4
> >>> filesystems.
> >>
> >> I think the test matrix is a reason for not enabling this only on v5
> >> filesystems. 
> > 
> > You're assuming that someone is doing lots of QA on v4 filesystems.
> > Most of my attention is focussed on v5 filesystems and compared to
> > the amount of v5 QA I'm doing, there is very little v4 QA. All my
> > development and prototyping is being done on v5 filesystems, and the
> > code I post indicates that.
> 
> Red Hat QE is doing quite a lot of testing of V4 at this point, although
> not on totally bleeding-edge kernels.

Right, there is QE being done, but not by developers writing new
features....

> > I'm hearing is people shouting at me for not bringing new features
> > to v4 filesystems.  Indeed, my reasons and plans to bring the
> > features to v4 in the near future are being completely ignored to
> > the point of recklessness...
> 
> That sounds perfectly reasonable to me; from your original RFC
> it wasn't clear to me that that was the plan (stage it & roll it out
> for V4 later).

You should assume this to be true for anything I do on v5
filesystems. If something can't be brought back to v4 filesystems,
then I'll make sure that everyone knows that.

However, even if something is possible, that doesn't mean it is a
good idea. There'll be plenty of new features coming through in the
not-to-distant future, and I'm seriously questioning the wisdom of
expecting everything to be made optional on v4 filesystems due to
the test matrix explosion. If it can be done in such a way that
doesn't explode the test matrix, then it's les sof an issue

Hence it may be worthwhile waiting on v4 and batching mutliple
features under a single feature bit (e.g. free inode btree, partial
inode chunk allocation and larger inode clusters all enabled by a
single v4 feature bit) once all the features are landed in v5 and
are stable. But a 1:1 mapping of features to mkfs options is simply
going to lead to problems due to insufficient QA coverage....

> >> Large inodes are an old and supported use case, although
> >> probably not as heavily tested as it should.  By introducing two
> >> different large inode cases we don't really help increasing test
> >> coverage for a code path that is the same for v4 and v5.
> > 
> > I think you've got it wrong - 512 byte inodes have not been
> > regularly or heavily tested until we introduced v5 filesystems.
> 
> Gluster users have been advised to use 512-byte inodes for quite
> some time, actually.
> (http://www.gluster.org/community/documentation/index.php/QuickStart)
> 
> So there is some real-world coverage, and presumably QE as well.

Right, but that is not testing code being developed and merged into
upstream dev trees and -rc kernels. i.e. it is upstream, bleeding
edge test coverage that I'm worried about, not on the kernels that
downstream products ship with...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] [RFC] xfs: increase inode cluster size for v5 filesystems

[Dave Chinner]

On Tue, Sep 17, 2013 at 08:51:09AM -0500, Mark Tinguely wrote:
> On 09/16/13 20:04, Dave Chinner wrote:
> >On Wed, Sep 11, 2013 at 09:21:59AM -0700, Christoph Hellwig wrote:
> >>On Tue, Sep 10, 2013 at 01:35:47AM +1000, Dave Chinner wrote:
> >>>The test matrix of having to test everything on v4 and v5 is just
> >>>nasty, especially if we are talking about prototyping code. I'd much
> >>>prefer to bring things to v5 filesytsems where we have much lower
> >>>exposure and risk of corruption problems, and then when we know it's
> >>>solid because of the QA we've done on it, then we can expose the
> >>>majority of the XFS userbase to it by bringing it back to v4
> >>>filesystems.
> >>
> >>I think the test matrix is a reason for not enabling this only on v5
> >>filesystems.
....
> We are *not* screaming for this on v4. Not screaming for this to be
> mandatory on v5.
> 
> It will make inode allocation more difficult as the drive fragments.

Yes. But we have a plan to solve that:

http://oss.sgi.com/archives/xfs/2013-08/msg00346.html

And this work follows directly after Brian's free inode btree
patches. i.e. you need to consider this patch in the context of the
architectural modifications to inode allocation that have been
posted for discussion, not as an isolated, random change.

As I've mentioned in the past, I publish design documentation so
that everyone knows what goals we're working towards and the steps
being taking to get there. This is just a small piece in that
puzzle.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs