[vox-tech] In Denial About These Hard Drive Problems

[ME]

On Wed, 19 Jun 2002, Richard S. Crawford wrote:
> This afternoon I noticed that my /home partition was expanding 
> again.  Normally when I run df -h it shows /home as being filled to 52% of 
> the available space; this afternoon, though, it was up to 100%.  I was away 
> from my computer and logging in remotely so I didn't want to do anything 
> too drastic.  I just found some wine processes that were running and killed 
> them, then deleted some extra tar files that I'd accumulated, to bring 
> things down to 98% so that my computer could keep running until I could get 
> home and reboot it, which is what stopped this problem before (I never did 
> figure out what was causing it).

How big is this mounted partition and what was using up the space? What
version kernel are you using, and what filesystem type is being used on
this partition and other? What kind of drive is it (IDE/ATAPI or SCSI)

> So when I rebooted, I found some root filesystem errors, fixed them with 
> fsck /.  Then X wouldn't start.  I checked the message log and saw this error:
> 
>          fatal error: could not open default font fixed
> 
> (or something like that).
> 
> Fearing nasty trouble, I decided I'd take the simpleton's way out and just 
> repair things from my installation disk.  That process complained because 
> I'd created a symbolic link to /var on a large extra partition on my hard 
> drive (it wanted me to transform the absolute symbolic link /var to a 
> relative symbolic link -- something that is outside my realm of knowledge, 
> I'm afraid, though I did try to find it in my books).

With sym links there are a few. For filesystems, they are *sort of* like
shortcuts in Windowsland (even though they are not really) and aliases in
Mac land (closer then windows land with MacOS 9 and earlier but still not
quite the same).

There are "links" to files and "symbolic links" to files

Lnks to files are much like pointers to space on a hard disk. Each pointer
uses up an "entry" on your partition's filesystem, but does not double the
size of space used by the file. 5 "hard" links to the same data (or
original file) on the same mounted filesystem/partition lead to only one
copy of that file on disk with 5 "pointers" to it. The file is not
actually deleted unless all of the links to the file are destroyed. When
the last link is destroyed, then the filesystem "forgets" where the file
was located even though the physical data is often still on disk (depends
on filesystem and settings though.)

Making hard links to folders/directories require root access and is
generally considered a "bad idea" due to risks with recursion/looping

symbolic links are not "hard links" to file. They are kind of like
redirection. A symbolic link to a file may exist even after the file it
was pointing at is deleted. This is sort of like an "alias" in a
shell. If you alias "ls" to be "ls -CF", then the alias still exists even
if "ls" is deleted. Of course, your alias (ls) will fail to run as
as "desired", but that is the way it goes. Symbolic links may span
filesystems and pass across network shares (big plus) and generally
should not cause problems to recursive directory searches (when a dir is
symlinked) unless you employ lesser known args to certain commands and
tel them to follow symlink as though they were real links (duhhhh... heh
heh).

In the world of sym links there are two common types:
relative
absolute

Borrowing from the world of HTML and web pages, you can see a very close
match.

Say you have /var/www as your server root and within it you have a file
"myimage.jpg" and another directory called "dir" and in "dir" you have a
file "index.html".
>From /var/www/dir/index.html you have an entry like:
<img src="/myimage.jpg"> you are using an absolute ref to the file.
(You are specifying the href path from the "/" root)
if instead you have:
<img src="../myimage.jpg"> you are using a relative link as you are
stating where that file can be found "relative" to the directory of the
html file (/var/www/dir/index.html)

A *huge* advantage of using relative paths when creating web content is it
makes the content portable within a tree. Using relative links, you could
take the entire root folder and copy it to dir/dir/dir and it would still
work and allow you to make a new file in /var/www/dir called index.html

in as much
ln -s /var/log/apache /etc/apache/logs
is an absolute symbolic link
while
cd /etc/apache
ln -s ../../var/log/apache logs
is a relative link

The advantage here is that a relative link works better if you should ever
want to work on a chroot-ed env without being ch-rooted in it. If a
chrooted env uses absolute sym links and is in /usr/export/chroot1 then
the link in /usr/export/chroot1/etc/apache/logs that points with an
absolute path to "/var/log/apache" will point to the "real /" not the
chrooted "/" (/usr/export/chroot1) while a relative symlink path of
"../../var/log/apache from /usr/export/chroot/etc/logs will work when
chrooted in the chroot1 dir or in the "real /".

cool tools in debian land for this:
symlinks (convert all absolute links into relative ones)
link (delete dangling symlinks - use with care and at risk!)

(I seem to recall warning people about using symlinks like this, and only
use it as a temporary "patch" but do the "right thing" and get a different
partition for it. not an "I told you so", more of, "another reason to
use separate real mounted partition")

> I decided I'd simply move the files in /var back to the root partition.  I 
> tried to start this process by creating a temporary directory in / with the 
> command,
> 
>          # mkdir /var2
> 
> ...to which I got this error:
> 
>          could not create directory /var2.  Input output error.

Strange error. Did you make sure your filesystems were mounted with rw
access? You made sure there was no /var2 folder/file too right? If you
were doing this work from a rescue disk, they often mount filesystems ro
(read only) but can be mounted with "rw" access as root by 
# mount -t fstype -o remount,rw /path/to/mount/point
like
# mount -t ext2 -o remount,rw /
for root

> ...and that just seems terrifying to me.

But there must be a good reason. Follow your nose. See where it leads.

> I'm running a Red Hat 7.2 system, not quite brave enough to do a full 
> reinstall of Linux (though I might just do that, after copying all of my 
> documents to a CD).
> 
> I hope I've provided enough information.  What else could I be doing?

There are many things to examine. Try going through the above and answer
some of the Q's posed. Others will undoubtedly have other ideas.

When you copy stuff to the newly mounted volume/space make sure to use:
# cp -aR /src /dst
if there are any device special files. (I often use this to be safe)
if you are not sure if there are any device special files (fifo, char,
block etc) then you can use the:
# cp -ar /src /dst

Hope this helps, but if it does not, let's keep going.
-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