[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