2

We have plenty of space on a different mounted device. Since the /var partition stays relatively static in terms of size (around 8-10GB because of big logs that we need), I'd be fairly happy to simply make our current /var space 65% full rather than 75%. In other words, we don't need to move much. Here's a snapshot of what's in there now:

4.0K    ./account
119M    ./cache
0       ./clamd
292M    ./cpanel
8.0K    ./crash
12M     ./csectsh
528M    ./data
16K     ./db
16K     ./empty
6.1G    ./lib
4.0K    ./local
24K     ./lock
1003M   ./log
16K     ./lost+found 
0       ./mail 
120K    ./named
4.0K    ./nis
4.0K    ./opt
8.0K    ./portsentry
20M     ./pravda
4.0K    ./preserve
84K     ./profiles
236K    ./run
115M    ./spool
470M    ./tmp
4.0K    ./yp

We just repartitioned a bunch of stuff on our production server, so I don't really feel like scheduling more downtime, especially since I believe we have an SLA with a client. I know that many of these files' parent processes would have a problem with sym links, but I'm far from an expert, as this is an inherited system. Does anybody know any sure bets for things that can move?

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
grepperschlepper
  • 135
  • 4

3 Answers3

3

I'd strongly suggest not symlinking, but using bind mounts instead.

That way the space is distinctly trackable rather than it being more wishy-washy as it is with symlinking.

http://aplawrence.com/Linux/mount_bind.html has a good intro to bind mounts.

warren
  • 18,369
  • 23
  • 84
  • 135
2

You probably have MySQL in /var/lib - move it to a different mount or set up a new disk for it. You can either symlink it or change the MySQL configuration.

pauska
  • 19,620
  • 5
  • 57
  • 75
  • I was going to suggest the same thing. We do this on a number of our servers as our database hd footprint has expanded. +1 – Kyle Buser Oct 05 '10 at 18:01
1

What is in ./data? That is not a standard directory and looks like a good candidate. I would also suggest you dig deeper into ./lib. Something in there is taking up a lot of space and may be up for deletion or a move.

Zoredache
  • 130,897
  • 41
  • 276
  • 420