[Cluster-devel] [PATCH] gfs2: Remove sdp->sd_jheightsize

Bob Peterson rpeterso at redhat.com
Fri Apr 13 13:29:45 UTC 2018


----- Original Message -----
> GFS2 keeps two arrarys in the superblock that define the maximum size of
> an inode depending on the inode's height: sdp->sd_heightsize defines the
> heights in units of sb->s_blocksize; sdp->sd_jheightsize defines them in
> units of sb->s_blocksize - sizeof(struct gfs2_meta_header).  These
> arrays are used to determine when additional layers of indirect blocks
> are needed.  The second array is used for directories which have an
> additional gfs2_meta_header at the beginning of each block.
> 
> Distinguishing between these two cases makes no sense: the height
> required for representing N blocks will come out the same no matter if
> the calculation is done in gross (sb->s_blocksize) or net
> (sb->s_blocksize - sizeof(struct gfs2_meta_header)) units.

Hm. Granted it's early morning for me and the caffeine still hasn't
made it to my brain, but I'm not convinced the above statement is true.

I know in almost all cases it's a stupid thing to do, but if the
block size is 512 bytes:

regular file: 512/8 bytes per pointer = 64 indirect pointers per block
regular file: max is: 64 * 512 = 32768 bytes before it goes to height 2

directory:    488/8 bytes per pointer = 61 indirect pointers per block
directory:    max is: 61 * 512 = 31232, but the number of pointers in a
              directory is always power of 2. 

So for a directory, if the exhash algorithm doubles the hash table
size from  2048 pointers to 4096 pointers, the table needs to go from
16K to 32K bytes. Thus, the height needs to go from 1 to 2, whereas if
the same thing was done to a file, the 16K would still fit inside a
dinode of height 1. Right?

Bob Peterson
Red Hat File Systems




More information about the Cluster-devel mailing list