Hi, we rely on some scheme of file names. Splitting by path / fileset does not work here as small- and large-record data have to be co-located. Small-record files will only be recognised if carrying some magic strings in the file name. This is not a normal user system, but ingests data generated automatically, and thus a systematic naming of files is possible to a large extent. Mit freundlichen Grüßen / Kind regards
Dr. Uwe Falke IT Specialist High Performance Computing Services / Integrated Technology Services / Data Center Services ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Rathausstr. 7 09111 Chemnitz Phone: +49 371 6978 2165 Mobile: +49 175 575 2877 E-Mail: uwefa...@de.ibm.com ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Business & Technology Services GmbH / Geschäftsführung: Thomas Wolter, Sven Schooß Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 17122 From: valdis.kletni...@vt.edu To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: 25/04/2018 02:10 Subject: Re: [gpfsug-discuss] ILM: migrating between internal pools while premigrated to external Sent by: gpfsug-discuss-boun...@spectrumscale.org On Wed, 25 Apr 2018 01:10:52 +0200, "Uwe Falke" said: > Instead, one of the internal pools (pool0) is used to receive files > written in very small records, the other (pool1) is the "normal" pool and > receives all other files. How do you arrange that to happen? As we found out on one of our GPFS clusters, you can't use filesize as a criterion in a file placement policy because it has to pick a pool before it knows what the final filesize will be. (The obvious-to-me method is to set filesets pointed at pools, and then attach fileset to pathnames, and then tell the users "This path is for small files, this one is for other files" and thwap any who get it wrong with a clue-by-four. ;) [attachment "attnayq3.dat" deleted by Uwe Falke/Germany/IBM] _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss