Date: Mon, 20 Feb 2012 17:05:53 -0500 From: Paul Mather <paul@gromit.dlib.vt.edu> To: freebsd-questions@freebsd.org Subject: Re: One or Four? Message-ID: <FE75F5F7-A679-4F2F-BBE6-AD9E435768B8@gromit.dlib.vt.edu> In-Reply-To: <20120218104914.3811510656DB@hub.freebsd.org> References: <20120218104914.3811510656DB@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 18 Feb 2012 08:39:53, Matthew Seaman = <m.seaman@infracaninophile.co.uk> wrote: > 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. >=20 >> 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. >=20 > 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. >=20 > 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[*]. >=20 > 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. I'm coming into this thread part way through, so maybe this has been = pointed out already, but, if so, I didn't see it. It seems from reading this thread that the focus has been on the running = out of space aspect. Using multiple partitions has a value that goes = beyond that: it can afford extra protection and help enhance security = and even performance. Separate partitions can have different mount = options. (Even in the Linux world they recognise this: the NSA = hardening tips for RHEL 5 = [http://www.nsa.gov/ia/_files/os/redhat/rhel5-pamphlet-i731.pdf] = suggests putting areas with user-writeable directories on = separately-mounted file systems and to use mount options to limit user = access appropriately.) Options like noexec and nosuid may help improve = security. Options like noatime and async may help improve performance. Using multiple partitions is very helpful if you are backing up using = dump. It can also help segregate areas of high file system churn, e.g., = /usr/ports; /usr/obj; /usr/src; etc. I like to keep these on separate = file systems so I can treat them differently to system areas I consider = to be more stable and valuable. > [*] Mostly I prefer ZFS nowadays, which renders this whole argument > moot, as having one common pool of free space is exactly how ZFS = works. I almost always use ZFS-only installs these days, for exactly the = reasons you mention. You get the best of both worlds: pooled storage = (meaning not having to agonize over partition sizes) and fine-grained = control over file sets (meaning being able to tune attributes to enhance = security and performance). Cheers, Paul.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE75F5F7-A679-4F2F-BBE6-AD9E435768B8>