[Top] [All Lists]

Re: [PATCH 59/60] xfs: Add xfs_log_rlimit.c

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 59/60] xfs: Add xfs_log_rlimit.c
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Mon, 24 Jun 2013 16:26:28 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1371617468-32559-60-git-send-email-david@xxxxxxxxxxxxx>
References: <1371617468-32559-1-git-send-email-david@xxxxxxxxxxxxx> <1371617468-32559-60-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 06/18/13 23:51, Dave Chinner wrote:
+        * 2) If the lsunit option is specified, a transaction requires 2 LSU
+        *    for the reservation because there are two log writes that can
+        *    require padding - the transaction data and the commit record which
+        *    are written separately and both can require padding to the LSU.
+        *    Consider that we can have an active CIL reservation holding 2*LSU,
+        *    but the CIL is not over a push threshold, in this case, if we
+        *    don't have enough log space for at one new transaction, which
+        *    includes another 2*LSU in the reservation, we will run into dead
+        *    loop situation in log space grant procedure. i.e.
+        *    xlog_grant_head_wait().
+        *
+        *    Hence the log size needs to be able to contain two maximally sized
+        *    and padded transactions, which is (2 * (2 * LSU + maxlres)).
+        *

Any thoughts on how we can separate the 2 * log stripe unit from the reservation.

The added extended attribute calls for parent inode pointers (especially xfs_rename() where it could add up to one and remove up to two attributes) is causing a huge multiplication cnt for reservation. Those multiplications would be killers on 256KiB log stripe units.


<Prev in Thread] Current Thread [Next in Thread>