lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] /var is 95% full


From: Vadim Zeitlin
Subject: Re: [lmi] /var is 95% full
Date: Wed, 19 Aug 2020 12:23:36 +0200

On Tue, 18 Aug 2020 23:48:04 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> Vadim--It looks like this corporate RHEL server's /var is filling up:
GC> 
GC> $df
GC> Filesystem                        1K-blocks     Used Available Use% Mounted 
on
GC> devtmpfs                            8109384        0   8109384   0% /dev
GC> tmpfs                               8123804        0   8123804   0% /dev/shm
GC> tmpfs                               8123804    28384   8095420   1% /run
GC> tmpfs                               8123804        0   8123804   0% 
/sys/fs/cgroup
GC> /dev/mapper/VolGroup00-lv_root      4184064  1081108   3102956  26% /
GC> /dev/mapper/VolGroup00-lv_usr       8378368  6681140   1697228  80% /usr
GC> /dev/sda1                            999320   232676    697832  26% /boot
GC> /dev/mapper/VolGroup00-lv_var       6805504  6403972    401532  95% /var

 Allocating just ~6.5GB for /var seems rather stingy, I'd recommend giving
it at least 20 on a normal system.

GC> /dev/mapper/VolGroup00-lv_opt       4184064  1763004   2421060  43% /opt
GC> /dev/mapper/VolGroup00-lv_home      2086912  1405344    681568  68% /home
GC> /dev/mapper/VolGroup00-lv_tmp       4184064  1507152   2676912  37% /tmp
GC> /dev/mapper/VolGroup00-lv_var_log   2086912   313536   1773376  16% /var/log

 Using just 2GB for /var/log doesn't seem like much neither, unless space
is really tight.

GC> Apparently this uses LVM. Everything except /boot is XFS. We use
GC> /var/cache to cache DEBs for the debian chroot, which total 2.5 GB.
GC> 
GC> They've given me two little drives. One is consumed by 4-GB partitions
GC> for each of /usr, /var, /opt, and so on. The other, /dev/sdb1 above,
GC> was unformatted, so I parted'd and mkfs.xfs'd it, and mounted it as
GC> /srv/chroot.
GC> 
GC> Is it really trivial and completely safe to resize /var before it
GC> runs out of space, given that I know nothing of LVM?

 LVM is not a problem, I can't type the required lvextend command without
looking up the man page, but it's simple enough and definitely works and is
100% reliable. However I've never done this with XFS partitions (which is
explained by the fact that I must have last used or even seen XFS
partitions in the last century). It is supposed to support this using
xfs_growfs, so it looks like it ought to work.

GC> I think I should just store those DEBs on /dev/sdb1 somewhere.

 Making /var/cache a symlink to some /srv/cache would definitely be even
simpler.

GC> But I figured I'd give you a chance to tell me that LVM makes
GC> everything so easy that I should just resize /var .

 It does make things easy, and it should work with XFS, but as with any
manipulation involving the partitions, it's best to have some backups. You
probably should be able to recover even if something goes wrong with /var,
and extending it keeps things tidier than having symlinks from one
partition to another, but if you absolutely don't want to take any risks
and don't care about the conceptual purity of your filesystem structure,
creating a symlink is simpler and even more totally safe (101%?).

 Regards,
VZ

Attachment: pgpCBtOP3mHZX.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]