Symbolic link

[AIMC]

Hi,

I want to move /sbin to a separate lvol mounted on /sbin2, how do i go about copying the current directory & symbolicly linking to the new /sbin2 lvol ?

Regards,

Aidan Mc Ardle

[Florian Heigl (new acc) · Accepted solution]

NO DO NOT EVEN THINK OF DOING THAT.

/sbin contains among other things /sbin/sh /sbin/fsck and /sbin/mount - Your system won't survive the next reboot.

If You have a space issue in / there are many other ways to solve it.

[A. Clay Stephenson]

Well, it's rather simple but it may not be very smart.

cd /sbin
find . -print | cpio -ocv > /var/tmp/cpio.dat
mkdir /sbin2
cpio -icvdum < /var/tmp/cpio.dat
cd /
rm -r /sbin
ln -s /sbin2 /sbin


Now, you stand an excellent chance of shooting yourself in the foot. All of the utilities in /sbin are statically linked and are expected to be in the root filesystem. If you mount them to another filesystem, you need the mount commandf to mount them but (oops) the mount command isn't available because the filesystem housing it is mounted.

As long as /sbin2 and /sbin are actually housed in the root filesystem then you should be okay but it that case a hard-link rather than a symbolic link would work. Since you are asking about soft (symbolic) links, you are implying a diffent filesystem. DON'T DO IT.

[A. Clay Stephenson]

Well, it's rather simple but it may not be very smart.

cd /sbin
find . -print | cpio -ocv > /var/tmp/cpio.dat
mkdir /sbin2
cpio -icvdum < /var/tmp/cpio.dat
cd /
rm -r /sbin
ln -s /sbin2 /sbin


Now, you stand an excellent chance of shooting yourself in the foot. All of the utilities in /sbin are statically linked and are expected to be in the root filesystem. If you mount them to another filesystem, you need the mount commandf to mount them but (oops) the mount command isn't available because the filesystem housing it is mounted.

As long as /sbin2 and /sbin are actually housed in the root filesystem then you should be okay but it that case a hard-link rather than a symbolic link would work. Since you are asking about soft (symbolic) links, you are implying a different filesystem. DON'T DO IT.

[AIMC]

So the short answer is don't do it!! I have a space issue in / filesystem & am not 100% sure whats causing it because is 1GB in size but i've noticed sbin is taking up 100MB. Can you suggest anyway of finding out whats taking up the space, i'm using du -ks * to see the following

# du -ks *
8 AUTO
644049 Linux_Distros
0 MANPATH
0 NULL
0 bin
0 cdrom
0 core
16 core.dtwm
100774 data
88 dev
67336 etc
0 home
0 lib
0 lost+found
0 net
0 nohup.out
2418096 opt
100232 sbin
0 sbin2
57616 stand
1007296 tmp
2045512 usr
393600 var

& bdf shows the following

# bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 1024000 1023688 312 100% /
/dev/vg00/lvol1 311296 66120 243312 21% /stand
/dev/vg00/lvol7 6291456 413056 5833128 7% /var
/dev/vg00/lvol8 2924544 2069600 848280 71% /usr
/dev/vg00/lvol6 4096000 1024104 3047968 25% /tmp
/dev/vg00/lvol5 5242880 2443848 2777192 47% /opt
/dev/vg00/lvol4 204800 8432 194848 4% /home
/dev/vg01/lvol1 2048000 117748 1809617 6% /data
/dev/vg02/lvol1 25600000 666798 23374883 3% /Linux_Distros
/dev/vg00/sbin2 1024000 16853 944336 2% /sbin2


Aidan

[Pete Randall]

644049 Linux_Distros

This would seem to have been downloaded into your root file system. Move it someplace more appropriate.


Pete

[AIMC]

Hi,

Linux_Distros has its own lvol in vg02.

Aidan

[A. Clay Stephenson]

Normally about 200GB is an EXTREMELY generous size of /. I would look for files largers than 2MB (or) in the root filesystem.

find / -xdev -type f -size +2000000c

A very common mistake is to do a backup to a regular file rather than a tape device node. You might look in /dev/rmt for any regular files.

[Jeff Schussele]

Hi Aidan,

Run the command this way:

du -akx / | sort -nr | more

The -x keeps the scan IN the filesystem & the reverse sort puts the big hitters up top.

HTH,
Jeff

[Florian Heigl (new acc)]

Please extend Your du command and if You wish, post it.

du -kx | sort -rn | head

This will show You the top disk space hogs in the root filesystem.

The usual way of extending / is to recover from an ignite tape and modify it there.

The only way to do it completely online works *only* if You have a 'relocatable' lv directly after lvol3 and run a mirrored configuration.
---
relocatable: not /stand, not pri swap, not /
nothing that needs contingous allocation.
---
On our systems /home resides in that space for this very reason.
If that is the case You can lvreduce the mirrors on the primary disk, create a unmirrored lv that fills the space, remirror the to-be-moved lv, then drop the other mirror and fill that space, remirror, drop both temporary lvs.
then check that original and mirror PEs of / are contiguous (LE X resides on the same PE of the mirrored disks) and extend the lvol3 and filesystem /.

also, You will have to take care that the /etc/lvmconf/*Z backups don't fill up the / directory and get damaged by it. These should better be moved to a safe place before every step.

Did I mention making backups and being aware that this is a lengthy process?

[Pete Randall]

Sorry, I missed the separate mountpoint for Linux_Distros.

Both your /etc/ and your /sbin/ look to be at least twice normal size. Try drilling down into them with "du -sk /etc/*" and "du -sk /sbin/*"


Pete

[Florian Heigl (new acc)]

I forgot to mention - with the filesystem being completely full the chances are very high that the file that filled it up is still open - do not simply remove what appears to be the problem, first do a
fuser -u to check it can safely be removed, otherwise the space will not become available before the next reboot.

if it's (sometimes happens, e.g. with problems on dld.sl) the file /etc/rc.log, copy it over to /tmp, compress it there and then wipe it using a redirect
> /etc/rc.log

[Gregory Fruth]

Your du output adds up to about 220 MB in /.
Check any "dot" files and directories
in "/" like /.mozilla, /.netscape, etc.
"du *" does not scan those. ("du /.*" is
overkill, because ".*" matches "..")

Also, files in directories which are hidden
under mount points count against your disk
usage. Go to single user mode and
see if there is anything in the directories
/usr, /tmp, etc. before /usr, /tmp, etc. get
mounted to them (from vg00, vg01, etc.)
You'll have to check /usr without the use of
"du" or "find", because they live in /usr.
Once you've checked /usr you can mount /usr
and scan the others with "du" or "find".