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

[Sven Oehme]

Hi,

i talked with a few others to confirm this, but unfortunate this is a
limitation of the code today (maybe not well documented which we will look
into). Encryption only encrypts data blocks, it doesn't encrypt metadata.
 Hence, if encryption is enabled, we don't store data in the inode, because
then it wouldn't be encrypted.  For the same reason HAWC and encryption are
incompatible.

Sven


On Fri, Jul 21, 2017 at 2:13 PM <valdis.kletnieks at vt.edu> wrote:

> 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?
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170721/a8ab6e7c/attachment.htm>