Toni Mueller wrote: ... >> It's not getting smaller anytime soon, so if planning ahead is something >> you like to do, I'd probably leave at least 2G for "future growth". > > That's why I asked... any estimates about the growth rate?
not really. Things putt along slowly for a while, then suddenly someone puts decides debugging symbols would make a lot of sense in the libraries, and BOOM...Nick is off to find another disk for his mac68k build machine. A great improvement, no doubt, but not without expected side-effects. Fortunately, my parts pile is wide and deep. I'm not sure, but Xenocara *may* use /usr/obj, that may create a jump in usage if that's true if you don't erase it between base and X compiles (which I would slightly recommend...I tend to think of the builds as "one big project", and don't like deleting stuff mid-way through. But that's me. I don't think that will take you near 2G, however. But I could be wrong. :) ... >> Or, just skip the usr/obj partition... Having been stung a few times by >> over partitioning recently, > > What's "overpartitioning"? ;-) That's when you say, "500M is plenty large for /var, except for this mail archive directory, which could grow really big under some failure conditions", so you create a 100G /var/archive partition and 500M /var partition, then discover that under the OPPOSITE failure conditions, massive amounts of mail ends up in /var/spool. At that point, you realize that splitting off the two partitions sounded good, but instead it just cost you some embarrassing down time and didn't help you in the slightest, AND PROBABLY NEVER WILL (and in fact, I can now think of other failure modes where it could bite me). Should have just put it in one huge /var partition. ... > But a toolset for relocating and resizing file systems, during live > operation if possible, would be really great... although I think this > will be quite hard, if possible at all. Much is possible if you spend enough time and effort and everything is possible if you are willing to redefine success. :) growfs is already there, and very cool. It would be great to have a "shrinkfs" command, but that would be much more difficult (and someone would have to actually do it, and I wouldn't suggest waiting for me). Live file system manipulations are scary, BUT in some cases, you can come respectably close if you understand your system and tools (and practice on non-critical systems). It is also a very good argument for leaving free space on the disk, you can accomplish a lot if you have a little free space. Nick.
