Chris's Wiki :: blog/linux/EverythingInRootFS Commentshttps://utcc.utoronto.ca/~cks/space/blog/linux/EverythingInRootFS?atomcommentsDWiki2017-04-20T04:25:32ZRecent comments in Chris's Wiki :: blog/linux/EverythingInRootFS.By Chris Siebenmann on /blog/linux/EverythingInRootFStag:CSpace:blog/linux/EverythingInRootFS:44a94f7b9d61eaa09f63c3ade9442cb658548f68Chris Siebenmann<div class="wikitext"><p>That's a good question. As far as I know (or can remember), one
big motivation for a separate <code>/boot</code> wasn't just BIOS booting,
it was <a href="https://utcc.utoronto.ca/~cks/space/blog/linux/WhySeparateBootFS">machines where the BIOS couldn't access the whole disk</a>. Rather than squeeze your entire root filesystem
down into what the BIOS could access, you just put a small <code>/boot</code>
in that space and left your root filesystem free to be as big as you
wanted and wherever on the disk you wanted.</p>
<p>Modern machines don't have this problem and haven't for a long time
(the fix apparently dates from 2003), so this isn't a real concern
any more.</p>
</div>2017-04-20T04:25:32ZBy Anon on /blog/linux/EverythingInRootFStag:CSpace:blog/linux/EverythingInRootFS:53adc2424680a45f5974c35f26e341ee44917cc2Anon<div class="wikitext"><p>What about old(er) computers stuck with BIOS booting? Wasn't the whole seperate /boot/ partially there to appease those systems?</p>
</div>2017-04-19T21:38:53ZFrom 193.219.181.217 on /blog/linux/EverythingInRootFStag:CSpace:blog/linux/EverythingInRootFS:127e57bed071ccb3bc32ea719fef5b7531014d72From 193.219.181.217https://nullroute.eu.org/~grawity/<div class="wikitext"><p>Regarding systemd, the only requirement for a separate /usr is that it must be mounted by the initrd/initramfs (most distros already have taken care of that). Separate /var is supported in the normal way.</p>
</div>2015-12-08T14:33:35ZBy John Wiersba on /blog/linux/EverythingInRootFStag:CSpace:blog/linux/EverythingInRootFS:e8f96e6e03a71e5a1ef7efd9bc296150dca42631John Wiersba<div class="wikitext"><p>Chris, I agree with your philosophy here. My machines have encrypted everything (except boot), so boot is a separate partion and everything else is LVM on LUKS. Inside LVM, I have root, swap, and data. The contents of my home directory physically reside under /data. I use symlinks pointing from /home/$ME/* to the locations under /data where those pieces actually live.</p>
</div>2015-10-06T04:44:09ZBy Aaron Toponce on /blog/linux/EverythingInRootFStag:CSpace:blog/linux/EverythingInRootFS:58f03de4ba1faf15e7cdfac4d8d1a26783a83ee1Aaron Toponcehttps://pthree.org<div class="wikitext"><p>Actually, now that I am a bit more careful, "/var/" itself isn't separately mounted, but "/var/www/vhosts/", "/var/log/", and many other subdirs under "/var/" are mounted. Same with "/home/". We have "/home/users/" NFS mounted to many hundreds of systems. Further with "/usr/", where nested dirs are separately mounted, but the root itself isn't.</p>
</div>2015-10-05T17:09:13ZBy Chris Siebenmann on /blog/linux/EverythingInRootFStag:CSpace:blog/linux/EverythingInRootFS:6e72b26a2675335b10ebeaf20efc64939796c660Chris Siebenmann<div class="wikitext"><p>For Linux specifically, separate <code>/usr</code> and I believe separate <code>/var</code>
is explicitly unsupported on any systemd-using distribution. With Ubuntu
following Debian's lead, this will soon include almost all major distros
(RHEL/CentOS 7 is systemd based, new Debian is systemd based, and so
the next Ubuntu LTS will be systemd based). I believe that you can still
push <code>/home</code> into a separate filesystem if you want to, but I don't see
any reason to use <code>/home</code> at all in a large-scale environment; if you
have lots of logins with lots of home directories, you're unlikely to
want them all piled into a single directory.</p>
<p>(Locally we have 126 separate home directory filesystems. Needless to
say, none of them are called '<code>/home</code>'.)</p>
<p>As far as swap goes, Linux kernels at least used to freak out under
memory pressure if you had no swap space at all. Putting in a small swap
area of some sort (partition, file, etc) was (and is) a precautionary
measure against such crippling events.</p>
<p>It is unfortunate that the logs in <code>/var</code> are basically forced to
consume space in the root filesystem. In large scale environments
you have two workarounds: shipping logs into some other log handling
environment (eg Logstash et al) and configuring programs (possibly
including your syslog daemon) to write them to a different location.
Since a large scale environment is unlikely to want to reuse the
standard configuration files for eg Apache, the latter isn't much of a
burden in my opinion.</p>
</div>2015-10-05T16:40:39ZBy Aaron Toponce on /blog/linux/EverythingInRootFStag:CSpace:blog/linux/EverythingInRootFS:68c1b444f32f9a49eb39f54f215ff6a6a360be9fAaron Toponcehttps://pthree.org<div class="wikitext"><p>Hmm. I have had a different experience. I understand your point, but it sounds like you haven't worked in shared hosting environments. Working for an ISP who offers hosting products, having /var/ on a separate mount is absolutely critical. Also, due to the hosting aspect, we need /home/ on its own separate mount as well, which is actually NFS mounted from a NetApp. Basically, in the "enterprise", I find separate /var/, /home/, and even /usr/ mount points to be critical to operation.</p>
<p>With that said, I don't do swap in the enterprise. If I'm running low on RAM, where swap would be needed, I get more RAM. I'll deploy "zram" and "zswap" however, where there are compressed swap spaces in RAM, but I won't do disk-based swap devices. I just don't see the need.</p>
<p>With home systems, however, I'm 100% behind you. I don't do separate partitions or mount points, unless I want ZFS for /home/ and ext4 for everything else. For home systems, also, I'm usually limited by budget, so installing more RAM may not be feasible, so I'll put down a 1GB swap partition on disk. But, I also have SSDs where I can put that swap, and I keep it cleaned out with regularity, so it's not an issue.</p>
</div>2015-10-05T14:16:39Z