From owner-freebsd-current@FreeBSD.ORG Thu Nov 24 12:31:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58E10106566C for ; Thu, 24 Nov 2011 12:31:54 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 117A18FC13 for ; Thu, 24 Nov 2011 12:31:53 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RTYT2-0002Xf-4y>; Thu, 24 Nov 2011 13:31:52 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RTYT2-0004NS-2m>; Thu, 24 Nov 2011 13:31:52 +0100 Message-ID: <4ECE3937.5060201@mail.zedat.fu-berlin.de> Date: Thu, 24 Nov 2011 13:31:51 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: krad References: <20111122080542.5c993efe@zelda.sugioarto.com> <20111122103043.82377106564A@hub.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 X-Mailman-Approved-At: Thu, 24 Nov 2011 12:56:43 +0000 Cc: David Cornejo , freebsd-current@freebsd.org, "C. P. Ghost" Subject: Re: /usr/home vs /home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 12:31:54 -0000 On 11/24/11 10:42, krad wrote: > On 22 November 2011 13:36, C. P. Ghost wrote: > >> On Tue, Nov 22, 2011 at 11:30 AM, <"Thomas Mueller >> wrote: >>> But I don't see any advantage to putting /, /usr, and /var on separate >> partitions. >>> >>> Tom >> >> Regarding separate /usr and /var: the advantage is that you can >> keep /usr read-only which is also important for security reasons >> since modifying system binaries becomes less easy. >> >> Furthermore, you can NFS share a read-only /usr among many >> similar machines, while /var is a per-machine specific read-write >> area. >> >> -cpghost. >> >> -- >> Cordula's Web. http://www.cordula.ws/ >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > > I always have /var and /tmp on separate file systems than /, but dont > normally have a separate /usr, bur I have a /usr/local. > > I like to keep the /var and /tmp fs separate as they as other are > mentioned. Therefore they are more prone to corruption in event of the > power failure. Keeping / separate in this case should make the system more > likely to reboot. Also it stops application filling up / which can stop you > logging into the system (I havent seen this issue for year admittedly) > > /usr/local is just for tidyness as it keeps base os separate from ports etc > > I also have /home on a separate as well to stops users filling up root as > well. > > my zfsroot boxes have this setup as well, but i also add a few reservations > and quotas. For my experiences in the past with OpenLDAP, which keeps its databases by default in /var, I had a lot of inconsistencies triggered due to the port OpenLDAP itself or DB4. I do not care about who caused the inconsistency, but after a reboot, the /var filesystem had to be fsck'ed or was completely trunkated and needed to be reformatted. If this happens to /var when /var is a part of / as a whole, then good night ... ;-) Sorry for the sloppy statement. I'd like to know how many big-company-server systems do have separated partitions and a lucky to have an easy way to repair in compare to home users with their home boxes using a linux like whole one partition ... and compared to that the failures and times to repair the filesystem. Regards, Oliver