<font size=2 face="sans-serif">Yes, "special" characters in
pathnames can lead to trouble... But just for the record...</font><br><br><font size=2 face="sans-serif">GPFS supports the same liberal file
name policy as standard POSIX. Namely any bytestring is valid, except:</font><br><br><font size=2 face="sans-serif">/ delimits directory names</font><br><br><font size=2 face="sans-serif">The \0 (zero or Null Character) byte
value marks the end of the pathname.</font><br><br><font size=2 face="sans-serif">There are limits on the length of an
individual file or directory name.</font><br><br><font size=2 face="sans-serif">AND there is an OS imposed limit on
the total length of a pathname you can pass through the file system APIs.</font><br><font size=2 face="sans-serif"><br></font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Buterbaugh, Kevin
L" <Kevin.Buterbaugh@Vanderbilt.Edu></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">gpfsug main discussion
list <gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">01/16/2018 01:58 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
GPFS best practises : end user standpoint</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><tt><font size=2>Hi Jonathan,<br><br><br><br>Comments / questions inline. Thanks!<br><br><br><br>Kevin<br><br><br><br>> On Jan 16, 2018, at 10:08 AM, Jonathan Buzzard <jonathan.buzzard@strath.ac.uk>
wrote:<br><br>> <br><br>> On Tue, 2018-01-16 at 15:47 +0000, Carl Zetie wrote:<br><br>>> Maybe this would make for a good session at a future user group<br><br>>> meeting -- perhaps as an interactive session? IBM could potentially<br><br>>> provide a facilitator from our Design practice.<br><br>>> <br><br>> <br><br>> Most of it in my view is standard best practice regardless of the
file<br><br>> system in use.<br><br>> <br><br>> So in our mandatory training for the HPC, we tell our users don't
use<br><br>> whacked out characters in your file names and directories. Specifically<br><br>> no backticks, no asterik's, no question marks, no newlines (yes<br><br>> really), no slashes (either forward or backward) and for Mac users<br><br>> don't start the name with a space (forces sorting to the top). We<br><br>> recommend sticking to plain ASCII so no accented characters either<br><br>> (harder if your native language is not English I guess but we are
UK<br><br>> based so...). We don't enforce that but if it causes the user problems<br><br>> then they are on their own.<br><br><br><br>We\u2019re in Tennessee, so not only do we not speak English, we barely speak
American \u2026 y\u2019all will just have to understand, bless your hearts! ;-).
<br><br><br><br>But seriously, like most Universities, we have a ton of users for whom
English is not their \u201cprimary\u201d language, so dealing with \u201cinteresting\u201d
filenames is pretty hard to avoid. And users\u2019 problems are our problems
whether or not they\u2019re our problem.<br><br><br><br>> <br><br>> We also strongly recommend using ISO 8601 date formats in file names
to<br><br>> get date sorting from a directory listing too. Surprisingly not widely<br><br>> known about, but a great "life hack".<br><br>> <br><br>> Then it boils down to don't create zillions of files. I would love
to<br><br>> be able to somehow do per directory file number quota's where one
could<br><br>> say set a default of a few thousand. Users would then have to justify<br><br>> needing a larger quota. Sure you can set a file number quota but that<br><br>> does not stop them putting them all in one directory.<br><br><br><br>If you\u2019ve got (bio)medical users using your cluster I don\u2019t see how you
avoid this \u2026 they\u2019re using commercial apps that do this kind of stupid
stuff (10\u2019s of thousands of files in a directory and the full path to
each file is longer than the contents of the files themselves!).<br><br><br><br>This reminds me of way back in 2005 when we moved from an NFS server to
GPFS \u2026 I was moving users over by tarring up their home directories on
the NFS server, copying the tarball over to GPFS and untarring it there
\u2026 worked great for 699 out of 700 users. But there was one user
for whom the untar would fail every time I tried \u2026 turned out that back
in early versions of GPFS 2.3 IBM hadn\u2019t considered that someone would
put 6 million files in one directory! :-O<br><br><br><br>> <br><br>> If users really need to have zillions of files then charge them more
so<br><br>> you can afford to beef up your metadata disks to SSD.<br><br><br><br>OK, so here\u2019s my main question \u2026 you\u2019re right that SSD\u2019s are the answer
\u2026 but how do you charge them more? SSDs are move expensive than
hard disks, and enterprise SSDs are stupid expensive \u2026 and users barely
want to pay hard drive prices for their storage. If you\u2019ve got the
magic answer to how to charge them enough to pay for SSDs I\u2019m sure I\u2019m
not the only one who\u2019d love to hear how you do it?!?!<br><br><br><br>> <br><br>> <br><br>> JAB.<br><br>> <br><br>> -- <br><br>> Jonathan A. Buzzard
Tel: +44141-5483420<br><br>> HPC System Administrator, ARCHIE-WeSt.<br><br>> University of Strathclyde, John Anderson Building, Glasgow. G4 0NG<br><br>> <br><br>> _______________________________________________<br><br>> gpfsug-discuss mailing list<br><br>> gpfsug-discuss at spectrumscale.org<br><br>> </font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fgpfsug.org-252Fmailman-252Flistinfo-252Fgpfsug-2Ddiscuss-26data-3D02-257C01-257CKevin.Buterbaugh-2540vanderbilt.edu-257Cdd3310fd309b4986f95c08d55cfb5d10-257Cba5a7f39e3be4ab3b45067fa80faecad-257C0-257C1-257C636517157039256068-26sdata-3DjZZV718gaMie92MW43qaxlDl6EQcULdk6FONrXpsP7c-253D-26reserved-3D0&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=7n72wm4bwHfrK-yGlxSHLkVEIq0FDXA7XrPI_pyQq1M&s=1cYF3dt9odnG5zCHjcxMGl9_LbVAVNFrFu1iuv5585U&e="><tt><font size=2>https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fgpfsug.org-252Fmailman-252Flistinfo-252Fgpfsug-2Ddiscuss-26data-3D02-257C01-257CKevin.Buterbaugh-2540vanderbilt.edu-257Cdd3310fd309b4986f95c08d55cfb5d10-257Cba5a7f39e3be4ab3b45067fa80faecad-257C0-257C1-257C636517157039256068-26sdata-3DjZZV718gaMie92MW43qaxlDl6EQcULdk6FONrXpsP7c-253D-26reserved-3D0&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=7n72wm4bwHfrK-yGlxSHLkVEIq0FDXA7XrPI_pyQq1M&s=1cYF3dt9odnG5zCHjcxMGl9_LbVAVNFrFu1iuv5585U&e=</font></tt></a><tt><font size=2><br><br><br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=7n72wm4bwHfrK-yGlxSHLkVEIq0FDXA7XrPI_pyQq1M&s=_puCWAGyopu4m3M7evNjbILg3LkDCmiI9vJN2IG1iBE&e="><tt><font size=2>https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=cvpnBBH0j41aQy0RPiG2xRL_M8mTc1izuQD3_PmtjZ8&m=7n72wm4bwHfrK-yGlxSHLkVEIq0FDXA7XrPI_pyQq1M&s=_puCWAGyopu4m3M7evNjbILg3LkDCmiI9vJN2IG1iBE&e=</font></tt></a><tt><font size=2><br><br></font></tt><br><br><BR>