[gpfsug-discuss] subblock sanity check in 5.0

Joseph Mendoza jam at ucar.edu
Tue Jun 26 01:58:53 BST 2018


Quick question, anyone know why GPFS wouldn't respect the default for
the subblocks-per-full-block parameter when creating a new filesystem? 
I'd expect it to be set to 512 for an 8MB block size but my guess is
that also specifying a metadata-block-size is interfering with it (by
being too small).  This was a parameter recommended by the vendor for a
4.2 installation with metadata on dedicated SSDs in the system pool, any
best practices for 5.0?  I'm guessing I'd have to bump it up to at least
4MB to get 512 subblocks for both pools.

fs1 created with:
# mmcrfs fs1 -F fs1_ALL -A no -B 8M -i 4096 -m 2 -M 2 -r 1 -R 2 -j
cluster -n 9000 --metadata-block-size 512K --perfileset-quota
--filesetdf -S relatime -Q yes --inode-limit 20000000:10000000 -T /gpfs/fs1

# mmlsfs fs1
<snipped>

flag                value                    description
------------------- ------------------------
-----------------------------------
 -f                 8192                     Minimum fragment (subblock)
size in bytes (system pool)
                    131072                   Minimum fragment (subblock)
size in bytes (other pools)
 -i                 4096                     Inode size in bytes
 -I                 32768                    Indirect block size in bytes

 -B                 524288                   Block size (system pool)
                    8388608                  Block size (other pools)

 -V                 19.01 (5.0.1.0)          File system version

 --subblocks-per-full-block 64               Number of subblocks per
full block
 -P                 system;DATA              Disk storage pools in file
system


Thanks!
--Joey Mendoza
NCAR



More information about the gpfsug-discuss mailing list