On Sun, Mar 30, 2014 at 11:31:59PM +0200, Aleksandar Kuktin wrote: > >On Sun, 30 Mar 2014 14:05:50 -0700 > >Al Szymanski <a...@mac.com> wrote: > > > > I am just trying to figure out the overall smallest size of hard > > drive space needed for all of the partitions. My sums from the 7.5 > > book come to 80 Gig plus whatever space I want for /home . > > > [ suggested partition sizes: > > root LFS 10Gig > > /usr/src 30-50Gig > > /opt 5-10Gig > > /usr 5Gig > > /tmp <5Gig > > swap 2xRAM > > /boot 100Meg > > =~81Gig ] > > Are these numbers your own estimates, or did you pick them up > somewhere? I'm asking because they overestimate. In particular, the line > for /usr/src seems way too big. My own tarball dir (which cotains > everything I build) is 2.7 GB, almost ten times smaller that your low > estimate. >
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 ?". 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. /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. 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. 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. /tmp : This is separate ? ken@ac4tv ~ $mountpoint /tmp /tmp is not 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. 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. /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. 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. 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. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
