xfs
[Top] [All Lists]

Re: [PATCH] libxcmd: fix counting of xfs entries in fs_table_insert

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH] libxcmd: fix counting of xfs entries in fs_table_insert
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 26 Sep 2016 07:38:18 +1000
Cc: Eryu Guan <eguan@xxxxxxxxxx>, linux-xfs@xxxxxxxxxxxxxxx, billodo@xxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160925161256.GA25791@xxxxxxxxxxxxx>
References: <1474798162-25960-1-git-send-email-eguan@xxxxxxxxxx> <20160925143155.GB29268@xxxxxxxxxxxxx> <20160925145816.GD27776@xxxxxxxxxxxxxxxxxxxxxxxx> <20160925161256.GA25791@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sun, Sep 25, 2016 at 09:12:56AM -0700, Christoph Hellwig wrote:
> On Sun, Sep 25, 2016 at 10:58:16PM +0800, Eryu Guan wrote:
> > It's already part of xfs/244, I noticed this bug because xfs/244 kept
> > running. I just put the minimum steps in commit log. So I think we're
> > good :)
> 
> But only as part of xfs/244 which doesn't work for v5 file systems.
> To have good coverage we should not rely on testing an old format.
> That beeing said I can't see a good reason for why xfs/244 should not
> be run for v5 file systems, so I'll look into that instead.

It's because it's testing the projid32bit mkfs option works
correctly. i.e. that project IDs > 16 bits fail on a a
filesystem that only supports 16 bit project IDs. v5 filesystems
only support 32 bit project IDs, so setting a > 16bit ID will
succeed, not fail like the test is expecting.

A new test would be simplest.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>