| Message ID | 481e3f11dda1f44efe5c93c24a3a70d9@herbolt.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | xfs-docs question | expand |
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 --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
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: ---