[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100727081538.GB3358@quack.suse.cz>
Date: Tue, 27 Jul 2010 10:15:38 +0200
From: Jan Kara <jack@...e.cz>
To: Eric Sandeen <sandeen@...deen.net>
Cc: Jan Kara <jack@...e.cz>, hch@...radead.org, xfs@....sgi.com,
ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 4/8] Add test of quota accounting using fsx
On Mon 26-07-10 16:46:17, Eric Sandeen wrote:
> On 06/15/2010 04:55 AM, Jan Kara wrote:
> > On Wed 09-06-10 12:49:49, Eric Sandeen wrote:
> >> Jan Kara wrote:
> >>> Run fsx (and also several fsx threads in parallel) and verify that
> >>> quota accounting is correct after they finish.
> >>
> >> Jan, I'm having trouble with this one on XFS for some reason, with our
> >> RHEL6 kernel and quota-3.17...
> > OK, attached is an improvement to the XFSQA tests after which all quota
> > tests pass for XFS just fine.
> > The second patch is just minor general improvement of _require_scratch
> > macro.
> > Could they be added to XFSQA repository? Thanks.
>
> Jan, I've got some ext4 failures reported on these, although I can't hit
> them, so not quite sure what's going on.
>
> In 231:
>
> +< fsgqa -- 760 0 0 3 0 0
> +---
> +> fsgqa -- 764 0 0 3 0 0
> +14c14
> +< fsgqa -- 760 0 0 3 0 0
> +---
> +> fsgqa -- 764 0 0 3 0 0
>
> after the quotacheck & repquota we have 4 more blocks. Maybe this
> is due to my accounting of metadata blocks at write time, and not
> before ... would it be reasonable to put a sync call as the first
> line of check_usage() ?
Just last week a change went into xfstests which introduces a generic
quota checking function and uses sync before getting quota usage. I think
xfstests passed for me with ext4 after this change but I've now restarted
the tests to recheck it.
> Also in 233:
>
> +< #501 -- 15392 0 0 998 0 0
> +< #501 -- 15392 32000 32000 998 1000 1000
> +---
> +> #501 +- 32084 32000 32000 7days 998 1000 1000
> +> #501 -- 32084 0 0 998 0 0
>
> "7days" magically appeared after the quotacheck. Not sure what's going
> on there...
That's because the usage after checking exceeded block soft limit and
thus grace time has been set. So it's the same problem as in the above
test.
Honza
--
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists