<span style=" font-size:10pt;font-family:sans-serif">There is no single
"optimal" number of files per directory.</span><br><br><span style=" font-size:10pt;font-family:sans-serif">GPFS can handle
millions of files in a directory, rather efficiently. It uses fairly
modern extensible hashing and caching techniques that makes lookup, insertions
and deletions go fast. But of course, reading or "listing"
all directory entries is going to require reading all the disk sectors
that contain the directory...</span><br><br><span style=" font-size:10pt;font-family:sans-serif">"during system
remount... restarting the system" -- NO! There is no relation
between directory sizes and mount and startup times... </span><br><span style=" font-size:10pt;font-family:sans-serif">If you are experiencing
long mount times, something else is happening. IF restart is after
a crash of some kind, then it is possible GPFS may need to process many
log entries -- but that would be proportional to the number of directory
updates "in flight" at the time of the crash...<br></span><br><span style=" font-size:10pt;font-family:sans-serif">Having said that
there are some changeover conditions in the way directories are stored,
as one adds more and more entries. Since directory entries are of
variable size, varying with the size of the file names, the exact numbers
depend on file name length, inode size and (meta)data block size:</span><br><br><span style=" font-size:10pt;font-family:sans-serif">A) All directory
entries fit in the directory inode. Best performance! But
I do not recommend deliberately changing apps to avoid spilling to ...</span><br><br><span style=" font-size:10pt;font-family:sans-serif">B) All directory
entries fit in one metadata block. </span><br><br><span style=" font-size:10pt;font-family:sans-serif">C) Directory entries
are spread over several blocks.</span><br><br><span style=" font-size:10pt;font-family:sans-serif">You can determine
how much storage a directory is using by a `stat /path` command or equivalent.</span><br><br><br><img align=left src=cid:_1_11A4710011A46CF0004D374585258305 alt="Marc A Kaplan" style="border:0px solid;"><br><br><br><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"Michael
Dutchak" <Michael.Dutchak@ibm.com></span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">gpfsug-discuss@spectrumscale.org</span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">09/11/2018
09:21 AM</span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">[gpfsug-discuss]
Optimal range on inode count for a single folder</span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">gpfsug-discuss-bounces@spectrumscale.org</span><br><hr noshade><br><br><br><tt><span style=" font-size:10pt">I would like to find out what the
limitation, or optimal range on inode <br>count for a single folder is in GPFS. We have several users that
have <br>caused issues with our current files system by adding up to a million <br>small files (1 ~ 40k) to a single directory. This causes issues during
<br>system remount where restarting the system can take excessive amounts of
<br>time.</span></tt><br><tt><span style=" font-size:10pt">_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></span></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><span style=" font-size:10pt">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</span></tt></a><tt><span style=" font-size:10pt"><br></span></tt><br><br><BR>