Date: Fri, 17 Feb 2012 15:55:49 -0800 From: Chuck Swiger <cswiger@mac.com> To: Devin Teske <Devin.Teske@fisglobal.com> Cc: FreeBSD - <freebsd-questions@freebsd.org> Subject: Re: One or Four? Message-ID: <290E977C-E361-4C7D-8F1E-C1D6D03BAD63@mac.com> In-Reply-To: <021101ccedc9$89445cf0$9bcd16d0$@fisglobal.com> References: <4F3ECF23.5000706@fisglobal.com> <20120217234623.cf7e169c.freebsd@edvax.de> <20120217225329.GB30014@gizmo.acns.msu.edu> <021101ccedc9$89445cf0$9bcd16d0$@fisglobal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 17, 2012, at 3:11 PM, Devin Teske wrote: > a. A security issue > > /tmp is by-default out-of-the-box world-writable (perms 1777). Yes. It works as intended even when /tmp is part of a single root partition; although mounting /tmp as a RAM- or swap-based tmpfs filesystem might be better for many situations. > Making this world-writable bucket part of "/" seems silly both for Desktops and Servers alike. You're welcome to your opinion. However, I suspect you're expecting FreeBSD systems to always be partitioned and administered by knowledgeable BSD Unix sysadmins, and those are not always so readily available as one might assume. > b. A nuisance > > As "Da Rock" points out, ... recovering your system from a > file-system-full-event when using "single-/" is just as difficult regardless of > Desktop versus Server. Having "/tmp" alleviates the difficulty. It would if /tmp was mounted on a disk partition, and if it also happened to be where space was being consumed. /var/log and /home tend to be more likely locations in my experience, but YMMV. > c. A performance issue > > I'm surprised nobody has pointed out the physical performance limitations of > rotating disks with respect to physical location of partitions on the spindle. > Granted, seek times are light years beyond what they used to be, but allocating > smaller "swap" and "tmp" partitions close to the center of the spindle is a > performance-enhancing setup just as much as it is for protecting against > file-system-full problems (security events included). I suggest you do some measurements; starting with diskinfo -t, or something like HDTach for Windows: http://en.wikipedia.org/wiki/File:HD_Tach_Hitachi_HTS541616J9S_SB40-screenshot.png It's very typical for the outermost tracks of a disk drive to be up to twice as fast as the innermost tracks due to the greater amount of data available per cylinder on the outer tracks. These outer tracks are most often given LBA 0, and the drive writes data inwards with higher LBA #'s. [ If performance is especially critical, folks will partition the disks so that they only use the outermost third or so of the disk, to maximize read/write performance and minimize seeking; this is known as "short stroking" a disk... ] > I'd argue that there should never be a single-"/" unless you are prepared to > deal with a truly 100%-full filesystem problem (especially considering that > Desktop users whom select the default-everything are often not skilled enough to > deal with that situation). If someone truly wants a single "/" and nothing else, > there's manual partitioning (which should prove pretty easy in the event that > you're only creating one partition and nothing else). More sophisticated partition schemes certainly can have value in terms of better isolation from unexpected logfile growth (etc), a separation of OS-provided files from user content, a separation of stuff which doesn't change often versus stuff that does, and so forth. However, for whatever reasons, the overwhelming majority of folks using MacOS X don't have problems using a single root partition, and while they sometimes do fill up their disks, that's a situation which they should be able to recover from without needing expert assistance. I don't recall having unusual issues in running a partition out of space under FreeBSD, either, or difficulty fixing things afterwards-- but such doesn't happen very often if you monitor your systems properly, and have time to respond to "low-space" conditions before they turn into "out of space" conditions. Regards, -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?290E977C-E361-4C7D-8F1E-C1D6D03BAD63>