summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorZhao Mengmeng <zhaomengmeng@kylinos.cn>2022-08-22 21:36:53 -0400
committerJonathan Corbet <corbet@lwn.net>2022-08-29 10:23:31 -0600
commitf926cee793b9c3c72beb235e32aec62a405eaae2 (patch)
tree657b0032c9600ec6df31d319827ea3e14fa6a8ed
parentc0d8f1f4601572d035da6a7ccb2cdf1ab2d9b98f (diff)
downloadlwn-f926cee793b9c3c72beb235e32aec62a405eaae2.tar.gz
lwn-f926cee793b9c3c72beb235e32aec62a405eaae2.zip
Documentation: filesystems: xfs: update pseudocode and typo fixes
According to the implementation of xfs_trans_roll(), it calls xfs_trans_reserve(), which reserves not only log space, but also free disk blocks. In short, the "transaction stuff". So change xfs_log_reserve() to xfs_trans_reserve(). Besides, fix several typo issues. Signed-off-by: Zhao Mengmeng <zhaomengmeng@kylinos.cn> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Link: https://lore.kernel.org/r/20220823013653.203469-1-zhaomzhao@126.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-rw-r--r--Documentation/filesystems/xfs-delayed-logging-design.rst12
1 files changed, 6 insertions, 6 deletions
diff --git a/Documentation/filesystems/xfs-delayed-logging-design.rst b/Documentation/filesystems/xfs-delayed-logging-design.rst
index 4ef419f54663..02b32030bab3 100644
--- a/Documentation/filesystems/xfs-delayed-logging-design.rst
+++ b/Documentation/filesystems/xfs-delayed-logging-design.rst
@@ -100,7 +100,7 @@ transactions together::
ntp = xfs_trans_dup(tp);
xfs_trans_commit(tp);
- xfs_log_reserve(ntp);
+ xfs_trans_reserve(ntp);
This results in a series of "rolling transactions" where the inode is locked
across the entire chain of transactions. Hence while this series of rolling
@@ -191,7 +191,7 @@ transaction rolling mechanism to re-reserve space on every transaction roll. We
know from the implementation of the permanent transactions how many transaction
rolls are likely for the common modifications that need to be made.
-For example, and inode allocation is typically two transactions - one to
+For example, an inode allocation is typically two transactions - one to
physically allocate a free inode chunk on disk, and another to allocate an inode
from an inode chunk that has free inodes in it. Hence for an inode allocation
transaction, we might set the reservation log count to a value of 2 to indicate
@@ -200,7 +200,7 @@ chain. Each time a permanent transaction rolls, it consumes an entire unit
reservation.
Hence when the permanent transaction is first allocated, the log space
-reservation is increases from a single unit reservation to multiple unit
+reservation is increased from a single unit reservation to multiple unit
reservations. That multiple is defined by the reservation log count, and this
means we can roll the transaction multiple times before we have to re-reserve
log space when we roll the transaction. This ensures that the common
@@ -259,7 +259,7 @@ the next transaction in the sequeunce, but we have none remaining. We cannot
sleep during the transaction commit process waiting for new log space to become
available, as we may end up on the end of the FIFO queue and the items we have
locked while we sleep could end up pinning the tail of the log before there is
-enough free space in the log to fulfil all of the pending reservations and
+enough free space in the log to fulfill all of the pending reservations and
then wake up transaction commit in progress.
To take a new reservation without sleeping requires us to be able to take a
@@ -615,7 +615,7 @@ those changes into the current checkpoint context. We then initialise a new
context and attach that to the CIL for aggregation of new transactions.
This allows us to unlock the CIL immediately after transfer of all the
-committed items and effectively allow new transactions to be issued while we
+committed items and effectively allows new transactions to be issued while we
are formatting the checkpoint into the log. It also allows concurrent
checkpoints to be written into the log buffers in the case of log force heavy
workloads, just like the existing transaction commit code does. This, however,
@@ -886,7 +886,7 @@ can be multiple outstanding checkpoint contexts, we can still see elevated pin
counts, but as each checkpoint completes the pin count will retain the correct
value according to it's context.
-Just to make matters more slightly more complex, this checkpoint level context
+Just to make matters slightly more complex, this checkpoint level context
for the pin count means that the pinning of an item must take place under the
CIL commit/flush lock. If we pin the object outside this lock, we cannot
guarantee which context the pin count is associated with. This is because of