<font size=2 face="sans-serif">Having multiple blocksizes in the same
file system would unnecessarily complicate things.  Consider migrating
a file from one pool to another with different blocksizes... How to represent
the indirect blocks (lists of blocks allocated to the file)?  Especially
consider that today, migration can proceed one block at a time, during
migration a file is "mis-placed" -- has blocks spread over more
than one pool....   </font><br><br><font size=2 face="sans-serif">The new feature that supports more than
32 sub-blocks per block - is a step in another direction but maybe addresses
some of your concerns....        </font><br><br><font size=2 face="sans-serif">We do support different blocksizes for
meta-data -- but meta-data is distinct from data and never migrates out
of system pool.</font><br><br><font size=2 face="sans-serif">--marc K.</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-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">01/08/2018 09:25 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
Multiple Block Sizes in a Filesystem (Was: Online data migration tool)</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>Thanks, Bryan! That's a great use case I hadn't thought
of.<br><br>GPFS can already support a different block size for the system pool so<br>in my very simplistic view of the world it's already possible (unless<br>there's some implementation detail about the system pool that lends<br>itself to a different block size from all other pools that doesn't apply<br>to other non-system pools differing from each other).<br><br>-Aaron<br><br>On 1/8/18 6:48 PM, Bryan Banister wrote:<br>> Hey Aaron... I have been talking about the same idea here and would
say it would be a massive feature and management improvement.<br>> <br>> I would like to have many GPFS storage pools in my file system, each
with tuned blocksize and subblock sizes to suite the application, using
independent filesets and the data placement policy to store the data in
the right GPFS storage pool.  Migrating the data with the policy engine
between these pools as you described would be a lot faster and a lot safer
than trying to migrate files individually (like with rsync).<br>> <br>> NSDs can only belong to one storage pool, so I don't see why the block
allocation map would be difficult to manage in this case.<br>> <br>> Cheers,<br>> -Bryan<br>> <br>> -----Original Message-----<br>> From: gpfsug-discuss-bounces@spectrumscale.org [</font></tt><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org"><tt><font size=2>mailto:gpfsug-discuss-bounces@spectrumscale.org</font></tt></a><tt><font size=2>]
On Behalf Of Aaron Knister<br>> Sent: Monday, January 08, 2018 4:57 PM<br>> To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>> Subject: [gpfsug-discuss] Multiple Block Sizes in a Filesystem (Was:
Online data migration tool)<br>> <br>> Note: External Email<br>> -------------------------------------------------<br>> <br>> I was thinking some more about the >32 subblock feature in scale
5.0. As<br>> mentioned by IBM the biggest advantage of that feature is on filesystems<br>> with large blocks (e.g. multiple MB). The majority of our filesystems<br>> have a block size of 1MB which got me thinking... wouldn't it be nice
if<br>> they had a larger block size (there seem to be compelling performance<br>> reasons for large file I/O to do this).<br>> <br>> I'm wondering, what's the feasibility is of supporting filesystem
pools<br>> of varying block sizes within a single filesystem? I thought allocation<br>> maps exist on a per-pool basis which gives me some hope it's not too
hard.<br>> <br>> If one could do this then, yes, you'd still need new hardware to migrate<br>> to a larger block size (and >32 subblocks), but it could be done
as part<br>> of a refresh cycle *and* (and this is the part most important to me)
it<br>> could be driven entirely by the policy engine which means storage
admins<br>> are largely hands off and the migration is by and large transparent
to<br>> the end user.<br>> <br>> This doesn't really address the need for a tool to address a filesystem<br>> migration to 4k metadata blocks (although I wonder if something could
be<br>> done to create a system_4k pool that contains 4k-aligned metadata
NSDs<br>> where key data structures get re-written during a restripe in a<br>> 4k-aligned manner, but that's really grasping at straws for me).<br>> <br>> -Aaorn<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=zfQZ_ymVgGc2EseA0szLiRxH-FgYnw7qMdx2qKo3Zes&s=2KsLTkZ-3MRyIMQhp8WwTn524NpfiKv8gwTy4P36xX4&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=zfQZ_ymVgGc2EseA0szLiRxH-FgYnw7qMdx2qKo3Zes&s=2KsLTkZ-3MRyIMQhp8WwTn524NpfiKv8gwTy4P36xX4&e=</font></tt></a><tt><font size=2><br>> <br>> <br>> ________________________________<br>> <br>> Note: This email is for the confidential use of the named addressee(s)
only and may contain proprietary, confidential or privileged information.
If you are not the intended recipient, you are hereby notified that any
review, dissemination or copying of this email is strictly prohibited,
and to please notify the sender immediately and destroy this email and
any attachments. Email transmission cannot be guaranteed to be secure or
error-free. The Company, therefore, does not make any guarantees as to
the completeness or accuracy of this email or any attachments. This email
is for informational purposes only and does not constitute a recommendation,
offer, request or solicitation of any kind to buy, sell, subscribe, redeem
or perform any type of transaction of a financial product.<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=zfQZ_ymVgGc2EseA0szLiRxH-FgYnw7qMdx2qKo3Zes&s=2KsLTkZ-3MRyIMQhp8WwTn524NpfiKv8gwTy4P36xX4&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=zfQZ_ymVgGc2EseA0szLiRxH-FgYnw7qMdx2qKo3Zes&s=2KsLTkZ-3MRyIMQhp8WwTn524NpfiKv8gwTy4P36xX4&e=</font></tt></a><tt><font size=2><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></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=zfQZ_ymVgGc2EseA0szLiRxH-FgYnw7qMdx2qKo3Zes&s=2KsLTkZ-3MRyIMQhp8WwTn524NpfiKv8gwTy4P36xX4&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=zfQZ_ymVgGc2EseA0szLiRxH-FgYnw7qMdx2qKo3Zes&s=2KsLTkZ-3MRyIMQhp8WwTn524NpfiKv8gwTy4P36xX4&e=</font></tt></a><tt><font size=2><br><br></font></tt><br><br><BR>