Date: Sat, 18 Feb 2012 08:39:53 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: freebsd-questions@freebsd.org Subject: Re: One or Four? Message-ID: <4F3F63D9.7060906@infracaninophile.co.uk> In-Reply-To: <ECC9F8CC-7535-4C82-9F88-358DA3B42D5C@mac.com> References: <4F3ECF23.5000706@fisglobal.com> <ECC9F8CC-7535-4C82-9F88-358DA3B42D5C@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD40A081FE91D6022B98BEFCF
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 17/02/2012 22:17, Chuck Swiger wrote:
> On Feb 17, 2012, at 2:05 PM, Robison, Dave wrote:
>>> We'd like a show of hands to see if folks prefer the "old" style
>>> default with 4 partitions and swap, or the newer iteration with 1
>>> partition and swap.
> For a user/desktop machine, I prefer one root partition. For other
> roles like a server, I prefer multiple partitions which have been
> sized for the intended usage.
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.
Cheers
Matthew
[*] Mostly I prefer ZFS nowadays, which renders this whole argument
moot, as having one common pool of free space is exactly how ZFS works.
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matthew@infracaninophile.co.uk Kent, CT11 9PW
--------------enigD40A081FE91D6022B98BEFCF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8/Y+AACgkQ8Mjk52CukIxzJACfV1zzNFl6BiQKSfbAhMTGil7x
zeMAnA56ccb760faxXrJkwDnKXxJ0u9B
=6JM4
-----END PGP SIGNATURE-----
--------------enigD40A081FE91D6022B98BEFCF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3F63D9.7060906>