Summary: Running out of /usr space

From: Craig Silva <csilva_at_vichealth.vic.gov.au>
Date: Thu, 30 Jan 1997 12:57:34 +1000 ()

As usual thanks for all the help:

Brian O'Connor, Christian Miranda, Pam Woods, Robert
McMillin, Dr. Tom Blinn, Alex Gorbachev, Guy Dallaire, Alan
Rollow, Stephen henry, Lucien Hercaud, Fabio Bossi, Martin
Moore and probably others.

original inquiry:
"I am looking for some suggestions on how best to increase
space in /usr -
df shows 99% used. /usr is on a 1gb disk with / , /var and some swap.

I obviously made the wrong guesses when I partitioned it initially and I
have /var on the same disk with only 16% used.

Further, there is another 2gb disk with 1 gb allocated to /data and
approx 1gb unallocated.

If I redo the disk label and increase the /usr partition at the expense of
the /var do I need to backup/restore /usr AND /var or will /usr survive
the increase in the partition? (it comes first in the
partition table). Are there any gotchas if I reduce the
/var partition? Any tips/hints on this procedure?
As an alternative, what are the politics of linking a
/var/users directory to /usr/users (i.e. moving /usr/users
to /var/users)? Any major problems with this as a solution?
BTW / , /usr and /var are advfs. "


Summary:

1. Good first suggestion was simply - check and delete any
core files lying around.

2. The most popular suggestion was use addvol:

"If you are using AdvFS, you can add the disk portion
unallocated to existing domain.

# addvol [ /dev/free_partition ] [ domain ]
# balance [ domain ]"

Howver to use addvol you need to purchase the PAK license:

"> Thanks for the reply btw - I was reading the documents
and
> it suggested that you needed to add a PAK license if you
> were going to add more than 1 volume to a domain. Any ideas?

Yes that's right, but in the long term the utilities are worth it
(the PAK costs a few hundred dollars, and IMHO advfs isn't worth it
 without the utilities)

Without addvol I guess you are stuck with either

  -house keeping on the /usr partition(netscape cache directories etc) or

  -mounting the new partition, moving data to it(/usr/share /usr/var are
   candidates) and linking(the traditional solution)or

  -backing up the usr partion, redoing the partitions, and
   restoring the data(long term, if you are not going to get addvol
   I would advise this)"



re the partition:

Since you have free space on your /data disk (assuming you've got a 1GB
/data partition, not a 2GB partition with 1GB used), you may be able to make
your life simpler by backing up the /var partition to unused space on the
/data disk, then re-sizing its partition on the shared root disk, then put
it back and then backup /usr to the /data disk, resize its partition on the
root disk, then move it back. It's messy, but it's do-able if you don't
blow it.

You can not just change the partition sizes in the disk label. That doesn't
work.

THE Fastest: Move the most full directories to another partition/disk and
softlink them back to the original location.

Commands: Directory disk space usage: du -sk *
                Soft Link creation: ln -s <location> <link>

None of our file systems current know how to grow into newly available
space, so you will have to backup/restore. Unless you're using AdvFS
for /usr and then you can add the unused partition to the domain with
addvol (if the have the Utilities). The other choice might be to
migrate a large part of /usr to the unused partition. /usr/users
would be a good choice if it is a significant fraction of the space
used in /usr. To do this you would:

1. Create a file system on the unused partition.
2. Move the data.

        mount /dev/whatever /mnt
        cd /usr/users
        tar cf - . | ( cd /mnt ; tar xpf - . )
        umount /mnt
        pwd # to verify you are in /usr/users
        rm -r * # this is why you verify...
        mount /dev/whatever /usr/users

3. Having a backup before this is wise.

If you change the disklabel on this disk, you will have to back up and restore
both /usr and /var, recreating the filesystems in the process. The filesystems
will *not* automatically pick up the change in size of the partitions.

But if you have a free 1GB partition, why not just newfs/mkfdmn on it and
mount it on /usr/users? You can mount filesystems anywhere in the directory
hierarchy--it doesn't have to be at the top level.


On linking:

> As an alternative, what are the politics of linking a
/var/users
> directory to /usr/users (i.e. moving /usr/users to /var/users)? Any
> major problems with this as a solution?

"None, unless you can think of a situation (i.e.,
single-user) where you
might need that space."


"I think that would work too. I personally am in favor of
changing the
home directory entry in the passwd file, but scripts that have the
home directory hard coded will fail. I try to use as few links as
possible. "



---------------------------------------------------------
Craig Silva, Electronic Outreach Program Officer
Victorian Health Promotion Foundation, Melbourne Australia
e-mail: csilva_at_vichealth.vic.gov.au, Tel: 61 3 9345 3211
Post: PO Box 154, Carlton Sth Victoria. 3053. Australia
---------------------------------------------------------
Received on Thu Jan 30 1997 - 03:20:03 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:47 NZDT