<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" >In GPFS blocks within a file are never fragmented. For example, if you have a file of size 7.3 MB and your file system block size is 1MB, then this file will be made up of 7 full blocks and one fragment of size 320k (10 subblocks). Each of the 7 full blocks will be contiguous on a singe diks (LUN) behind a single NSD server. The fragment that makes up the last part of the file will also be contiguous on a single disk, just shorter than a full block.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Frank Schmuck<br>IBM Almaden Research Center<br> </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: Aaron Knister <aaron.s.knister@nasa.gov><br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>To: <gpfsug-discuss@spectrumscale.org><br>Cc:<br>Subject: Re: [gpfsug-discuss] file layout API + file fragmentation<br>Date: Sun, Nov 5, 2017 3:39 PM<br>
<div><font face="Default Monospace,Courier New,Courier,monospace" size="2" >Thanks Marc, that helps. I can't easily use tsdbfs for what I'm working<br>on since it needs to be run as unprivileged users.<br><br>Perhaps I'm not asking the right question. I'm wondering how the file<br>layout api behaves if a given "block"-aligned offset in a file is made<br>up of sub-blocks/fragments that are not all on the same NSD. The<br>assumption based on how I've seen the API used so far is that all<br>sub-blocks within a block at a given offset within a file are all on the<br>same NSD.<br><br>-Aaron<br><br>On 11/5/17 6:01 PM, Marc A Kaplan wrote:<br>> I googled GPFS_FCNTL_GET_DATABLKDISKIDX<br>><br>> and found this discussion:<br>><br>> Â <a href="https://www.ibm.com/developerworks/community/forums/html/topic?id=db48b190-4f2f-4e24-a035-25d3e2b06b2d&ps=50" target="_blank" >https://www.ibm.com/developerworks/community/forums/html/topic?id=db48b190-4f2f-4e24-a035-25d3e2b06b2d&ps=50</a><br>><br>> In general, GPFS files ARE deliberately "fragmented" but we don't say<br>> that - we say they are "striped" over many disks -- and that is<br>> generally a good thing for parallel performance.<br>><br>> Also, in GPFS, if the last would-be block of a file is less than a<br>> block, then it is stored in a "fragment" of a block. Â <br>> So you see we use "fragment" to mean something different than other file<br>> systems you may know.<br>><br>> --marc<br>><br>><br>><br>> From: Â Â Â Â Aaron Knister <aaron.s.knister@nasa.gov><br>> To: Â Â Â Â gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>> Date: Â Â Â Â 11/04/2017 12:22 PM<br>> Subject: Â Â Â Â [gpfsug-discuss] file layout API + file fragmentation<br>> Sent by: Â Â Â Â gpfsug-discuss-bounces@spectrumscale.org<br>> ------------------------------------------------------------------------<br>><br>><br>><br>> 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>> <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=" target="_blank" >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=</a><br>><br>><br>><br>><br>><br>><br>> _______________________________________________<br>> gpfsug-discuss mailing list<br>> gpfsug-discuss at spectrumscale.org<br>> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIF-g&c=jf_iaSHvJObTbx-siA1ZOg&r=ai3ddVzf50ktH78ovGv6NU4O2LZUOWLpiUiggb8lEgA&m=pUdB4fbWLD03ZTAhk9OlpRdIasz628Oa_yG8z8NOjsk&s=kisarJ7IVnyYBx05ZZiGzdwaXnPqNR8UJoywU1OJNRU&e=" target="_blank" >https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIF-g&c=jf_iaSHvJObTbx-siA1ZOg&r=ai3ddVzf50ktH78ovGv6NU4O2LZUOWLpiUiggb8lEgA&m=pUdB4fbWLD03ZTAhk9OlpRdIasz628Oa_yG8z8NOjsk&s=kisarJ7IVnyYBx05ZZiGzdwaXnPqNR8UJoywU1OJNRU&e=</a><br>><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><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIF-g&c=jf_iaSHvJObTbx-siA1ZOg&r=ai3ddVzf50ktH78ovGv6NU4O2LZUOWLpiUiggb8lEgA&m=pUdB4fbWLD03ZTAhk9OlpRdIasz628Oa_yG8z8NOjsk&s=kisarJ7IVnyYBx05ZZiGzdwaXnPqNR8UJoywU1OJNRU&e=" target="_blank" >https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIF-g&c=jf_iaSHvJObTbx-siA1ZOg&r=ai3ddVzf50ktH78ovGv6NU4O2LZUOWLpiUiggb8lEgA&m=pUdB4fbWLD03ZTAhk9OlpRdIasz628Oa_yG8z8NOjsk&s=kisarJ7IVnyYBx05ZZiGzdwaXnPqNR8UJoywU1OJNRU&e=</a></font><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>