<font size=2 face="sans-serif">I googled </font><tt><font size=2>GPFS_FCNTL_GET_DATABLKDISKIDX</font></tt><br><br><font size=2 face="sans-serif">and found this discussion:</font><br><br><font size=2 face="sans-serif"> </font><a href="https://www.ibm.com/developerworks/community/forums/html/topic?id=db48b190-4f2f-4e24-a035-25d3e2b06b2d&ps=50"><font size=2 color=blue face="sans-serif">https://www.ibm.com/developerworks/community/forums/html/topic?id=db48b190-4f2f-4e24-a035-25d3e2b06b2d&ps=50</font></a><font size=2 face="sans-serif"><br></font><br><font size=2 face="sans-serif">In general, GPFS files ARE deliberately
"fragmented" but we don't say that - we say they are "striped"
over many disks -- and that is generally a good thing for parallel performance.</font><br><br><font size=2 face="sans-serif">Also, in GPFS, if the last would-be
block of a file is less than a block, then it is stored in a "fragment"
of a block.  </font><br><font size=2 face="sans-serif">So you see we use "fragment"
to mean something different than other file systems you may know.</font><br><br><font size=2 face="sans-serif">--marc</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Aaron Knister <aaron.s.knister@nasa.gov></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">gpfsug main discussion
list <gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">11/04/2017 12:22 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">[gpfsug-discuss]
file layout API + file fragmentation</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><tt><font size=2>I've got a question about the file layout API and
how it reacts in the<br>case of fragmented files.<br><br>I'm using the GPFS_FCNTL_GET_DATABLKDISKIDX structure and have some code<br>based on tsGetDataBlk.C. I'm basing the block size based off of what's<br>returned by filemapOut.blockSize but that only seems to return a value
><br>0 when filemapIn.startOffset is 0.<br><br>In a case where a file were to be made up of a significant number of<br>non-contiguous fragments (which... would be awful in of itself) how<br>would this be reported by the file layout API? Does the interface<br>technically just report the disk location information of the first block<br>of the $blockSize range and assume that it's contiguous?<br><br>Thanks!<br><br>-Aaron<br><br>-- <br>Aaron Knister<br>NASA Center for Climate Simulation (Code 606.2)<br>Goddard Space Flight Center<br>(301) 286-2776<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=wnR7m6d4urZ_8dM4mkHQjMbFD9xJEeesmJyzt1osCnM&s=-dgGO6O5i1EqWj-8MmzjxJ1Iz2I5gT1aRmtyP44Cvdg&e="><tt><font size=2>https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=wnR7m6d4urZ_8dM4mkHQjMbFD9xJEeesmJyzt1osCnM&s=-dgGO6O5i1EqWj-8MmzjxJ1Iz2I5gT1aRmtyP44Cvdg&e=</font></tt></a><tt><font size=2><br><br></font></tt><br><br><BR>