Re: Definition of XFS_DQUOT_LOGRES()

[David Chinner <dgc@sgi.com>]

On Mon, Mar 31, 2008 at 03:45:28PM -0700, Michael Nishimoto wrote:
> The comment for XFS_DQUOT_LOGRES states that we need to reserve space
> for 3 dquots.  I can't figure out why we need to add this amount to *all*
> operations and why this amount wasn't added after doing a runtime
> quotaon check.

It probably could be done that way.  But given that:

> /*
>  * In the worst case, when both user and group quotas are on,
>  * we can have a max of three dquots changing in a single transaction.
>  */
> #define XFS_DQUOT_LOGRES(mp)    (sizeof(xfs_disk_dquot_t) * 3)

sizeof(xfs_disk_dquot_t) = 104 bytes,

the overall addition to the reservations is minor considering:

[0]kdb> xtrres 0xe0000038055ac6c0
write: 109752   truncate: 223672        rename: 305976
link: 153144    remove: 153144  symlink: 158520
create: 158392  mkdir: 158392   ifree: 58936
ichange: 2104   growdata: 45696 swrite: 384
addafork: 70584 writeid: 384    attrinval: 179328
attrset: 22968  attrrm: 90552   clearagi: 1152
growrtalloc: 66048      growrtzero: 4224        growrtfree: 6272
[0]kdb>

on a 14GB filesystem most of the transactions this is added to
are on the far side of 150k and that means we're talking about less
than 0.2% of the entire reservation comes from the dquot. With
larger block sizes and/or larger filesystems, these get much
larger. e.g. same 14GB device, 64k block size instead of 4k:

[0]kdb> xtrres 0xe00000b8027d39f8
write: 987576   truncate: 1977272       rename: 2891064
link: 1445688   remove: 1445688 symlink: 1512504
create: 1511864 mkdir: 1511864  ifree: 470584
ichange: 1592   growdata: 395904        swrite: 384
addafork: 658616        writeid: 384    attrinval: 1581696
attrset: 329656 attrrm: 791480  clearagi: 640
growrtalloc: 592640     growrtzero: 65664       growrtfree: 67200

The rename reservation is *2.8MB* (up from 300k). IOWs, 300 bytes is
really noise when it comes to reservation space. (OT: See why I want to
increase the log size now? :)

Is it worth the complexity of adding this dquot reservation at
runtime for a best case reduction of 0.2% in log space reservation
usage? Probably not, but patches can be convincing ;)

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group