diff mbox series

xfs-docs question

Message ID 481e3f11dda1f44efe5c93c24a3a70d9@herbolt.com (mailing list archive)
State New
Headers show
Series xfs-docs question | expand

Commit Message

lukas@herbolt.com March 24, 2021, 8:34 a.m. UTC
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.

---
+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:
---

Comments

Darrick J. Wong March 24, 2021, 6:48 p.m. UTC | #1
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
diff mbox series

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