[gpfsug-discuss] Converting a dependent fileset to independent

David Johnson david_johnson at brown.edu
Wed Apr 25 14:07:19 BST 2018 

Yes, independent snapshotting would be an issue.  However at the moment we have 570 dependent filesets in our
main filesystem, which is not all that far from the limit of 1000 independent filesets per filesystem.  
There was a thread concerning fileset issues back in February, wondering if the limits had changed 
between 4.x to 5.0.0 releases, but it went unanswered.  

We would love to be able to use the features independent filesets (quicker traversal by policy engine,
snapshots as you mention, etc), but the thought that we could run out of them as our user base grows killed that idea.

> On Apr 25, 2018, at 8:35 AM, Sobey, Richard A <r.sobey at imperial.ac.uk> wrote:
> 
> You can apply fileset quotas to independent filesets to you know. Sorry if that sounds passive aggressive, not meant to be!
>  
> Main reason for us NOT to use dependent filesets is lack of snapshotting.
>  
> Richard
>  
> From: gpfsug-discuss-bounces at spectrumscale.org <mailto:gpfsug-discuss-bounces at spectrumscale.org> <gpfsug-discuss-bounces at spectrumscale.org <mailto:gpfsug-discuss-bounces at spectrumscale.org>> On Behalf Of david_johnson at brown.edu <mailto:david_johnson at brown.edu>
> Sent: 25 April 2018 13:14
> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org <mailto:gpfsug-discuss at spectrumscale.org>>
> Subject: Re: [gpfsug-discuss] Converting a dependent fileset to independent
>  
> We use a dependent fileset for each research group / investigator. We do this mainly so we can apply fileset quotas.   We tried independent filesets but they were quite inconvenient:
> 1) limited number independent filesets could be created compared to dependent
> 2) requirement to manage number of inodes allocated to each and every independent fileset
>  
> There may have been other issues but we create a new dependent fileset whenever  a new researcher joins our cluster. 
>   -- ddj
> Dave Johnson
> 
> On Apr 25, 2018, at 5:42 AM, Daniel Kidger <daniel.kidger at uk.ibm.com <mailto:daniel.kidger at uk.ibm.com>> wrote:
> 
> It would though be a nice to have feature: to leave the file data where it was and just move the metadata into its own inode space?
>  
> A related question though:
> In what case do people create new *dependant* filesets ? I can't see many cases where an independent fileset would be just as valid.
> Daniel
> 
>  
>  <https://www.youracclaim.com/user/danel-kidger>	
> <~WRD000.jpg> <https://www.youracclaim.com/user/danel-kidger>	
>  
>  
>  
> Dr Daniel Kidger
> IBM Technical Sales Specialist
> Software Defined Solution Sales
> 
> +44-(0)7818 522 266 
> daniel.kidger at uk.ibm.com <mailto:daniel.kidger at uk.ibm.com>
>  
>  
>  
> ----- Original message -----
> From: "Sobey, Richard A" <r.sobey at imperial.ac.uk <mailto:r.sobey at imperial.ac.uk>>
> Sent by: gpfsug-discuss-bounces at spectrumscale.org <mailto:gpfsug-discuss-bounces at spectrumscale.org>
> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org <mailto:gpfsug-discuss at spectrumscale.org>>
> Cc:
> Subject: Re: [gpfsug-discuss] Converting a dependent fileset to independent
> Date: Wed, Apr 25, 2018 10:01 AM
>  
> 
> Hi Marc
> 
>  
> 
> Yes, copying the data to a freshly created fileset and unlinking/renaming/relinking is our solution; it was always a long shot expecting to be able to convert it 😊
> 
>  
> 
> Richard
> 
>  
> 
> From: gpfsug-discuss-bounces at spectrumscale.org <mailto:gpfsug-discuss-bounces at spectrumscale.org> <gpfsug-discuss-bounces at spectrumscale.org <mailto:gpfsug-discuss-bounces at spectrumscale.org>> On Behalf Of Marc A Kaplan
> Sent: 24 April 2018 13:49
> To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org <mailto:gpfsug-discuss at spectrumscale.org>>
> Subject: Re: [gpfsug-discuss] Converting a dependent fileset to independent
> 
>  
> 
> To help make sense of this, one has to understand that "independent" means a different range of inode numbers.
> 
> If you have a set of files within one range of inode numbers, say 3000-5000 and now you want to move some of them to a new range of inode numbers, say 7000-8000, you're going to have to create that new range as a new independent fileset, and then move (copy!) the files to the new fileset.  And then rename directories so that you can once again refer to the files by the pathnames that they "used to" have.
> 
> During the copying and renaming, you would have to make sure there are no applications trying to access those files and directories.
> 
> 
> 
> From:        "Sobey, Richard A" <r.sobey at imperial.ac.uk <mailto:r.sobey at imperial.ac.uk>>
> To:        "'gpfsug-discuss at spectrumscale.org <mailto:gpfsug-discuss at spectrumscale.org>'" <gpfsug-discuss at spectrumscale.org <mailto:gpfsug-discuss at spectrumscale.org>>
> Date:        04/24/2018 05:20 AM
> Subject:        [gpfsug-discuss] Converting a dependent fileset to independent
> Sent by:        gpfsug-discuss-bounces at spectrumscale.org <mailto:gpfsug-discuss-bounces at spectrumscale.org>
> 
> 
> 
> Hi all,
>  
> Is there any way, without starting over, to convert a dependent fileset to independent?
>  
> My gut says no but in the spirit of not making unnecessary work I wanted to ask.
>  
> Also, the documentation states that I should see a “dpnd” next to a dependent fileset when I run mmlsfileset with -L; this is not the case even though the parent fileset is root in this case.
>  
> [root at nsd bin]# mmlsfileset gpfs studentrecruitmentandoutreach -L
> Filesets in file system 'gpfs':
> Name                            Id      RootInode  ParentId Created                      InodeSpace      MaxInodes    AllocInodes Comment
> studentrecruitmentandoutreach  241        8700824         0 Wed Feb 14 14:25:49 2018        0                    0              0
>  
> Thanks
> Richard_______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org <http://spectrumscale.org/>
> 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=W9WH1n93tRRhW5npPGd73Dqgcp4d0oAYKt4yOI02PWU&s=MnsN-hjjhZirIDfK1k-awRB9hodsX2Ylh1Z1IzoJij0&e= <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=W9WH1n93tRRhW5npPGd73Dqgcp4d0oAYKt4yOI02PWU&s=MnsN-hjjhZirIDfK1k-awRB9hodsX2Ylh1Z1IzoJij0&e=>
> 
> 
> 
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org <http://spectrumscale.org/>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=HlQDuUjgJx4p54QzcXd0_zTwf4Cr2t3NINalNhLTA2E&m=q3YHYji1-ohlnu_yLuOGmxLnmk9znaxUJdg04aGLU_U&s=Axp36hWpcuKZbTMbdVde_ifZreMvOlR5sHUYX3A79hQ&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=HlQDuUjgJx4p54QzcXd0_zTwf4Cr2t3NINalNhLTA2E&m=q3YHYji1-ohlnu_yLuOGmxLnmk9znaxUJdg04aGLU_U&s=Axp36hWpcuKZbTMbdVde_ifZreMvOlR5sHUYX3A79hQ&e=>
>  
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org <http://spectrumscale.org/>
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss <http://gpfsug.org/mailman/listinfo/gpfsug-discuss>_______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org <http://spectrumscale.org/>
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss <http://gpfsug.org/mailman/listinfo/gpfsug-discuss>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20180425/908762a1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5458 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20180425/908762a1/attachment.bin>

More information about the gpfsug-discuss mailing list