From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Mon, 31 Mar 2008 18:28:44 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m311SWcX007842 for ; Mon, 31 Mar 2008 18:28:35 -0700 Date: Tue, 1 Apr 2008 11:28:56 +1000 From: David Chinner Subject: Re: Definition of XFS_DQUOT_LOGRES() Message-ID: <20080401012856.GL103491721@sgi.com> References: <47F16988.2080406@agami.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47F16988.2080406@agami.com> Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: Michael Nishimoto Cc: XFS Mailing List 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