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