Partitioning and symlinks
Hi Folks, (Some of you may have seen this query on the SuSE list a couple of days ago, where I got but one though not useless reply; I had also sent it, I thought, to the debian-user list but do not seem to have received it from that list. Apologies if this makes you see it twice, or even thrice!). 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 approach has the disadvantage that the association between logical sub-tree and physical 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 restructuring 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 itself 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. Or, you have got /opt but there's not enough room. 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 should never be used? So, over to you! Best wishes, Ted. E-Mail: (Ted Harding) [EMAIL PROTECTED] Date: 11-Aug-99 Time: 21:45:20 -- XFMail -- --End of forwarded message- E-Mail: (Ted Harding) [EMAIL PROTECTED] Date: 12-Aug-99 Time: 02:47:10 -- XFMail --
Re: Partitioning and symlinks
On Tue, Aug 10, 1999 at 02:49:51PM +0100, Ted Harding wrote: (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. yes, a problematic area for newbies. Although the advantages of speed (when partitions are split across multiple disks)/ and the oft-quoted reason of not taking the whole system down if the mail spool gets very full etc. make this a good way of doing it. -- ,-. Frankie | Drum'n'Bass tunes and samples. frankie at skunkpussy.dhis.org | http://www.skunkpussy.freeserve.co.uk/ `-' pgpdxxDnyuqAU.pgp Description: PGP signature
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) [EMAIL PROTECTED] Date: 10-Aug-99 Time: 14:49:51 -- XFMail --