On Wed, 2017-04-19 at 20:05 +0000, Simon Thompson (IT Research Support) wrote: > By having many LUNs, you get many IO queues for Linux to play with. Also the > raid6 overhead can be quite significant, so it might be better to go with > raid1 anyway depending on the controller... > > And if only gpfs had some sort of auto tier back up the pools for hot or data > caching :-) >
If you have sized the "fast" pool correctly then the "slow" pool will be spending most of it's time doing diddly squat, aka under 10 IOPS per second unless you are flushing the pool of old files to make space. I have graphs that show this. Then two things happen, if you are just reading the file then fine, probably coming from the cache or the disks are not very busy anyway so you won't notice. If you happen to *change* the file and start doing things actively with it again, then because most programs approach this by creating an entirely new file with a temporary name, then doing a rename and delete shuffle so a crash will leave you with a valid file somewhere then the changed version ends up on the fast disk by virtue of being a new file. JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Fife, United Kingdom. _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
