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
|