[vox-tech] My Wayward RH Box

[ME]

On Tue, 23 Apr 2002, Richard S. Crawford wrote:
[chop]
> I deactivated the screen saver, and simply left it on "blank screen". 
> That appears to have helped.
[chop]

That was a known problem (mentioned before). Just setting a screensaver
seems to be one of the "fixes". Use of blank screen is a good, low CPU
consuming choice.

> Also, executing df -h indicates that the root filesystem was at 100%
> capacity.  I removed a few minor rpm's that I didn't need, and am now at
> 99% capacity; I need to figure out how to increase the size of the root
> partition, or move some more files off that partition and onto another
> monster unused partition that I have set up.
[chop]

Partitions that tend to use up a lot of space and are mostly safe for
re-allocation:
/usr ( A *huge* user in many systems )
/home (A good idea so that you can clobber all other partitions in an
       upgrade but keep your user stuff safe)
/usr/local (I like to install my own packaged here and my own src trees
 here, separate from the distro's install and then change the search path
 to include /usr/local/bin and /usr/local/sbin before /usr/bin and
 /usr/sbin. If you do not use this system , then /usr/local will likely
 not be a filesystem to move and help with your root fs being full.)
/tmp (not much help in having this be off "/" but insulates you if you
 have users who want to use gimp and use /tmp for their images or cdrom
 ISO for burning.)
/var ( a good one to relocate to another partition / mounted-volume as it
 often contains your web stuff (default in many instances /var/www) and
 your log files (/var/log) and you dont want a runaway daemon spewing
 fourth jibberish to fill up your root partition.
/var/log even better to give /var/log its own place after you have a
 separate place for /var so the logging services wont impact your web
 users

Brief (for me) steps on moving data to new partitions...
Partition new space (on a new disk, or existing free space)

(Broken to 2 choices.
The first one is long, time consuming and is the "right" way. (Opinion) 
The second one is a short "hack" or "patch" that can be used, but is not
an ideal solution. It is of course shorter, but not as well liked unless
you are in an emergency and need to ave the least downtime and can do it
"right" later when you can schedule down-time for the server.
)

You can use other filesystems if your kernel has support for them - make
sure they are compiled as part of the kernel - not as a module. This is
really critical for the "/" volume

Let us assume it is /deb/hdd1 (a second Hard disk on an IDE/ATAPI
interface that is on the secondary bus and is a slave, and its first
partition)

(Side note: Primary IDE/ATAP Master = /dev/hdaN where /dev/hda is the
whole device, and if a number is where "N" is, that describeds the
partition (1-4 = primary while 5+ extended partitions of a Primary
partition.) and then /dev/hdbN is primary slave, /dev/hdcN is secondary
master, and /dev/hddN secondary slave. SCSI would be /dev/sdaN,
/dev/sdbN, /dev/sdcN, /dev/sddN, /dev/sdeN  with "s" = SCSI, "d"=disk,
(letter, "a", "b", "c"..) based on SCSI ID, and "N" same as hda... series
above)

Format the partition (the deletes all data on that partition)
# mkfs -t ext2 /dev/hdd1
This assumes you are formatting with ext2. If you are more advanced, note
that reiserfs and ext3 have more features that many consider better. There
are also other filesystems available too. ext2 is just one of the easier
ones to setup as it is older supported and still popular.)

Create a mount point (Say we are going to move /usr tree to the newly
mounted partition, let's call this one /usr2)
# mkdir /usr2

Now mount the partition to the mount point:
# mount -t ext2 /dev/hdd1 /usr2

Now copy all of the stuff from the old /usr tree to the new /usr2 tree. It
is not a simple copy, because you want to make sure all of the information
(ownership privs) is copied over and that you do a recursive copy.
# cp -aR /usr/* /usr2/

This will take a while. The -a flag does an archive copy to maintain
ownership and privs. The -R does a recursive and is different from a -r in
that the -R can better handle device special files (fifos, named pipes,
block special devices, character special devices, etc.) It is unlikely
that you would have such a device special file in /usr (outside of
/dev) but is still possible.

(At this point, you may want to boot your machine in Single user mode, or
kill all daemons in multiusermode and force all users to log out. You
want nothing with open files in the /usr tree or umount of it will fail.)

After the system finishes doing the copy, you should be able to:
# sync
(not really necessary, but I thinit is safer)
# umount /usr2
# mv /usr2 /usr
# mv /usr /usr.bak
# mount -t ext2 /dev/hdd1 /usr

But you are not done yet!

Now you should edit /etc/fstab
(sample of before with a monolithic filesystem, proc and a swap)

# /etc/fstab: static file system information.
#
# <fs>   <mp>     <type> <options>                             <d><p>
/dev/hda3 /        ext2   defaults,errors=remount-ro,usrquota   0  1
/dev/hda2 none     swap   sw                                    0  0
proc      /proc    proc   defaults                              0  0

(The "usrquota" is when you are using user based quotas. It will not be in
most systems. Do not worry too much if yours does not look exactly like
the above. Just note the changes with the one below.)

And then after and entry for /usr is added (sample)
# /etc/fstab: static file system information.
#
# <fs>   <mp>     <type> <options>                             <d><p>
/dev/hda3 /        ext2   defaults,errors=remount-ro,usrquota   0  1
/dev/hda2 none     swap   sw                                    0  0
/dev/hdd1 /usr     ext2   defaults,rw                           0  2
proc      /proc    proc   defaults                              0  0

After you save this, you should test it:
# umount /usr

# df

(You should not see /usr listed)

# mount /usr

# df

(You should see /usr listed)

You can also compare size / used space (which chould be close but not
always exactly the same.:)
# du -s /usr.bak
# du -s /usr
both should be very close

Also, maybe compare # files:
# ls -laR /usr.bak | wc
# ls -laR /usr | wc

Numbers reported should be very close but not always exactly the same.

If you want, you can reboot, but that should not be necessary. If you were
in Single user mode, then a reboot would be a good idea to make sure all
of your services startup as they should.

You can backup /usr.bak to take or elsewhere if you want to be safe before
the next step.

Now, what I would do next, is to try your system for a few days
(weeks?) and see how it works. If you are satisfied that it is happy, you
can
# rm -rf /usr.bak
and reclaim that space

Part 2:

As a *cheat* (I don't suggest this route as it is not the "right" way to
do things...)

If you have /home as a BIG volume not being used by musch with lots of
free space, you can
# mkdir /home/usr
# cp -aR /usr/* /home/usr/
# mv /usr /usr.bak
# ln -s /home/usr /usr

You still should make sure no daemons or users are using anything is /usr
when you go to move it and then symlink to /home/usr from it.

Hope this helps...


-ME

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html