Hello, We have a hard code number of "128" for almost all sorts of transactions space reservations. This number is used to reserve the space for the struct xfs_buf_log_format that gets written into the log for every buffer as well as a little bit of extra space because there also needs a log opheader, i.e. struct xlog_op_header. This idea is totally inspired by Dave's comments at: http://oss.sgi.com/archives/xfs/2012-12/msg00009.html I'll add Signed-off-by for Dave once the patches are qualified to be accept for his credit. The patches replace the magic number with a new function xfs_buf_log_overhead(), which is introduced to examine the extra buf log space more flexible than hard coding it. Maybe it's better to tweak it up in a macro to make the code style in xfs_trans.c looks a bit neat? #define XFS_BUF_LOG_OVERHEAD (xfs_buf_log_overhead()) To make sure there is no regression with those changes, I have run dozens of xfs test cases, they are works to me. [PATCH 1/4] Add a new function xfs_buf_log_overhead() to replace the hard-code number of 128 [PATCH 2/4] Make xfs_fs_log_dummy() aware of this change [PATCH 3/4] Make super block unit change related transactions aware of this change [PATCH 4/4] Make disk quota related transactions aware of this change --- fs/xfs/xfs_dquot.c | 6 ++- fs/xfs/xfs_fsops.c | 5 +- fs/xfs/xfs_mount.c | 15 +++--- fs/xfs/xfs_qm.c | 6 +-- fs/xfs/xfs_qm_syscalls.c | 20 ++++---- fs/xfs/xfs_trans.c | 113 ++++++++++++++++++++++++++++++---------------- fs/xfs/xfs_trans.h | 4 +- 7 files changed, 106 insertions(+), 63 deletions(-) Thanks, -Jeff _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs