Hacker News Reader

Comment by rosser | Hacker News Reader

If this proposal ends up being widely adopted, you're only losing the ability to keep /usr on its own filesystem. You still can (and very much should) keep /var and /tmp on dedicated volumes. (And should probably also symlink /var/tmp to /tmp, so that you don't have a world-writable directory on the filesystem you want to keep safe for writing logs to...)

View on HN

Given today's disk capacities it rarely makes sense to create any partitions whatsoever within a disk other than for swap. Partitioning /usr, /var or anything else on the same disk only increases the chances of one or more partitions filling. Admins and OSs who create inter-disk partitions without an explicit need are operating on legacy superstition.

If /tmp fills up, things start mysteriously not working (a surprising number of things create temp files, including things you wouldn't expect to), so it needs to be on a partition that won't fill up. I usually put it in its own partition, so that accidentally filling up / won't bring cause mysterious problems.

/var should go on a separate partition so that the log files don't fill up the partition that /tmp is on. A server can easily generate large log files quickly, and it would be unfortunate if that caused the server to fail in weird ways at inconvenient times.

> If /tmp fills up ... so it needs to be on a partition

Makes no logical sense. When you create an (inter-disk) partition you reduce the blocks available to all remaining partitions on that disk. By reducing partition size you _increase_ the probability of all remaining partitions filling.

If you had said adding disks for /tmp and /var were indicated I might agree, but would still be wondering what kind of applications you have.

Looking back at Unix' history we see that partitioning was only added before RAID and only to accommodate additional disks. It is the failure to understand this history and rational that leads certain sysadmins to believe that inter-disk partitions accomplish anything other than reducing robustness (in absence of a badly behaved application, which is 99% of the time a badly configured server or application, per the log rotation example).

Partitioning has some security and performance gains. Different filesystems for different workload (e.g. perhaps xfs for database files and reisterfs for /tmp), mounting with noexec or ro in some cases.

'Nix allows mounts at any arbitrary point in the filesystem hierarchy. While you could symlink /var/tmp to /tmp, you could also dedicate a filesystem to it. Given that the strict definitions differ (/var/tmp does persist across reboots, /tmp may persist), you risk annoying/disapointing someone at some point if you do otherwise.

I am sure I have used systems with tmpfs /var/tmp.

In that case they were not FHS compliant.

Except that /usr is where /usr/local lives (all software installed through the FreeBSD ports tree) and I don't want that on my / partition, so now I have to create a partition just for /usr/local? How about the various other files under /usr, they now have to be moved to / as well? On FreeBSD /usr also houses /usr/home. /home/ is a symlink to /usr/home!

/ on a FreeBSD system is generally kept small. It doesn't have softupdates on when using UFS2 since it is also the location where your kernel lives, along with rescue utilities and your main /bin. Nothing else.

The proposal as put forth is misguided (talking about Fedora's in this case) and I don't think that the system should be re-engineered just because that is the default use case these days. I remember when I first started using Linux and I created a separate, /boot, /, /usr, /home, and /tmp. Just because udev and others now fail to work correctly doesn't mean it isn't a good idea to keep those separate...

This is just going to cause more trouble, more fragmentation between unix/unix-like systems and Linux and it's various distributions.

You can make a good case that /usr/local should be separate from /usr, where as /usr belongs on the same partition/slice as / on FreeBSD. /usr is the whole system as maintained by FreeBSD, where as /usr/local is where your ports are installed. /usr is going to grow slowly, /usr/local could get huge. Separate /usr/local out from /usr on a different disk.

FreeBSD recommends softupdates on all filesystems, including /.

Also, the LSB doesn't really apply much to the BSD's.

The defaults for FreeBSD are / as UFS2 with no softupdates, see picture 2-19 in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/in... for an example.

It has been a few months since I had to administer a FreeBSD machine, but personally since at least FreeBSD 7 I have had softupdates on on /.

The installer may still not have softupdates on, but the installer is very very conservative about defaults, and probably hasn't changed since, well ever. However, from the handbook http://www.freebsd.org/doc/en/books/faq/disks.html#SAFE-SOFT...

"9.4. Which partitions can safely use Soft Updates? I have heard that Soft Updates on / can cause problems.

Short answer: you can usually use Soft Updates safely on all partitions.

Long answer: There used to be some concern over using Soft Updates on the root partition. ..."

Under the proposal, you can still keep /usr on it's own read-only filesystem. The difference is that it has to mounted in single-user mode.

Reply on news.ycombinator.com