Ken Moffat wrote: > I think we are all following Al in asking the wrong question ;-) > Surely, the first question ought to be "What partitions will suit > _my_ usage ?".
I agree. > In my own builds, /sources is an nfs mount (and it contains in > excess of 20GB : I pruned it last week, but it has source for most > of the packages in BLFS, so that I could test them for 7.5. My own > builds are motly on desktops, and in general I have the following as > separate filesystems : /, /boot, /home and swap. I _only_ use LFS, > so I need at least two partitions which can be used for '/', and I > also allocate my remaining space [ modern disks are stupidly big for > desktop users ] to /scratch which does _not_ get backed up. > > Also, if you have the space in /home, you can keep the sources > there. > > Re the other places mentioned : > > /usr/src : why do anything here ? In BLFS you are recommended to > _not_ build as root (although I do in my scripts) and by default > /usr/src is only writable by root. Similarly, anyone who says that > the kernel tree belongs in /usr/src/linux is living in the distant > past - that idea was obsolete even when I first used linux at the > turn of the millenium. Building newer kernels in ~/ is good. I use /usr/src and mount it as a separate partition. Works for me. > /opt : Sometimes it is useful to keep this separate, but unless you > intend to put TeX or KDE in /opt I would NOT make it separate. Even > if you do intend to use those space-hogs, a bigger '/' [ ideally > with room for TWO versions of /opt ] will make building a newer > version on the current system _much_ easier. If you do separate > /opt, please remember that its programs and libraries will link to > libs in '/lib' and '/usr/lib', so sharing /opt between multiple > systems on the same machine is not usually possible. I don't seem to have a problem reusing programs in /opt. The libs in /lib and /usr/lib seem to be compatible. > Perhaps I should stress that the recommended upgrade path for LFS > is to build a new system. So, if you have /opt as a separate > filesystem for the first LFS you will need a simialr amount of space > for the replacement system. I reuse it. Sometimes I build a new version of a package like KDE. $ ls -ld /opt/kde* lrwxrwxrwx 1 root root 10 Feb 28 12:40 /opt/kde -> kde-4.12.2 drwxr-xr-x 6 root root 4096 Jun 23 2013 /opt/kde-4.10.3 drwxr-xr-x 6 root root 4096 Aug 26 2013 /opt/kde-4.11.0 drwxr-xr-x 6 root root 4096 Oct 24 06:53 /opt/kde-4.11.2 drwxr-xr-x 6 root root 4096 Feb 28 12:52 /opt/kde-4.12.2 > IMHO, far better to make '/' big, with /opt and /usr part of the > root filesystem. But whatever you do, if you keep building LFS or > similar systems you will eventually find that your partitioning no > longer meets your requirements. A rescue CD is essential [ please > let me mention systemrescuecd, even though it uses zsh and is > therefore not always plain-sailing when entering chroot ]. > > /usr : A separate /usr is a very old idea. Useful if you are on a > network where /usr is an nfs mount shared by several machines. I'm > sure there are other use cases, but I can't think of any at the > moment. For most of us, giving /usr on its own filesystem makes no > sense. We still support the capability, although I agree that it's not very common any more. I haven't done it in many years. > /tmp : This is separate ? > ken@ac4tv ~ $mountpoint /tmp > /tmp is not a mountpoint It is for me. $ mountpoint /tmp /tmp is a mountpoint > At one time we used to mount a tmpfs on /tmp, but somewhere along > the way (perhaps between 6.8 and 7.0) we stopped doing that, which > from my POV was a shame. But I cannot see any good reason to give > /tmp its own filesystem. It can prevent a user from running the rest of the system out of space. The reason I did it was because I build in /tmp although that is surely not common. When it is separate, I can adjust the size easily. > swap : yes. The traditional theory was 2 x physical memory, but I > might go with more than that if physical memory is small (e.g. <= > 4GB). On what is now a small disk I would not go overboard with the > swap. swapping is bad. If you need swap, buy more RAM. It's pretty cheap. I don't recall ever needing more than 2G. > /boot : yes, it makes things easier when you upgrade your LFS > syustem by building a fresh system. For me, at the moment I have <3 > MB in /boot/grub, and <5 MB per kernel - and I've got a lot of > those, but they are generally slimmed-down to match my hardware. > Sticking a finger i nthe air, 100MB lookss adequate. I've gone to 200Mb, but I build a lot of kernels. 100M is plenty for most. > For *servers*, some other directories might benefit from having > their own filesystem, it all depends on what you are doing. I've > seen a use-case for separating /var/log, and I myself separate > /var/tmp on my server - I also have other non-standard filesystems > there. That is all a question of what fits best with what you > intend to do. Check. > I used to use 6GB partitions for '/' with /sources separate (nfs), > but my desktop builds increased to cover more of what is in BLFS. I > now use 8GB, but that is not enough for all of the desktop > alternatives, and doesn't give enough space for TeX even on my > normal desktop [ I put TeX in my /sccratch partition, and bind it if > I need to use it, but for a "full-ish" desktop including more than > one DE [ 64-bit ] I guess I would be looking at 12GB for '/' if I > wanted to include TeX. On my server (apache to provide local > copies of the LFS/BLFS books, a postgres database, and separate > filesystems for my backups and for my media files) I am currently > using just over 2.5GB in the rootfs. Sounds abut right. The point here is your original comment. You need to customize for your own situation. If you have no idea, 10G for root, 2G swap and 100M /boot is my recommended starting point. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
