> On a Tru64 4.0f system I have 28,000 small files in a single directory,
> which the user insists must stay there, slowly increasing, forever.
Thanks for the many speedy responses. I have a bit more reading to
do before I can take full advantage of all the info, but here's a
brief summary.
(BTW, Fate stepped in and ran the main filesystem out of disk space
for other reasons related to this application, so suddenly we have
the... ahem... opportunity to reconsider a whole lot of things. :-)
General consensus was that it is a very bad idea to let so many files
build up in a single directory, there will be performance problems and
general usage problems e.g. shell globbing and directory search delays,
also issues related to the number of files in the domain (see below),
also that neither the user nor the application developer know what's
good for them, and that I should be careful to make no guarantees
about its impact on performance etc.
However, some people who reported having problems with such large
directories had had over 100,000 files. I guess it's all relative,
and configurable to some extent.
Suggestions for improving and/or understanding the situation included:
-Try to re-organise the files into directories containing <2000 files
-AdvFS might possibly cope better with version 5.x than 4.x
-If all defaults were used, AdvFS will probably do me around 50000 files
-Set up the AdvFS domain to allow for this kind of usage (then restore data)
-mkfdmn man page has info relevant for setting up the domain to cope
-Look into the problem of BMT exhaustion, see list archives and man pages
-Check the LogPgs size
It seems from all this that it is well worth finding out more about
the program/user's requirements before setting up the disk in the
first place, so that such unusual requirements can be accommodated.
If it is possible to extract the info from them at that early stage.
On the other hand, one should expect a very good reason for wanting
so many files to be held in a single directory. Ease of use seems
to be the misapplied goal here, since the ordinary user will be
unable to deal with files in a directory that contains so many files.
After being pointed at a few relevant terms, the manuals and other
resources are starting to look a lot more useful.
Thanks to:
Richard Tame
Alan _at_nabeth
John Venier
Trevor Osatchuk
Damon Gosforth
Alan Ford
Tom Blinn
Stan Horwitz
and apologies if there's anyone I've missed
--
Sue Blake
Received on Fri Jan 25 2002 - 05:53:42 NZDT