Re: [PATCH v1] Documentation: filesystems: xfs: update pseudocode and typo fixes

From: Darrick J. Wong
Date: Tue Aug 23 2022 - 12:48:16 EST


On Mon, Aug 22, 2022 at 09:36:53PM -0400, zhaomzhao@xxxxxxx wrote:
> From: Zhao Mengmeng <zhaomengmeng@xxxxxxxxxx>
>
> 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@xxxxxxxxxx>
> ---
> .../filesystems/xfs-delayed-logging-design.rst | 12 ++++++------
> 1 file 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

Thanks for the editing :)

Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx>

--D

> 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
> --
> 2.37.1
>