[PATCH 14/15] xfs: dquot log reservations are too small

[Mark Tinguely]

On 06/27/13 01:04, Dave Chinner wrote:
> From: Dave Chinner<dchinner at redhat.com>
>
> During review of the separate project quota inode patches, it bcame
> obvious that the dquot log reservation calculation underestimated
> the number dquots that can be modified in a transaction. This has
> it's roots way back in the Irix quota implementation.
>
> That is, when quotas were first implemented in XFS, it only
> supported user and project quotas as Irix did not have group quotas.
> Hence the worst case operation involving dquot modification was
> calculated to involve 2 user dquots and 1 project dquot or 1 user
> dequot and 2 project dquots. i.e. 3 dquots. This was determined back
> in 1996, and has remained unchanged ever since.
>
> However, back in 2001, the Linux XFS port dropped all support for
> project quota and implmented group quotas over the top. This was
> effectively done with a search-and-replace of project with group,
> and as such the log reservation was not changed. However, with the
> advent of group quotas, chmod and rename now could modify more than
> 3 dquots in a single transaction - both could modify 4 dquots. Hence
> this log reservation has been wrong for a long time.
>
> In 2005, project quotas were reintroduced into Linux, but they were
> implemented to be mutually exclusive to group quotas, and so this
> didn't add any new changes to the dquot log reservation. hence when
> project quotas were in use, everything was still fine, just like
> in the Irix days.
>
> Now, with the addition of the separate project quota inode, group
> and project quotas are no longer mutually exclusive, and hence
> operations can now modify three dquots per inode where previously it
> was only two. The worst case here is the rename transaction, which
> can allocate/free space on two different directory inodes, and if
> they have different uid/gid/prid configurations and are world
> writeable, then rename can actually modify 6 different dquots now.
>
> Further, the dquot log reservation doesn't take into account the
> space used by the dquot log format structure that preceeds the dquot
> that is logged, and hence further underestimates the worst case
> log space required by dquots during a transaction.
>
> Hence the worst case log reservation needs to be increased from 3 to
> 6, and it needs to take into account a log format header for each of
> those dquots.
>
> Signed-off-by: Dave Chinner<dchinner at redhat.com>
> ---

Looks good.

Reviewed-by: Mark Tinguely <tinguely at sgi.com>