xfs-docs question

xfs-docs question

[lukas]

Hi,
I came across chapter in XFS documentation "12.4.1 xfs_db AGI Example" 
quoting bellow:
---
recs[1-85] = [startino,freecount,free]1:[96,0,0] 2:[160,0,0] 3:[224,0,0] 
4:[288,0,0]
                                       5:[352,0,0] 6:[416,0,0] 
7:[480,0,0] 8:[544,0,0]
                                       9:[608,0,0] 10:[672,0,0] 
11:[736,0,0] 12:[800,0,0]
                                       ...
                                       85:[5792,9,0xff80000000000000]

Most of the inode chunks on this filesystem are totally full, since the 
free value is zero.
This means that we ought to expect inode 160 to be linked somewhere in 
the directory structure.
However, notice that 0xff80000000000000 in record 85 — this means that 
we would expect inode 5856
to be free. Moving on to the free inode B+tree, we see that this is 
indeed the case:
---

As there are 9 inodes free in the last chunk of 64 inodes it gives me 
first free inode 5847 (5792+55),
on the other hand inode 5856 is also free as it's last inode in the 
chunk.

My question is do I understand correctly that the first free inode in 
that AG is 5847?
Thanks, bellow possible patch.

---
diff --git a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc 
b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
index 992615d..cdc8545 100644
--- a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
+++ b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
@@ -1099,7 +1099,7 @@ recs[1-85] = [startino,freecount,free]
 Most of the inode chunks on this filesystem are totally full, since the 
+free+
 value is zero.  This means that we ought to expect inode 160 to be 
linked
 somewhere in the directory structure.  However, notice that 
0xff80000000000000
-in record 85 -- this means that we would expect inode 5856 to be free. 
 Moving
+in record 85 -- this means that we would expect inode 5847 to be free. 
 Moving
 on to the free inode B+tree, we see that this is indeed the case:
---

-- 
Lukas Herbolt

Re: xfs-docs question

[Darrick J. Wong]

On Wed, Mar 24, 2021 at 09:34:58AM +0100, lukas@herbolt.com wrote:
> Hi,
> I came across chapter in XFS documentation "12.4.1 xfs_db AGI Example"
> quoting bellow:
> ---
> recs[1-85] = [startino,freecount,free]1:[96,0,0] 2:[160,0,0] 3:[224,0,0]
> 4:[288,0,0]
>                                       5:[352,0,0] 6:[416,0,0] 7:[480,0,0]
> 8:[544,0,0]
>                                       9:[608,0,0] 10:[672,0,0] 11:[736,0,0]
> 12:[800,0,0]
>                                       ...
>                                       85:[5792,9,0xff80000000000000]
> 
> Most of the inode chunks on this filesystem are totally full, since the free
> value is zero.
> This means that we ought to expect inode 160 to be linked somewhere in the
> directory structure.
> However, notice that 0xff80000000000000 in record 85 — this means that we
> would expect inode 5856
> to be free. Moving on to the free inode B+tree, we see that this is indeed
> the case:
> ---
> 
> As there are 9 inodes free in the last chunk of 64 inodes it gives me first
> free inode 5847 (5792+55),
> on the other hand inode 5856 is also free as it's last inode in the chunk.
> 
> My question is do I understand correctly that the first free inode in that
> AG is 5847?

Oops, yes, you are correct.  The first free inode is 5847, not 5856 as
stated in 12.4.1.

> Thanks, bellow possible patch.

It looks reasonable, but the patch needs to have a Signed-off-by tag
with your name and email (per kernel patch submission rules[1]) before
I can proceed with review.

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

> ---
> diff --git a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
> b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
> index 992615d..cdc8545 100644
> --- a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
> +++ b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
> @@ -1099,7 +1099,7 @@ recs[1-85] = [startino,freecount,free]
>  Most of the inode chunks on this filesystem are totally full, since the
> +free+
>  value is zero.  This means that we ought to expect inode 160 to be linked
>  somewhere in the directory structure.  However, notice that
> 0xff80000000000000

This patch seems to have been line wrapped.  Would you mind resending it
with the DCO tag I mentioned above, and without wrapping?  Or as a text
attachment if that's the only option?

--D

> -in record 85 -- this means that we would expect inode 5856 to be free.
>  Moving
> +in record 85 -- this means that we would expect inode 5847 to be free.
>  Moving
>  on to the free inode B+tree, we see that this is indeed the case:
> ---
> 
> -- 
> Lukas Herbolt

[PATCH] xfsdocs: Small fix to correct first free inode to be 5847 not 5856.

[lukas]

From: Lukas Herbolt <lukas@herbolt.com>

Thanks for confirmation, I was not sure about it.

Signed-off-by: Lukas Herbolt <lukas@herbolt.com>
---
 design/XFS_Filesystem_Structure/allocation_groups.asciidoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
index 992615d..cdc8545 100644
--- a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
+++ b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
@@ -1099,7 +1099,7 @@ recs[1-85] = [startino,freecount,free]
 Most of the inode chunks on this filesystem are totally full, since the +free+
 value is zero.  This means that we ought to expect inode 160 to be linked
 somewhere in the directory structure.  However, notice that 0xff80000000000000
-in record 85 -- this means that we would expect inode 5856 to be free.  Moving
+in record 85 -- this means that we would expect inode 5847 to be free.  Moving
 on to the free inode B+tree, we see that this is indeed the case:
 
 ----
-- 
2.26.2

Re: [PATCH] xfsdocs: Small fix to correct first free inode to be 5847 not 5856.

[Darrick J. Wong]

On Thu, Mar 25, 2021 at 09:14:16AM +0100, lukas@herbolt.com wrote:
> From: Lukas Herbolt <lukas@herbolt.com>
> 
> Thanks for confirmation, I was not sure about it.
> 
> Signed-off-by: Lukas Herbolt <lukas@herbolt.com>

I'll massage the commit message a bit, but otherwise this looks fine.
Thank you for the correction!

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

--D

> ---
>  design/XFS_Filesystem_Structure/allocation_groups.asciidoc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
> index 992615d..cdc8545 100644
> --- a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
> +++ b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc
> @@ -1099,7 +1099,7 @@ recs[1-85] = [startino,freecount,free]
>  Most of the inode chunks on this filesystem are totally full, since the +free+
>  value is zero.  This means that we ought to expect inode 160 to be linked
>  somewhere in the directory structure.  However, notice that 0xff80000000000000
> -in record 85 -- this means that we would expect inode 5856 to be free.  Moving
> +in record 85 -- this means that we would expect inode 5847 to be free.  Moving
>  on to the free inode B+tree, we see that this is indeed the case:
>  
>  ----
> -- 
> 2.26.2
>