From owner-freebsd-fs@FreeBSD.ORG Sun Sep 2 12:52:37 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB3D4106564A; Sun, 2 Sep 2012 12:52:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3E17D8FC08; Sun, 2 Sep 2012 12:52:37 +0000 (UTC) Received: by eeke52 with SMTP id e52so1754575eek.13 for ; Sun, 02 Sep 2012 05:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=pYcfFabUEtz9VSpFIQkH5xqQ0r5n8c3vOqmJJGUIBT8=; b=hpCJ16QSlGRQ3X+pkLwJwMLQxecWkHckM7AMfGj4dluWjEzfnCFtglSQfX5JuUjcGd HpJM9+gdwqvVc9RS0ZcuK+jfNnErbVUNqwNjQ7HfeFRKPvlBa3cRQcwFxdAZIpp85Ken gWxdFp+ak184s2Zw5hjzSUDM6rj3UX1QSgm8JdBqKpIiOLVXkmi6fE/Od5dnyIoigpzv jvd8Oqn9DnhA+M94UV4jCLIsir8QfLSQ7oMLPVQPcAMDZz/XVt6B2g0Iw3y6Uf8hxkn9 TiUU8BZ7RxudMxrNRLrV5s5PRJ2ktiLswRlb1l9yN9lTRQQPRfFbLEuSeUqclR4DBWiH u9Xg== Received: by 10.14.213.137 with SMTP id a9mr17462033eep.38.1346590356197; Sun, 02 Sep 2012 05:52:36 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id h42sm28069245eem.5.2012.09.02.05.52.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Sep 2012 05:52:35 -0700 (PDT) Date: Sun, 2 Sep 2012 14:52:28 +0200 From: Mateusz Guzik To: Marcel Moolenaar Message-ID: <20120902125228.GA29075@dft-labs.eu> References: <96DC4416-6CA5-45B4-B790-068797FAA2C6@xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <96DC4416-6CA5-45B4-B790-068797FAA2C6@xcllnt.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Grzegorz Bernacki Subject: Re: NANDFS: out of space panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 12:52:38 -0000 On Fri, Aug 31, 2012 at 01:09:40PM +0100, Marcel Moolenaar wrote: > > On Aug 22, 2012, at 4:34 PM, Boris Astardzhiev wrote: > > Now when I attempt to delete /mnt/file1234 I get a panic: > > root@smartcpe:/mnt # rm file1234 > > panic: bmap_truncate_mapping: error 28 when truncate at level 1 > > I think this is a step in the right direction and should help for originally reported testcase: http://people.freebsd.org/~mjg/patches/nandfs-out-of-space1.diff > 2. There's a real bug. For me it gives the following panic > (by virtue of me changing the behaviour of point 1): > > nandfs_new_segment: cannot create segment error 1 > create_segment: cannot create next segment [snip] > panic: brelse: not dirty > cpuid = 0 > KDB: enter: panic > While error handling in this case is clearly bogus, I believe that the sole fact that nandfs ran out of free segments is a sign of another and more important bug. Mail ended up quite lengthy with some repetitions and possibly bad English, so sorry for that. I didn't touch this filesystem for a couple of months now and may remember things incorrectly. Also ideas presented here are my own and may or may not be of any value. Some definitions to help avoid confusion: segment - fixed size continunous area filled with blocks containing user and filesystem data; partitions consist of some number of segments sufile - segment usage file (tells you which segments are free and so on) datfile - virtual-physical block translation map ifile - inode file, contains all user file inodes Free space is reclaimed as follows: 1. cleaner reads n segments and dirties blocks that are still in use 2. syncer writes dirtied blocks in new segments along with updated sufile and erases old segments 3. repeat with another n next segments. if reached end of partition, start from the beginning In other words, nandfs needs some space in order to reclaim anything. Thus, if the user is allowed to use all available segments, nandfs is unable to clean up. fs should allow the user to write data to some point. After that point is reached it should be possible to remove at least some parts of data (which results in writes). And after that it should be possible to reclaim free space (which results in additional writes). So we need safe enough first threshold (i.e. you can reach it, delete everything from fs and it still has place to clean up) or safe enough second threshold (you are allowed to delete stuff to some point). In both cases fs can return ENOSPC or try to adapt to situation by suspending write operations and trying to free up more space that in normal conditions. nandfs currently maintains only one threshold and returns ENOSPC when reached. Only removal operations are allowed (as noted earlier, this causes additional writes, threshold is just ignored for such cases). And unfortunately this can leave fs without free segments. So this is a "first threshold" with incorrect value. Some ways in which nandfs can adapt: Less coding-way: temporarily increase number of scanned segments per iteration or frequency of iterations until acceptable level of free space is reached (or there is no more space to reclaim). More coding-way: scan entire filesystem and free up top n segments with stale blocks. Possibly track this information constantly so that full scan is required once per mount. Another thing that can help is reduction of data written during deletion. I believe that during large file removal intermediate bmap blocks can be written, even though a segment later such blocks become stale. datfile and ifile never shrink. So if you happen to "free" all virtual block numbers from given datfile block, it's still carried around even though it could be just removed (note that it does not mean that datfile leaks anything - such blocks are used again as new vblocks are allocated, similar situation with ifile). Again, these ideas my be completely bogus or of little value. > Also: design documentation is missing right now, which > does mean that there's a pretty steep curve for anyone > who didn't write the file system to go in and fix any > bugs. > While it's true that there is no documentation describing current state of nandfs, there still are some ideas that originated from nilfs2, so one can get some understanding after reading their materials. -- Mateusz Guzik From owner-freebsd-fs@FreeBSD.ORG Sun Sep 2 16:40:24 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E1D51065675 for ; Sun, 2 Sep 2012 16:40:24 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:141:52a3:186::]) by mx1.freebsd.org (Postfix) with ESMTP id 122878FC0A for ; Sun, 2 Sep 2012 16:40:24 +0000 (UTC) Received: from [10.10.1.100] (unknown [217.71.4.82]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id CCC7DD07A8 for ; Sun, 2 Sep 2012 18:40:22 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.5.2 mail.tyknet.dk CCC7DD07A8 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1346604023; bh=k/YEpHYsOHwYjpkKFYDGueoPmW7Z3tgcRPIldd1YgSM=; h=Date:From:To:Subject; b=mEE2265L0/13NPT+K5j+D6moLjWUlpmLeXaPsnVbjRkJUUAzAMKf707LzuTRzlfw/ 0oi60oA1yOoIBliOM4Gxe89dFpkAdO8P6q9MKAk2/7y/fOwwyLPmYVCGzS5wq4NZzp gjxvQat9pIVARhwYbxOWP009RT8dLSEi29Ly8+hI= Message-ID: <50438BF5.8030004@gibfest.dk> Date: Sun, 02 Sep 2012 18:40:21 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120604 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 16:40:24 -0000 Hello list, For some reason it seems like the -r argument to "zfs send" isn't implemented in FreeBSD. It is documented in the usage output seen below: ------------------------------------------------------------------------- # zfs send -r invalid option 'r' usage: send [-DnPpRrv] [-i snapshot | -I snapshot] For the property list, run: zfs set|get For the delegated permission list, run: zfs allow|unallow ------------------------------------------------------------------------- This is on a recent 9-STABLE: # uname -rms FreeBSD 9.1-PRERELEASE amd64 The option is also documented in the manpage zfs(8): -r Recursively send all descendant snapshots. This is similar to the -R flag, but information about deleted and renamed datasets is not included, and property information is only included if the -p flag is specified. I've checked the source and /usr/src/cddl/contrib/opensolaris/cmd/zfs/zfs_main.c doesn't contain any traces of a -r option in zfs_do_send() I've also checked the IllumOS source and the situation is the same there, the option is documented but not present in the code: https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/zfs/zfs_main.c#L3543 Does anyone know what is going on here ? Either the code should be imported, whereever it is, or the manpage and usage info of zfs(8) needs updating. Best regards, Thomas Steen Rasmussen From owner-freebsd-fs@FreeBSD.ORG Sun Sep 2 18:31:08 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8E65106566B for ; Sun, 2 Sep 2012 18:31:08 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 862E38FC0A for ; Sun, 2 Sep 2012 18:31:08 +0000 (UTC) Received: by obbun3 with SMTP id un3so10650822obb.13 for ; Sun, 02 Sep 2012 11:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VJwmNLaEprIZAm2DPshuAN4LOjK4+p0fFt9k/FxUNOI=; b=cXjyQfUFW0q0v1ssBiFWoWqYQcy3rLYtS18ZuFl5RrMLO8KZSY/dotjPrgyBeZmdme /nkRpzLW02h4K9GAwTuhwJ4ud+8qJw651D+gRqik9qz2sJhsqhkqbs9bNwL9nKNgF7fl X5ByEEZvnT1CPjeam60iNqa41IdIoG6yk/mhmzb7q3gwY1Ua4SEelTZ1eFfTZk2NQ6Pa Wfq5k++HqKPkhoixUeJvSUyDle2kCGSC19LYnVkSUMtzeKGscGvbKGgKTVA5VrsGl0Kh fWYx3zzViFfJIXAIdIdd1tX5w4WriVHvAC3oqOZGl80D1nqDIutrQoRkmvtOX2Ekw9gI Fdnw== MIME-Version: 1.0 Received: by 10.60.169.8 with SMTP id aa8mr12209577oec.109.1346610661781; Sun, 02 Sep 2012 11:31:01 -0700 (PDT) Received: by 10.60.46.165 with HTTP; Sun, 2 Sep 2012 11:31:01 -0700 (PDT) In-Reply-To: <50438BF5.8030004@gibfest.dk> References: <50438BF5.8030004@gibfest.dk> Date: Sun, 2 Sep 2012 20:31:01 +0200 Message-ID: From: Andreas Nilsson To: Thomas Steen Rasmussen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 18:31:08 -0000 On Sun, Sep 2, 2012 at 6:40 PM, Thomas Steen Rasmussen wrote: > Hello list, > > For some reason it seems like the -r argument to "zfs send" isn't > implemented in FreeBSD. It is documented in the usage output > seen below: > > > snip I have similar "issues", but with a twist: on my laptop ( 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r238754 ) I have zfs send -r in man page, and FreeBSD 9.1 November 26, 2011 FreeBSD 9.1 at the end of man page. On my desktop I have zfs send [-vR] [-[iI] snapshot] snapshot in man page and SunOS 5.11 24 Sep 2009 zfs(1M) at the end om man page. It's a bit older ( 9.0-STABLE FreeBSD 9.0-STABLE). I had a similar experience with out-of-sync docs and then I think a missing mergemaster might have had something to do with it. Best regards Andreas From owner-freebsd-fs@FreeBSD.ORG Sun Sep 2 19:17:41 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AD681065675 for ; Sun, 2 Sep 2012 19:17:41 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:141:52a3:186::]) by mx1.freebsd.org (Postfix) with ESMTP id 8EEA08FC17 for ; Sun, 2 Sep 2012 19:17:40 +0000 (UTC) Received: from [10.10.1.100] (unknown [217.71.4.82]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 2DF44D09AA; Sun, 2 Sep 2012 21:17:31 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.5.2 mail.tyknet.dk 2DF44D09AA DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1346613452; bh=WvmN03j/LvR+Y4CHMkk96edawO8LWRe5tfty9ii03cU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=yp7H0Bcnwp6b5ymQwVVItF4sWf//dKjKOFW3txLewCEkxkZct5hN3JsBG3pIuZShR VPp7aUXAk8v9mLq/mbNIa47UZS+ivfL3LC0qWwi00GYroy+Eetk8UI3eE8vP/Btbb7 4S64YCLrkMK7NyGrT8gvgwlPu4my2Q9g6S3DfV2Q= Message-ID: <5043B0CB.8040907@gibfest.dk> Date: Sun, 02 Sep 2012 21:17:31 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120604 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andreas Nilsson References: <50438BF5.8030004@gibfest.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 19:17:41 -0000 On 02.09.2012 20:31, Andreas Nilsson wrote: > > > On Sun, Sep 2, 2012 at 6:40 PM, Thomas Steen Rasmussen > > wrote: > > Hello list, > > For some reason it seems like the -r argument to "zfs send" isn't > implemented in FreeBSD. It is documented in the usage output > seen below: > > > I had a similar experience with out-of-sync docs and then I think a > missing mergemaster might have had something to do with it. > Hello, This is not just the manpage out of sync. Ironically the zfs tool itself reports the lower-case -r option in the usage output that it shows me because -r is an invalid option: ------------------------------------------------------------ $ zfs send -r invalid option 'r' usage: send [-DnPpRrv] [-i snapshot | -I snapshot] For the property list, run: zfs set|get For the delegated permission list, run: zfs allow|unallow $ ------------------------------------------------------------ Best regards, Thomas Steen Rasmussen From owner-freebsd-fs@FreeBSD.ORG Sun Sep 2 19:31:04 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32716106566B; Sun, 2 Sep 2012 19:31:04 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id F10C28FC14; Sun, 2 Sep 2012 19:31:03 +0000 (UTC) Received: from glenbarber.us (75.97.141.105.res-cmts.sewb.ptd.net [75.97.141.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id D513F23F645; Sun, 2 Sep 2012 15:31:02 -0400 (EDT) Date: Sun, 2 Sep 2012 15:31:00 -0400 From: Glen Barber To: Thomas Steen Rasmussen Message-ID: <20120902193100.GG1266@glenbarber.us> References: <50438BF5.8030004@gibfest.dk> <5043B0CB.8040907@gibfest.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UlxN1C6awaFNesUv" Content-Disposition: inline In-Reply-To: <5043B0CB.8040907@gibfest.dk> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, Martin Matuska Subject: Re: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 19:31:04 -0000 --UlxN1C6awaFNesUv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 02, 2012 at 09:17:31PM +0200, Thomas Steen Rasmussen wrote: > > Hello list, > > > > For some reason it seems like the -r argument to "zfs send" isn't > > implemented in FreeBSD. It is documented in the usage output > > seen below: > > > > > > I had a similar experience with out-of-sync docs and then I think a=20 > > missing mergemaster might have had something to do with it. > > > Hello, >=20 > This is not just the manpage out of sync. Ironically > the zfs tool itself reports the lower-case -r option > in the usage output that it shows me because -r > is an invalid option: >=20 > ------------------------------------------------------------ > $ zfs send -r > invalid option 'r' > usage: > send [-DnPpRrv] [-i snapshot | -I snapshot] >=20 I reported this to Martin a few days ago, but not yet had time myself to check if this is also a bug upstream. Glen --UlxN1C6awaFNesUv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQQ7P0AAoJEFJPDDeguUajd0UH+gLLzj1dvTc/x44vTpsZlmXY NgMtQ4aQHrpW2Fv6YgWRXPf713wfho8JlVLv7kievKZdck6u74KIVox1gkE0LTjA WMaZKiHCNU3QvrigtfJlbszzFyTnk5cc9JWNTlVdTfalPXvWp4i2LO49hGm6F4Km Eyz4ibaXEMS5GaDbtZiHvrUv4pbNYikyQYwD+4XmLNypHITiRCSYulcbANpt+c5P TqZdDO9yx1BbjJbcNWLw9Ae8YaWsOe4juVirp2hDbCNmnq24b0Nmb4Zb/z7ec+Kv zqmJ5nMQJ/3mRmFkuO2wzlbgf/UR8hlDANFRF6J4RnqUL8MHYvF68hSnthRPKjA= =mgZs -----END PGP SIGNATURE----- --UlxN1C6awaFNesUv-- From owner-freebsd-fs@FreeBSD.ORG Sun Sep 2 19:56:42 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89C50106564A for ; Sun, 2 Sep 2012 19:56:42 +0000 (UTC) (envelope-from Yuri.Pankov@nexenta.com) Received: from mail132.messagelabs.com (mail132.messagelabs.com [216.82.242.115]) by mx1.freebsd.org (Postfix) with ESMTP id 3193F8FC0A for ; Sun, 2 Sep 2012 19:56:41 +0000 (UTC) X-Env-Sender: Yuri.Pankov@nexenta.com X-Msg-Ref: server-11.tower-132.messagelabs.com!1346615399!12290532!1 X-Originating-IP: [199.119.192.67] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18517 invoked from network); 2 Sep 2012 19:50:00 -0000 Received: from out001.apptixemail.net (HELO out001.apptixemail.net) (199.119.192.67) by server-11.tower-132.messagelabs.com with AES128-SHA encrypted SMTP; 2 Sep 2012 19:50:00 -0000 Received: from [192.168.1.4] (10.2.67.253) by smtp.apptixemail.net (10.2.65.59) with Microsoft SMTP Server id 14.2.247.3; Sun, 2 Sep 2012 14:49:59 -0500 Message-ID: <5043B866.6060204@nexenta.com> Date: Sun, 2 Sep 2012 23:49:58 +0400 From: Yuri Pankov Organization: Nexenta Systems, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-fs , illumos-zfs , Matthew Ahrens References: <50438BF5.8030004@gibfest.dk> <5043B0CB.8040907@gibfest.dk> <20120902193100.GG1266@glenbarber.us> In-Reply-To: <20120902193100.GG1266@glenbarber.us> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 19:56:42 -0000 On Sun, 2 Sep 2012 15:31:00 -0400, Glen Barber wrote: > On Sun, Sep 02, 2012 at 09:17:31PM +0200, Thomas Steen Rasmussen wrote: >>> Hello list, >>> >>> For some reason it seems like the -r argument to "zfs send" isn't >>> implemented in FreeBSD. It is documented in the usage output >>> seen below: >>> >>> >>> I had a similar experience with out-of-sync docs and then I think a >>> missing mergemaster might have had something to do with it. >>> >> Hello, >> >> This is not just the manpage out of sync. Ironically >> the zfs tool itself reports the lower-case -r option >> in the usage output that it shows me because -r >> is an invalid option: >> >> ------------------------------------------------------------ >> $ zfs send -r >> invalid option 'r' >> usage: >> send [-DnPpRrv] [-i snapshot | -I snapshot] >> > > I reported this to Martin a few days ago, but not yet had time myself to > check if this is also a bug upstream. Talking about upstream, looks like -r was added to usage and man page in r13524 by Matthew Ahrens (CCed), but the functionality itself is missing. From owner-freebsd-fs@FreeBSD.ORG Sun Sep 2 21:03:42 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA3F6106564A; Sun, 2 Sep 2012 21:03:42 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [176.9.45.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5898FC0A; Sun, 2 Sep 2012 21:03:42 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id C3C5C260A2; Sun, 2 Sep 2012 23:03:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id g_0DBSHM4g80; Sun, 2 Sep 2012 23:03:33 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-15.dynamic.chello.sk [188.167.78.15]) by mail.vx.sk (Postfix) with ESMTPSA id B50B426097; Sun, 2 Sep 2012 23:03:33 +0200 (CEST) Message-ID: <5043C9A5.5070409@FreeBSD.org> Date: Sun, 02 Sep 2012 23:03:33 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Glen Barber References: <50438BF5.8030004@gibfest.dk> <5043B0CB.8040907@gibfest.dk> <20120902193100.GG1266@glenbarber.us> In-Reply-To: <20120902193100.GG1266@glenbarber.us> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 21:03:43 -0000 On 2.9.2012 21:31, Glen Barber wrote: > On Sun, Sep 02, 2012 at 09:17:31PM +0200, Thomas Steen Rasmussen wrote: >>> Hello list, >>> >>> For some reason it seems like the -r argument to "zfs send" isn't >>> implemented in FreeBSD. It is documented in the usage output >>> seen below: >>> >>> >>> I had a similar experience with out-of-sync docs and then I think a >>> missing mergemaster might have had something to do with it. >>> >> Hello, >> >> This is not just the manpage out of sync. Ironically >> the zfs tool itself reports the lower-case -r option >> in the usage output that it shows me because -r >> is an invalid option: >> >> ------------------------------------------------------------ >> $ zfs send -r >> invalid option 'r' >> usage: >> send [-DnPpRrv] [-i snapshot | -I snapshot] >> > I reported this to Martin a few days ago, but not yet had time myself to > check if this is also a bug upstream. > > Glen > I confirm this bug existing upstream. I am going to report it to the vendor at illumos issues. -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Sun Sep 2 21:26:06 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C3C2106564A for ; Sun, 2 Sep 2012 21:26:06 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id DC0B58FC0C for ; Sun, 2 Sep 2012 21:26:05 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T8HgB-0002oj-FM for freebsd-fs@freebsd.org; Sun, 02 Sep 2012 23:26:03 +0200 Received: from cpe-188-129-82-176.dynamic.amis.hr ([188.129.82.176]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 02 Sep 2012 23:26:03 +0200 Received: from ivoras by cpe-188-129-82-176.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 02 Sep 2012 23:26:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Sun, 02 Sep 2012 23:25:38 +0200 Lines: 17 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-82-176.dynamic.amis.hr User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 Subject: UFS and ACLs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 21:26:06 -0000 Hi, Can someone give an estimated / expected answer on these questions: * What is the performance impact (if any) for file systems mounted with either of the ACL options: acls, nfsv4acls, in the situation where most of the files do not have (and do not need) any ACLs? * Will the kernel automagically add ACLs (other than the regular Unix DAC bits) to new files on file systems mounted with acls/nfsv4acls? * The "regular" DAC bits have some nice propagation rules, e.g. new files created by a user belonging to a group which owns the directory have the GID of this group. Does this work with ACLs? * Which is the easier option to use/maintain, POSIX or NFSv4 ACLs? From owner-freebsd-fs@FreeBSD.ORG Sun Sep 2 21:34:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 294901065670; Sun, 2 Sep 2012 21:34:28 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id E85D98FC18; Sun, 2 Sep 2012 21:34:27 +0000 (UTC) Received: from glenbarber.us (75.97.141.105.res-cmts.sewb.ptd.net [75.97.141.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 164EB23F645; Sun, 2 Sep 2012 17:34:27 -0400 (EDT) Date: Sun, 2 Sep 2012 17:34:25 -0400 From: Glen Barber To: Martin Matuska Message-ID: <20120902213425.GA1507@glenbarber.us> References: <50438BF5.8030004@gibfest.dk> <5043B0CB.8040907@gibfest.dk> <20120902193100.GG1266@glenbarber.us> <5043C9A5.5070409@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <5043C9A5.5070409@FreeBSD.org> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 21:34:28 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 02, 2012 at 11:03:33PM +0200, Martin Matuska wrote: > I confirm this bug existing upstream. I am going to report it to the > vendor at illumos issues. >=20 Thank you. Sorry for not following up with you on this sooner. :\ Glen --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQQ9DhAAoJEFJPDDeguUajcssH/R9h6fG/bRXaP+D4vrYY7c4j k7dNak/O7dF/hi7ZoPwZNSHFMAcM4smzi6S4Q/NCM6FWtRQNs3sRDAf3BVXqI4wY hYUgpawhaOnZk9GX8HDpt+s4fJ3x1eVX5C3PX2lF8wuzdGmbknzl5vK2NWj96sfO h9RI2UmkYVxOpecZniTqJMh6y6fUCbRk83+PmJDRtxHPb2SN8ZzAfc/Sv4I59ccD Y5GakXlrt1zsKkCOgRNOJVccSQPJkPpHEtOcEcuezaCvbHq4+vbZfRDq+DoupzUX On/dFmitAqZ0Vp0LmYM8xinlvziEC434tIjEsVJ26kLfrXHwiUsUV9z57JP+yWc= =lgtE -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-fs@FreeBSD.ORG Sun Sep 2 22:00:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77BEE1065670 for ; Sun, 2 Sep 2012 22:00:10 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id 1ACB38FC16 for ; Sun, 2 Sep 2012 22:00:10 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 79B8735C3C for ; Mon, 3 Sep 2012 00:00:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id xnyaSaCP7e3N for ; Mon, 3 Sep 2012 00:00:07 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-15.dynamic.chello.sk [188.167.78.15]) by mail.vx.sk (Postfix) with ESMTPSA id A8F0A35C38 for ; Mon, 3 Sep 2012 00:00:07 +0200 (CEST) Message-ID: <5043D6E7.8090308@FreeBSD.org> Date: Mon, 03 Sep 2012 00:00:07 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 CC: freebsd-fs@freebsd.org References: <50438BF5.8030004@gibfest.dk> <5043B0CB.8040907@gibfest.dk> <20120902193100.GG1266@glenbarber.us> <5043C9A5.5070409@FreeBSD.org> <20120902213425.GA1507@glenbarber.us> In-Reply-To: <20120902213425.GA1507@glenbarber.us> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 22:00:10 -0000 On 2.9.2012 23:34, Glen Barber wrote: > On Sun, Sep 02, 2012 at 11:03:33PM +0200, Martin Matuska wrote: >> I confirm this bug existing upstream. I am going to report it to the >> vendor at illumos issues. >> > Thank you. Sorry for not following up with you on this sooner. :\ > > Glen > Vendor issue opened: https://www.illumos.org/issues/3144 -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Sun Sep 2 22:15:22 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3307F106564A for ; Sun, 2 Sep 2012 22:15:22 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:141:52a3:186::]) by mx1.freebsd.org (Postfix) with ESMTP id B8DE38FC08 for ; Sun, 2 Sep 2012 22:15:21 +0000 (UTC) Received: from [10.10.1.100] (unknown [217.71.4.82]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 8C7F2D0AD4 for ; Mon, 3 Sep 2012 00:15:20 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.5.2 mail.tyknet.dk 8C7F2D0AD4 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1346624120; bh=C7pje0yqxxXuZEKgjeYqvlJUfWThpoFea8gI5+Fcfak=; h=Date:From:To:Subject:References:In-Reply-To; b=eKSiPpdDsNJMEmnNzZWU4vX2qTQjU4/EH+5tn3w6ma99+KOe6W/37eQwJ79hEkxjo TBbQxXHdwnJ2qcb4KcD8/WpPpp04zs3MVqbhIfayP2CKa7C7tr+GTZIcOixcxCZCtH V7kvn1K0R69YMN0gGtWglHP5QJ1mxNlavG38nZ48= Message-ID: <5043DA77.6000304@gibfest.dk> Date: Mon, 03 Sep 2012 00:15:19 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120604 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <50438BF5.8030004@gibfest.dk> <5043B0CB.8040907@gibfest.dk> <20120902193100.GG1266@glenbarber.us> <5043C9A5.5070409@FreeBSD.org> <20120902213425.GA1507@glenbarber.us> <5043D6E7.8090308@FreeBSD.org> In-Reply-To: <5043D6E7.8090308@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 22:15:22 -0000 On 03.09.2012 00:00, Martin Matuska wrote: > On 2.9.2012 23:34, Glen Barber wrote: >> On Sun, Sep 02, 2012 at 11:03:33PM +0200, Martin Matuska wrote: >>> I confirm this bug existing upstream. I am going to report it to the >>> vendor at illumos issues. >>> >> Thank you. Sorry for not following up with you on this sooner. :\ >> >> Glen >> > Vendor issue opened: > https://www.illumos.org/issues/3144 > Hello guys, Thanks for getting on this so fast. Would you like me to open up a FreeBSD PR as well, to keep track of our end of the issue ? Best regards, Thomas Steen Rasmussen From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 03:15:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91A201065670; Mon, 3 Sep 2012 03:15:05 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 54F158FC14; Mon, 3 Sep 2012 03:15:05 +0000 (UTC) Received: from glenbarber.us (75.97.141.105.res-cmts.sewb.ptd.net [75.97.141.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 5CB7D23F645; Sun, 2 Sep 2012 23:15:03 -0400 (EDT) Date: Sun, 2 Sep 2012 23:15:02 -0400 From: Glen Barber To: Thomas Steen Rasmussen Message-ID: <20120903031502.GH1507@glenbarber.us> References: <50438BF5.8030004@gibfest.dk> <5043B0CB.8040907@gibfest.dk> <20120902193100.GG1266@glenbarber.us> <5043C9A5.5070409@FreeBSD.org> <20120902213425.GA1507@glenbarber.us> <5043D6E7.8090308@FreeBSD.org> <5043DA77.6000304@gibfest.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mGCtrYeZ202LI9ZG" Content-Disposition: inline In-Reply-To: <5043DA77.6000304@gibfest.dk> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 03:15:05 -0000 --mGCtrYeZ202LI9ZG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 03, 2012 at 12:15:19AM +0200, Thomas Steen Rasmussen wrote: > Would you like me to open up a FreeBSD PR as well, > to keep track of our end of the issue ? Right now, I'd say a FreeBSD PR is not necessary since this is an upstream bug as well. Glen --mGCtrYeZ202LI9ZG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQRCC2AAoJEFJPDDeguUajELcH+wRV9g4xKz0G2RpeQ/rObfId Gc8/eTko9/QIKUIBZau1IFJfHKl2tHuUfOVOcFM80hus5IeAcNPCVBmv9uXZ0CMv KZGV6Oe8MT5uCQTKmjdrHVowPFXmfuDG+uSHKMYjxbIlTN9ef8Q00ZnZhYOpCtBr CxwHNqK3qpwPASvNllFE41CrIM5y7w5MOdRVFLfTwuyLq0GSykgoHS0uoajxMsF6 rkXO72iYN8LXzLF9Q59AKbQcsxw0wY8WE62M/cVfM/4HJ2b5H0t7tFeZCSVl0d3O knyRL9mW4aElk7jdcH4LE3fKus/q/ggQ4y1NWfqXJbyerqwO59l6wUQ2z5NtSFk= =yy2g -----END PGP SIGNATURE----- --mGCtrYeZ202LI9ZG-- From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 03:50:31 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4D56106564A for ; Mon, 3 Sep 2012 03:50:31 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 08B088FC15 for ; Mon, 3 Sep 2012 03:50:30 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sweb; b=qo0f5+fFt90TOkwR22B p+MaN9AEku6njHeVbcmobmZLKseKDIp/Ae3DkWiNoEjXIM2a+8+7OeHaphDR5KPq /rs+Edkik9dLv5JfVxyMvKNP4DzTGdfp53crOPI6DxuMOH6cU2Ps00PXj37FOWCY eP94QOOLZ3l+deuPQb1ADbng= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sweb; bh=bSeuXBnDnyozTpQN7ziABe7ZP St48IIjVZVUkVH3MgM=; b=NBDx7+Yq723XYrhTCokXSMY8n2JVpA88jUAmXef5Z jlgqZp/VJF5FImqGXY28+iD99PE+1y78H0Wa/4Qui6Ek3/UQsDmLh9GMvgXKBShI vadWpiS/NtygCQXIxz9MIGcXsoPqWqy4AkvqTInCfMfDx4lLVWoFk7/gsqX9v/DE gw= Received: (qmail 80961 invoked from network); 2 Sep 2012 22:50:23 -0500 Received: from unknown (HELO ?10.10.0.115?) (bryan@shatow.net@10.10.0.115) by sweb.xzibition.com with ESMTPA; 2 Sep 2012 22:50:23 -0500 Message-ID: <504428EB.4020702@shatow.net> Date: Sun, 02 Sep 2012 22:50:03 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Enigmail-Version: 1.4.4 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Panic in zfs_freebsd_getattr -> zfs_fuid_table_load - avl_find() succeeded inside avl_add() [ACL, 9.1-PRERELEASE] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 03:50:31 -0000 Running 9.1-PRERELEASE currently. Just set this server up, imported the pool from OpenIndiana 151 I believe it was. When I access (simply `ls`) certain files/directories, the system panics. These files have ACL properties set on them from the Solaris system. This system has 32gb of ram and only 8gb swap setup, so I do not currently have a kernel core dump. It's also practically a production machine, so I do not have much leeway in testing on it. backtrace: >From running ls(1): panic: avl_find() succeeded inside avl_add() avl_add+0x4b zfs_fuid_table_load+0x198 zfs_fuid_init+0x12c zfs_fuid_find_by_idx+0xc7 zfs_fuid_map_id+0x19 zfs_groupmember+0x16 zfs_zaccess_aces_check+0x196 zfs_zaccess+0xc6 zfs_freebsd_getattr+0x1c1 vn_stat+0x6a kern_statat_vnhook+0xf9 kern_statat+0x15 sys_lstat+0x2a amd64_syscall+0x540 At first I thought this was related to MAC / ugidfw, but I am able to reproduce with those not compiled in. FWIW, here is a backtrace from having that enabled: panic: avl_find() succeeded inside avl_add() avl_add+0x4b zfs_fuid_table_load+0x198 zfs_fuid_init+0x12c zfs_fuid_find_by_idx+0xc7 zfs_fuid_map_id+0x19 zfs_groupmember+0x16 zfs_zaccess_aces_check+0x196 zfs_zaccess+0xc6 zfs_freebsd_getattr+0x1c1 ugidfw_check_vp+0x6c mac_vnode_check_stat+0xa7 vn_stat+0x39 kern_statat_vnhook+0xf9 kern_statat+0x15 sys_stat+0x2a amd64_syscall+0x540 Is there some easy way to clear these ACL properties on the files? I do not need them. Any suggestions on how I might fix this or debug this further? Bryan From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 04:19:09 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA60C106564A for ; Mon, 3 Sep 2012 04:19:09 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3963D8FC0C for ; Mon, 3 Sep 2012 04:19:08 +0000 (UTC) Received: by lage12 with SMTP id e12so4082839lag.13 for ; Sun, 02 Sep 2012 21:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JR6jg8U16as5SMiJFWAsPlC25hUgi3HKg5Hzg5YRxJk=; b=SxzwjME32bUI1plRgXWGa9vtmjA9IFiDGHQrxiDD+4Nc/PoFBcLbZ/cbQLrg8iCum1 TyJKMKGO8tzXC0XMJIcHbbaOEo8+g515MhktNv9da8vBkX0ZPsEfUb6ST9G+fPxQ41KX 9oKyTf7n4K739B31X7H2datx2Vlu3TOu1IY9p6MaMl125H12ByBYCca3PArJk6HHoRR9 Zs6iN7thV94XCCYsJX7pI3t6PApnO5mWEjWvBGYdggVmHN+zG00/qsg1iI8bxDF6Z9ss 2pRCvhNUvM0WMD+tYuTaOFna7tHjIqQaNUSioXXM0i30M/fxJQ1rbaJub6N5KJj//dNN oHqQ== MIME-Version: 1.0 Received: by 10.152.103.146 with SMTP id fw18mr12762132lab.30.1346645947506; Sun, 02 Sep 2012 21:19:07 -0700 (PDT) Received: by 10.114.23.230 with HTTP; Sun, 2 Sep 2012 21:19:07 -0700 (PDT) Received: by 10.114.23.230 with HTTP; Sun, 2 Sep 2012 21:19:07 -0700 (PDT) In-Reply-To: <504428EB.4020702@shatow.net> References: <504428EB.4020702@shatow.net> Date: Sun, 2 Sep 2012 21:19:07 -0700 Message-ID: From: Freddie Cash To: Bryan Drewery Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Panic in zfs_freebsd_getattr -> zfs_fuid_table_load - avl_find() succeeded inside avl_add() [ACL, 9.1-PRERELEASE] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 04:19:09 -0000 (Please forgive the top-post, sent from my phone.) There's a pool or zfs property that deals with how acl inheritance works, and how to handle failures (panic, continue, ignore, etc). Don't recall the exact name but it's along the lines of aclinherit. What's it currently set to? And how does the system react if you change it? See the zpool and zfs man pages for info. On Sep 2, 2012 8:51 PM, "Bryan Drewery" wrote: > Running 9.1-PRERELEASE currently. > > Just set this server up, imported the pool from OpenIndiana 151 I > believe it was. > > When I access (simply `ls`) certain files/directories, the system > panics. These files have ACL properties set on them from the Solaris > system. > > This system has 32gb of ram and only 8gb swap setup, so I do not > currently have a kernel core dump. It's also practically a production > machine, so I do not have much leeway in testing on it. > > backtrace: > > >From running ls(1): > > panic: avl_find() succeeded inside avl_add() > avl_add+0x4b > zfs_fuid_table_load+0x198 > zfs_fuid_init+0x12c > zfs_fuid_find_by_idx+0xc7 > zfs_fuid_map_id+0x19 > zfs_groupmember+0x16 > zfs_zaccess_aces_check+0x196 > zfs_zaccess+0xc6 > zfs_freebsd_getattr+0x1c1 > vn_stat+0x6a > kern_statat_vnhook+0xf9 > kern_statat+0x15 > sys_lstat+0x2a > amd64_syscall+0x540 > > At first I thought this was related to MAC / ugidfw, but I am able to > reproduce with those not compiled in. FWIW, here is a backtrace from > having that enabled: > > panic: avl_find() succeeded inside avl_add() > avl_add+0x4b > zfs_fuid_table_load+0x198 > zfs_fuid_init+0x12c > zfs_fuid_find_by_idx+0xc7 > zfs_fuid_map_id+0x19 > zfs_groupmember+0x16 > zfs_zaccess_aces_check+0x196 > zfs_zaccess+0xc6 > zfs_freebsd_getattr+0x1c1 > ugidfw_check_vp+0x6c > mac_vnode_check_stat+0xa7 > vn_stat+0x39 > kern_statat_vnhook+0xf9 > kern_statat+0x15 > sys_stat+0x2a > amd64_syscall+0x540 > > > Is there some easy way to clear these ACL properties on the files? I do > not need them. > > Any suggestions on how I might fix this or debug this further? > > > Bryan > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 04:24:48 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 035BA106564A for ; Mon, 3 Sep 2012 04:24:48 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id A18C28FC08 for ; Mon, 3 Sep 2012 04:24:47 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=m/mQDB tjFt0LDkHw+JK3VF4Hz3iOv5jYsrPKSZPo9nQgS9eAFvVMAj5jzjSxC7G/FYyFZl mpGVsZVPHXFr/uIRgCDPv5QcEybO3seoroXKPr+ArCVk9al7qzfZe6MGSHdFlEyw Plw7e3xotyHAXAATWHVeBxXvQpUuuKZh8l+iU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=NThqJVRUlFxG N1/n1UJPFpLNk7wBqLHiLEOcpbudkeE=; b=WMEXk72Qb93gUoSKR0IKEko3WF+6 vFZmwKpMqgtFk1YuTZuw+qfnfCtrMhYt/WhpdDb+8TXSBQ0Niu3fTedIRPhdWhJ0 D7zDgyZ28GEVK+5dIWt6IbOTvcbIHyds+K+hVQtdDBI4j9PEkhT8vOCwvt36ynU2 SLxDTlnLuDvhRIs= Received: (qmail 46489 invoked from network); 2 Sep 2012 23:24:45 -0500 Received: from unknown (HELO ?10.10.0.115?) (bryan@shatow.net@10.10.0.115) by sweb.xzibition.com with ESMTPA; 2 Sep 2012 23:24:45 -0500 Message-ID: <504430F9.8000105@shatow.net> Date: Sun, 02 Sep 2012 23:24:25 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Freddie Cash References: <504428EB.4020702@shatow.net> In-Reply-To: X-Enigmail-Version: 1.4.4 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Panic in zfs_freebsd_getattr -> zfs_fuid_table_load - avl_find() succeeded inside avl_add() [ACL, 9.1-PRERELEASE] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 04:24:48 -0000 On 9/2/2012 11:19 PM, Freddie Cash wrote: > (Please forgive the top-post, sent from my phone.) > > There's a pool or zfs property that deals with how acl inheritance > works, and how to handle failures (panic, continue, ignore, etc). Don't > recall the exact name but it's along the lines of aclinherit. What's it > currently set to? And how does the system react if you change it? > > See the zpool and zfs man pages for info. According to the manpage, those properties (aclinherit, aclmode), only affect creation and modification (chmod) of files. I don't think they'll help here as I can't even access them. > > On Sep 2, 2012 8:51 PM, "Bryan Drewery" > wrote: > > Running 9.1-PRERELEASE currently. > > Just set this server up, imported the pool from OpenIndiana 151 I > believe it was. > > When I access (simply `ls`) certain files/directories, the system > panics. These files have ACL properties set on them from the Solaris > system. > > This system has 32gb of ram and only 8gb swap setup, so I do not > currently have a kernel core dump. It's also practically a production > machine, so I do not have much leeway in testing on it. > > backtrace: > > >From running ls(1): > > panic: avl_find() succeeded inside avl_add() > avl_add+0x4b > zfs_fuid_table_load+0x198 > zfs_fuid_init+0x12c > zfs_fuid_find_by_idx+0xc7 > zfs_fuid_map_id+0x19 > zfs_groupmember+0x16 > zfs_zaccess_aces_check+0x196 > zfs_zaccess+0xc6 > zfs_freebsd_getattr+0x1c1 > vn_stat+0x6a > kern_statat_vnhook+0xf9 > kern_statat+0x15 > sys_lstat+0x2a > amd64_syscall+0x540 > > At first I thought this was related to MAC / ugidfw, but I am able to > reproduce with those not compiled in. FWIW, here is a backtrace from > having that enabled: > > panic: avl_find() succeeded inside avl_add() > avl_add+0x4b > zfs_fuid_table_load+0x198 > zfs_fuid_init+0x12c > zfs_fuid_find_by_idx+0xc7 > zfs_fuid_map_id+0x19 > zfs_groupmember+0x16 > zfs_zaccess_aces_check+0x196 > zfs_zaccess+0xc6 > zfs_freebsd_getattr+0x1c1 > ugidfw_check_vp+0x6c > mac_vnode_check_stat+0xa7 > vn_stat+0x39 > kern_statat_vnhook+0xf9 > kern_statat+0x15 > sys_stat+0x2a > amd64_syscall+0x540 > > > Is there some easy way to clear these ACL properties on the files? I do > not need them. > > Any suggestions on how I might fix this or debug this further? > > > Bryan > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org > " > -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 06:03:29 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 394CD106564A for ; Mon, 3 Sep 2012 06:03:29 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id D4CA08FC20 for ; Mon, 3 Sep 2012 06:03:27 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=0n15wd NXBH7epxOTyTCo4uMET13DqetUR2sZg82CrBlhbWyAfIlLSPnWDZYumh9NsiFANT UamXHCDfaZbG505vrO6SXIWADbdRnFCckNe/cmfodJaVbbagXGcmDqAkVpMGAKR4 TZE5ZtzpJnEFkZnhSqhFmEQZwcMHQuuGo5ocw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=6uDVWUyAfcqk 5dCSDHjh4Cs2dSxovQ/cne/MuIH+IQk=; b=oVJiB7WvSdc/2RHk7kX1P6jx/YAO J16AK1bftTPWVRI0hOPNQnmrQ47u+PIkNXUOR8cO2zikQ8SCvkhz+O17NoIIBWaw 1JnT6ejvRcCHcDKsiMrzHsrk5Qp7C7caL3Bg90PtrVJstpvEXdaYKgZAe5CZ/o7C YTxSQbXotXA8wdI= Received: (qmail 8214 invoked from network); 3 Sep 2012 01:03:26 -0500 Received: from unknown (HELO ?10.10.0.115?) (bryan@shatow.net@10.10.0.115) by sweb.xzibition.com with ESMTPA; 3 Sep 2012 01:03:26 -0500 Message-ID: <5044482D.90602@shatow.net> Date: Mon, 03 Sep 2012 01:03:25 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <504428EB.4020702@shatow.net> <504430F9.8000105@shatow.net> In-Reply-To: <504430F9.8000105@shatow.net> X-Enigmail-Version: 1.4.4 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Panic in zfs_freebsd_getattr -> zfs_fuid_table_load - avl_find() succeeded inside avl_add() [ACL, 9.1-PRERELEASE] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 06:03:29 -0000 On 9/2/2012 11:24 PM, Bryan Drewery wrote: > On 9/2/2012 11:19 PM, Freddie Cash wrote: >> (Please forgive the top-post, sent from my phone.) >> >> There's a pool or zfs property that deals with how acl inheritance >> works, and how to handle failures (panic, continue, ignore, etc). Don't >> recall the exact name but it's along the lines of aclinherit. What's it >> currently set to? And how does the system react if you change it? >> >> See the zpool and zfs man pages for info. > > According to the manpage, those properties (aclinherit, aclmode), only > affect creation and modification (chmod) of files. > > I don't think they'll help here as I can't even access them. > Confirming this did not help. Thank you for the suggestion though. > >> >> On Sep 2, 2012 8:51 PM, "Bryan Drewery" > > wrote: >> >> Running 9.1-PRERELEASE currently. >> >> Just set this server up, imported the pool from OpenIndiana 151 I >> believe it was. >> >> When I access (simply `ls`) certain files/directories, the system >> panics. These files have ACL properties set on them from the Solaris >> system. >> >> This system has 32gb of ram and only 8gb swap setup, so I do not >> currently have a kernel core dump. It's also practically a production >> machine, so I do not have much leeway in testing on it. >> >> backtrace: >> >> >From running ls(1): >> >> panic: avl_find() succeeded inside avl_add() I removed my seat belt and made this PANIC into a return; I don't know the impact of this, but I am able to access the files now. I'm looking for what duplicated entries there are. Any advice on this would be appreciated. I'll avoid clearing the ACL properties for now. >> avl_add+0x4b >> zfs_fuid_table_load+0x198 >> zfs_fuid_init+0x12c >> zfs_fuid_find_by_idx+0xc7 >> zfs_fuid_map_id+0x19 >> zfs_groupmember+0x16 >> zfs_zaccess_aces_check+0x196 >> zfs_zaccess+0xc6 >> zfs_freebsd_getattr+0x1c1 >> vn_stat+0x6a >> kern_statat_vnhook+0xf9 >> kern_statat+0x15 >> sys_lstat+0x2a >> amd64_syscall+0x540 >> >> At first I thought this was related to MAC / ugidfw, but I am able to >> reproduce with those not compiled in. FWIW, here is a backtrace from >> having that enabled: >> >> panic: avl_find() succeeded inside avl_add() >> avl_add+0x4b >> zfs_fuid_table_load+0x198 >> zfs_fuid_init+0x12c >> zfs_fuid_find_by_idx+0xc7 >> zfs_fuid_map_id+0x19 >> zfs_groupmember+0x16 >> zfs_zaccess_aces_check+0x196 >> zfs_zaccess+0xc6 >> zfs_freebsd_getattr+0x1c1 >> ugidfw_check_vp+0x6c >> mac_vnode_check_stat+0xa7 >> vn_stat+0x39 >> kern_statat_vnhook+0xf9 >> kern_statat+0x15 >> sys_stat+0x2a >> amd64_syscall+0x540 >> >> >> Is there some easy way to clear these ACL properties on the files? I do >> not need them. >> >> Any suggestions on how I might fix this or debug this further? >> >> >> Bryan >> > > -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 07:00:00 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 679A3106564A for ; Mon, 3 Sep 2012 07:00:00 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 1A2F08FC14 for ; Mon, 3 Sep 2012 07:00:00 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=AH+2lt iOoskJKg3LgUYT4UcHs4htXUvFFEBdkErNTHtRvqzp9u1pFmADSRzB0irDZekrkN 49SDHA/f6MkFa6B+YMhzPpA4VnYSyp65MeimL3z+dO4Koro6ylsYdUmo1CQmg0bL SRMPO7BrHpB9U1FF0G5TPuuNjrkloj2cw45co= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=mNJWQjpPnpSg y7jwRNNFfwEcbudB4h9YUWk2qB6k2Wo=; b=Z7s2/XwR+R/ChiulHCf79w0sfv+8 lGFA/ayPLFsA9tMujk/XkgSXsV+231OvyIqxUBBn/xTmNoqWvOVxRmQluKl9HFYD AaAyyOLmPPrpvFGO/+75pR8tfhOuEjFAyHcWcrZw5D4965ldsyJ5p/JHz9CWn4CF Vjv5PexIjaq2hzc= Received: (qmail 47842 invoked from network); 3 Sep 2012 01:59:57 -0500 Received: from unknown (HELO ?10.10.0.115?) (bryan@shatow.net@10.10.0.115) by sweb.xzibition.com with ESMTPA; 3 Sep 2012 01:59:57 -0500 Message-ID: <5044556C.3020208@shatow.net> Date: Mon, 03 Sep 2012 01:59:56 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek , mm@freebsd.org References: <504428EB.4020702@shatow.net> <504430F9.8000105@shatow.net> <5044482D.90602@shatow.net> In-Reply-To: <5044482D.90602@shatow.net> X-Enigmail-Version: 1.4.4 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Panic in zfs_freebsd_getattr -> zfs_fuid_table_load - avl_find() succeeded inside avl_add() [ACL, 9.1-PRERELEASE] [SOLVED] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 07:00:00 -0000 On 9/3/2012 1:03 AM, Bryan Drewery wrote: > On 9/2/2012 11:24 PM, Bryan Drewery wrote: >>> On Sep 2, 2012 8:51 PM, "Bryan Drewery" >> > wrote: >>> >>> Running 9.1-PRERELEASE currently. >>> >>> Just set this server up, imported the pool from OpenIndiana 151 I >>> believe it was. >>> >>> When I access (simply `ls`) certain files/directories, the system >>> panics. These files have ACL properties set on them from the Solaris >>> system. >>> >>> This system has 32gb of ram and only 8gb swap setup, so I do not >>> currently have a kernel core dump. It's also practically a production >>> machine, so I do not have much leeway in testing on it. >>> >>> backtrace: >>> >>> >From running ls(1): >>> >>> panic: avl_find() succeeded inside avl_add() > > I removed my seat belt and made this PANIC into a return; I don't know > the impact of this, but I am able to access the files now. > > I'm looking for what duplicated entries there are. Any advice on this > would be appreciated. > > I'll avoid clearing the ACL properties for now. I've solved this and now have a working system. r230454 [1] fixes this. It had a MFC of 1 week but never made it to 9-STABLE. Please MFC this! OTOH, the change looks wrong, but I don't know enough to say that for certain. Why change kd_name to size 1, and then use strcpy(). Looks like an easy overflow. [1] http://lists.freebsd.org/pipermail/svn-src-head/2012-January/033707.html > > >>> avl_add+0x4b >>> zfs_fuid_table_load+0x198 >>> zfs_fuid_init+0x12c >>> zfs_fuid_find_by_idx+0xc7 >>> zfs_fuid_map_id+0x19 >>> zfs_groupmember+0x16 >>> zfs_zaccess_aces_check+0x196 >>> zfs_zaccess+0xc6 >>> zfs_freebsd_getattr+0x1c1 >>> vn_stat+0x6a >>> kern_statat_vnhook+0xf9 >>> kern_statat+0x15 >>> sys_lstat+0x2a >>> amd64_syscall+0x540 >>> >>> At first I thought this was related to MAC / ugidfw, but I am able to >>> reproduce with those not compiled in. FWIW, here is a backtrace from >>> having that enabled: >>> >>> panic: avl_find() succeeded inside avl_add() >>> avl_add+0x4b >>> zfs_fuid_table_load+0x198 >>> zfs_fuid_init+0x12c >>> zfs_fuid_find_by_idx+0xc7 >>> zfs_fuid_map_id+0x19 >>> zfs_groupmember+0x16 >>> zfs_zaccess_aces_check+0x196 >>> zfs_zaccess+0xc6 >>> zfs_freebsd_getattr+0x1c1 >>> ugidfw_check_vp+0x6c >>> mac_vnode_check_stat+0xa7 >>> vn_stat+0x39 >>> kern_statat_vnhook+0xf9 >>> kern_statat+0x15 >>> sys_stat+0x2a >>> amd64_syscall+0x540 >>> >>> >>> Is there some easy way to clear these ACL properties on the files? I do >>> not need them. >>> >>> Any suggestions on how I might fix this or debug this further? >>> >>> >>> Bryan > >>> >> >> > > -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 08:51:26 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA87A106566C for ; Mon, 3 Sep 2012 08:51:26 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3EC8FC16 for ; Mon, 3 Sep 2012 08:51:26 +0000 (UTC) Received: from [78.35.150.55] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1T8SNK-0001kx-UE for freebsd-fs@freebsd.org; Mon, 03 Sep 2012 10:51:19 +0200 Date: Mon, 3 Sep 2012 10:45:25 +0200 From: Fabian Keil To: freebsd-fs@freebsd.org Message-ID: <20120903104525.531e5d3d@fabiankeil.de> In-Reply-To: <5044556C.3020208@shatow.net> References: <504428EB.4020702@shatow.net> <504430F9.8000105@shatow.net> <5044482D.90602@shatow.net> <5044556C.3020208@shatow.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/z7A1qHRzIKOAgt1D2bMG2FI"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Subject: Re: Panic in zfs_freebsd_getattr -> zfs_fuid_table_load - avl_find() succeeded inside avl_add() [ACL, 9.1-PRERELEASE] [SOLVED] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 08:51:27 -0000 --Sig_/z7A1qHRzIKOAgt1D2bMG2FI Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Bryan Drewery wrote: > On 9/3/2012 1:03 AM, Bryan Drewery wrote: > > On 9/2/2012 11:24 PM, Bryan Drewery wrote: > >>> On Sep 2, 2012 8:51 PM, "Bryan Drewery" >>> > wrote: > >>> > >>> Running 9.1-PRERELEASE currently. > >>> > >>> Just set this server up, imported the pool from OpenIndiana 151 I > >>> believe it was. > >>> > >>> When I access (simply `ls`) certain files/directories, the system > >>> panics. These files have ACL properties set on them from the Sola= ris > >>> system. > >>> > >>> This system has 32gb of ram and only 8gb swap setup, so I do not > >>> currently have a kernel core dump. It's also practically a produc= tion > >>> machine, so I do not have much leeway in testing on it. For the space issue setting debug.minidump and vfs.zfs.zio.exclude_metadata could help (if they aren't set already). > I've solved this and now have a working system. >=20 > r230454 [1] fixes this. It had a MFC of 1 week but never made it to > 9-STABLE. >=20 > Please MFC this! >=20 > OTOH, the change looks wrong, but I don't know enough to say that for > certain. >=20 >=20 > Why change kd_name to size 1, and then use strcpy(). Looks like an easy > overflow. >=20 > [1] http://lists.freebsd.org/pipermail/svn-src-head/2012-January/033707.h= tml Note that the size of the allocated buffer is sizeof(*kd) + strlen(domain), not just sizeof(*kd). Fabian --Sig_/z7A1qHRzIKOAgt1D2bMG2FI Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBEbikACgkQBYqIVf93VJ1ORQCglmhDuUv3+y7l9abJDD5ZT76p gy4AoJO11Y58ooMLPS7Br+EsO6ZnSkhQ =rrRy -----END PGP SIGNATURE----- --Sig_/z7A1qHRzIKOAgt1D2bMG2FI-- From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 08:53:59 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBE59106564A for ; Mon, 3 Sep 2012 08:53:59 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 55B0E8FC08 for ; Mon, 3 Sep 2012 08:53:59 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=wU4lKU M/Bw7L6sSTLZgpTqxHFs4+29K695f+OOUy6CxikuFGOEir682pEAWd9A+gKrn7j9 Pf58S7kvCAiop0Zaz5V7oYv3xxhCIg5Ph4mEEWTrj/PehTr9RJxXQ/fn+g3A4a+u nzL53jbBf1PtKHKDGgdT4dSTgTPO3qYpZ73qY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=CIemKve1L+CW zPUBPi4wfyyJvgf/6aYak5MciJySTJI=; b=tbA17r9QIJCi1sHMdVfIV8RQunT7 7caeEdDxbN6yiImihuMDlBy6wBU+OepvnQCgg2eEif7cjFdchzr8zHC3TXWKcyCX REejIYneGb54ZmnaIgPhhr5H0kS2vGMPozYTsPe3fm+SfnAj4nR/funZV78xyD+x 4JsqHeogKwhQfqo= Received: (qmail 62634 invoked from network); 3 Sep 2012 03:53:57 -0500 Received: from unknown (HELO ?10.10.0.115?) (bryan@shatow.net@10.10.0.115) by sweb.xzibition.com with ESMTPA; 3 Sep 2012 03:53:57 -0500 Message-ID: <50447024.9020209@shatow.net> Date: Mon, 03 Sep 2012 03:53:56 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Fabian Keil References: <504428EB.4020702@shatow.net> <504430F9.8000105@shatow.net> <5044482D.90602@shatow.net> <5044556C.3020208@shatow.net> <20120903104525.531e5d3d@fabiankeil.de> In-Reply-To: <20120903104525.531e5d3d@fabiankeil.de> X-Enigmail-Version: 1.4.4 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Panic in zfs_freebsd_getattr -> zfs_fuid_table_load - avl_find() succeeded inside avl_add() [ACL, 9.1-PRERELEASE] [SOLVED] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 08:53:59 -0000 On 9/3/2012 3:45 AM, Fabian Keil wrote: > Bryan Drewery wrote: > >> On 9/3/2012 1:03 AM, Bryan Drewery wrote: >>> On 9/2/2012 11:24 PM, Bryan Drewery wrote: >>>>> On Sep 2, 2012 8:51 PM, "Bryan Drewery" >>>> > wrote: >>>>> >>>>> Running 9.1-PRERELEASE currently. >>>>> >>>>> Just set this server up, imported the pool from OpenIndiana 151 I >>>>> believe it was. >>>>> >>>>> When I access (simply `ls`) certain files/directories, the system >>>>> panics. These files have ACL properties set on them from the Solaris >>>>> system. >>>>> >>>>> This system has 32gb of ram and only 8gb swap setup, so I do not >>>>> currently have a kernel core dump. It's also practically a production >>>>> machine, so I do not have much leeway in testing on it. > > For the space issue setting debug.minidump and vfs.zfs.zio.exclude_metadata > could help (if they aren't set already). Thanks, will look at those. > >> I've solved this and now have a working system. >> >> r230454 [1] fixes this. It had a MFC of 1 week but never made it to >> 9-STABLE. >> >> Please MFC this! >> >> OTOH, the change looks wrong, but I don't know enough to say that for >> certain. >> >> >> Why change kd_name to size 1, and then use strcpy(). Looks like an easy >> overflow. >> >> [1] http://lists.freebsd.org/pipermail/svn-src-head/2012-January/033707.html > > Note that the size of the allocated buffer is sizeof(*kd) + strlen(domain), > not just sizeof(*kd). I saw and realized this after sending. > > Fabian > -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 10:39:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CAA61065674; Mon, 3 Sep 2012 10:39:05 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id AC5FB8FC17; Mon, 3 Sep 2012 10:39:04 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 588DF43230; Mon, 3 Sep 2012 12:39:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id fGua5wD52vks; Mon, 3 Sep 2012 12:38:57 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-15.dynamic.chello.sk [188.167.78.15]) by mail.vx.sk (Postfix) with ESMTPSA id 937534320A; Mon, 3 Sep 2012 12:38:57 +0200 (CEST) Message-ID: <504488C1.9040803@FreeBSD.org> Date: Mon, 03 Sep 2012 12:38:57 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <504428EB.4020702@shatow.net> <504430F9.8000105@shatow.net> <5044482D.90602@shatow.net> <5044556C.3020208@shatow.net> In-Reply-To: <5044556C.3020208@shatow.net> X-Enigmail-Version: 1.4.4 Content-Type: multipart/mixed; boundary="------------090307020801000706040405" Cc: freebsd-fs@freebsd.org Subject: Re: Panic in zfs_freebsd_getattr -> zfs_fuid_table_load - avl_find() succeeded inside avl_add() [ACL, 9.1-PRERELEASE] [SOLVED] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 10:39:05 -0000 This is a multi-part message in MIME format. --------------090307020801000706040405 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Pawel, what do you think of the attached patch? It does the alloc/free more the "illumos" way and also enhances readability. Cheers, mm On 3.9.2012 8:59, Bryan Drewery wrote: > On 9/3/2012 1:03 AM, Bryan Drewery wrote: >> On 9/2/2012 11:24 PM, Bryan Drewery wrote: >>>> On Sep 2, 2012 8:51 PM, "Bryan Drewery" >>> > wrote: >>>> >>>> Running 9.1-PRERELEASE currently. >>>> >>>> Just set this server up, imported the pool from OpenIndiana 151 I >>>> believe it was. >>>> >>>> When I access (simply `ls`) certain files/directories, the system >>>> panics. These files have ACL properties set on them from the Solaris >>>> system. >>>> >>>> This system has 32gb of ram and only 8gb swap setup, so I do not >>>> currently have a kernel core dump. It's also practically a production >>>> machine, so I do not have much leeway in testing on it. >>>> >>>> backtrace: >>>> >>>> >From running ls(1): >>>> >>>> panic: avl_find() succeeded inside avl_add() >> I removed my seat belt and made this PANIC into a return; I don't know >> the impact of this, but I am able to access the files now. >> >> I'm looking for what duplicated entries there are. Any advice on this >> would be appreciated. >> >> I'll avoid clearing the ACL properties for now. > I've solved this and now have a working system. > > r230454 [1] fixes this. It had a MFC of 1 week but never made it to > 9-STABLE. > > Please MFC this! > > OTOH, the change looks wrong, but I don't know enough to say that for > certain. > > > Why change kd_name to size 1, and then use strcpy(). Looks like an easy > overflow. > > [1] http://lists.freebsd.org/pipermail/svn-src-head/2012-January/033707.html > > >> >>>> avl_add+0x4b >>>> zfs_fuid_table_load+0x198 >>>> zfs_fuid_init+0x12c >>>> zfs_fuid_find_by_idx+0xc7 >>>> zfs_fuid_map_id+0x19 >>>> zfs_groupmember+0x16 >>>> zfs_zaccess_aces_check+0x196 >>>> zfs_zaccess+0xc6 >>>> zfs_freebsd_getattr+0x1c1 >>>> vn_stat+0x6a >>>> kern_statat_vnhook+0xf9 >>>> kern_statat+0x15 >>>> sys_lstat+0x2a >>>> amd64_syscall+0x540 >>>> >>>> At first I thought this was related to MAC / ugidfw, but I am able to >>>> reproduce with those not compiled in. FWIW, here is a backtrace from >>>> having that enabled: >>>> >>>> panic: avl_find() succeeded inside avl_add() >>>> avl_add+0x4b >>>> zfs_fuid_table_load+0x198 >>>> zfs_fuid_init+0x12c >>>> zfs_fuid_find_by_idx+0xc7 >>>> zfs_fuid_map_id+0x19 >>>> zfs_groupmember+0x16 >>>> zfs_zaccess_aces_check+0x196 >>>> zfs_zaccess+0xc6 >>>> zfs_freebsd_getattr+0x1c1 >>>> ugidfw_check_vp+0x6c >>>> mac_vnode_check_stat+0xa7 >>>> vn_stat+0x39 >>>> kern_statat_vnhook+0xf9 >>>> kern_statat+0x15 >>>> sys_stat+0x2a >>>> amd64_syscall+0x540 >>>> >>>> >>>> Is there some easy way to clear these ACL properties on the files? I do >>>> not need them. >>>> >>>> Any suggestions on how I might fix this or debug this further? >>>> >>>> >>>> Bryan -- Martin Matuska FreeBSD committer http://blog.vx.sk --------------090307020801000706040405 Content-Type: text/plain; charset=windows-1250; name="sid.h.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sid.h.patch" SW5kZXg6IHN5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9zeXMvc2lkLmgKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL3N5cy9zaWQuaAkocmV2aXNp b24gMjM5NzcwKQorKysgc3lzL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL3N5cy9zaWQuaAko d29ya2luZyBjb3B5KQpAQCAtMzAsNyArMzAsOCBAQAogI2RlZmluZQlfT1BFTlNPTEFSSVNf U1lTX1NJRF9IXwogCiB0eXBlZGVmIHN0cnVjdCBrc2lkZG9tYWluIHsKLQljaGFyCWtkX25h bWVbMV07CS8qIERvbWFpbiBwYXJ0IG9mIFNJRCAqLworCWNoYXIJKmtkX25hbWU7CS8qIERv bWFpbiBwYXJ0IG9mIFNJRCAqLworCXVpbnRfdAlrZF9sZW47CiB9IGtzaWRkb21haW5fdDsK IHR5cGVkZWYgdm9pZAlrc2lkX3Q7CiAKQEAgLTM4LDggKzM5LDEyIEBACiBrc2lkX2xvb2t1 cGRvbWFpbihjb25zdCBjaGFyICpkb21haW4pCiB7CiAJa3NpZGRvbWFpbl90ICprZDsKKwlz aXplX3QgbGVuOwogCi0Ja2QgPSBrbWVtX2FsbG9jKHNpemVvZigqa2QpICsgc3RybGVuKGRv bWFpbiksIEtNX1NMRUVQKTsKKwlsZW4gPSBzdHJsZW4oZG9tYWluKSArIDE7CisJa2QgPSBr bWVtX2FsbG9jKHNpemVvZigqa2QpLCBLTV9TTEVFUCk7CisJa2QtPmtkX2xlbiA9ICh1aW50 X3QpbGVuOworCWtkLT5rZF9uYW1lID0ga21lbV9hbGxvYyhsZW4sIEtNX1NMRUVQKTsKIAlz dHJjcHkoa2QtPmtkX25hbWUsIGRvbWFpbik7CiAJcmV0dXJuIChrZCk7CiB9CkBAIC00OCw2 ICs1Myw3IEBACiBrc2lkZG9tYWluX3JlbGUoa3NpZGRvbWFpbl90ICprZCkKIHsKIAorCWtt ZW1fZnJlZShrZC0+a2RfbmFtZSwga2QtPmtkX2xlbik7CiAJa21lbV9mcmVlKGtkLCBzaXpl b2YoKmtkKSk7CiB9CiAK --------------090307020801000706040405-- From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 11:09:25 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABD1510656E1 for ; Mon, 3 Sep 2012 11:09:25 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 93F828FC19 for ; Mon, 3 Sep 2012 11:09:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q83B9PWw044579 for ; Mon, 3 Sep 2012 11:09:25 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q83B9Nbf044168 for freebsd-fs@FreeBSD.org; Mon, 3 Sep 2012 11:09:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Sep 2012 11:09:23 GMT Message-Id: <201209031109.q83B9Nbf044168@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 11:09:25 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/170945 fs [gpt] disk layout not portable between direct connect o kern/170914 fs [zfs] [patch] Import patchs related with issues 3090 a o kern/170912 fs [zfs] [patch] unnecessarily setting DS_FLAG_INCONSISTE o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/170238 fs [zfs] [panic] Panic when deleting data o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167066 fs [zfs] ZVOLs not appearing in /dev/zvol o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165923 fs [nfs] Writing to NFS-backed mmapped files fails if flu o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo p kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " p kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 289 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 12:21:38 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39A12106566C for ; Mon, 3 Sep 2012 12:21:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 708A58FC1E for ; Mon, 3 Sep 2012 12:21:37 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA21449; Mon, 03 Sep 2012 15:21:33 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <5044A0CC.1000401@FreeBSD.org> Date: Mon, 03 Sep 2012 15:21:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: Trent Nelson References: <20120824011517.GJ42732@snakebite.org> <503CD4F1.6060001@FreeBSD.org> <503CDD4E.6050902@FreeBSD.org> <20120831230553.GC59852@snakebite.org> In-Reply-To: <20120831230553.GC59852@snakebite.org> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@FreeBSD.org" Subject: Re: chmod -h 000x against symlink has bizarre results on ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 12:21:38 -0000 on 01/09/2012 02:05 Trent Nelson said the following: > On Tue, Aug 28, 2012 at 08:01:34AM -0700, Andriy Gapon wrote: >> on 28/08/2012 17:25 Andriy Gapon said the following: >> Will you be able to test the following patch? >> Preferably on a temporary test pool - I don't want to risk your data. >> >> diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c >> b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c >> index 69374fb..7f61517 100644 >> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c >> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c >> @@ -1695,6 +1695,7 @@ sa_modify_attrs(sa_handle_t *hdl, sa_attr_type_t newattr, >> ASSERT(action == SA_REPLACE); >> SA_ADD_BULK_ATTR(attr_desc, j, attr, >> locator, datastart, buflen); >> + length_idx++; >> } else { >> length = SA_REGISTERED_LEN(sa, attr); >> if (length == 0) { >> > > That looks like it did the trick. Nice one :-) Thank you very much for testing and reporting! > What's the protocol for ZFS bugfixes? I'm happy to do the leg work > (submitting PRs to other teams etc). I am already discussing this issue with Illumos guys. Thank you for the offer. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 15:59:22 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C29AF106564A; Mon, 3 Sep 2012 15:59:22 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4BA8FC08; Mon, 3 Sep 2012 15:59:21 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1T7SHj-0006n0-If; Fri, 31 Aug 2012 17:33:23 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id A8BA31CC23; Fri, 31 Aug 2012 17:33:24 +0300 (EEST) Date: Fri, 31 Aug 2012 17:33:24 +0300 From: Andrey Simonenko To: Rick Macklem Message-ID: <20120831143324.GA81282@pm513-1.comsys.ntu-kpi.kiev.ua> References: <20120831110151.GA21041@pm513-1.comsys.ntu-kpi.kiev.ua> <42823120.1362161.1346414363645.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42823120.1362161.1346414363645.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-08-31 17:33:23 X-Connected-IP: 10.18.52.101:37394 X-Message-Linecount: 82 X-Body-Linecount: 66 X-Message-Size: 3722 X-Body-Size: 2950 Cc: freebsd-fs@FreeBSD.ORG, rmacklem@FreeBSD.org Subject: Re: Why vfs_stdcheckexp is a VFS operation? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 15:59:23 -0000 On Fri, Aug 31, 2012 at 07:59:23AM -0400, Rick Macklem wrote: > Andrey Simonenko wrote: > > On Wed, Aug 29, 2012 at 08:59:11AM -0400, Rick Macklem wrote: > > > > > > It seems that changing the semantics of /etc/exports is very > > > difficult > > > (it's a stumbling block w.r.t. adoption of nfse, as an example) at > > > this > > > time so, although confusing, exporting a directory that is not a > > > mount > > > point results in the entire mount point exported for NFS RPCs, but a > > > restriction of only mounting that directory is enforced for the > > > Mount > > > protocol (only done at mount time and only for NFSv3). > > > > > > > Which information is the statement about semantics of exports(5) and > > nfse is based on? > > I was just going on what you have posted. You always seem to say that > certain buggy cases for how mountd interprets /etc/exports is handled > differently for nfse, but I may have misunderstood. It depends on the year of my posts related to NFSE, I modified and improved it many times, so something said before can be wrong comparing with implementation from more recent versions. Brief statements: 1. nfse works with nfs.exports(5) that is not compatible with exports(5). 2. nfse run with the -C switch is completely compatible with exports(5). 3. mountd is incompatible with exports(5). Detail description for 2 and 3 statements is here: http://nfse.sourceforge.net/COMPATIBILITY Originally mountd was more or less compatible with exports(5), but it was broken several years ago. I corrected some of these mistakes: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/170295 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/170413 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/170447 Some command line options that exist in mountd are not supported by nfse. Some of these command line options do not work correctly or are ignored in mountd. There are some questions related to integration that I gave in the QUESTIONS file from the NFSE archive. New nfs.exports(5) was proposed, just because existent exports(5) cannot solve some configuration tasks. The style of nfs.exports(5) is based on style of exports(5) from FreeBSD, but semantics is different. If one wants to use exports(5), then there is the compatibility mode in nfse (the -C command line switch). Some existent exports(5) configurations will not work, just because they were not written according to exports(5) rules and "nfse -C" is completely compatible with exports(5) rules and is strict to exports(5) rules. (well the -webnfs option is not supported by nfse) >From my point of view there are logic errors in exports(5), I tried to correct them in nfs.exports(5). There are logic errors in mountd from CURRENT and recent STABLEs, so people can get some unexpected results and because of complexity of exports(5) (mount points vs subdirectories) can think that this is correct behaviour and mountd is just more flexible. From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 17:25:18 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11FD7106564A for ; Mon, 3 Sep 2012 17:25:18 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id C27F38FC16 for ; Mon, 3 Sep 2012 17:25:17 +0000 (UTC) Received: by iebc12 with SMTP id c12so4757892ieb.13 for ; Mon, 03 Sep 2012 10:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y/X+FNS1CRpHYafi7uBEEAsVYlMeeGmTCYCnS6eGgIo=; b=DhIVJJ7vu4X9kSleZIxtvrg2Wp1hXgo0OIIlIaBN5xfnvpmKyW00MpUZYFsiDT0zj7 MN9HKs0gD2N181PwxvumnO7hyJdrwdJEXPMqN6aKfYPIgBSNtftTaVX1yXG3qMJ5Btwu OfTcBKD5yubGfiix9fY4uZ7TLee6aUToYoj1c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Y/X+FNS1CRpHYafi7uBEEAsVYlMeeGmTCYCnS6eGgIo=; b=LQtjaiW8HutwZIkthDS/lLmRPhMN43+7N19+Tf1MTf7IXmfgmX3eDxZV6rYtrQJGWm b5cK7OMolmSEGiB+GK1hup5AYsH1Uy24ZcOhi6P6Z95ZpM9FX1DazzrRb4/nIzVWmktw OMDl2b9CziZI2KVWYgBIIVvEkipAvgJcLbPAi1LoRuKONdXkRaNyAnNzWq25PWgVnDvU Xw4FpeLdM+vUi7btf0jozed2pBVvRfGcAUYNIMqj/mWUnANdTxQ4KGJIR3D87B29T7IZ 3DuU6RwWCJb0oSGRDnXmlVfW5zFix2hp9RFIOAOauBaF8w4R2c3nuWLBMTcnobbcsy4n yO/w== MIME-Version: 1.0 Received: by 10.50.237.38 with SMTP id uz6mr11474114igc.2.1346693117132; Mon, 03 Sep 2012 10:25:17 -0700 (PDT) Received: by 10.50.0.140 with HTTP; Mon, 3 Sep 2012 10:25:17 -0700 (PDT) In-Reply-To: <5043B866.6060204@nexenta.com> References: <50438BF5.8030004@gibfest.dk> <5043B0CB.8040907@gibfest.dk> <20120902193100.GG1266@glenbarber.us> <5043B866.6060204@nexenta.com> Date: Mon, 3 Sep 2012 10:25:17 -0700 Message-ID: From: Matthew Ahrens To: Yuri Pankov Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnPo0PpldiHFrdAVLYpK4I7dhTDQx2onxI44R11tyVlQY/+ubbqnCr+t8x8nS0fzCE7jrqb Cc: freebsd-fs , illumos-zfs Subject: Re: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 17:25:18 -0000 On Sun, Sep 2, 2012 at 12:49 PM, Yuri Pankov wrote: > On Sun, 2 Sep 2012 15:31:00 -0400, Glen Barber wrote: >> >> On Sun, Sep 02, 2012 at 09:17:31PM +0200, Thomas Steen Rasmussen wrote: >>>> >>>> Hello list, >>>> >>>> For some reason it seems like the -r argument to "zfs send" isn't >>>> implemented in FreeBSD. It is documented in the usage output >>>> seen below: >>>> >>>> >>>> I had a similar experience with out-of-sync docs and then I think a >>>> missing mergemaster might have had something to do with it. >>>> >>> Hello, >>> >>> This is not just the manpage out of sync. Ironically >>> the zfs tool itself reports the lower-case -r option >>> in the usage output that it shows me because -r >>> is an invalid option: >>> >>> ------------------------------------------------------------ >>> $ zfs send -r >>> invalid option 'r' >>> usage: >>> send [-DnPpRrv] [-i snapshot | -I snapshot] >>> >> >> I reported this to Martin a few days ago, but not yet had time myself to >> check if this is also a bug upstream. > > > Talking about upstream, looks like -r was added to usage and man page in > r13524 by Matthew Ahrens (CCed), but the functionality itself is missing. Indeed. This was a mistake. A long time ago we intended to implement this flag, but it was never integrated. I think I typo'ed the options string in the zfs command; and then when writing the manpage I remembered that long-lost implementation. In any case, we should remove the documentation of the "zfs send -r" flag, as that flag doesn't actually exist. --matt From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 19:30:16 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C144106567E for ; Mon, 3 Sep 2012 19:30:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EA6898FC15 for ; Mon, 3 Sep 2012 19:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q83JUF3P056933 for ; Mon, 3 Sep 2012 19:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q83JUFCo056924; Mon, 3 Sep 2012 19:30:15 GMT (envelope-from gnats) Date: Mon, 3 Sep 2012 19:30:15 GMT Message-Id: <201209031930.q83JUFCo056924@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Paavo Pokkinen Cc: Subject: Re: kern/161968: [zfs] [hang] renaming snapshot with -r including a zvol snapshot causes total ZFS freeze/lockup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paavo Pokkinen List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 19:30:16 -0000 The following reply was made to PR kern/161968; it has been noted by GNATS. From: Paavo Pokkinen To: bug-followup@FreeBSD.org, peter.maloney@brockmann-consult.de Cc: Subject: Re: kern/161968: [zfs] [hang] renaming snapshot with -r including a zvol snapshot causes total ZFS freeze/lockup Date: Mon, 03 Sep 2012 22:16:46 +0300 I can confirm this exists on 9.1-RC1. Simply issuing "zfs snapshot -r pakka@test" and after that "zfs rename -r pakka@test pakka@test2" hangs. The filesystem appears to continue work, but all zfs commands start hanging. Only reboot eventually helps. CTRL-T gives me: load: 0.00 cmd: zfs 1629 [tx->tx_sync_done_cv)] 412.62r 0.00u 0.00s 0% 2640k The hardware is pentium G630T with 8G ram on asus P8H77-I, four disks are WD RED 3TB. The zpool is raidz1, and I'm using it on plain disks without partitioning. I also have swap on zvol, apparently it also gets snapshotted. -- Paavo Pokkinen From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 20:30:15 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74A711065673 for ; Mon, 3 Sep 2012 20:30:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 162C88FC0A for ; Mon, 3 Sep 2012 20:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q83KUEhS045525 for ; Mon, 3 Sep 2012 20:30:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q83KUE4b045507; Mon, 3 Sep 2012 20:30:14 GMT (envelope-from gnats) Date: Mon, 3 Sep 2012 20:30:14 GMT Message-Id: <201209032030.q83KUE4b045507@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Paavo Pokkinen Cc: Subject: Re: kern/161968: [zfs] [hang] renaming snapshot with -r including a zvol snapshot causes total ZFS freeze/lockup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paavo Pokkinen List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 20:30:15 -0000 The following reply was made to PR kern/161968; it has been noted by GNATS. From: Paavo Pokkinen To: bug-followup@FreeBSD.org, peter.maloney@brockmann-consult.de Cc: Subject: Re: kern/161968: [zfs] [hang] renaming snapshot with -r including a zvol snapshot causes total ZFS freeze/lockup Date: Mon, 03 Sep 2012 23:25:00 +0300 I did some testing, and it appears at least in my case hanging is related to presence of zvols. I removed my swap zvol, and renaming snapshots appears to work fine. Then I created the zvol (did not swapon), and hang appeared just like previously. -- Paavo Pokkinen From owner-freebsd-fs@FreeBSD.ORG Tue Sep 4 00:51:38 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41D061065673; Tue, 4 Sep 2012 00:51:38 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 937408FC0C; Tue, 4 Sep 2012 00:51:37 +0000 (UTC) Received: by wicr5 with SMTP id r5so3476344wic.13 for ; Mon, 03 Sep 2012 17:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=7VNTIbgGefmas4gwDbs9Fs6dimr2a6cWdCN7QUpeu1w=; b=WNopC3TXwuumkWGQyf/6VkV3lYIHkeaJ/zCQwvRhx696Aec5kUOFj/dQlT/zv8dfdv lAfkgBxcbZ6x/5tLZi2yOCyyw5vGJdn13RDP8ygdfH4jpXFPW/8JUSAho+Gvie6HkNl2 q45rieqMr9N9LOz51Jmuh0Lpb9yLR3bskFyZhgOhchEMamn3sj8AtVGVJnaaLh4I0JEG 1D+TXDpno/C4B0O8XQMkEvyWgbPsGt1Cl5Q9JZewZzUPwO6ZiumLMpvKmpNHOzfjPMhi 95rmPT3RxbMI3GWhanHx0eZ1JT/2YXv6K3SYPDy5Mm9eVCE0znAWbg+kb0QZKSM4/uru 50Ow== Received: by 10.216.134.169 with SMTP id s41mr10696517wei.183.1346719896611; Mon, 03 Sep 2012 17:51:36 -0700 (PDT) Received: from [192.168.1.104] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPS id el6sm21684401wib.8.2012.09.03.17.51.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Sep 2012 17:51:36 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: Date: Tue, 4 Sep 2012 02:51:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0BA0AE08-FF4D-422E-A00A-D8AA1146B66A@FreeBSD.org> References: To: Ivan Voras X-Mailer: Apple Mail (2.1278) Cc: freebsd-fs@freebsd.org Subject: Re: UFS and ACLs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 00:51:38 -0000 Wiadomo=B6=E6 napisana przez Ivan Voras w dniu 2 wrz 2012, o godz. = 23:25: > Hi, >=20 > Can someone give an estimated / expected answer on these questions: >=20 > * What is the performance impact (if any) for file systems mounted = with > either of the ACL options: acls, nfsv4acls, in the situation where = most > of the files do not have (and do not need) any ACLs? Performance impact for files that don't have an ACL should be = unmeasurable. ACLs are stored in extended attributes, and that has some impact, but we don't store ACLs unless it's actually required. > * Will the kernel automagically add ACLs (other than the regular Unix > DAC bits) to new files on file systems mounted with acls/nfsv4acls? No, unless there are some inheritable ACL entries on the containing directory. > * The "regular" DAC bits have some nice propagation rules, e.g. new > files created by a user belonging to a group which owns the directory > have the GID of this group. Does this work with ACLs? Yes. Mounting the filesystem with ACLs doesn't change anything at all in the behaviour, until you actually set some ACLs. > * Which is the easier option to use/maintain, POSIX or NFSv4 ACLs? Depends on what you need. Conceptually POSIX ACLs are simpler. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-fs@FreeBSD.ORG Tue Sep 4 02:18:06 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4024106566C for ; Tue, 4 Sep 2012 02:18:06 +0000 (UTC) (envelope-from ian@ianshome.com) Received: from smtp2.woosh.co.nz (smtp2.woosh.co.nz [202.74.207.41]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0D38FC08 for ; Tue, 4 Sep 2012 02:18:06 +0000 (UTC) Received: from 202-74-193-82.static.woosh.co.nz ([202.74.193.82] helo=[192.168.42.9]) by smtp2.woosh.co.nz with esmtp (Exim 4.77) (envelope-from ) id 1T8iFJ-0000h1-Pp; Tue, 04 Sep 2012 13:48:05 +1200 Message-ID: <50455DD3.9070808@ianshome.com> Date: Tue, 04 Sep 2012 13:48:03 +1200 From: Ian Collins User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:12.0) Gecko/20120423 Thunderbird/12.0 MIME-Version: 1.0 To: zfs@lists.illumos.org References: <50438BF5.8030004@gibfest.dk> <5043B0CB.8040907@gibfest.dk> <20120902193100.GG1266@glenbarber.us> <5043B866.6060204@nexenta.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs , Matthew Ahrens , Yuri Pankov Subject: Re: [zfs] Re: zfs send -r missing - but documented in zfs(8) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 02:18:06 -0000 On 09/ 4/12 05:25 AM, Matthew Ahrens wrote: > On Sun, Sep 2, 2012 at 12:49 PM, Yuri Pankov wrote: >> On Sun, 2 Sep 2012 15:31:00 -0400, Glen Barber wrote: >>> On Sun, Sep 02, 2012 at 09:17:31PM +0200, Thomas Steen Rasmussen wrote: >>>>> Hello list, >>>>> >>>>> For some reason it seems like the -r argument to "zfs send" isn't >>>>> implemented in FreeBSD. It is documented in the usage output >>>>> seen below: >>>>> >>>>> >>>>> I had a similar experience with out-of-sync docs and then I think a >>>>> missing mergemaster might have had something to do with it. >>>>> >>>> Hello, >>>> >>>> This is not just the manpage out of sync. Ironically >>>> the zfs tool itself reports the lower-case -r option >>>> in the usage output that it shows me because -r >>>> is an invalid option: >>>> >>>> ------------------------------------------------------------ >>>> $ zfs send -r >>>> invalid option 'r' >>>> usage: >>>> send [-DnPpRrv] [-i snapshot | -I snapshot] >>>> >>> I reported this to Martin a few days ago, but not yet had time myself to >>> check if this is also a bug upstream. >> >> Talking about upstream, looks like -r was added to usage and man page in >> r13524 by Matthew Ahrens (CCed), but the functionality itself is missing. > Indeed. This was a mistake. A long time ago we intended to implement > this flag, but it was never integrated. I think I typo'ed the options > string in the zfs command; and then when writing the manpage I > remembered that long-lost implementation. > > In any case, we should remove the documentation of the "zfs send -r" > flag, as that flag doesn't actually exist. It is implemented (and useful, I used it today!) in Solaris 11. Will it ever follow on to illumos? -- Ian. From owner-freebsd-fs@FreeBSD.ORG Tue Sep 4 05:26:53 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2760106566B for ; Tue, 4 Sep 2012 05:26:53 +0000 (UTC) (envelope-from httpd@weblinux04.bighost.com.br) Received: from weblinux04.bighost.com.br (static.200.219.245.52.datacenter1.com.br [200.219.245.52]) by mx1.freebsd.org (Postfix) with ESMTP id 91F498FC17 for ; Tue, 4 Sep 2012 05:26:53 +0000 (UTC) Received: by weblinux04.bighost.com.br (Postfix, from userid 398) id D9650522A2; Tue, 4 Sep 2012 01:59:26 -0300 (BRT) To: freebsd-fs@freebsd.org X-PHP-Script: technotest.com.br/arquivos/Empresa/1.php for 123.108.252.51 From: Gmail Team Content-Transfer-Encoding: 8bit Message-Id: <20120904045926.D9650522A2@weblinux04.bighost.com.br> Date: Tue, 4 Sep 2012 01:59:26 -0300 (BRT) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Access temporarily disabled X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 05:26:53 -0000 Account has been disabled You've been redirected to this page from the sign-in page, it means that access to your Google Account is about to be disabled. In most cases, accounts are disabled if we believe you have violated either the Google Terms of Service. new window product-specific Terms of Service (available on the product page), or [1]product-specific policies. new window Your account has not been deleted, your data is still intact, and it is possible to regain access to your account. Click the link to regain access to your account [2]http://support.google.com/accounts/bin/request.py?hl=en&contact_typ e=disabled2&p= Why Google disables accounts Google wants to ensure that everyone has a chance to safely and securely connect and communicate. To help preserve this environment, Google reserves the right to: Please start by reviewing the relevant Terms of Service. ©2012 Google - [3]Google Home - [4]Terms of Service - [5]Privacy Policy - [6]Help References 1. file://www.google.com/support/accounts/bin/answer.py?answer=147806 2. http://7iemejour.free.fr/language/en-GB/maill.htm 3. http://www.google.com/ 4. https://accounts.google.com/TOS?hl=en 5. http://www.google.com/intl/en/privacy/ 6. http://www.google.com/support/accounts?hl=en From owner-freebsd-fs@FreeBSD.ORG Wed Sep 5 09:19:03 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0BD61065687; Wed, 5 Sep 2012 09:19:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 898598FC08; Wed, 5 Sep 2012 09:19:02 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q859J7ih064743; Wed, 5 Sep 2012 12:19:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q859IsVd051302; Wed, 5 Sep 2012 12:18:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q859IsTf051301; Wed, 5 Sep 2012 12:18:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 5 Sep 2012 12:18:54 +0300 From: Konstantin Belousov To: fs@freebsd.org Message-ID: <20120905091854.GD33100@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8nNlsiDOXg6+a5Ho" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: pho@freebsd.org Subject: Nullfs shared lookup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 09:19:03 -0000 --8nNlsiDOXg6+a5Ho Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I, together with Peter Holm, developed a patch to enable shared lookups on nullfs mounts when lower filesystem allows the shared lookups. The lack of shared lookup support for nullfs is quite visible on any VFS-intensive workloads which utilize path translations. In particular, it was a complain on $dayjob which started me thinking about this issue. There are two problems which prevent direct translation of shared lookup bit into nullfs upper mount bit: 1. When vfs_lookup() calls VOP_LOOKUP() for nullfs, which passes lookup operation to lower fs, resulting vnode is often only shared-locked. Then null_nodeget() cannot instantiate covering vnode for lower vnode, since insmntque1() and null_hashins() require exclusive lock on the lower. The solution is straightforward, if null hash failed to find pre-existing nullfs vnode for lower vnode, the lower vnode lock is upgraded. 2. (More serious). Nullfs reclaims its vnodes on deactivation. The cause is due to nullfs inability to detect reclamation of the lower vnode. Reclamation of a nullfs vnode at deactivation time prevents a reference to the lower vnode to become stale. Unfortunately, this means that all lookups on nullfs need exclusive lock to instantiate upper vnode, which is never cached. Solution which we propose is to add VFS notification to the upper filesystem about reclamation of the vnode in the lower filesystem. Now, vgone() calls new VFS op vfs_reclaim_lowervp() with an argument lowervp which is reclaimed. It is possible to register several reclamation event listeners, to correctly handle the case of several nullfs mounts over the same directory. For the filesystem not having nullfs mounts over it, the overhead added is a single mount interlock lock/unlock in the vnode reclamation path. Benchmarks consisting of up 1K threads doing parallel stat(2) on the same file demonstate almost constant execution time, not depending of number of running threads. While without the patch, exec time between single-threaded run and run with 1024 threads performing the same total count of stat(2), differ in 6 times. Somewhat problematic detail, IMO, is that nullfs reclamation procedure calls vput() on the lowervp vnode, temporary unlocking the vnode being reclaimed. This seems to be fine for MPSAFE filesystems, but not-MPSAFE code often put partially initialized vnode on some globally visible list, and later can decide that half-constructed vnode is not needed. If nullfs mount is created above such filesystem, then other threads might catch such not properly initialized vnode. Instead of trying to overcome this case, e.g. by recursing the lower vnode lock in null_reclaim_lowervp(), I decided to rely on nearby extermination of non-MPSAFE filesystems support. I think that unionfs can also benefit from this mechanism, but I did not even looked at unionfs. Patch is available at http://people.freebsd.org/~kib/misc/nullfs_shared_lookup.1.patch It survived stress2 torturing. Comments ? --8nNlsiDOXg6+a5Ho Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBHGP4ACgkQC3+MBN1Mb4jWwACg0Wt552c/FcNg9Gc8MC8z36wv DsMAnAoCKzEU561FtBc4rUMJZLiKAUO5 =qa7h -----END PGP SIGNATURE----- --8nNlsiDOXg6+a5Ho-- From owner-freebsd-fs@FreeBSD.ORG Wed Sep 5 13:58:32 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83C2A106566C for ; Wed, 5 Sep 2012 13:58:32 +0000 (UTC) (envelope-from attila.bogar@linguamatics.com) Received: from mail.linguamatics.com (mail.linguamatics.com [188.39.80.203]) by mx1.freebsd.org (Postfix) with ESMTP id 05B968FC1C for ; Wed, 5 Sep 2012 13:58:31 +0000 (UTC) Received: from [10.252.10.232] (random.linguamatics.com [10.252.10.232]) by mail.linguamatics.com (Postfix) with ESMTPSA id D0196EFB450; Wed, 5 Sep 2012 14:58:24 +0100 (BST) Message-ID: <50475A81.2040105@linguamatics.com> Date: Wed, 05 Sep 2012 14:58:25 +0100 From: =?UTF-8?B?QXR0aWxhIEJvZ8Ohcg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Rick Macklem References: <817398955.1415204.1346543870350.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <817398955.1415204.1346543870350.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@FreeBSD.org Subject: Re: NFS: rpcsec_gss with Linux clients X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:58:32 -0000 Hi Rick, On 02/09/12 00:57, Rick Macklem wrote: > This certainly sounds bogus. I can see an argument for 2 TCP > connections for trunking, but since a security context should only be > destroyed when the client is done with it, doing a DESTROY doesn't > make sense? (There is something in the RPC header called a "handle". > It identifies the security context, and it would be nice to check the > wireshark trace to see if it the same as the one being used on the > other connection?) TCP0: -> Linux NFS AUTH_NULL TCP0: <- FreeBSD responds TCP1: -> Linux sends RPCSEC_GSS_INIT TCP1: <- FreeBSD responds by establishing GSS Context (it's a 16 byte token) TCP1: -> Linux sends RPCSEC_GSS_DESTROY using the received 16 byte token TCP0: -> Linux sends NFS:PUTROOTFS|GETATTR using the same 16 byte received gss context token >> I don't quite know why, but during the destroy within the the >> svc_rpc_gss_validate() gss_verify_mic() returns maj_stat = >> GSS_S_DEFECTIVE_TOKEN, no matter what heimdal version I use. >> > That would indicate the encrypted checksum isn't correct. It > might be using an algorithm only supported by the newer RPCSEC_GSS_V3? It's RPC version 2, GSS version: 1 > For DESTROY when it will fail, I'm not sure if marking the > context stale makes sense. (I can see an argument for and against > doing this.) If you "know" other people's context by snooping the wire, you can invalidate their client entry on the nfs server by sending a corrupted (corrupted, because you don't know their keytab) RPCSEC_GSS_DESTROY message. I suspect an attacker can force the kerberos clients to re-establish the security context again and again. I'm not sure this statistically can lead to any advantage breaking the keys, kerberos experts may answer this. > I've attached a small patch with disables setting client->cl_state > to CLIENT_STALE for this case, which you could try, to see if it > helps? I'll look at it. > I'd suggest contacting the Linux folks first and see if they are > willing to look at the wireshark trace or know of an issue/fix, > because it really sounds like a Linux client issue. > Waiting 4 minutes instead of 5 shouldn't have any real effect, > although it might avoid the problem for your case w.r.t. timing. This is an intuition to test a fix for another bug. I noticed, that when my users need long file access, they get a permission denied error at the gss key change time, which is very annoying after the program having run for multiple hours. > This time is usually the TGT lifetime (12->24hrs), so subtracting > 12 sec from it doesn't really make any sense. (I will note that > the calculation of cred_lifetime for the GSS_C_INDEFINITE case > looks incorrect, since time_uptime gets added twice, but I doubt > that's relevant to your problem, since it is set to more than 24hrs.) The rpcsec timestamp is valid, so this passes this layer. But when it's actually handled by the NFS layer, how can this permission denied come into the picture? Is there another GSS timestamp check on the upper level? > /* > * Fill in cred details in the rawcred structure. > @@ -990,7 +995,7 @@ > gss_buffer_desc rpcbuf, checksum; > OM_uint32 maj_stat, min_stat; > gss_qop_t qop_state; > - int32_t rpchdr[128 / sizeof(int32_t)]; > + int32_t rpchdr[2048 / sizeof(int32_t)]; > int32_t *buf; Note, that I changed the buffer from 128 bytes to 2048 bytes. This is as per PR 162009, which is also hanging around. I think checking the code for the RPC 128 byte buffers would be nice for security and other reasons. I'm going to send an email to the linux-nfs@ to find out what's going on this area - maybe this has been already fixed, as I use some old EL6 and Ubuntu 12.04 flavours. However dropping the sec context even with failed kerberos ticket seems like a FreeBSD bug. Kind regards, Attila -- Attila Bogár Systems Administrator Linguamatics - Cambridge, UK http://www.linguamatics.com/ From owner-freebsd-fs@FreeBSD.ORG Wed Sep 5 15:40:11 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86A61106564A for ; Wed, 5 Sep 2012 15:40:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE568FC0C for ; Wed, 5 Sep 2012 15:40:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q85FeBAk071950 for ; Wed, 5 Sep 2012 15:40:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q85FeBIJ071933; Wed, 5 Sep 2012 15:40:11 GMT (envelope-from gnats) Date: Wed, 5 Sep 2012 15:40:11 GMT Message-Id: <201209051540.q85FeBIJ071933@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Nikolai Schupbach Cc: Subject: Re: kern/156781: [zfs] zfs is losing the snapshot directory, X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nikolai Schupbach List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:40:11 -0000 The following reply was made to PR kern/156781; it has been noted by GNATS. From: Nikolai Schupbach To: bug-followup@FreeBSD.org Cc: bmeyer@mesoft.com.au Subject: Re: kern/156781: [zfs] zfs is losing the snapshot directory, Date: Thu, 6 Sep 2012 03:28:26 +1200 I would like to note that we are also experiencing this issue. We are = just using the basic core ZFS features only - snapshots and zfs = send/receive. There does not seem to be any set pattern as to when this = issue occurs (the machine below had the issue appear after 47 days) and = it doesn't affect all filesystems at once. It would be good if we could get some traction on this issue as it = appears to be a systemic issue, across all releases and architectures, = reported by multiple people over the last 2-3 years. As snapshots are a = basic core feature of ZFS, I would really like to see this bug moved to = a higher priority. # ls -l /mailstore/domains/.zfs ls: snapshot: Bad file descriptor total 2 dr-xr-xr-x 2 root wheel 2 Jul 19 15:46 shares # uname -a FreeBSD 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 = UTC 2012 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # uptime 2:45AM up 47 days, 4:30, 1 user, load averages: 0.29, 0.29, 0.21 # zfs list NAME USED AVAIL REFER MOUNTPOINT mailstore 466G 3.11T 34K /mailstore mailstore/domains 464G 3.11T 247G /mailstore/domains mailstore/queue 3.31M 100G 102K /mailstore/queue mailstore/var 1.30G 3.11T 182M /mailstore/var system 15.4G 258G 32K none system/root 15.2G 258G 7.08G legacy # zpool status pool: mailstore state: ONLINE scan: scrub repaired 0 in 0h11m with 0 errors on Sun Aug 19 03:13:05 = 2012 config: NAME STATE READ WRITE CKSUM mailstore ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 label/disk8 ONLINE 0 0 0 label/disk16 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 label/disk9 ONLINE 0 0 0 label/disk17 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 label/disk10 ONLINE 0 0 0 label/disk18 ONLINE 0 0 0 mirror-3 ONLINE 0 0 0 label/disk11 ONLINE 0 0 0 label/disk19 ONLINE 0 0 0 mirror-4 ONLINE 0 0 0 label/disk12 ONLINE 0 0 0 label/disk20 ONLINE 0 0 0 mirror-5 ONLINE 0 0 0 label/disk13 ONLINE 0 0 0 label/disk21 ONLINE 0 0 0 mirror-6 ONLINE 0 0 0 label/disk14 ONLINE 0 0 0 label/disk22 ONLINE 0 0 0 mirror-7 ONLINE 0 0 0 label/disk15 ONLINE 0 0 0 label/disk23 ONLINE 0 0 0 logs mirror-8 ONLINE 0 0 0 label/disk3 ONLINE 0 0 0 label/disk4 ONLINE 0 0 0 cache label/disk5 ONLINE 0 0 0 spares label/disk6 AVAIL =20 label/disk7 AVAIL =20 errors: No known data errors pool: system state: ONLINE scan: scrub repaired 0 in 0h4m with 0 errors on Mon Aug 20 03:05:52 = 2012 config: NAME STATE READ WRITE CKSUM system ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 spares gpt/disk2 AVAIL =20 errors: No known data errors # zpool get all mailstore NAME PROPERTY VALUE SOURCE mailstore size 3.62T - mailstore capacity 12% - mailstore altroot - default mailstore health ONLINE - mailstore guid 5477043980362510628 default mailstore version 28 default mailstore bootfs - default mailstore delegation on default mailstore autoreplace off default mailstore cachefile - default mailstore failmode wait default mailstore listsnapshots off default mailstore autoexpand off default mailstore dedupditto 0 default mailstore dedupratio 1.00x - mailstore free 3.17T - mailstore allocated 466G - mailstore readonly off =20 # zfs get all mailstore/domains NAME PROPERTY VALUE SOURCE mailstore/domains type filesystem - mailstore/domains creation Thu Jul 19 15:46 2012 - mailstore/domains used 463G - mailstore/domains available 3.11T - mailstore/domains referenced 247G - mailstore/domains compressratio 1.00x - mailstore/domains mounted yes - mailstore/domains quota none default mailstore/domains reservation none default mailstore/domains recordsize 128K default mailstore/domains mountpoint /mailstore/domains default mailstore/domains sharenfs off default mailstore/domains checksum on default mailstore/domains compression off default mailstore/domains atime off local mailstore/domains devices on default mailstore/domains exec on default mailstore/domains setuid off = inherited from mailstore mailstore/domains readonly off default mailstore/domains jailed off default mailstore/domains snapdir hidden default mailstore/domains aclmode discard default mailstore/domains aclinherit restricted default mailstore/domains canmount on default mailstore/domains xattr off = temporary mailstore/domains copies 1 default mailstore/domains version 5 - mailstore/domains utf8only off - mailstore/domains normalization none - mailstore/domains casesensitivity sensitive - mailstore/domains vscan off default mailstore/domains nbmand off default mailstore/domains sharesmb off default mailstore/domains refquota none default mailstore/domains refreservation none default mailstore/domains primarycache all default mailstore/domains secondarycache all default mailstore/domains usedbysnapshots 217G - mailstore/domains usedbydataset 247G - mailstore/domains usedbychildren 0 - mailstore/domains usedbyrefreservation 0 - mailstore/domains logbias latency default mailstore/domains dedup off default mailstore/domains mlslabel - mailstore/domains sync standard default mailstore/domains refcompressratio 1.00x - # zpool history History for 'mailstore': 2012-07-19.15:46:37 zpool create -f mailstore mirror label/disk8 = label/disk16 mirror label/disk9 label/disk17 mirror label/disk10 = label/disk18 mirror label/disk11 label/disk19 mirror label/disk12 = label/disk20 mirror label/disk13 label/disk21 mirror label/disk14 = label/disk22 mirror label/disk15 label/disk23 log mirror label/disk3 = label/disk4 cache label/disk5 spare label/disk6 label/disk7 2012-07-28.10:30:00 zfs snapshot -r mailstore@autosnap-2012-07-28_10.30 2012-07-28.10:30:05 zfs destroy -r mailstore@autosnap-2012-07-28_08.30 2012-07-28.10:45:01 zfs snapshot -r mailstore@autosnap-2012-07-28_10.45 2012-07-28.10:45:06 zfs destroy -r mailstore@autosnap-2012-07-28_08.45 2012-07-28.11:00:01 zfs snapshot -r mailstore@autosnap-2012-07-28_11.00 2012-07-28.11:00:06 zfs destroy -r mailstore@autosnap-2012-07-27_11.00 2012-07-28.11:15:00 zfs snapshot -r mailstore@autosnap-2012-07-28_11.15 2012-07-28.11:15:05 zfs destroy -r mailstore@autosnap-2012-07-28_09.15 2012-07-28.11:30:01 zfs snapshot -r mailstore@autosnap-2012-07-28_11.30 ... 2012-09-06.02:00:01 zfs snapshot -r mailstore@autosnap-2012-09-06_02.00 2012-09-06.02:00:06 zfs destroy -r mailstore@autosnap-2012-09-05_02.00 2012-09-06.02:15:00 zfs snapshot -r mailstore@autosnap-2012-09-06_02.15 2012-09-06.02:15:05 zfs destroy -r mailstore@autosnap-2012-09-06_00.15 2012-09-06.02:30:00 zfs snapshot -r mailstore@autosnap-2012-09-06_02.30 2012-09-06.02:30:05 zfs destroy -r mailstore@autosnap-2012-09-06_00.30 2012-09-06.02:45:00 zfs snapshot -r mailstore@autosnap-2012-09-06_02.45 2012-09-06.02:45:05 zfs destroy -r mailstore@autosnap-2012-09-06_00.45 # truss ls -l /mailstore/domains/.zfs mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D = 34366279680 (0x80063d000) issetugid(0x80063e015,0x800632d7e,0x80084e7f0,0x80084e7c0,0xb297,0x0) =3D = 0 (0x0) open("/etc/libmap.conf",O_RDONLY,0666) ERR#2 'No such file or = directory' open("/var/run/ld-elf.so.hints",O_RDONLY,057) =3D 3 (0x3) read(3,"Ehnt\^A\0\0\0\M^@\0\0\0u\0\0\0\0"...,128) =3D 128 (0x80) lseek(3,0x80,SEEK_SET) =3D 128 (0x80) read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,117) =3D 117 (0x75) close(3) =3D 0 (0x0) access("/lib/libutil.so.9",0) =3D 0 (0x0) open("/lib/libutil.so.9",O_RDONLY,041017540) =3D 3 (0x3) fstat(3,{ mode=3D-r--r--r-- ,inode=3D10999,size=3D70168,blksize=3D70656 = }) =3D 0 (0x0) pread(0x3,0x800840f40,0x1000,0x0,0x101010101010101,0x8080808080808080) =3D= 4096 (0x1000) mmap(0x0,2166784,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =3D = 34368450560 (0x80084f000) = mmap(0x80084f000,61440,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCOR= E,3,0x0) =3D 34368450560 (0x80084f000) = mmap(0x800a5e000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xf000)= =3D 34370609152 (0x800a5e000) = mmap(0x800a5f000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,= -1,0x0) =3D 34370613248 (0x800a5f000) close(3) =3D 0 (0x0) access("/lib/libncurses.so.8",0) =3D 0 (0x0) open("/lib/libncurses.so.8",O_RDONLY,041017540) =3D 3 (0x3) fstat(3,{ mode=3D-r--r--r-- ,inode=3D10996,size=3D321040,blksize=3D131072 = }) =3D 0 (0x0) pread(0x3,0x800840f40,0x1000,0x0,0x101010101010101,0x8080808080808080) =3D= 4096 (0x1000) mmap(0x0,2412544,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =3D = 34370617344 (0x800a60000) = mmap(0x800a60000,294912,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCO= RE,3,0x0) =3D 34370617344 (0x800a60000) = mmap(0x800ca8000,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x4800= 0) =3D 34373009408 (0x800ca8000) close(3) =3D 0 (0x0) access("/lib/libc.so.7",0) =3D 0 (0x0) open("/lib/libc.so.7",O_RDONLY,041017540) =3D 3 (0x3) fstat(3,{ mode=3D-r--r--r-- ,inode=3D10991,size=3D1315160,blksize=3D131072= }) =3D 0 (0x0) pread(0x3,0x800840f40,0x1000,0x0,0x101010101010101,0x8080808080808080) =3D= 4096 (0x1000) mmap(0x0,3432448,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =3D = 34373029888 (0x800cad000) = mmap(0x800cad000,1179648,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOC= ORE,3,0x0) =3D 34373029888 (0x800cad000) = mmap(0x800fcd000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x1200= 00) =3D 34376306688 (0x800fcd000) = mmap(0x800fd8000,110592,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANO= N,-1,0x0) =3D 34376351744 (0x800fd8000) close(3) =3D 0 (0x0) munmap(0x800644000,4096) =3D 0 (0x0) mmap(0x0,40960,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D = 34366308352 (0x800644000) munmap(0x80064a000,16384) =3D 0 (0x0) mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D = 34366332928 (0x80064a000) = sysarch(0x81,0x7fffffffd310,0x800643188,0x0,0xffffffffff672680,0x808080808= 0808080) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) ioctl(1,TIOCGETA,0xffffd410) =3D 0 (0x0) ioctl(1,TIOCGWINSZ,0xffffd470) =3D 0 (0x0) getuid() =3D 0 (0x0) readlink("/etc/malloc.conf",0x7fffffffcef0,1024) ERR#2 'No such file or = directory' = issetugid(0x800da9bc1,0x7fffffffcef0,0xffffffffffffffff,0x0,0x2,0x7fffffff= d18f) =3D 0 (0x0) break(0x800000) =3D 0 (0x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D = 34376462336 (0x800ff3000) mmap(0x8013f3000,53248,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = =3D 34380656640 (0x8013f3000) munmap(0x800ff3000,53248) =3D 0 (0x0) lstat("/mailstore/domains/.zfs",{ mode=3Ddr-xr-xr-x = ,inode=3D1,size=3D4,blksize=3D4096 }) =3D 0 (0x0) open(".",O_RDONLY,00) =3D 3 (0x3) fchdir(0x3,0x0,0x20,0x20,0x1,0x0) =3D 0 (0x0) stat("/mailstore/domains/.zfs",{ mode=3Ddr-xr-xr-x = ,inode=3D1,size=3D4,blksize=3D4096 }) =3D 0 (0x0) open("/mailstore/domains/.zfs",O_NONBLOCK|0x20000,0100401200) =3D 4 = (0x4) fstat(4,{ mode=3Ddr-xr-xr-x ,inode=3D1,size=3D4,blksize=3D4096 }) =3D 0 = (0x0) fcntl(4,F_SETFD,FD_CLOEXEC) =3D 0 (0x0) fstatfs(0x4,0x7fffffffd0a0,0x0,0x26,0x606fe0,0x7fffffffc630) =3D 0 (0x0) fstat(4,{ mode=3Ddr-xr-xr-x ,inode=3D1,size=3D4,blksize=3D4096 }) =3D 0 = (0x0) fchdir(0x4,0x7fffffffd2b0,0x4,0x0,0x606fe0,0x7fffffffc610) =3D 0 (0x0) = getdirentries(0x4,0x801027000,0x1000,0x801025068,0x606fe0,0x7fffffffc610) = =3D 60 (0x3c) lstat("snapshot",0x801020450) ERR#9 'Bad file = descriptor' lstat("shares",{ mode=3Ddr-xr-xr-x ,inode=3D7,size=3D2,blksize=3D4096 }) = =3D 0 (0x0) getdirentries(0x4,0x801027000,0x1000,0x801025068,0xffffffffffff95d4,0x0) = =3D 0 (0x0) lseek(4,0x0,SEEK_SET) =3D 0 (0x0) madvise(0x801069000,0x1000,0x5,0x68,0x7fffffffca10,0x7fffffffca10) =3D 0 = (0x0) madvise(0x801026000,0x2000,0x5,0x25,0x7fffffffca10,0x7fffffffca10) =3D 0 = (0x0) madvise(0x801025000,0x1000,0x5,0x24,0x7fffffffca70,0x7fffffffca10) =3D 0 = (0x0) close(4) =3D 0 (0x0) fchdir(0x3,0x0,0x0,0x6,0x801000000,0x7fffffffca80) =3D 0 (0x0) stat("/etc/nsswitch.conf",{ mode=3D-rw-r--r-- = ,inode=3D11094,size=3D323,blksize=3D4096 }) =3D 0 (0x0) open("/etc/nsswitch.conf",O_RDONLY,0666) =3D 4 (0x4) ioctl(4,TIOCGETA,0xffffcaf0) ERR#25 'Inappropriate = ioctl for device' fstat(4,{ mode=3D-rw-r--r-- ,inode=3D11094,size=3D323,blksize=3D4096 }) = =3D 0 (0x0) read(4,"#\n# nsswitch.conf(5) - name ser"...,4096) =3D 323 (0x143) read(4,0x801045000,4096) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) access("/lib/nss_compat.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/nss_compat.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/compat/nss_compat.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/lib/nss_compat.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/lib/dovecot/nss_compat.so.1",0) ERR#2 'No such file = or directory' access("/usr/local/lib/mysql/nss_compat.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/libexec/openldap/nss_compat.so.1",0) ERR#2 'No such = file or directory' access("/lib/nss_compat.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/nss_compat.so.1",0) ERR#2 'No such file or = directory' sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) access("/lib/nss_nis.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/nss_nis.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/compat/nss_nis.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/lib/nss_nis.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/lib/dovecot/nss_nis.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/lib/mysql/nss_nis.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/libexec/openldap/nss_nis.so.1",0) ERR#2 'No such file = or directory' access("/lib/nss_nis.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/nss_nis.so.1",0) ERR#2 'No such file or = directory' sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) access("/lib/nss_files.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/nss_files.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/compat/nss_files.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/lib/nss_files.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/lib/dovecot/nss_files.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/lib/mysql/nss_files.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/libexec/openldap/nss_files.so.1",0) ERR#2 'No such = file or directory' access("/lib/nss_files.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/nss_files.so.1",0) ERR#2 'No such file or = directory' sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) access("/lib/nss_dns.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/nss_dns.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/compat/nss_dns.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/lib/nss_dns.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/lib/dovecot/nss_dns.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/lib/mysql/nss_dns.so.1",0) ERR#2 'No such file or = directory' access("/usr/local/libexec/openldap/nss_dns.so.1",0) ERR#2 'No such file = or directory' access("/lib/nss_dns.so.1",0) ERR#2 'No such file or = directory' access("/usr/lib/nss_dns.so.1",0) ERR#2 'No such file or = directory' sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) ioctl(4,TIOCGETA,0xffffcb00) ERR#25 'Inappropriate = ioctl for device' close(4) =3D 0 (0x0) madvise(0x80108a000,0x1000,0x5,0x89,0x7fffffffc2e0,0xffffffff) =3D 0 = (0x0) madvise(0x801044000,0x2000,0x5,0x43,0x7fffffffc2e0,0xffffffff) =3D 0 = (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) geteuid() =3D 0 (0x0) open("/etc/spwd.db",O_RDONLY,00) =3D 4 (0x4) fcntl(4,F_SETFD,FD_CLOEXEC) =3D 0 (0x0) fstat(4,{ mode=3D-rw------- ,inode=3D54894,size=3D40960,blksize=3D40960 = }) =3D 0 (0x0) read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) =3D 260 (0x104) pread(0x4,0x801090000,0x1000,0x6000,0x1,0x0) =3D 4096 (0x1000) stat("/etc/nsswitch.conf",{ mode=3D-rw-r--r-- = ,inode=3D11094,size=3D323,blksize=3D4096 }) =3D 0 (0x0) stat("/etc/nsswitch.conf",{ mode=3D-rw-r--r-- = ,inode=3D11094,size=3D323,blksize=3D4096 }) =3D 0 (0x0) pread(0x4,0x801091000,0x1000,0x4000,0x1,0x0) =3D 4096 (0x1000) stat("/etc/nsswitch.conf",{ mode=3D-rw-r--r-- = ,inode=3D11094,size=3D323,blksize=3D4096 }) =3D 0 (0x0) open("/etc/group",O_RDONLY,0666) =3D 5 (0x5) stat("/etc/nsswitch.conf",{ mode=3D-rw-r--r-- = ,inode=3D11094,size=3D323,blksize=3D4096 }) =3D 0 (0x0) stat("/etc/nsswitch.conf",{ mode=3D-rw-r--r-- = ,inode=3D11094,size=3D323,blksize=3D4096 }) =3D 0 (0x0) fstat(5,{ mode=3D-rw-r--r-- ,inode=3D11080,size=3D570,blksize=3D4096 }) = =3D 0 (0x0) lseek(5,0x0,SEEK_CUR) =3D 0 (0x0) lseek(5,0x0,SEEK_SET) =3D 0 (0x0) read(5,"# $FreeBSD: release/9.0.0/etc/gr"...,4096) =3D 570 (0x23a) close(5) =3D 0 (0x0) stat("/usr/share/nls/C/libc.cat",0x7fffffffc920) ERR#2 'No such file or = directory' stat("/usr/share/nls/libc/C",0x7fffffffc920) ERR#2 'No such file or = directory' stat("/usr/local/share/nls/C/libc.cat",0x7fffffffc920) ERR#2 'No such = file or directory' stat("/usr/local/share/nls/libc/C",0x7fffffffc920) ERR#2 'No such file = or directory' ls: write(2,"ls: ",4) =3D 4 (0x4) snapshot: Bad file descriptorwrite(2,"snapshot: Bad file descriptor",29) = =3D 29 (0x1d) write(2,"\n",1) =3D 1 (0x1) fstat(1,{ mode=3Dcrw--w---- ,inode=3D185,size=3D0,blksize=3D4096 }) =3D = 0 (0x0) ioctl(1,TIOCGETA,0xffffbff0) =3D 0 (0x0) total 2 write(1,"total 2\n",8) =3D 8 (0x8) lpathconf(0x7fffffffc9e0,0x40,0x0,0x0,0x7ff7fefdc3f0,0x7fffffffc43f) = ERR#22 'Invalid argument' = lpathconf(0x7fffffffc9e0,0x3b,0xffffffffffffffff,0x16,0x7ff7fefdc3f0,0x7ff= fffffc43f) ERR#22 'Invalid argument' clock_gettime(13,{1346858032.000000000 }) =3D 0 (0x0) access("/etc/localtime",4) =3D 0 (0x0) open("/etc/localtime",O_RDONLY,0100000700) =3D 5 (0x5) fstat(5,{ mode=3D-r--r--r-- ,inode=3D16452,size=3D2434,blksize=3D4096 }) = =3D 0 (0x0) read(5,"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0"...,41448) =3D 2434 (0x982) close(5) =3D 0 (0x0) issetugid(0x800db1fd1,0x8010d6000,0x0,0xa7,0x4e,0xc) =3D 0 (0x0) open("/usr/share/zoneinfo/posixrules",O_RDONLY,056) =3D 5 (0x5) fstat(5,{ mode=3D-r--r--r-- ,inode=3D545,size=3D3519,blksize=3D4096 }) =3D= 0 (0x0) read(5,"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0"...,41448) =3D 3519 (0xdbf) close(5) =3D 0 (0x0) madvise(0x80111e000,0xb000,0x5,0x11d,0x7fffffffb880,0x607050) =3D 0 = (0x0) madvise(0x8010d6000,0x5000,0x5,0xd5,0x7fffffffba70,0xffffffff) =3D 0 = (0x0) madvise(0x8010d2000,0x1000,0x5,0xd1,0x7fffffffba70,0xffffffff) =3D 0 = (0x0) madvise(0x801075000,0xb000,0x5,0x74,0x7fffffffba70,0xffffffff) =3D 0 = (0x0) dr-xr-xr-x 2 root wheel 2 Jul 19 15:46 shares write(1,"dr-xr-xr-x 2 root wheel 2 Jul"...,49) =3D 49 (0x31) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) = sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTER= M|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) process exit, rval =3D 1 Regards, Nikolai Schupbach From owner-freebsd-fs@FreeBSD.ORG Wed Sep 5 17:38:55 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CCCC1065676; Wed, 5 Sep 2012 17:38:55 +0000 (UTC) (envelope-from orientalsensation@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id EBC8C8FC1A; Wed, 5 Sep 2012 17:38:54 +0000 (UTC) Received: by iebc12 with SMTP id c12so1990255ieb.13 for ; Wed, 05 Sep 2012 10:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=nin1t0DjpQ8Y2WCWkCL9px7wCD7f2T0ctuv+AphHIAg=; b=ntb93mM5U9gteHC9kju328aSZAd5l5z2MZ2bNhZVTP4PDZUw5O8LxN8XrJowKL/RWd OIgvaGPj2ax4E/HtzjDCWhcjAiPFPQZlnEhOOLc6SduNgpYqHK5blAJAK2whggndNfaf K7cbSjTH23viU+cyrqyomFScusBbEzyPBqtQPUp4kFskJ1HEVaJ0HJtc07+3Ln4IcwDq 2pZMIf88ud1XVAmeCDkVG4zQHFaQeZcFkBJ9gWExF2p/Q4JAn1OVo0McZo7lyb9ebnGp Ygt3sm36tSV+JWrRBKFHh5uU/4K/n4JrJsg+M6MZn3biX53doc+FvLPfBDC9C+hQCEZ3 2kaA== MIME-Version: 1.0 Received: by 10.50.160.233 with SMTP id xn9mr19089398igb.37.1346866734500; Wed, 05 Sep 2012 10:38:54 -0700 (PDT) Sender: orientalsensation@gmail.com Received: by 10.64.81.226 with HTTP; Wed, 5 Sep 2012 10:38:54 -0700 (PDT) Date: Wed, 5 Sep 2012 19:38:54 +0200 X-Google-Sender-Auth: fwvXIjLpxt-LY7KpynAirVnwW_o Message-ID: From: OriS To: freebsd-questions@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Auto-mounting sshfs from /etc/fstab X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 17:38:55 -0000 Hello all, I've been trying to find a page on the Internet where an example is posted explaining how to mount sshfs from /etc/fstab, but I can't find any! I'm on 9.1-PR amd64 and I've installed Fuse and sshfs, I have enabled Fuse in rc.conf and I can see /dev/fuse. Furthermore, using sshfs from the command line, I am even able to mount the remote file system. I can manually mount the remote file system using: *sshfs user@host:/ /mnt* Then, I do 'mount -p' and get: */dev/fuse0 /mnt fusefs.sshfs rw,sync 0 0* This isn't sufficient for mounting/unmounting from fstab since it's missing the authentication details I've used in sshfs. So.. the question is: How to add the authentication details to /etc/fstab so that I can mount the sshfs just by using: *mount /mnt* Thanks in advance, and kindly Cc me on your replies! /OriS From owner-freebsd-fs@FreeBSD.ORG Wed Sep 5 22:29:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 387D9106566B for ; Wed, 5 Sep 2012 22:29:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D1B008FC15 for ; Wed, 5 Sep 2012 22:29:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKLQR1CDaFvO/2dsb2JhbABFhgW2KYIgAQEEASMERAMLBRYHEQICDRkCSBEGiBoGp3OTBYEhigUPhQ+BEgOVWYkzhmeCf4E9CA X-IronPort-AV: E=Sophos;i="4.80,376,1344225600"; d="scan'208";a="180347618" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 05 Sep 2012 18:29:02 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id AC106B401A; Wed, 5 Sep 2012 18:29:02 -0400 (EDT) Date: Wed, 5 Sep 2012 18:29:02 -0400 (EDT) From: Rick Macklem To: =?utf-8?Q?Attila_Bog=C3=A1r?= Message-ID: <87865688.117574.1346884142683.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <50475A81.2040105@linguamatics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org Subject: Re: NFS: rpcsec_gss with Linux clients X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 22:29:10 -0000 Attila Bogar wrote: > Hi Rick, >=20 > On 02/09/12 00:57, Rick Macklem wrote: > > This certainly sounds bogus. I can see an argument for 2 TCP > > connections for trunking, but since a security context should only > > be > > destroyed when the client is done with it, doing a DESTROY doesn't > > make sense? (There is something in the RPC header called a "handle". > > It identifies the security context, and it would be nice to check > > the > > wireshark trace to see if it the same as the one being used on the > > other connection?) > TCP0: -> Linux NFS AUTH_NULL > TCP0: <- FreeBSD responds >=20 > TCP1: -> Linux sends RPCSEC_GSS_INIT > TCP1: <- FreeBSD responds by establishing GSS Context (it's a 16 byte > token) >=20 > TCP1: -> Linux sends RPCSEC_GSS_DESTROY using the received 16 byte > token As I mentioned before, this makes no sense. > TCP0: -> Linux sends NFS:PUTROOTFS|GETATTR using the same 16 byte > received gss context token >=20 Btw, a GSSAPI token is much larger than 16bytes. The 16byte entry is the RPCSEC_GSS handle (shorthand) for the security context created via the RPCSEC_GSS_INIT. This shorthand is known to the client and server and both should know the session key used with this shorthand handle. This shorthand handle can be used by the client until either it does a RPCSEC_GSS_DESTROY of it or the server side replies with an authentication error that tells the client the handle is no longer usable. This latter case can occur when the handle falls out of the server side cache or hits its time limit. > >> I don't quite know why, but during the destroy within the the > >> svc_rpc_gss_validate() gss_verify_mic() returns maj_stat =3D > >> GSS_S_DEFECTIVE_TOKEN, no matter what heimdal version I use. > >> > > That would indicate the encrypted checksum isn't correct. It > > might be using an algorithm only supported by the newer > > RPCSEC_GSS_V3? > It's RPC version 2, GSS version: 1 >=20 Yea, there's already a spec (or at least a draft of one) for V3 as well. It's hard to keep up with the spec writers. > > For DESTROY when it will fail, I'm not sure if marking the > > context stale makes sense. (I can see an argument for and against > > doing this.) > If you "know" other people's context by snooping the wire, you can > invalidate their client entry on the nfs server by sending a corrupted > (corrupted, because you don't know their keytab) RPCSEC_GSS_DESTROY > message. > I suspect an attacker can force the kerberos clients to re-establish > the > security context again and again. Yes, I think it could be used this way by a bad guy. I tend to resist mentioning such things on public mailing lists, but since you have done so.= ..;-) The best protection is not allowing the "world" to do NFS mounts, even when Kerberos is used. > I'm not sure this statistically can lead to any advantage breaking the > keys, kerberos experts may answer this. >=20 >=20 > > I've attached a small patch with disables setting client->cl_state > > to CLIENT_STALE for this case, which you could try, to see if it > > helps? > I'll look at it. >=20 Yes, please test it. It seems to have fixed the problem for the other person reporting a similar issue and I believe it is safe to commit. > > I'd suggest contacting the Linux folks first and see if they are > > willing to look at the wireshark trace or know of an issue/fix, > > because it really sounds like a Linux client issue. >=20 > > Waiting 4 minutes instead of 5 shouldn't have any real effect, > > although it might avoid the problem for your case w.r.t. timing. >=20 > This is an intuition to test a fix for another bug. I noticed, that > when my users need long file access, they get a permission denied > error > at the gss key change time, which is very annoying after the program > having run for multiple hours. >=20 The client should try and get a new security handle via RPCSEC_GSS_INIT when the old handle times out (or falls out of the server side handle cache). If the client causes syscalls to fail at this point (assuming the user in the client has a valid TGT), I would call that a client side error, too. (If your Kerberos system is issuing renewable tickets, running a daemon like krenew that renews TGT tickets before they expire, is needed for long running apps.) Although the patch to support host based initiator credentials in a keytab is not in head, once it is applied, the FreeBSD client optionally allows one of those to be used for client credentials and that avoids the hassle of TGT expiration for long running apps. (I don't think the Linux client has support for such a thing, so use of a non-Kerberized mount is probably preferred for long running apps?) > > This time is usually the TGT lifetime (12->24hrs), so subtracting > > 12 sec from it doesn't really make any sense. (I will note that > > the calculation of cred_lifetime for the GSS_C_INDEFINITE case > > looks incorrect, since time_uptime gets added twice, but I doubt > > that's relevant to your problem, since it is set to more than > > 24hrs.) > The rpcsec timestamp is valid, so this passes this layer. But when > it's > actually handled by the NFS layer, how can this permission denied come > into the picture? Is there another GSS timestamp check on the upper > level? >=20 The timeout is passed to the server in the GSSAPI token that is a part of the RPCSEC_GSS_INIT request. That is remembered by the server side and normally used, except for the ..INDEFINITE case. The timeout is up to the client, but is usually the time when the TGT used to get the GSSAPI token for the RPCSEC_GSS_INIT request times out. (Simple, eh:-) >=20 > > /* > > * Fill in cred details in the rawcred structure. > > @@ -990,7 +995,7 @@ > > gss_buffer_desc rpcbuf, checksum; > > OM_uint32 maj_stat, min_stat; > > gss_qop_t qop_state; > > - int32_t rpchdr[128 / sizeof(int32_t)]; > > + int32_t rpchdr[2048 / sizeof(int32_t)]; > > int32_t *buf; > Note, that I changed the buffer from 128 bytes to 2048 bytes. This is > as per PR 162009, which is also hanging around. > I think checking the code for the RPC 128 byte buffers would be nice > for > security and other reasons. >=20 I'll take a look at this. At this time, I don't know what rpchdr[] is used for. > I'm going to send an email to the linux-nfs@ to find out what's going > on > this area - maybe this has been already fixed, as I use some old EL6 > and > Ubuntu 12.04 flavours. > However dropping the sec context even with failed kerberos ticket > seems > like a FreeBSD bug. >=20 Yes, I think I agree. You noted a possible DOS attack that a bogus client could do if the context is deleted for this case. The alternate argument is that contexts will be left around for a long time when a buggy client does the RPCSEC_DESTROY at the correct time, but uses the wrong session key and/or encrypted checksum alg, so VerifyMIC() fails on it. It seems that the current Linux client bug causes the RPCSEC_DESTROY to happen at the wrong time with the wrong session key and/or encrypted checksum alg. rick > Kind regards, > Attila >=20 > -- > Attila Bog=C3=A1r > Systems Administrator > Linguamatics - Cambridge, UK > http://www.linguamatics.com/ From owner-freebsd-fs@FreeBSD.ORG Thu Sep 6 12:23:04 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60117106564A; Thu, 6 Sep 2012 12:23:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 08D1E8FC12; Thu, 6 Sep 2012 12:23:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAE+USFCDaFvO/2dsb2JhbAA9CBaFcLYfgiABAQUjVhsOCgICDRkCWQYtAYdyC6dmkwOBIYoGEYUMgRIDlVmBFI8Ggn+BPAIh X-IronPort-AV: E=Sophos;i="4.80,380,1344225600"; d="scan'208";a="177907467" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 06 Sep 2012 08:22:57 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0C04DB4032; Thu, 6 Sep 2012 08:22:57 -0400 (EDT) Date: Thu, 6 Sep 2012 08:22:57 -0400 (EDT) From: Rick Macklem To: Konstantin Belousov Message-ID: <178291859.130610.1346934177033.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120905091854.GD33100@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: pho@freebsd.org, fs@freebsd.org Subject: Re: Nullfs shared lookup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 12:23:04 -0000 Konstantin Belousov wrote: > I, together with Peter Holm, developed a patch to enable shared > lookups > on nullfs mounts when lower filesystem allows the shared lookups. The > lack > of shared lookup support for nullfs is quite visible on any > VFS-intensive > workloads which utilize path translations. In particular, it was a > complain > on $dayjob which started me thinking about this issue. > > There are two problems which prevent direct translation of shared > lookup bit into nullfs upper mount bit: > > 1. When vfs_lookup() calls VOP_LOOKUP() for nullfs, which passes > lookup > operation to lower fs, resulting vnode is often only shared-locked. > Then > null_nodeget() cannot instantiate covering vnode for lower vnode, > since > insmntque1() and null_hashins() require exclusive lock on the lower. > > The solution is straightforward, if null hash failed to find > pre-existing > nullfs vnode for lower vnode, the lower vnode lock is upgraded. > > 2. (More serious). Nullfs reclaims its vnodes on deactivation. The > cause > is due to nullfs inability to detect reclamation of the lower vnode. > Reclamation of a nullfs vnode at deactivation time prevents a > reference > to the lower vnode to become stale. > > Unfortunately, this means that all lookups on nullfs need exclusive > lock > to instantiate upper vnode, which is never cached. > > Solution which we propose is to add VFS notification to the upper > filesystem about reclamation of the vnode in the lower filesystem. > Now, > vgone() calls new VFS op vfs_reclaim_lowervp() with an argument > lowervp > which is reclaimed. It is possible to register several reclamation > event > listeners, to correctly handle the case of several nullfs mounts over > the same directory. > > For the filesystem not having nullfs mounts over it, the overhead > added is > a single mount interlock lock/unlock in the vnode reclamation path. > > Benchmarks consisting of up 1K threads doing parallel stat(2) on the > same file demonstate almost constant execution time, not depending of > number of running threads. While without the patch, exec time between > single-threaded run and run with 1024 threads performing the same > total > count of stat(2), differ in 6 times. > > Somewhat problematic detail, IMO, is that nullfs reclamation procedure > calls vput() on the lowervp vnode, temporary unlocking the vnode being > reclaimed. This seems to be fine for MPSAFE filesystems, but > not-MPSAFE > code often put partially initialized vnode on some globally visible > list, and later can decide that half-constructed vnode is not needed. > If nullfs mount is created above such filesystem, then other threads > might catch such not properly initialized vnode. Instead of trying > to overcome this case, e.g. by recursing the lower vnode lock in > null_reclaim_lowervp(), I decided to rely on nearby extermination of > non-MPSAFE filesystems support. > > I think that unionfs can also benefit from this mechanism, but I did > not > even looked at unionfs. > > Patch is available at > http://people.freebsd.org/~kib/misc/nullfs_shared_lookup.1.patch > It survived stress2 torturing. > > Comments ? It all sounds reasonable to me. (Not much of a comment, but since I didn't see anyone else commenting, I figured I would:-) No news is good news, I'd guess? rick From owner-freebsd-fs@FreeBSD.ORG Thu Sep 6 13:30:07 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9D44106566C for ; Thu, 6 Sep 2012 13:30:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9463F8FC14 for ; Thu, 6 Sep 2012 13:30:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q86DU7WM084790 for ; Thu, 6 Sep 2012 13:30:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q86DU71T084769; Thu, 6 Sep 2012 13:30:07 GMT (envelope-from gnats) Date: Thu, 6 Sep 2012 13:30:07 GMT Message-Id: <201209061330.q86DU71T084769@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Matuska Cc: Subject: Re: kern/149173: [patch] [zfs] make OpenSolaris < sys/nvpair.h> installable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:30:07 -0000 The following reply was made to PR kern/149173; it has been noted by GNATS. From: Martin Matuska To: bug-followup@FreeBSD.org, rmh@gnu.org Cc: Subject: Re: kern/149173: [patch] [zfs] make OpenSolaris <sys/nvpair.h> installable Date: Thu, 06 Sep 2012 15:27:34 +0200 If this wasn't imported into OpenSolaris I suggest a illumos issue gets filled. https://www.illumos.org/issues -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Thu Sep 6 13:32:14 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F36B51065689; Thu, 6 Sep 2012 13:32:13 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C6DB08FC19; Thu, 6 Sep 2012 13:32:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q86DWDC9013924; Thu, 6 Sep 2012 13:32:13 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q86DWD5J013913; Thu, 6 Sep 2012 13:32:13 GMT (envelope-from bdrewery) Date: Thu, 6 Sep 2012 13:32:13 GMT Message-Id: <201209061332.q86DWD5J013913@freefall.freebsd.org> To: bdrewery@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: bdrewery@FreeBSD.org Cc: Subject: Re: kern/171380: [ZFS] 9.1: Panic when importing pool from OpenSolaris/OpenIndiana that has multiple FUID domains X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:32:14 -0000 Synopsis: [ZFS] 9.1: Panic when importing pool from OpenSolaris/OpenIndiana that has multiple FUID domains Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: bdrewery Responsible-Changed-When: Thu Sep 6 13:32:12 UTC 2012 Responsible-Changed-Why: Over to maintainer http://www.freebsd.org/cgi/query-pr.cgi?pr=171380 From owner-freebsd-fs@FreeBSD.ORG Thu Sep 6 13:40:07 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDCAB106564A for ; Thu, 6 Sep 2012 13:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A7A5B8FC14 for ; Thu, 6 Sep 2012 13:40:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q86De7dM015056 for ; Thu, 6 Sep 2012 13:40:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q86De7xT015043; Thu, 6 Sep 2012 13:40:07 GMT (envelope-from gnats) Date: Thu, 6 Sep 2012 13:40:07 GMT Message-Id: <201209061340.q86De7xT015043@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Matuska Cc: Subject: Re: kern/139564: [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdown X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:40:08 -0000 The following reply was made to PR kern/139564; it has been noted by GNATS. From: Martin Matuska To: bug-followup@FreeBSD.org, hlh@restart.be Cc: Subject: Re: kern/139564: [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdown Date: Thu, 06 Sep 2012 15:29:49 +0200 Is this problem still current? -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Thu Sep 6 13:40:13 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36F9B106566C for ; Thu, 6 Sep 2012 13:40:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 082E28FC16 for ; Thu, 6 Sep 2012 13:40:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q86DeCSJ015892 for ; Thu, 6 Sep 2012 13:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q86DeCex015878; Thu, 6 Sep 2012 13:40:12 GMT (envelope-from gnats) Date: Thu, 6 Sep 2012 13:40:12 GMT Message-Id: <201209061340.q86DeCex015878@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Matuska Cc: Subject: Re: kern/145229: [zfs] Vast differences in ZFS ARC behavior between 8.0-RC1 and 8.0-RELEASE [regression] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:40:13 -0000 The following reply was made to PR kern/145229; it has been noted by GNATS. From: Martin Matuska To: bug-followup@FreeBSD.org, rercola@acm.jhu.edu Cc: Subject: Re: kern/145229: [zfs] Vast differences in ZFS ARC behavior between 8.0-RC1 and 8.0-RELEASE [regression] Date: Thu, 06 Sep 2012 15:30:28 +0200 Is this problem still current? Or can we close this? -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Thu Sep 6 13:40:18 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD8F910656FB for ; Thu, 6 Sep 2012 13:40:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B66338FC1A for ; Thu, 6 Sep 2012 13:40:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q86DeIot016807 for ; Thu, 6 Sep 2012 13:40:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q86DeIEU016793; Thu, 6 Sep 2012 13:40:18 GMT (envelope-from gnats) Date: Thu, 6 Sep 2012 13:40:18 GMT Message-Id: <201209061340.q86DeIEU016793@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Matuska Cc: Subject: Re: kern/147881: [zfs] [patch] ZFS " sharenfs" doesn' t allow different "exports" options for different hosts X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:40:18 -0000 The following reply was made to PR kern/147881; it has been noted by GNATS. From: Martin Matuska To: bug-followup@FreeBSD.org, Richard.Conto@gmail.com Cc: Subject: Re: kern/147881: [zfs] [patch] ZFS "sharenfs" doesn't allow different "exports" options for different hosts Date: Thu, 06 Sep 2012 15:36:13 +0200 The purpose of the sharenfs property is not to completely replace /etc/exports. What we have is just a tricky workaround that populates /etc/zfs/exports. T he commands to NFS-share filesystems on illumos are different and our options are mostly incompatible with illumos. So you e.g. sharenfs="-maproot=root" is invalid if imported on a Openindiana system. Have you considered using just /etc/exports for more-complex configurations? -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Thu Sep 6 13:49:00 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02327106566B; Thu, 6 Sep 2012 13:49:00 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C93828FC17; Thu, 6 Sep 2012 13:48:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q86DmxDa064910; Thu, 6 Sep 2012 13:48:59 GMT (envelope-from mm@freefall.freebsd.org) Received: (from mm@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q86Dmxlw064906; Thu, 6 Sep 2012 13:48:59 GMT (envelope-from mm) Date: Thu, 6 Sep 2012 13:48:59 GMT Message-Id: <201209061348.q86Dmxlw064906@freefall.freebsd.org> To: mm@FreeBSD.org, freebsd-fs@FreeBSD.org, mm@FreeBSD.org From: mm@FreeBSD.org Cc: Subject: Re: kern/171380: [ZFS] 9.1: Panic when importing pool from OpenSolaris/OpenIndiana that has multiple FUID domains X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:49:00 -0000 Synopsis: [ZFS] 9.1: Panic when importing pool from OpenSolaris/OpenIndiana that has multiple FUID domains Responsible-Changed-From-To: freebsd-fs->mm Responsible-Changed-By: mm Responsible-Changed-When: Thu Sep 6 13:48:59 UTC 2012 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=171380 From owner-freebsd-fs@FreeBSD.ORG Thu Sep 6 14:31:59 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1910D1065670; Thu, 6 Sep 2012 14:31:59 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E0FD48FC19; Thu, 6 Sep 2012 14:31:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q86EVw45061972; Thu, 6 Sep 2012 14:31:58 GMT (envelope-from mm@freefall.freebsd.org) Received: (from mm@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q86EVvcq061748; Thu, 6 Sep 2012 14:31:57 GMT (envelope-from mm) Date: Thu, 6 Sep 2012 14:31:57 GMT Message-Id: <201209061431.q86EVvcq061748@freefall.freebsd.org> To: hlh@restart.be, mm@FreeBSD.org, freebsd-fs@FreeBSD.org From: mm@FreeBSD.org Cc: Subject: Re: kern/139564: [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdown X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:31:59 -0000 Synopsis: [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdown State-Changed-From-To: open->closed State-Changed-By: mm State-Changed-When: Thu Sep 6 14:31:56 UTC 2012 State-Changed-Why: Problen no longer current. Closing. http://www.freebsd.org/cgi/query-pr.cgi?pr=139564 From owner-freebsd-fs@FreeBSD.ORG Thu Sep 6 18:06:37 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFC46106566B for ; Thu, 6 Sep 2012 18:06:37 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 41F8A8FC24 for ; Thu, 6 Sep 2012 18:06:36 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id q86I6P7J098393 for ; Thu, 6 Sep 2012 21:06:25 +0300 (EEST) Message-ID: <20120906210625.98392@relay.ibs.dn.ua> Date: Thu, 06 Sep 2012 21:06:25 +0300 From: Zeus Panchenko To: cc: Organization: I.B.S. LLC X-Mailer: MH-E 8.2; GNU Mailutils 2.99.97; GNU Emacs 23.4.1 X-Face: &sReWXo3Iwtqql1[My(t1Gkx; y?KF@KF`4X+'9Cs@PtK^y%}^.>Mtbpyz6U=,Op:KPOT.uG )Nvx`=er!l?WASh7KeaGhga"1[&yz$_7ir'cVp7o%CGbJ/V)j/=]vzvvcqcZkf; JDurQG6wTg+?/xA go`}1.Ze//K; Fk&/&OoHd'[b7iGt2UO>o(YskCT[_D)kh4!yY'<&:yt+zM=A`@`~9U+P[qS:f; #9z~ Or/Bo#N-'S'!'[3Wog'ADkyMqmGDvga?WW)qd=?)`Y&k=o}>!ST\ Subject: is dedupe feature pool-wide or fs-wide? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:06:38 -0000 hi all, please, forgive me this stupid question, but is dedup feature pool-wide or fs-wide indeed? what I mean is: if I have dedup=on on two fs, than while copying one file to the fist one and after that to the second one, I will or will not have data deduplicated on the second copying? am I correct to think if dedup is block-level then it is pool-wide? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Thu Sep 6 18:11:56 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B0F81065676 for ; Thu, 6 Sep 2012 18:11:56 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id DF59F8FC15 for ; Thu, 6 Sep 2012 18:11:55 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so1766279lbb.13 for ; Thu, 06 Sep 2012 11:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dVd3MGvN2W6/pFqg32/1gYzJufmn0zqjRVZoA2Q7qYw=; b=q2SGdBDCMyaMlnWYJ+ssD+8IQ0WhyYh/PyRPYphGzMvZQbXQzWvqsh8TM1RRAmJkSr ce7wOMiRapTCu2oZHkfnC3a3YyO8p9sADFMFFG0gcC5VeV/5OksuRgetlYLM2CYH+fgi ZmVai8EOSV+MqJqrXGMA50aLOJrEKLpSV91LE1mScOm4L3IW3uuqUVgwJ5+k+Nm24QMx c7tH8pTiC0sF2BJOmoDDzHelVLJOzym6dnoRzX2VsqVgGV7+dE5kTXV+RCjSl411AnIR 3vZl+1i7hz/qGVqkCpxKhfZZGZrefTrBz7HRKw3mdVmveNQt9ck2IU9rJkn0WG78N8M1 4ABQ== MIME-Version: 1.0 Received: by 10.112.48.193 with SMTP id o1mr1223597lbn.62.1346955113809; Thu, 06 Sep 2012 11:11:53 -0700 (PDT) Received: by 10.114.23.230 with HTTP; Thu, 6 Sep 2012 11:11:53 -0700 (PDT) In-Reply-To: <20120906210625.98392@relay.ibs.dn.ua> References: <20120906210625.98392@relay.ibs.dn.ua> Date: Thu, 6 Sep 2012 11:11:53 -0700 Message-ID: From: Freddie Cash To: Zeus Panchenko Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: is dedupe feature pool-wide or fs-wide? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:11:56 -0000 On Thu, Sep 6, 2012 at 11:06 AM, Zeus Panchenko wrote: > please, forgive me this stupid question, but is dedup feature pool-wide > or fs-wide indeed? > > what I mean is: if I have dedup=on on two fs, than while copying one > file to the fist one and after that to the second one, I will or will > not have data deduplicated on the second copying? > > am I correct to think if dedup is block-level then it is pool-wide? It's pool-wide, but can be enabled/disabled on a per-dataset basis. IOW, ZFS scans all dedup-enabled datasets for duplicate blocks. So, copying from one dedup-enabled filesystem to another dedupe-enabled filesystem will generated duplicate blocks that should end up with only DDT updates and not use any extra storage space. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Thu Sep 6 23:41:08 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B6E2106566B for ; Thu, 6 Sep 2012 23:41:08 +0000 (UTC) (envelope-from ayoung@mosaicarchive.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 398D38FC08 for ; Thu, 6 Sep 2012 23:41:07 +0000 (UTC) Received: by obbun3 with SMTP id un3so4546084obb.13 for ; Thu, 06 Sep 2012 16:41:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=sR6MdMDY4K5D8zbPE5cbrBRIljO9O5Qra5gzMJ27CFs=; b=ILvvGBF6HDAkvKj1fk1hPr0xWl8QCw2EBOj6bQYXyd6mpSbKcg7lVJqmf1ocC9PVxT GWi7NbkwNUIx/Svebu/E68atsxjstEuARMr7KNC9E1b4aij0KcCdp7XzcFKAeu9A1CUq DLPukd7QoEw9YXvGY4f11EVOTFj65U1kwURAFqjRtfr33NukgoDCvwByTJJjQkFhMV6p b4b2wWYyisOzhobuPVMjYeZY0kPceKyc85/G8beWQ42v7QSm/XO6EwoR6XHsCvxOksZR WEwZu3r+8xtO4UzWFVo9BMdy475+109KJ+Frrr3q5XiMjfPUyT0tSrxuF4PZgjv3xL6D x/bg== MIME-Version: 1.0 Received: by 10.182.174.68 with SMTP id bq4mr4005613obc.53.1346974867107; Thu, 06 Sep 2012 16:41:07 -0700 (PDT) Received: by 10.76.174.38 with HTTP; Thu, 6 Sep 2012 16:41:07 -0700 (PDT) X-Originating-IP: [96.237.242.243] Date: Thu, 6 Sep 2012 19:41:07 -0400 Message-ID: From: Andy Young To: freebsd-fs@freebsd.org X-Gm-Message-State: ALoCoQlYw1WRRsU/fjsH9ErTUOUlMoC/Sa09vCCv2INMPab4WvmaDClObmatffqZ7uTQRbPmDjjY Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Question on ZFS and redundancy X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 23:41:08 -0000 In the past I've used multiple RAID6 volumes under Linux. The thing I disliked about this was that my code had to worry about splitting my data across the volumes. I had to worry about which ones were full and manage all of that complexity myself. However, the volumes were independent. If I lost three drives in a volume then yes I would lose the volume but it wouldn't affect any other volumes. Now with ZFS and raidz2 I love the fact that I can use a single pool to spread data across multiple vdevs. However, the vdevs aren't independent anymore right? Because ZFS stripes data across the vdevs, if I lose three drives in a single vdev, doesn't this put the entire pool at risk? Andy From owner-freebsd-fs@FreeBSD.ORG Fri Sep 7 00:12:39 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A289F106564A for ; Fri, 7 Sep 2012 00:12:39 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 53FFC8FC08 for ; Fri, 7 Sep 2012 00:12:38 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id q8703s9U021830; Thu, 6 Sep 2012 19:03:54 -0500 (CDT) Date: Thu, 6 Sep 2012 19:03:54 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Andy Young In-Reply-To: Message-ID: References: User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Thu, 06 Sep 2012 19:03:54 -0500 (CDT) Cc: freebsd-fs@freebsd.org Subject: Re: Question on ZFS and redundancy X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 00:12:39 -0000 On Thu, 6 Sep 2012, Andy Young wrote: > > Now with ZFS and raidz2 I love the fact that I can use a single pool to > spread data across multiple vdevs. However, the vdevs aren't independent > anymore right? Because ZFS stripes data across the vdevs, if I lose three > drives in a single vdev, doesn't this put the entire pool at risk? Yes. It is a bigger basket. If you need a stronger basket, consider raidz3 and/or pay close attention to the physical layout and connectivity of the drives so that there is the least opportunity for the drives to share the same problem. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Fri Sep 7 18:10:07 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFCF2106566B for ; Fri, 7 Sep 2012 18:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B98898FC14 for ; Fri, 7 Sep 2012 18:10:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q87IA7iN099124 for ; Fri, 7 Sep 2012 18:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q87IA7lP099110; Fri, 7 Sep 2012 18:10:07 GMT (envelope-from gnats) Date: Fri, 7 Sep 2012 18:10:07 GMT Message-Id: <201209071810.q87IA7lP099110@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Richard Conto Cc: Subject: Re: kern/147881: [zfs] [patch] ZFS " sharenfs" doesn' t allow different " exports" options for different hosts X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Richard Conto List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:10:07 -0000 The following reply was made to PR kern/147881; it has been noted by GNATS. From: Richard Conto To: Martin Matuska Cc: Richard Conto , bug-followup@FreeBSD.org Subject: Re: kern/147881: [zfs] [patch] ZFS "sharenfs" doesn't allow different "exports" options for different hosts Date: Fri, 7 Sep 2012 14:05:39 -0400 On Sep 6, 2012, at 9:36 AM, Martin Matuska wrote: > The purpose of the sharenfs property is not to completely replace > /etc/exports. > What we have is just a tricky workaround that populates = /etc/zfs/exports. > T > he commands to NFS-share filesystems on illumos are different and our > options are mostly incompatible with illumos. > So you e.g. sharenfs=3D"-maproot=3Droot" is invalid if imported on a > Openindiana system. >=20 > Have you considered using just /etc/exports for more-complex = configurations? Yes. It doesn't scale - and scaling is the whole purpose of NFS. It = also makes it difficult for distributed management of access rights to = end-user NFS exports. I wouldn't mind using a FreeBSD specific attribute to populate = /etc/zfs/exports with FreeBSD specific values such as is used for = swapping to ZFS. Merging the two different attributes would either be = tricky, or the use of the FreeBSD one should cause "sharenfs" to be = ignored entirely. > --=20 > Martin Matuska > FreeBSD committer > http://blog.vx.sk >=20 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 7 19:53:09 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D50641065670; Fri, 7 Sep 2012 19:53:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A684F8FC1A; Fri, 7 Sep 2012 19:53:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q87Jr9ck046758; Fri, 7 Sep 2012 19:53:09 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q87Jr9Cv046738; Fri, 7 Sep 2012 19:53:09 GMT (envelope-from linimon) Date: Fri, 7 Sep 2012 19:53:09 GMT Message-Id: <201209071953.q87Jr9Cv046738@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/171415: [zfs] zfs recv fails with "cannot receive incremental stream: invalid backup stream" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 19:53:09 -0000 Synopsis: [zfs] zfs recv fails with "cannot receive incremental stream: invalid backup stream" Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Sep 7 19:52:59 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=171415 From owner-freebsd-fs@FreeBSD.ORG Sat Sep 8 04:59:16 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A6F61065672; Sat, 8 Sep 2012 04:59:16 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 45F9C8FC0A; Sat, 8 Sep 2012 04:59:15 +0000 (UTC) Received: by dadr6 with SMTP id r6so198540dad.13 for ; Fri, 07 Sep 2012 21:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=n1qtwypXX5SYqMVVSdaY5t0Tr71yV4iq8TiVyLekHiI=; b=he/DQyJQVWSgADdGk+qJLApSYfKir2w5c3e2wKDS1mLvC7PutsBsMaCMaFWahL2wkW ufS4oX/0s+Q4co6dIwzXqkD+VrhW0YEPPIuokPx36AhnlIbHs/Z4DiKdyz56+edf42VO RsOtDG6NTwDF1ya840qIEBPacwnNAjShCuu6baUvav3BUZJ5VIiBzq3Sf4Irj9ExwIXw Ki9t53hrZAJayHfM8pGZCqcKJyKyG4wqEB19U2BzriDXpxZQ1zalS2p+HsBBzeEGI045 3UI9Au37IWlxiu64bm9QXoiIzv+JTjz6Nb+4yhZzzGkKavyMnB4INkJBPxbBOacFhbUu JMiQ== Received: by 10.68.129.131 with SMTP id nw3mr13724526pbb.43.1347080355487; Fri, 07 Sep 2012 21:59:15 -0700 (PDT) Received: from localhost (c-24-130-155-143.hsd1.ca.comcast.net. [24.130.155.143]) by mx.google.com with ESMTPS id pj10sm4477604pbb.46.2012.09.07.21.59.13 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 21:59:14 -0700 (PDT) Date: Fri, 7 Sep 2012 21:59:21 -0700 From: Gleb Kurtsou To: Konstantin Belousov Message-ID: <20120908045921.GA1419@reks> References: <20120905091854.GD33100@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120905091854.GD33100@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: pho@freebsd.org, fs@freebsd.org Subject: Re: Nullfs shared lookup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 04:59:16 -0000 On (05/09/2012 12:18), Konstantin Belousov wrote: > I, together with Peter Holm, developed a patch to enable shared lookups > on nullfs mounts when lower filesystem allows the shared lookups. The lack > of shared lookup support for nullfs is quite visible on any VFS-intensive > workloads which utilize path translations. In particular, it was a complain > on $dayjob which started me thinking about this issue. > > There are two problems which prevent direct translation of shared > lookup bit into nullfs upper mount bit: > > 1. When vfs_lookup() calls VOP_LOOKUP() for nullfs, which passes lookup > operation to lower fs, resulting vnode is often only shared-locked. Then > null_nodeget() cannot instantiate covering vnode for lower vnode, since > insmntque1() and null_hashins() require exclusive lock on the lower. > > The solution is straightforward, if null hash failed to find pre-existing > nullfs vnode for lower vnode, the lower vnode lock is upgraded. > > 2. (More serious). Nullfs reclaims its vnodes on deactivation. The cause > is due to nullfs inability to detect reclamation of the lower vnode. > Reclamation of a nullfs vnode at deactivation time prevents a reference > to the lower vnode to become stale. > > Unfortunately, this means that all lookups on nullfs need exclusive lock > to instantiate upper vnode, which is never cached. > > Solution which we propose is to add VFS notification to the upper > filesystem about reclamation of the vnode in the lower filesystem. Now, > vgone() calls new VFS op vfs_reclaim_lowervp() with an argument lowervp > which is reclaimed. It is possible to register several reclamation event > listeners, to correctly handle the case of several nullfs mounts over > the same directory. > > For the filesystem not having nullfs mounts over it, the overhead added is > a single mount interlock lock/unlock in the vnode reclamation path. > > Benchmarks consisting of up 1K threads doing parallel stat(2) on the > same file demonstate almost constant execution time, not depending of > number of running threads. While without the patch, exec time between > single-threaded run and run with 1024 threads performing the same total > count of stat(2), differ in 6 times. > > Somewhat problematic detail, IMO, is that nullfs reclamation procedure > calls vput() on the lowervp vnode, temporary unlocking the vnode being > reclaimed. This seems to be fine for MPSAFE filesystems, but not-MPSAFE > code often put partially initialized vnode on some globally visible > list, and later can decide that half-constructed vnode is not needed. > If nullfs mount is created above such filesystem, then other threads > might catch such not properly initialized vnode. Instead of trying > to overcome this case, e.g. by recursing the lower vnode lock in > null_reclaim_lowervp(), I decided to rely on nearby extermination of > non-MPSAFE filesystems support. > > I think that unionfs can also benefit from this mechanism, but I did not > even looked at unionfs. > > Patch is available at > http://people.freebsd.org/~kib/misc/nullfs_shared_lookup.1.patch > It survived stress2 torturing. > > Comments ? I only had a glance look at the patch, sorry it I missed something obvious. How do we achieve propagation of rename/rm/rmdir to upper level name cache? From owner-freebsd-fs@FreeBSD.ORG Sat Sep 8 07:00:16 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74756106564A for ; Sat, 8 Sep 2012 07:00:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 450948FC0C for ; Sat, 8 Sep 2012 07:00:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8870Fro026442 for ; Sat, 8 Sep 2012 07:00:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8870FVR026428; Sat, 8 Sep 2012 07:00:15 GMT (envelope-from gnats) Date: Sat, 8 Sep 2012 07:00:15 GMT Message-Id: <201209080700.q8870FVR026428@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Birgmeier Cc: Subject: Re: kern/171415: [zfs] zfs recv fails with " cannot receive incremental stream: invalid backup stream" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Birgmeier List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 07:00:16 -0000 The following reply was made to PR kern/171415; it has been noted by GNATS. From: Martin Birgmeier To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/171415: [zfs] zfs recv fails with "cannot receive incremental stream: invalid backup stream" Date: Sat, 08 Sep 2012 08:50:34 +0200 There is one more interesting hit with Google: https://wikis.oracle.com/display/FishWorks/ak-2011.04.24.2.0+Release+Notes In it, one finds: --- Issues Addressed The following CRs have been fixed in this release: [...] 7056496 cannot receive new filesystem stream: invalid backup stream --- So it seems Sun/Oracle have already resolved this. Regards, Martin From owner-freebsd-fs@FreeBSD.ORG Sat Sep 8 16:13:59 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 811C51065676; Sat, 8 Sep 2012 16:13:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 18E008FC1B; Sat, 8 Sep 2012 16:13:58 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q88GE1O9063423; Sat, 8 Sep 2012 19:14:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q88GDmu6090318; Sat, 8 Sep 2012 19:13:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q88GDmuD090317; Sat, 8 Sep 2012 19:13:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 8 Sep 2012 19:13:48 +0300 From: Konstantin Belousov To: Gleb Kurtsou Message-ID: <20120908161348.GG33100@deviant.kiev.zoral.com.ua> References: <20120905091854.GD33100@deviant.kiev.zoral.com.ua> <20120908045921.GA1419@reks> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pIqiiB6HxdjnOZqe" Content-Disposition: inline In-Reply-To: <20120908045921.GA1419@reks> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: pho@freebsd.org, fs@freebsd.org Subject: Re: Nullfs shared lookup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 16:13:59 -0000 --pIqiiB6HxdjnOZqe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 07, 2012 at 09:59:21PM -0700, Gleb Kurtsou wrote: > On (05/09/2012 12:18), Konstantin Belousov wrote: > > I, together with Peter Holm, developed a patch to enable shared lookups > > on nullfs mounts when lower filesystem allows the shared lookups. The l= ack > > of shared lookup support for nullfs is quite visible on any VFS-intensi= ve > > workloads which utilize path translations. In particular, it was a comp= lain > > on $dayjob which started me thinking about this issue. > >=20 > > There are two problems which prevent direct translation of shared > > lookup bit into nullfs upper mount bit: > >=20 > > 1. When vfs_lookup() calls VOP_LOOKUP() for nullfs, which passes lookup > > operation to lower fs, resulting vnode is often only shared-locked. Then > > null_nodeget() cannot instantiate covering vnode for lower vnode, since > > insmntque1() and null_hashins() require exclusive lock on the lower. > >=20 > > The solution is straightforward, if null hash failed to find pre-existi= ng > > nullfs vnode for lower vnode, the lower vnode lock is upgraded. > >=20 > > 2. (More serious). Nullfs reclaims its vnodes on deactivation. The cause > > is due to nullfs inability to detect reclamation of the lower vnode. > > Reclamation of a nullfs vnode at deactivation time prevents a reference > > to the lower vnode to become stale. > >=20 > > Unfortunately, this means that all lookups on nullfs need exclusive lock > > to instantiate upper vnode, which is never cached. > >=20 > > Solution which we propose is to add VFS notification to the upper > > filesystem about reclamation of the vnode in the lower filesystem. Now, > > vgone() calls new VFS op vfs_reclaim_lowervp() with an argument lowervp > > which is reclaimed. It is possible to register several reclamation event > > listeners, to correctly handle the case of several nullfs mounts over > > the same directory. > >=20 > > For the filesystem not having nullfs mounts over it, the overhead added= is > > a single mount interlock lock/unlock in the vnode reclamation path. > >=20 > > Benchmarks consisting of up 1K threads doing parallel stat(2) on the > > same file demonstate almost constant execution time, not depending of > > number of running threads. While without the patch, exec time between > > single-threaded run and run with 1024 threads performing the same total > > count of stat(2), differ in 6 times. > >=20 > > Somewhat problematic detail, IMO, is that nullfs reclamation procedure > > calls vput() on the lowervp vnode, temporary unlocking the vnode being > > reclaimed. This seems to be fine for MPSAFE filesystems, but not-MPSAFE > > code often put partially initialized vnode on some globally visible > > list, and later can decide that half-constructed vnode is not needed. > > If nullfs mount is created above such filesystem, then other threads > > might catch such not properly initialized vnode. Instead of trying > > to overcome this case, e.g. by recursing the lower vnode lock in > > null_reclaim_lowervp(), I decided to rely on nearby extermination of > > non-MPSAFE filesystems support. > >=20 > > I think that unionfs can also benefit from this mechanism, but I did not > > even looked at unionfs. > >=20 > > Patch is available at > > http://people.freebsd.org/~kib/misc/nullfs_shared_lookup.1.patch > > It survived stress2 torturing. > >=20 > > Comments ? >=20 > I only had a glance look at the patch, sorry it I missed something > obvious. How do we achieve propagation of rename/rm/rmdir to upper > level name cache? We don't. If you look at the nullfs vnode op table, you should note that nullfs provides a bypass function for vop_lookup. To use the name cache, filesytem shall set vop_lookup to vfs_cache_lookup, and implement vop_cachedlookup. See for instance UFS. The cache avoidance was the reason why working null_vptocnp() was a high-priority item (together with the weird locking protocol for the vop). --pIqiiB6HxdjnOZqe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBLbrwACgkQC3+MBN1Mb4iUBQCg2NbQ8sAXz9ETnQlgRJSXrhgt kxcAn274Vd6vBO92HnO+YFJM8Y8ryQcx =4yUR -----END PGP SIGNATURE----- --pIqiiB6HxdjnOZqe--