From owner-freebsd-fs@FreeBSD.ORG Thu Apr 4 03:58:12 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1E71F3EB for ; Thu, 4 Apr 2013 03:58:12 +0000 (UTC) (envelope-from allan@physics.umn.edu) Received: from mail.physics.umn.edu (smtp.spa.umn.edu [128.101.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id EFDCF302 for ; Thu, 4 Apr 2013 03:58:11 +0000 (UTC) Received: from c-174-53-189-64.hsd1.mn.comcast.net ([174.53.189.64] helo=[192.168.0.138]) by mail.physics.umn.edu with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UNbJH-000A2o-FM; Wed, 03 Apr 2013 22:58:05 -0500 Message-ID: <515CFA63.8080808@physics.umn.edu> Date: Wed, 03 Apr 2013 22:58:27 -0500 From: Graham Allan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Bob Friesenhahn References: <515B84E8.2090202@physics.umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mrmachenry.spa.umn.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, TW_ZF autolearn=no version=3.3.2 Subject: Re: zfs home directories best practice X-SA-Exim-Version: 4.2 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 03:58:12 -0000 On 4/3/2013 9:20 PM, Bob Friesenhahn wrote: > On Tue, 2 Apr 2013, Graham Allan wrote: > >> We're building a new NFS home directory server on FreeBSD with ZFS. >> The Solaris ZFS Best Practices docs say to create a separate >> filesystem for each user home directory. My instinct is to ask "Are >> you serious???". My gut feeling isn't entirely logical but the idea of >> getting 1000+ lines of output from a simple "df" just feels wrong... ... > > As others have said, the NFS export is where the time gets expended. It > is not necessary to have zfs do the exports for you. > > There is indeed value to each user having their own home directory. The > 1000+ lines of output from 'df' is quite useful if it tells you exactly > how much space each user has consumed so that you don't have to do > something really evil like run 'du' in each directory to find the hogs. > The ability to snapshot filesystems on a per-user basis is quite useful. I haven't tried it yet though but I imagine the "zfs userquota" function can list each users space consumption much like on our existing (ahem) "legacy" unix system. The filesystem quota still does seem nicer since it can inherit its value from the parent object. Many times we've found we simply missed applying any quota to some handful of users on our existing system...! I would like to give users access to their own snapshots, but I feel sure it should be possible to permit that somehow, even if they aren't within the home directory. We did used to try this on our rsync-based backup system which started out with UFS snapshots which we would NFS-export to let users access them. When we switched that system to ZFS though, we found it would sometimes panic, we think when it was trying to delete a snapshot which someone had mounted over NFS. However that was a while back (FreeBSD 7.1 days) and we were probably doing a lot of things wrong... > Probably I shouldn't be answering since I have only used this at a small > scale with a Solaris server (but with a FreeBSD client). > > Having a good NFS automounter on the clients is useful if you have a > home directory per user. The AMD automounter which comes with FreeBSD > is just barely competent for the task. It is able to automount user > home directories on request but not enumerate them via 'ls /home/*' as > Solaris and Apple OS X clients can. It will only list the currently > automounted directories. Have to agree I'm not a big fan of "amd", though it also has a lot of complexity I haven't dug into. Almost all the clients will be RHEL (well, Scientific Linux) using autofs. Thanks! Graham --