So we're running GPFS 4.2.2.3 and LTFS/EE 1.2.3 to use as an archive service. Inode size is 4K, and we had a requirement to encrypt-at-rest, so encryption is in play as well. Data is replicated 2x and fragment size is 32K.
I was investigating how much data-in-inode would help deal with users who put
large trees of small files into the archive (yes, I know we can use applypolicy
with external programs to tarball offending directories, but that's a separate
discussion ;)
## ls -ls *
64 -rw-r--r-- 1 root root 2048 Jul 21 14:47 random.data
64 -rw-r--r-- 1 root root 512 Jul 21 14:48 random.data.1
64 -rw-r--r-- 1 root root 128 Jul 21 14:50 random.data.2
64 -rw-r--r-- 1 root root 32 Jul 21 14:50 random.data.3
64 -rw-r--r-- 1 root root 16 Jul 21 14:50 random.data.4
Hmm.. I was expecting at least *some* of these to fit in the inode, and
not take 2 32K blocks...
## mmlsattr -d -L random.data.4
file name: random.data.4
metadata replication: 2 max 2
data replication: 2 max 2
immutable: no
appendOnly: no
flags:
storage pool name: system
fileset name: root
snapshot name:
creation time: Fri Jul 21 14:50:51 2017
Misc attributes: ARCHIVE
Encrypted: yes
gpfs.Encryption: 0x4541 (... another 296 hex digits)
EncPar 'AES:256:XTS:FEK:HMACSHA512'
type: wrapped FEK WrpPar 'AES:KWRAP' CmbPar 'XORHMACSHA512'
KEY-97c7f4b7-06cb-4a53-b317-1c187432dc62:archKEY1_gpfsG1
Hmm.. Doesn't *look* like enough extended attributes to prevent storing even
16 bytes in the inode, should be room for around 3.5K minus the above 250 bytes
or so of attributes....
What am I missing here? Does "encrypted" or LTFS/EE disable data-in-inode?
pgpbIbLWeWl69.pgp
Description: PGP signature
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
