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

Partitioning and symlinks



(I already posted this to the SuSE list, so apologies if you see it twice)

A query/discussion-point for those of you who know their way around
these things --

When you first set up partitions (for /, /usr, /home etc) you won't be
sure how the takeup of space on these will turn out in the long run,
so you make an intelligent guess. Sometimes the partitions you create
will be on the same physical hard drive, sometimes on different HDs.

The usual (and recommended) approach is that a particular partition
on a particular drive will be home to a particular sub-tree: for
instance you may have created /dev/hdb2 to contain /home and then,
when the system boots, /dev/hdb2 gets mounted onto /home.

However, this aproach has the disadvantage that the association
between logical sub-tree and phyical disk-space is, as it were,
carved in stone. If it turns out, for instance, that you under-estimated
the space required for /home, then you have some retructuring to do.

Or, you may find that you encounter a need for an additional sub-tree
for which you don't have space on the partition housing its parent;
nor can you now create a new partition anywhere else which you
could mount. An example of this would be a big package which installs
itelf into (say) /opt, and you haven't got a /opt, have you? There's
no room left in the disk partition which mounts onto /, and you can't
make any more partitions on your existing disks.

An alternative approach (which I first adopted in an emergency arising
for such reasons as in the previous paragraphs) uses symbolic links.

Say there happens to be a lot of space left in the disk partition which
mounts onto /usr/local.

Then you can

  mkdir /usr/local/link_opt
  ***[see below]
  ln -s /usr/local/link_opt /opt

or, if you already had a /opt but you have simply run out of space to
put anything else on it, you insert, at ***, above the lines
  cd /opt
  cp -a * /usr/local/link_opt
  rm -rf *
  cd ..
  rmdir /opt

Taken to its limits, this approach could imply that all you need is
a mount-point under /, within the primary partition that mounts
onto /, for each of the other physical partitions on your hard drives.
Then _every_ other sub-tree of / which you might need can be
_physically_ placed where you like in any of these physical partitions,
given therein it own peculiar name -- like "link_opt" above -- and
_logically_ placed where it should be by means of a symbolic link.
This would (if it worked without problems) be a very flexible solution
to problems arising from ill-judged initial partitioning.

Now, the reason I'm raising it as a query/discussion-point is that
sym-links are not treated entirely in the same way as either sub-tree
which are physically on the same partition or physical partitions
which are mounted onto mount-points.

A simple example of this is the 'ls' command, for which the special
option '-L' is required to "follow" sym-links: for instance, compare
the outputs from the two commands

  ls -l /var/X*/lib

and

  ls -lL /var/X*/lib

Such a difference could, for instance, break some scripts. The big
new package you just installed into /opt (which is really a sym-link
to /usr/local/link_opt) might not work, or not work properly.

'tar' is another command needing a special option ('d') in order to
act as though the sym-link was a real one.

Not being expert in all the details of how sym-links are handled
compared with "ordinary" links, I'd like to hear from people who've
been down this road before, or who know what to watch out for if
you do go down it. It strikes me that the method can be useful, but
needs using with great care. Are there, for instance, directories
for which it hould never be used?

So, over to you!

Best wishes,
Ted.


--------------------------------------------------------------------
E-Mail: (Ted Harding) <Ted.Harding@nessie.mcc.ac.uk>
Date: 10-Aug-99                                       Time: 14:49:51
------------------------------ XFMail ------------------------------


Reply to: