The title, of course, suggests a fundamentally flawed endevour. But do hear out my reasons.
I’m uncomfortable with predicting what space on my hd will be used for.
/usr, i know, is bound to be a big directory. So is /home, if i store movies and audacity projects.
Right now, i have a / partition, and a /home partition, and each fills up independently. I’ve pulled my hair out trying to optimize the size of each of these partitions, and no matter what configuration i choose, the ideal scenario would this: a small partition for the OS essentials, ie, ‘/’, and all the remaining space for /home AND /usr. This way, i won’t be in a mess when my /home directory is full and /usr has Gigs of space free, or the other way around; i don’t know which will happen first, if at all.
Not partitioning at all is of course an option, but i wish to keep my /home intact if i do a fresh install…
Can i create the mount point for /usr on one partition, and somehow get my /home directory on that partition (either BESIDE /usr, or under it)? I’m essentially messing with the directory tree, but moving /home around shouldn’t be apocalypse, since (i guess)the files in there aren’t touched by any system process…
In your case, it looks like the ideal scenario would be an LVM based system, so you don’t have to worry about partition sizes. openSUSE setup offers that possibility.
It all depends on what you plan to install on the system. Also what kind of major database you plan to maintain. I suggest if you maintain large data that the data should alway be on it’s on partition or in home somewhere. This allows an OS reinstall or change without touch the data.
Right. Symlink seems useful.
I do understand what /usr/local is about. I do not, however, know how to install programs there from an RPM…
Say /usr has its own partition. Will a system reinstall erase data from this partition too (/usr does have OS-specific files), or do i have to play around with disk partitioning again? And can i symlink /home to a folder on this partition?
25Gs for / is it? Never fills up? Maybe i’m being overly precautious…
Nearly always you have no say in where a RPM installs its files and it cannot be changed because files are expected in particular locations. So /usr/local usually contains third party software or software compiled from source by yourself.
Say /usr has its own partition. Will a system reinstall erase data from this partition too (/usr does have OS-specific files),
Yes a reinstall or upgrade will and should zap /usr, so you don’t put any data there. Hosted data like databases or mail (unless using Maildir which go into user’s home directories) go into /var and web apps go into /srv.
25Gs for / is it? Never fills up? Maybe i’m being overly precautious…
If you know you are going to be hosting a lot of databases or a lot of web content, or create a mail host for the whole company, then you would probably know how to design a bespoke partitioning scheme and not be asking this question. It sounds like you’re just a home user who doesn’t need to worry so much.
Generally when you install you format the root partition. Upgrades and repairs do not.IMO you should not do upgrades it is more trouble then it is worth. If home is on the same partition then it to will be zapped. It is much better for home to have its own partition. As to usr that is where the user installed software goes for the most part. Currently my /usr has 5.9 gig I have installed a couple of largest packages (12.5gig over all on a 20gig partition). Sometimes packages may use /var or even /usr for internal data which may cause root usage to grow. But unless you plan on installing a million mp3 or something I’d not worry too much about it. Just use 20-30 gig and that should be plenty of room for casual usage. You would only need more for very special usage. In any case it is always best to tell serious data applications (mysql, Oracle, VMware, VirtualDisk, etc) to put there data on a partition (mount point) that is not on the root partition. Thus making up grades reinstalles change in OS much much easier.
In LVM, disks are organized in logical volumes which get automatically extended as needed. For example, if /home get filled, it can take some free space from another volume (for example, /usr) automatically. Also a logical volume can include several harddisks. It makes it easy to extend /home, for example, by simply adding a new HD.
While installing openSUSE, you have the choice between ‘partition based’ and ‘LVM based’. The default - using partitions - is suitable for most users. LVM is normally used on servers (often in combination with RAID). It works well on desktop machines, allthough it is seldom necessary. openSUSE setup makes it easier than other distros setups.
There’s some gotcha’s about LVM though. Filesystem barrier’s don’t work with it in place, also 11.2-GM doesn’t seem to like LVM or RAID setups.
Using LVM, you create an area with slices of space, that are allocated between filesystems. But they do not automatically grow, you still assign sizes and need to grow filesystems when they’re short of space, LVM simply makes this easier.
There’s also bind mounts, to splice together filesystems stored in seperate areas, without recourse to “ugly” symlinks.
openSUSE setup makes it easier than other distros setups.
I noticed. The partitioning options during installation are really easy to navigate, and extensive.
There’s also bind mounts, to splice together filesystems stored in seperate areas, without recourse to “ugly” symlinks.
Are these a feature of LVM alone?
You’re actually not right to “optimise” space usage too much, because empty space offers performance for areas where you’re writing, free blocks together can be used avoiding fragmentation. Now whilst I don’t think it’s a good idea to put /home and /usr together, I do have sympathy with having /usr & those big project files in the same partition.
What you can do is have :
/, /tmp, & /var (/home if you insist but makes upgrades harder) together - size over provisioned so it’s mostly empty eg) 2-4 GB.
/home - small & kept empty as possible, 1GB for dotfiles, application config, and browser cache files etc.
Have a huge partition called /big
/usr same physical disk as / (for availability reasons) in /big/usr
In /etc/fstab :
/big/usr /usr auto bind 0 0
Have similar entries for any other data you want to move into the huge partition, after you’ve copied it into /big. You can can have convenience symlinks like ‘audacity’ in $HOME, pointing to a /big/audacity/$USER directory.
If you install with /usr in the /big partition, then in single user mode, you can move all the /usr directories, into a usr subidirectory and alter fstab(5) to mount /big rather than /usr on reboot.
To avoid confusion, I like using Partition Labels and the LABEL=<NAME> method of mounting for non-root filesystems, that can then move from disk to disk.
“Wasting” about 8GB for a spare partition, will prove handy when it comes to upgrade time, you could use it to store disk copy of install DVD in meantime to speed up application installation.
If your disk space is so tight, then it’s likely because you have an older disk, in which case an upgrade to recent disk technology will be good performance & capacity boost, giving you a more useful system.
bind mounts are a general feature that’s been in Linux quite a while (new in 2.4), but aren’t in real UNIX.
I still don’t like humungeous partitions for heavily used stuff though, they mean files are scattered across more disk area, so I prefer breaking projects up, and moving and splicing them later, if space requirements change.
Our posts crossed, I already made the more detailed explanation, before seeing your new question!
As a home user I prefer to keep one large variable partition and that partition is /home. If there are other directories that may grow a lot in size, I use one or another technique (symlink, bind mount) to redirect that to the large variable partition. So far only /usr/local qualifies (I’m a pack rat for software downloads).
Currently I have a 24GB /. I’m not too worried about a future openSUSE release exceeding that limit with lots of programs. By the time that happens, I will have had lots of warning and will have changed my machine and disks by then. I’ve grown / over the years from about 10GB to 16GB and now 24GB. Now and then it’s good to do a complete switchover to a new machine and get a new start.
Now if you are a sysadmin and have servers to maintain and need to cater for future expansion for years and years with minimal downtime, then LVM is a tool for you. But for a home user, LVM means the setup is more brittle, and you have more disks making noise and heat. It’s often better to replace a couple of old small disks with one new large one because of the lower power draw. Give the old disks to a deserving person/machine, use them as external disk backup, make computers for your kids, whatever.
So don’t try to be too smart, KISS; home computers are meant to be enjoyed. Unless you happen to enjoy practising to be a sysadmin, in that case go right ahead with the complexity.
/, /tmp, & /var (/home if you insist but makes upgrades harder) together - size over provisioned so it’s mostly empty eg) 2-4 GB.
/home - small & kept empty as possible, 1GB for dotfiles, application config, and browser cache files etc.
Have a huge partition called /big
/usr same physical disk as / (for availability reasons) in /big/usr
In /etc/fstab :
/big/usr /usr auto bind 0 0
Have similar entries for any other data you want to move into the huge partition, after you’ve copied it into /big. You can can have convenience symlinks like ‘audacity’ in $HOME, pointing to a /big/audacity/$USER directory.
Seems perfect. I’ll be happy.
If you install with /usr in the /big partition, then in single user mode, you can move all the /usr directories, into a usr subidirectory and alter fstab(5) to mount /big rather than /usr on reboot.
Sorry, didn’t quite get that. Super newbie here. This is basically to ensure that installed software goes into /big, is it?
Symlinks, Wikipedia says, are “transparent for most software”. Does this imply that /usr symlinked to another directory won’t mess with the functionality of system applications?
I still don’t like humungeous partitions for heavily used stuff though, they mean files are scattered across more disk area, so I prefer breaking projects up, and moving and splicing them later, if space requirements change.
I’ve heard, though, that the Linux filesystem prevents “fragmenting” of the disk… Nevertheless, it makes more sense for performance and general HD health to have more partitions, right? Thanks for that.
So don’t try to be too smart, KISS; home computers are meant to be enjoyed. Unless you happen to enjoy practising to be a sysadmin, in that case go right ahead with the complexity.
Heh. They are meant to be enjoyed, and i am enjoying myself. Playing around is one of the reasons to jump into Linux joy- you’re not told off like a little child.
Thanks a billion, bunch. I’ll try out robopensuse’s configuration. Be back if i get lost!
/usr same physical disk as / (for availability reasons) in /big/usr
In /etc/fstab :
/big/usr /usr auto bind 0 0
-Is this a symlink, or a blind mount?
-Will installing new packages (say Opera from an RPM) automatically store their bulk into my /big/usr equivalent?
-During initial partition setup, i don’t talk about mounting /usr at all right? So that it (initially) mounts on the same patition as / ? I think robopensuse has already told me this, i’m just not certain…
Glad the info is interesting, it takes a while to type and explain things, so nice when appreciation is shown in response or indeed by the reputation button.
Symlinks, Wikipedia says, are “transparent for most software”. Does this imply that /usr symlinked to another directory won’t mess with the functionality of system applications?
Yes, it should be OK, but a symlink is actually effectively a small file which needs to be read, rather than an entry in kernel memory mount table.
The main compatability issue of moving directories around, is that hard links do not work across filesystem boundaries; hard links are multiple directory entries for the same data file sharing all attributes but the name.
Shows usage of hard & soft links, the hard linked files, have a link count higher than 1. See the mkfs.ext? entries above with link count of 4, and same filesize, each entry is equal.
I’ve heard, though, that the Linux filesystem prevents “fragmenting” of the disk… Nevertheless, it makes more sense for performance and general HD health to have more partitions, right? Thanks for that.
The layout of ext2/3/4 has strategies to mitigate fragmentation, a key part is the minimum free space reservation hence my fist comments on free disk space not being wasted.
Using partitions mean that files have to be stored with certain locality. I try to have commonly used partitions in a “hot area” of disk, with read-mostly & write-heavy areas separated. That allows using a 2nd disk for area like /var & /tmp to benefit from 2 disk arms. Large media files and backup files, are put in seperate huge area. That means /home, /var & /tmp cannot be filled up by mp3, ogg, flv, avi, iso or backup stuff.
Anyway the bind mount extract code is a way of moving the whole of /usr out of / and into a filesystem called /big. Normal mount points would let you store the directory /usr and it’s contents in a separate partition.
bind mounts let you splice partitions together for convenience effectively sharing disk partition allocations.
The extract code, is a bind mount line for file /etc/fstab documented in man pages starting fstab(5). fstab(5) controls filesystem mounting on boot up, so an entry here is needed to make mounts persistent.
/big/usr /usr auto bind 0 0
Means, transparently overlay the /usr directory with contents of /big/usr directory, hiding the any contents of /usr until /big/usr is unmounted from it again.
So one can move an important filesystem like /usr, test it out, and only when happy, unmount the bind mount, raname the original directory and remove the original contents later.
The bind mount, re-arranges the filesystems so their is no way, rpm can access the original /usr directory in /.
Just as you can choose during the installation to have /usr in a seperate partition, you can move /usr out of / later and put it in /big/usr by method shown.
When a pathname is resolved the kernel checks at each level whether it crosses mount points changing devices so you wouldn’t want to have 100’s of them for little used items.
All of options are available to expert during installation, when they chose custom partitioning. It is also possible to get a shell on virtual console and do stuff by hand, but the GUI options are actually flexible enough not to require this.
