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.