On 17/02/2012 22:17, Chuck Swiger wrote:

I thought the installer switched to the one-partition style based on disk size? Whatever. Personally I much prefer using one big partition, even for servers -- this applies to /, /usr, /usr/local, /var -- standard OS level bits, and not to application specific bits like partitions dedicated to RDBMS data areas (particularly if the application needs to write a lot of data). Having /tmp on a separate memory backed fiesystem is important though: if sshd can't create its socket there, then you won't be able to login remotely and fix things.

The reasoning is simple: running out of space in any partition requires expensive sys-admin intervention to fix. The root partition has historically been a particular problem in this regard. Even if it is just log files filling up /var -- sure you can just remove some files, but why would you keep the logs in the first place if they weren't important? Splitting space up into many small pieces means each piece has limited headroom in which to expand. Having effectively one common chunk of free space makes that scenario much less likely[*].

Yes, in principle you can fill up the entire disk like this. However, firstly, on FreeBSD that doesn't actually tend to kill the server entirely, unless the workload is write-heavy (but see the caveat above about application specific partitions) and the system will generally carry on perfectly happily if you can get rid of some files and create space. [Note: this is not true of most OSes -- FreeBSD is particularly good in this regard.] Secondly, typical server grade hardware will have something like 80--120GB for system drives nowadays. FreeBSD + a selection of server applications takes under 5GB. Even allowing for a pretty large load of application data, you're going to have tens of Gb of free space there. Generally your monitoring is going to flag that the disk is filling up well before the space does run out. Yes, I know there are disaster scenarios where the disk fills up in minutes; you're screwed whatever partitioning scheme you use in those cases, just a few seconds slower than in the multiple partitions case.

[*] Mostly I prefer ZFS nowadays, which renders this whole argument moot, as having one common pool of free space is exactly how ZFS works.