| Message ID | 20210325081416.3190060-1-lukas@herbolt.com (mailing list archive) |
|---|---|
| State | Deferred, archived |
| Headers | show |
| Series | xfsdocs: Small fix to correct first free inode to be 5847 not 5856. | expand |
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 >
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: ----