[Top] [All Lists]

Re: [PATCH] xfs: kill xfs_qmops

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: kill xfs_qmops
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 27 May 2009 15:06:25 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20090527095616.GA19069@xxxxxxxxxxxxx>
References: <20090224143736.GA16616@xxxxxxxxxxxxx> <4A1C2839.3010005@xxxxxxxxxxx> <20090527095616.GA19069@xxxxxxxxxxxxx>
User-agent: Thunderbird (X11/20090320)
Christoph Hellwig wrote:

> never, but that's a bug because the loop should now start at 0.  Looks
> like out quota testing in xfsqa still isn't that good or the first
> inode is always already attached in normal operation (probably the latter).
> Updated patch below:
> Subject: xfs: kill xfs_qmops
> From: Christoph Hellwig <hch@xxxxxx>
> Kill the quota ops function vector and replace it with direct calls or
> stubs in the CONFIG_XFS_QUOTA=n case.
> Make sure we check XFS_IS_QUOTA_RUNNING in the right spots.  We can remove
> the number of those checks because the XFS_TRANS_DQ_DIRTY flag can't be set
> otherwise.
> This brings us back closer to the way this code worked in IRIX and earlier
> Linux versions, but we keep a lot of the more useful factoring of common
> code.
> Eventually we should also kill xfs_qm_bhv.c, but that's left for a later
> patch.
> Reduces the size of the source code by about 250 lines and the size of
> XFS module by about 1.5 kilobytes with quotas enabled:
>    text          data     bss     dec     hex filename
>  615957          2960    3848  622765   980ad fs/xfs/xfs.o
>  617231          3152    3848  624231   98667 fs/xfs/xfs.o.old
> Fallout:
>  - xfs_qm_dqattach is split into xfs_qm_dqattach_locked which expects
>    the inode locked and xfs_qm_dqattach which does the locking around it,
>    thus removing XFS_QMOPT_ILOCKED.
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>

Looks better to me now, thanks.  Though worrisome that quota doesn't
seem well-tested in xfsqa, as you said... but as far as I can tell seems
ok now.  Have arekm test it a bit too ;)

Reviewed-by: Eric Sandeen <sandeen@xxxxxxxxxxx>

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