<html><body><p>Exactly how much data can fit into an inode depends on whether any extended attributes (EAs) are present, which makes this complicated, as EAs may be set explicitly by the user or implicitly by the system. In any inode, there's a fixed footprint of the inode header, 128 bytes on recent GPFS streams. So if there's no possibility to fit more than (inodeSize - 128) bytes into an inode. If some EAs are present, this becomes more complicated. GPFS can store EAs either in the inode, or in a special "EA overflow block". Certain EAs used by GPFS internally (for encryption, AFM, DMAPI, clones) must reside in the inode, due to the need to have those set at certain junctures when it's tricky to accommodate EA overflow allocation with proper atomicity guarantees. Other subsystems, e.g. SELinux, may implicitly use EAs as well. So a given inode may have less space for data than described above. This is another big part of the reason why 4K is the current default inode size. And of course this is not an external spec set in stone, but rather the way the current implementation works. A future version of GPFS may have a bigger inode header, for example. So it would be imprudent to bank on file/directory data fitting into an inode with a great deal of precision. A better way to view this is as a kind of a performance optimization.<br><br>DMAPI won't "punch out" data that resides in inode. Such a file has zero blocks allocated, so there's nothing for an HSM app to migrate. TCT can copy in-inode data to cloud for co-resident mode. And yes, TCT doesn't rely on the same DMAPI API as HSM, per se, but naturally the underlying code shares some of the infrastructure.<br><br>yuri<br><br><img width="16" height="16" src="cid:1__=07BB0AD6DFCBA0818f9e8a93df938690918c07B@" border="0" alt="Inactive hide details for Luke Raimbach ---10/03/2016 09:16:41 AM---It doesn't, but the end result is the same... data shipped "><font color="#424282">Luke Raimbach ---10/03/2016 09:16:41 AM---It doesn't, but the end result is the same... data shipped off 'somewhere else' with a stub file?</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Luke Raimbach <luke.raimbach@googlemail.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>, </font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">10/03/2016 09:16 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [gpfsug-discuss] Biggest file that will fit inside an inode?</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><font size="4">It doesn't, but the end result is the same... data shipped off 'somewhere else' with a stub file?</font><br><br><font size="4">I have in my mind that DMAPI support was around before data-in-inode (or at least 4K inodes) was introduced, so it had to be made a bit cleverer to cope, but I may be misremembering that.</font><br><br><font size="4">On Mon, 3 Oct 2016 at 17:10 Simon Thompson (Research Computing - IT Services) <</font><a href="mailto:S.J.Thompson@bham.ac.uk"><u><font size="4" color="#0000FF">S.J.Thompson@bham.ac.uk</font></u></a><font size="4">> wrote:</font><ul><font size="4"><br>TCT doesn't use dmapi though I thought?<br>________________________________________<br>From: </font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss-bounces@spectrumscale.org</font></u></a><font size="4"> [</font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss-bounces@spectrumscale.org</font></u></a><font size="4">] on behalf of Luke Raimbach [</font><a href="mailto:luke.raimbach@googlemail.com" target="_blank"><u><font size="4" color="#0000FF">luke.raimbach@googlemail.com</font></u></a><font size="4">]<br>Sent: 03 October 2016 17:07<br>To: gpfsug main discussion list<br>Subject: Re: [gpfsug-discuss] Biggest file that will fit inside an inode?<br><br>Surely it wouldn't go? Maybe the data would get copied out rather than stubbed... DMAPI can't be stupid enough to stub data out of an inode? Can it? Interesting question.<br><br>Maybe I'll test that one.<br><br>On Mon, 3 Oct 2016 at 17:00 Simon Thompson (Research Computing - IT Services) <</font><a href="mailto:S.J.Thompson@bham.ac.uk" target="_blank"><u><font size="4" color="#0000FF">S.J.Thompson@bham.ac.uk</font></u></a><font size="4"><mailto:</font><a href="mailto:S.J.Thompson@bham.ac.uk" target="_blank"><u><font size="4" color="#0000FF">S.J.Thompson@bham.ac.uk</font></u></a><font size="4">>> wrote:<br><br>Would you tier an in-inode file to the cloud?<br><br>I mean, I wouldn't tier an in-inode file out to tape?<br><br>Simon<br>________________________________________<br>From: </font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss-bounces@spectrumscale.org</font></u></a><font size="4"><mailto:</font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss-bounces@spectrumscale.org</font></u></a><font size="4">> [</font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss-bounces@spectrumscale.org</font></u></a><font size="4"><mailto:</font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss-bounces@spectrumscale.org</font></u></a><font size="4">>] on behalf of Oesterlin, Robert [</font><a href="mailto:Robert.Oesterlin@nuance.com" target="_blank"><u><font size="4" color="#0000FF">Robert.Oesterlin@nuance.com</font></u></a><font size="4"><mailto:</font><a href="mailto:Robert.Oesterlin@nuance.com" target="_blank"><u><font size="4" color="#0000FF">Robert.Oesterlin@nuance.com</font></u></a><font size="4">>]<br>Sent: 03 October 2016 16:56<br>To: gpfsug main discussion list<br>Subject: Re: [gpfsug-discuss] Biggest file that will fit inside an inode?<br><br>What's going be taken away if you use Encryption or Transparent Cloud Tiering?<br><br><br>Bob Oesterlin<br>Sr Storage Engineer, Nuance HPC Grid<br><br><br>From: <</font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss-bounces@spectrumscale.org</font></u></a><font size="4"><mailto:</font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss-bounces@spectrumscale.org</font></u></a><font size="4">>> on behalf of Marc A Kaplan <</font><a href="mailto:makaplan@us.ibm.com" target="_blank"><u><font size="4" color="#0000FF">makaplan@us.ibm.com</font></u></a><font size="4"><mailto:</font><a href="mailto:makaplan@us.ibm.com" target="_blank"><u><font size="4" color="#0000FF">makaplan@us.ibm.com</font></u></a><font size="4">>><br>Reply-To: gpfsug main discussion list <</font><a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss@spectrumscale.org</font></u></a><font size="4"><mailto:</font><a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss@spectrumscale.org</font></u></a><font size="4">>><br>Date: Monday, October 3, 2016 at 10:46 AM<br>To: gpfsug main discussion list <</font><a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss@spectrumscale.org</font></u></a><font size="4"><mailto:</font><a href="mailto:gpfsug-discuss@spectrumscale.org" target="_blank"><u><font size="4" color="#0000FF">gpfsug-discuss@spectrumscale.org</font></u></a><font size="4">>><br>Subject: [EXTERNAL] Re: [gpfsug-discuss] Biggest file that will fit inside an inode? 3968!!<br><br>On a non-SELINUX system the answer is 3968 of data in a 4K inode, just 128 bytes of metadata.<br><br>Caution: it's possible in some future release, this could change ... I don't know of any plans, I'm just saying ...<br><br>Inode 16346892 [16346892] snap 0 (index 12 in block 255420):<br> Inode address: 6:123049056 size 4096 nAddrs 330<br> indirectionLevel=INODE status=USERFILE<br> objectVersion=1 generation=0xC0156CB nlink=1<br> owner uid=0 gid=0 mode=0200100644: -rw-r--r--<br> blocksize code=5 (32 subblocks)<br> lastBlockSubblocks=0<br> checksum=0xAD8E0B4B is Valid<br> fileSize=3968 nFullBlocks=0<br> currentMetadataReplicas=1 maxMetadataReplicas=2<br> currentDataReplicas=1 maxDataReplicas=2<br> ...<br> Data [3968]:<br>0000000000000000: BCA91252 2B64BEDC A7D7BA9D D5BE8C30 *...R+d.........0*<br>...<br>0000000000000F70: DA925E2F 16A68C01 03CA5E37 08D72B7F *..^/......^7..+.*<br> trailer: is NULL<br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at </font><a href="http://spectrumscale.org/" target="_blank"><u><font size="4" color="#0000FF">spectrumscale.org</font></u></a><font size="4"><</font><a href="http://spectrumscale.org/" target="_blank"><u><font size="4" color="#0000FF">http://spectrumscale.org</font></u></a><font size="4">></font><u><font size="4" color="#0000FF"><br></font></u><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank"><u><font size="4" color="#0000FF">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></u></a><font size="4"><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at </font><a href="http://spectrumscale.org/" target="_blank"><u><font size="4" color="#0000FF">spectrumscale.org</font></u></a><u><font size="4" color="#0000FF"><br></font></u><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank"><u><font size="4" color="#0000FF">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></u></a><tt>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></tt><tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></tt><tt><br></tt><br></ul><BR>
</body></html>