On Wed, 2017-08-02 at 21:03 -0400, Aaron Knister wrote: > Oh, the one *huge* gotcha I thought I'd share-- we wrote a perl script > to drive the migration and part of the perl script's process was to > clone quotas from old uid numbers to the new number. I upset our GPFS > cluster during a particular migration in which the user was over the > grace period of the quota so after a certain point every chown() put the > destination UID even further over its quota. The problem with this being > that at this point every chown() operation would cause GPFS to do some > cluster-wide quota accounting-related RPCs. That hurt. It's worth making > sure there are no quotas defined for the destination UID numbers and if > they are that the data coming from the source UID number will fit.
For similar reasons if you are doing a restore of a file system (any file system for that matter not just GPFS) for whatever reason, don't turn quotas back on till *after* the restore is complete. Well unless you can be sure a user is not going to go over quota during the restore. However as this is generally not possible to determine you end up with no quota's either set/enforced till the restore is complete. JAB. -- Jonathan A. Buzzard Tel: +44141-5483420 HPC System Administrator, ARCHIE-WeSt. University of Strathclyde, John Anderson Building, Glasgow. G4 0NG _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
