From owner-freebsd-questions@FreeBSD.ORG Sat Feb 18 10:49:02 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88EBC1065673 for ; Sat, 18 Feb 2012 10:49:02 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0E18FC0A for ; Sat, 18 Feb 2012 10:49:01 +0000 (UTC) Received: from mail.unitedinsong.com.au (bell.herveybayaustralia.com.au [192.168.0.40]) by mail.unitedinsong.com.au (Postfix) with ESMTP id 993725C28 for ; Sat, 18 Feb 2012 21:02:27 +1000 (EST) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.177]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 2CFDB5C22 for ; Sat, 18 Feb 2012 21:02:27 +1000 (EST) Message-ID: <4F3F80FD.8070201@herveybayaustralia.com.au> Date: Sat, 18 Feb 2012 20:44:13 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <4F3ECF23.5000706@fisglobal.com> <20120217234623.cf7e169c.freebsd@edvax.de> <3D08D03C85ACFBB1ABCDC5DA@mac-pro.magehandbook.com> <20120218112252.772c878b.freebsd@edvax.de> In-Reply-To: <20120218112252.772c878b.freebsd@edvax.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: /usr/home vs /home X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-questions@freebsd.org List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 10:49:02 -0000 On 02/18/12 20:22, Polytropon wrote: > On Sat, 18 Feb 2012 00:05:49 -0600 (CST), Lars Eighner wrote: >> It seems to me that partition and mount point are being confused to a >> degree. There is no reason what is mounted at /usr/home cannot be a >> separate partition as well as if it were mounted at root. > I thought of this fact as such an obvious thing that I > didn't bother even mentioning it. :-) > > Of course, /usr/home can be a separate partition (even on > a separate disk), just like /usr/ports or /usr/obj or even > /usr/local could be. I've also seen systems having several > subtrees in /export, each one being on an individual partition, > some of them even on an own disk. > > > >> There are some >> good reasons for the user directories (and perhaps some other data) to be on >> a separate partition - mostly the reasons relate to ease of back up and >> migration whether planned or emergency. Arguments about where to mount that >> partition are not so practical, being more in the philosophic and historical >> realm. Pick one, recognize not everyone will be on the same page and put >> appropriate links in. > I'd still be interested in why this particular location has > been chosen. The typical access path for home directories > is /home (that's why the symlink), and as long as this > "top level entry" points to the proper data (no matter where > they are located), it should be fine. > > > >> There may have been a historic reason, but now it is philosophical - trying >> to keep the system and userland distinction clear. But there are many flaws >> in the attempted separation. /var for example is the default location for >> many logs, both system and user, the spools (remember news?), and databases. >> You really cannot drop /usr into a different system and have an operational >> result. > Correct. Also see the difference in usage interpretation for > /tmp (not guaranteed to be present after reboot) and /var/tmp > (should be present in the same state after reboot). > > The separation of concepts FreeBSD is famous for basically is > "the OS" (primarily /, /etc, /(s)bin, /usr/(s)bin) that provides > the minimal functionality to bring up the operating system even > in worst case, where only the root partition needs to be mounted, > which can be done in read-only mode, to finally reach the single- > user mode, and "3rd party applications" (everything in /usr/local). > However, both system and 3rd party programs access things in /var > or /tmp. Not having actual _user_ data in between can be a benefit > especially when something goes wrong. > > > >> (I put the home directories, the www directory, databases and spools all on >> the same physical partition which I mount arbitrarily at /usr/local/data. It >> isn't exactly plug-n-play, but in tests and emergencies is has proved >> practical to drop the partition into several linices with a high level of >> functionally - depending on application versioning being close to in sync.) > And I assume you still have /home pointing to the correct location > on that "new" path? I think it all depends particularly on what you're using the system for, really. Say you were going to run a print server, or a logging server, or some other service, then you would arrange the system accordingly. I notice that the general use case of www is already arranged to provide this - the webroot is setup on the usr/local/www, but that could be a mounted partition there too; it does protect the novice. OTOH if you were setting up a print server, you would probably put a spool partition specifically for that purpose where needed. That way if you get a lot of large print jobs you're covered. This general layout (the traditional one, to clarify: /, /var, /tmp, /usr) offers the most protection and instruction to the novice user, and usually works well in most general cases. I have yet to try ZFS (lack of resources really), but when I can I will setup a SAN and it will be interesting to see how this works and I probably will use a single partition. But for the general filesystem I doubt a single partition will cut it (I could be a stick in the mud though :) ), and I highly recommend this path for the new user; especially using a desktop. BTW I was intending to put across the concept of /usr being user related - anything a user may need or use; as opposed to / for the system related stuff that keeps it running. Maybe I wasn't as clear as I had thought... :)