[gpfsug-discuss] GPFS, LTFS/EE and data-in-inode?

[valdis.kletnieks at vt.edu]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170721/138ec81e/attachment.sig>