You're spot-on with the qtree comment;
there is only one directory in the qtree. I also agree that the flat
structure is a bad idea. Unfortunately, that's the way this particular
application likes to store its files (boo!). Sounds like I'll need
to beat up on the app owner to see what we can do about creating additional
depot directories to thin things out a bit.
However, it's good to know that we can
move this up and down as we need to (...and hopefully don't need to). Thanks
for the info.
Jeff Mery - MCSE, MCP
National Instruments
-------------------------------------------------------------------------
"Allow me to extol the virtues of the Net Fairy, and of all the fantastic
dorks that make the nice packets go from here to there. Amen."
TB - Penny Arcade
-------------------------------------------------------------------------
Chris Thompson <cet1@cus.cam.ac.uk> Sent by: owner-toasters@mathworks.com
05/22/2007 03:48 PM
To
toasters@mathworks.com
cc
Subject
Re: Maxdirsize
jeff.mery@ni.com (Jeff Mery) asks
>
> On a related note to the conversation below - What's the impact to
> increasing maxdirsize on a given volume? We have a qtree approaching
the
> limit for its volume. Does maxdirsize function like maxfiles/inodes?
Not really. maxdirsize can be altered up or down at any time. It's a safety
limit on the size of any individual directory. What hurts the system (often
quite badly) is actually having directories that big (maxdirsize defaults
to 1% of the filer's memory size). Putting it back down will not cause
an
overlarge directory to shrink (although it will stop it getting any larger).
"A qtree approaching the limit for its volume" doesn't sound
relevant here
unless you have only one directory in the qtree, i.e. a completely flat
naming scheme. That certainly isn't a good idea.