Okay if you have double parity why not just resize the disk. And let gpfs recover using the parity. And by the way there is a qos setting for maintenance operations and you can give that higher priority to make the recovery/deleting/adding operations quicker. Also I don't know if this matters in gpfs but you may want to change the affinity for disk (distribute the primary/first node for each disk/Christmas tree it) to a different servers to spread the load. I don't know if gpfs will actually use that to distribute load, but worth checking.
Alec On Mon, Jun 20, 2022, 12:20 PM Jonathan Buzzard < [email protected]> wrote: > On 20/06/2022 20:12, Jaime Pinto wrote: > > > > Thanks JAB and Luis > > > > I know, there are mmdelnsd, mmdeldisk, mmrestripefs and a few other > > correlated mm* commands. They are very high-level in work in bulk > > discreet fashion (I mean, considering the number of NSDs we have, each > > deletion will shave 4% of the storage at once, that is too much). > > > > Then you are goosed. An NSD cannot be changed in size once created and > can only ever be in a file system or out a file system. The only way to > change the size of a GPFS file system is by adding or removing NSD's. > > I am not a fan of how the DSS-G creates small numbers of huge NSD's. In > fact the script sucks a *lot* from a systems admin perspective. Then > again someone at IBM thought redeploying your entire OS every time you > want to make a point release upgrade was a good idea. > > > 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 gpfsug.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org >
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at gpfsug.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org
