From owner-freebsd-fs@FreeBSD.ORG Sun Apr 17 00:45:48 2011 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 80E2A106564A for ; Sun, 17 Apr 2011 00:45:48 +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 440578FC08 for ; Sun, 17 Apr 2011 00:45:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAOA3qk2DaFvO/2dsb2JhbACETqI9iG+qeI9zgSmDTnoEjgM X-IronPort-AV: E=Sophos;i="4.64,225,1301889600"; d="scan'208";a="118564184" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 16 Apr 2011 20:45:46 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E7A71B3F30; Sat, 16 Apr 2011 20:45:46 -0400 (EDT) Date: Sat, 16 Apr 2011 20:45:46 -0400 (EDT) From: Rick Macklem To: Bob Friesenhahn Message-ID: <331249373.149024.1303001146870.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 17 Apr 2011 00:45:48 -0000 > > My main interest is interoperability with systems other than FreeBSD > such as Solaris, Linux, and Apple's OS X. I have Leopard and Solaris10 and do interop testing with them. I have done some with Linux (and had a couple hundred Linux desktops mounting the server a few years ago), but since there are sooo many Linux variants, it only indicates some have worked at some point. (The server also saw Snow Leopard clients for a while, but my Mac is an old G4 Powerbook so its Leopard for me:-) > Client throughput of > FreeBSD's default NFS is low. I would be hoping to get more > throughput. Also, modern NFS uses TCP so I would expect to use that. Hmm. At least for read rate on a large file, others see wire speed at 1Gbps and I think some get close to wire speed on 10Gbps. (I see wire speed for 100Mbps, but that doesn't say much:-) Was it read rate you were referring to or something else? I would certainly consider it a bug if people see poorer perf. for the new client than the old on the same setup. (I think the difference in read rate observed some time ago is now fixed in head. The experimental client was using a default readahead of 0 instead of 1.) > I am also using the automounter and hope that the updated NFS works at > least as well (or better) than the default one. > Righto, I need to test that. rick From owner-freebsd-fs@FreeBSD.ORG Sun Apr 17 15:20:06 2011 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 4B88A106566C for ; Sun, 17 Apr 2011 15:20:06 +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 0C11C8FC12 for ; Sun, 17 Apr 2011 15:20:05 +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 p3HFK4DC001933; Sun, 17 Apr 2011 10:20:04 -0500 (CDT) Date: Sun, 17 Apr 2011 10:20:04 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Rick Macklem In-Reply-To: <331249373.149024.1303001146870.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <331249373.149024.1303001146870.JavaMail.root@erie.cs.uoguelph.ca> 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]); Sun, 17 Apr 2011 10:20:04 -0500 (CDT) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 17 Apr 2011 15:20:06 -0000 On Sat, 16 Apr 2011, Rick Macklem wrote: > >> Client throughput of >> FreeBSD's default NFS is low. I would be hoping to get more >> throughput. Also, modern NFS uses TCP so I would expect to use that. > > Hmm. At least for read rate on a large file, others see wire speed at 1Gbps > and I think some get close to wire speed on 10Gbps. (I see wire speed for 100Mbps, > but that doesn't say much:-) > > Was it read rate you were referring to or something else? Yes, read rate. Large file read performance was much better between two Solaris systems compared with Solaris as the server and FreeBSD as the client. This is when using gigabit ethernet. 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 Sun Apr 17 19:08:55 2011 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 C1430106564A for ; Sun, 17 Apr 2011 19:08:55 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 69DF18FC08 for ; Sun, 17 Apr 2011 19:08:54 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C4E5145F60; Sun, 17 Apr 2011 21:08:53 +0200 (CEST) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 796EF45F1F; Sun, 17 Apr 2011 21:08:48 +0200 (CEST) Date: Sun, 17 Apr 2011 21:08:34 +0200 From: Pawel Jakub Dawidek To: Rick Macklem Message-ID: <20110417190834.GF22319@garage.freebsd.pl> References: <1369404502.72409.1302871750151.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lIrNkN/7tmsD/ALM" Content-Disposition: inline In-Reply-To: <1369404502.72409.1302871750151.JavaMail.root@erie.cs.uoguelph.ca> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 17 Apr 2011 19:08:55 -0000 --lIrNkN/7tmsD/ALM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 15, 2011 at 08:49:10AM -0400, Rick Macklem wrote: > Hi, >=20 > I think that the experimental NFS server is now ready for generic use > and that the experimental NFS client will be soon, after some commits > over the next week or so. >=20 > How do folks feel w.r.t. making these the default? You should definiately do that! 1. The code is in the tree for a long time. 2. Old NFS client/server stays and it is trivial to switch back to them in case of problems. Would be nice to have UPDATING entry for this. 3. This is FreeBSD HEAD only for now, so people should be ready for experimental stuff in there. 4. Would be great to have NFSv4 in FreeBSD 9.0-RELEASE. Really, Rick, there is nothing to wait for. :) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --lIrNkN/7tmsD/ALM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk2rOrEACgkQForvXbEpPzTDGwCeNIvpdw7Am7/9aconj4C9BC4G rTwAn2wTZpjg4mrd7lHC2G2Qc3VjyzC9 =muQy -----END PGP SIGNATURE----- --lIrNkN/7tmsD/ALM-- From owner-freebsd-fs@FreeBSD.ORG Sun Apr 17 20:18:26 2011 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 EF300106564A; Sun, 17 Apr 2011 20:18:26 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [64.81.247.49]) by mx1.freebsd.org (Postfix) with ESMTP id CFFC48FC0C; Sun, 17 Apr 2011 20:18:26 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id p3HKH57W019795; Sun, 17 Apr 2011 13:17:06 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201104172017.p3HKH57W019795@chez.mckusick.com> To: Rick Macklem In-reply-to: <20110417190834.GF22319@garage.freebsd.pl> Date: Sun, 17 Apr 2011 13:17:05 -0700 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 17 Apr 2011 20:18:27 -0000 I complete agree with Pawel's assesment. In the end, you have to have more extensive testing to shake out the last few issues. There is plenty of time before the 9.0 release, so if any serious issues arise, you can change the default back. Kirk McKusick =-=-= Date: Sun, 17 Apr 2011 21:08:34 +0200 From: Pawel Jakub Dawidek To: Rick Macklem Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one On Fri, Apr 15, 2011 at 08:49:10AM -0400, Rick Macklem wrote: > Hi, > > I think that the experimental NFS server is now ready for generic use > and that the experimental NFS client will be soon, after some commits > over the next week or so. > > How do folks feel w.r.t. making these the default? You should definiately do that! 1. The code is in the tree for a long time. 2. Old NFS client/server stays and it is trivial to switch back to them in case of problems. Would be nice to have UPDATING entry for this. 3. This is FreeBSD HEAD only for now, so people should be ready for experimental stuff in there. 4. Would be great to have NFSv4 in FreeBSD 9.0-RELEASE. Really, Rick, there is nothing to wait for. :) -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com From owner-freebsd-fs@FreeBSD.ORG Sun Apr 17 20:22:26 2011 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 9DD1D106564A for ; Sun, 17 Apr 2011 20:22:26 +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 58CEB8FC16 for ; Sun, 17 Apr 2011 20:22:26 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAEhLq02DaFvO/2dsb2JhbACET6IEsmCPRIEpg056BI4D X-IronPort-AV: E=Sophos;i="4.64,228,1301889600"; d="scan'208";a="117727089" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 17 Apr 2011 16:22:25 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6095DB3F3E; Sun, 17 Apr 2011 16:22:25 -0400 (EDT) Date: Sun, 17 Apr 2011 16:22:25 -0400 (EDT) From: Rick Macklem To: Bob Friesenhahn Message-ID: <339303189.168341.1303071745334.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: 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 - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 17 Apr 2011 20:22:26 -0000 > > > > Was it read rate you were referring to or something else? > > Yes, read rate. Large file read performance was much better between > two Solaris systems compared with Solaris as the server and FreeBSD as > the client. This is when using gigabit ethernet. > I know it sounds like I'm dodging the bullet, but my experience has been that much slower has usually been related to the network layer. (There were some krpc transport related issues in FreeBSD8 that could cause abissmal performance is certain cases. I think/hope those are all fixed now.) Here I have a Solaris10 box where the net interface drops a packet repeatedly under one load situation. I also have a laptop where the low end Realtek chip drops packets, as reported by the stats from the chip (this latter one appears to be a pure hardware issue). Both result in really slow NFS perf. when you bump into them. The traffic that NFS generates looks very different than what a bulk data transfer's does. It tends to be small segments in both directions on the TCP connection and then bursts of TCP segments going one way. (It is usually a segment in the burst or a TCP segment going the opposite way at the time of the burst that gets dropped.) If you can easily reproduce the problem, you could capture a packet trace (I wouldn't need a huge one, just enough of the slow stuff to see retransmits, etc) and email it to me, if you want. Others might be able to comment on good/not so good experiences with various net chips/drivers they've used NFS with? Anyhow you mentioned that you saw this on the regular NFS client, so I guess I won't be in trouble if the new one is slow too:-) rick From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 03:45:09 2011 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 A4C58106566C for ; Mon, 18 Apr 2011 03:45:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 88CED8FC14 for ; Mon, 18 Apr 2011 03:45:09 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Yr3x1g0051eYJf8A9rl9i6; Mon, 18 Apr 2011 03:45:09 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.emeryville.ca.mail.comcast.net with comcast id Yrl81g00B1t3BNj01rl87b; Mon, 18 Apr 2011 03:45:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F2AA69B42B; Sun, 17 Apr 2011 20:45:07 -0700 (PDT) Date: Sun, 17 Apr 2011 20:45:07 -0700 From: Jeremy Chadwick To: Rick Macklem Message-ID: <20110418034507.GA63656@icarus.home.lan> References: <20110415140435.GA4278@icarus.home.lan> <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 18 Apr 2011 03:45:09 -0000 On Fri, Apr 15, 2011 at 08:57:00PM -0400, Rick Macklem wrote: > > I can't speak for others, but I would feel much more comfortable if a > > well-written and verbose document/web page was put up somewhere with a > > full, concise list of what the changes are. > > Well, if you mean source code changes, I can't think of how I could > come up with this. The experimental > NFS implementation is based on work I started in 2003 and is a separate > implementation from the other one in FreeBSD, so I can't produce any > kind of "log" of changes for it. (I started from the code in OpenBSD2.6, > but there would be very little of that code left at this point.) > > I can tell you that, as far as I know, it supports NFSv2 and NFSv3 in > the same way the other/regular server does. (There might be an obscure > case where it returns a different errno for some failure or similar, > but nothing that I am aware of.) I ran it in production mode for a few > years, where the clients were mostly Linux 2.4 and 2.6 systems, plus a > FreeBSD4.6 system and didn't see issues when they used NFSv3 mounts. > > I would like to think that folks won't notice anything when they switch > over, but I am not nieve(sp?) enough to believe no one will find problems with it. > > The one area that is different is what nfsstat reports, since the "-e" version > includes extra information. If that causes difficulties for folks, it > should be possible to implement a "old nfsstat -s" compatible output that > just reports the same information as "nfsstat -s" does now. Here's a better way to phrase what I'm requesting: You're announcing to people "Hey! What do you think about me making the experimental server the default?" yet nobody knows what the experimental server does differently (for better or worse) than the non-experimental server. Documenting the differences -- not on a source code level -- is what I'm asking for. Without those differences (improvements, etc.) then I have absolutely no inclination to try something that's labelled "experimental" when the author cannot explain (or advocate) *why* someone should change to it. :-) I think you might answer the question of what's changed further down in your Email however. > > Additionally, documentation stating *exactly* what to do / provide > > you in the case something starts acting wonky would be highly > > beneficial (commands, kernel stuff, whatever would help you in > > troubleshooting). > > > I can't think of a good answer for this, either, because it depends > upon what "wonky" means. I don't think it's much different than any > other issue that shows up in freebsd-current (or freebsd-stable or > freebsd-fs) or a PR? (Then add the "-o" option to flip back to the > old server until the problem gets resolved.) I'm willing to slide on this one, but I'm mainly referring focused on situations where nfsd can't be killed, or the kernel "deadlocks" (is alive/NumLock works/etc. but is wedged). I'm a little surprised that you didn't say "procstat -kk would be a good start". :-) > Well, about the only improvement is NFSv4, so for you there is no incentive > at this time. Hopefully you may find the better file locking, ACLs etc that > NFSv4 offsers useful improvements someday. > > It does have a rather novel DRC (duplicate request cache), which I believe > works better, particularily when clients use TCP, but I can't say that > you'll see a noticible change because of this. (Maybe less mbuf hungry > compared to the generic one in the FreeBSD8 krpc.) Okay, so there's two items for the list: NFSv4 support (which offers improved locking and a better ACL model), and use of a duplicate request cache which can (ideally) help improve performance for TCP clients. This is the kind of stuff I'm looking for, and I imagine a lot of others are too. It sounds like NFSv2 and NFSv3 are basically untouched (no direct changes to them, but probably some indirect changes), I'm willing to switch over to using -e on our production cluster, while keeping the clients using mount_nfs *without* -o nfsv4. > ... > > One of the reasons that I was encouraged to suggest this is to get it > more widely tested. I can only do so much in this regard and that has > already happened. If others aren't willing to try and run it, it can't > progress beyond where it is now. > > Maybe someone from Isilon could chime in with some information on what > testing they've put it through, recognizing that their system is > significantly different and without giving out any information that > they would consider proprietary? > > Again, I can't guarantee there won't be a regression, but until others > try to run it, I/we won't know. I truly understand this situation, as it's been happening with all sorts of features in FreeBSD for years now. Change (or feature) X gets introduced, it's a Good Thing(tm), but how do you get users to actually test it? When is it truly "safe" to commit it as the default? I think the number of testers of the experimental server would increase if, like I said, there was a concise list of what the actual differences are between the non-experimental and experimental server. Once that is written (the FreeBSD Wiki would be a perfect place for it) and the URL disseminated, sending a mail to the lists (-fs, -stable, -current, and maybe -net -- not sure of the last one) asking people to test it would make most sense. That's my view, anyway. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 04:09:43 2011 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 2CE94106564A for ; Mon, 18 Apr 2011 04:09:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id CA4FA8FC12 for ; Mon, 18 Apr 2011 04:09:42 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta10.westchester.pa.mail.comcast.net with comcast id Ys7s1g0050cZkys5As9jVp; Mon, 18 Apr 2011 04:09:43 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta10.westchester.pa.mail.comcast.net with comcast id Ys9h1g00o1t3BNj3Ws9iNs; Mon, 18 Apr 2011 04:09:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id ACE8C9B42B; Sun, 17 Apr 2011 21:09:40 -0700 (PDT) Date: Sun, 17 Apr 2011 21:09:40 -0700 From: Jeremy Chadwick To: Rick Macklem Message-ID: <20110418040940.GA64222@icarus.home.lan> References: <20110415140435.GA4278@icarus.home.lan> <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca> <20110418034507.GA63656@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110418034507.GA63656@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 18 Apr 2011 04:09:43 -0000 On Sun, Apr 17, 2011 at 08:45:07PM -0700, Jeremy Chadwick wrote: > It sounds like NFSv2 and NFSv3 are basically untouched (no direct > changes to them, but probably some indirect changes), I'm willing to > switch over to using -e on our production cluster, while keeping the > clients using mount_nfs *without* -o nfsv4. Well that didn't go well. Server is RELENG_8 dated Thu Feb 24 22:06:45 PST 2011. rc.conf had the following: nfs_server_enable="yes" nfs_server_flags="-e -u -t -n 4" mountd_enable="yes" Note that I *did not* set nfsv4_server_enable="yes" because that appears to do mountd and nfsd were full stopped then started (in correct order). nfsd did not start, and this error was thrown on console: Apr 17 20:47:36 ra nfsd[23423]: Can't open /var/db/nfs-stablerestart Quickly digging through source introduced me to stablerestart(5), which states this: BUGS If the file is empty, the NFS V4 server has no choice but to return NFSERR_NOGRACE for all Reclaim requests. Although correct, this is a highly undesirable occurrence, so the file should not be lost if at all possible. Nfsd will not create the file if it does not exist and will simply log a failure to start, in the hopes that the file can be recov- ered from a backup. To move the file, you must edit the nfsd sources and recompile it. This was done to discourage accidental relocation of the file. The first line of this BUGS section implies touch'ing the file is insufficient. I was forced to review the source code to see what this file contains/how it's maintained; it appears to store two raw unsigned 32-bit ints to the file, otherwise it throws error "Can't read stable storage file" and exits. So how does one go about properly creating/initialising this file? And what should the proper file perm/ownership be? My opinion is that the rc.d scripts need to somehow do this, but only once. The nuances/complexities of this situation seem very high, as blindly creating the (presumably 8-byte) file on startup (if it doesn't exist) doesn't sound like it's the correct solution. Also, the nfsd(8) man page needs to list stablerestart(5) in its SEE ALSO section. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 04:12:20 2011 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 C336B106566C for ; Mon, 18 Apr 2011 04:12:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id A75038FC08 for ; Mon, 18 Apr 2011 04:12:20 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta05.emeryville.ca.mail.comcast.net with comcast id YsB31g0021vN32cA5sCLef; Mon, 18 Apr 2011 04:12:20 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id YsCK1g0081t3BNj8isCKZh; Mon, 18 Apr 2011 04:12:19 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id EF3B69B42B; Sun, 17 Apr 2011 21:12:18 -0700 (PDT) Date: Sun, 17 Apr 2011 21:12:18 -0700 From: Jeremy Chadwick To: Rick Macklem Message-ID: <20110418041218.GA64633@icarus.home.lan> References: <20110415140435.GA4278@icarus.home.lan> <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca> <20110418034507.GA63656@icarus.home.lan> <20110418040940.GA64222@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110418040940.GA64222@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 18 Apr 2011 04:12:20 -0000 On Sun, Apr 17, 2011 at 09:09:40PM -0700, Jeremy Chadwick wrote: > Note that I *did not* set nfsv4_server_enable="yes" because that appears > to do ...things in both rc.d/nfsd (specifically induce use of "nfsuserd" which is an NFSv4 thing) and rc.d/mountd (use -e on mountd too). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 09:44:05 2011 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 1FA13106566B for ; Mon, 18 Apr 2011 09:44:05 +0000 (UTC) (envelope-from aavzz@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [77.88.46.21]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5D28FC12 for ; Mon, 18 Apr 2011 09:44:04 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward5.mail.yandex.net (Yandex) with ESMTP id EE2E412011A0 for ; Mon, 18 Apr 2011 13:28:46 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1303118926; bh=l3/xyW9PAkr+VyY1DE4Zd6pTb6KjkcXT1JFhrsUdsGQ=; h=Subject:From:To:Content-Type:Date:Message-ID:Mime-Version: Content-Transfer-Encoding; b=A1JR+DIKfnlQ39rMTWffwe1rMLzkW/cJVUQvPOgXhH1TJH8PDfYIXDgZRW6JeARQC X7uQ1UFN+f/IYVGhL6iOsqxoHcmwe6z/6JP0hMPt9mzHIUQlKTvV4hkidxSAlgdWjn 5JbEPmD6sS/3qTJTBMLV2PuXUKXTy46uZO9cGJeg= Received: from [10.88.1.200] (unknown [91.210.24.47]) by smtp3.mail.yandex.net (Yandex) with ESMTPA id B544069800B1 for ; Mon, 18 Apr 2011 13:28:46 +0400 (MSD) From: Alex Zimnitsky To: freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Mon, 18 Apr 2011 13:29:08 +0400 Message-ID: <1303118948.2112.40.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Yandex-Spam: 1 Subject: unionfs kernel panic while mounting (i386, R8.2) 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, 18 Apr 2011 09:44:05 -0000 Hi everyone! There is a problem with unionfs mount procedure which consistently causes system crash. I observed this behavior (freshly installed release 8.2) on two i386 boxes one of which was an ancient laptop with 256MB RAM and the other was a not-so-old desktop with more than 4GB jf RAM. ******* How to reproduce: ************** mkdir /var/ftp mkdir /var/ftpdata1 mkdir /var/ftpdata2 ... mkdir /var/ftpdata15 mount -t unionfs /var/ftpdata1 /var/ftp mount -t unionfs /var/ftpdata2 /var/ftp ... mount -t unionfs /var/ftpdata15 /var/ftp mounting /var/ftpdata12 reliably caused kernel panic on the laptop in my case (desktop reliably crashed while mounting ftpdata10-12) ************ Possible cause **************** A little investigation revealed that this crash happens in unionfs_statfs which lives in /usr/src/sys/fs/unionfs/union_vfsops.c Debug printing showed that it calls itself recursively n+1 times depending on the quantity of previously mounted dirs: mount -t unionfs /var/ftpdata1 /var/ftp - 2 times mount -t unionfs /var/ftpdata2 /var/ftp - 3 times ... mount -t unionfs /var/ftpdata10 /var/ftp - 11 times ... It appears that the crash is caused by lack of system resources (stack I guess) The crash itself writes something like "double fault" or "double error" (I'm sure about that "double") **************** Workaround ************************ Reducing recursion eliminates the problem. unionfs_statfs part: old (with the problem): --------------------------------------------------------------- struct unionfs_mount *ump; int error; struct statfs mstat; uint64_t lbsize; ump = MOUNTTOUNIONFSMOUNT(mp); UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", (void *)mp, (void *)ump->um_lowervp, (void *)ump->um_uppervp); bzero(&mstat, sizeof(mstat)); error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); ----------------------------------------------------------------------- new (without crashes): ----------------------------------------------------------------------- struct unionfs_mount *ump; int error; struct statfs mstat; uint64_t lbsize; struct unionfs_mount *ump_aavzz; /*AAVZZ*/ /*ump = MOUNTTOUNIONFSMOUNT(mp);*/ /*AAVZZ*/ ump_aavzz = MOUNTTOUNIONFSMOUNT(mp); /*AAVZZ*/ UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", (void *)mp, (void *)ump->um_lowervp, (void *)ump->um_uppervp); bzero(&mstat, sizeof(mstat)); /*Dirty hack to fast forward*/ while (! strcmp(ump_aavzz->um_lowervp->v_mount->mnt_stat.f_fstypename, "unionfs")) { ump_aavzz=MOUNTTOUNIONFSMOUNT(ump_aavzz->um_lowervp->v_mount); } ump=ump_aavzz; /*end of dirty hack*/ error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); ------------------------------------------------------------------------------- **************************** Considerations ************************** I'm sure that the above is not the way to treat the problem. But I do not have deep understanding of the internal workings of filesystems in general and unionfs in particular and cannot come up with anything better. Probably this growing recursion should not take place at all, which requires defferent handling of ump->um_lowervp->v_mount during list creation (mount?). Regards, Alex From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 11:06:58 2011 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 F2EEC1065670 for ; Mon, 18 Apr 2011 11:06:58 +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 DFE708FC0C for ; Mon, 18 Apr 2011 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p3IB6wAj019479 for ; Mon, 18 Apr 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p3IB6wJj019477 for freebsd-fs@FreeBSD.org; Mon, 18 Apr 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Apr 2011 11:06:58 GMT Message-Id: <201104181106.p3IB6wJj019477@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, 18 Apr 2011 11:06:59 -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/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156168 fs [nfs] [panic] Kernel panic under concurrent access ove 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 o kern/155484 fs [ufs] GPT + UFS boot don't work well together o 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 o kern/154447 fs [zfs] [panic] Occasional panics - solaris assert somew f 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/153847 fs [nfs] [panic] Kernel panic from incorrect m_free in nf 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 kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small p kern/152488 fs [tmpfs] [patch] mtime of file updated when only inode 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 kern/151845 fs [smbfs] [patch] smbfs should be upgraded to support Un 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/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa f kern/149022 fs [hang] File system operations hangs with suspfs state 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 bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload 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 " o kern/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o 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 o 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/142914 fs [zfs] ZFS performance degradation over time 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/140134 fs [msdosfs] write and fsck destroy filesystem integrity 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/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u 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/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int 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/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [ffs] [snapshot] System crashes when manipulat 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 bin/118249 fs [ufs] mv(1): moving a directory changes its mtime 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/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani 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 kern/116170 fs [panic] Kernel panic when mounting /tmp 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 kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system 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/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk 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/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash 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 221 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 11:21:06 2011 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 71F7A106566B for ; Mon, 18 Apr 2011 11:21:06 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6308FC13 for ; Mon, 18 Apr 2011 11:21:05 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 8714B12543B; Mon, 18 Apr 2011 20:02:16 +0900 (JST) Date: Mon, 18 Apr 2011 20:02:16 +0900 From: Daichi GOTO To: freebsd-fs@freebsd.org Message-Id: <20110418200216.c50b687b.daichi@freebsd.org> In-Reply-To: <1303118948.2112.40.camel@localhost> References: <1303118948.2112.40.camel@localhost> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: unionfs kernel panic while mounting (i386, R8.2) 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, 18 Apr 2011 11:21:06 -0000 As you mentioned, deep unionfs mounts lead kernel stack over flow and panic. I have created a patch to prevent this issue: http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-cross-mount.diff If you want to solve, above patch will help you. p.s. so sorry, I don't remenber why this patch has not been merged. It was probably a policy of fs/kernel src... Does anyone remember? On Mon, 18 Apr 2011 13:29:08 +0400 Alex Zimnitsky wrote: > Hi everyone! > > > There is a problem with unionfs mount procedure > which consistently causes system crash. I observed > this behavior (freshly installed release 8.2) on > two i386 boxes one of which was an ancient laptop > with 256MB RAM and the other was a not-so-old > desktop with more than 4GB jf RAM. > > ******* How to reproduce: ************** > > mkdir /var/ftp > > mkdir /var/ftpdata1 > mkdir /var/ftpdata2 > ... > mkdir /var/ftpdata15 > > mount -t unionfs /var/ftpdata1 /var/ftp > mount -t unionfs /var/ftpdata2 /var/ftp > ... > mount -t unionfs /var/ftpdata15 /var/ftp > > mounting /var/ftpdata12 reliably caused > kernel panic on the laptop in my case > (desktop reliably crashed while mounting ftpdata10-12) > > ************ Possible cause **************** > > A little investigation revealed that this crash > happens in unionfs_statfs which lives > in /usr/src/sys/fs/unionfs/union_vfsops.c > > Debug printing showed that it calls itself > recursively n+1 times depending on the > quantity of previously mounted dirs: > > mount -t unionfs /var/ftpdata1 /var/ftp - 2 times > mount -t unionfs /var/ftpdata2 /var/ftp - 3 times > ... > mount -t unionfs /var/ftpdata10 /var/ftp - 11 times > ... > > It appears that the crash is caused by lack of system > resources (stack I guess) > > The crash itself writes something like "double fault" > or "double error" (I'm sure about that "double") > > > **************** Workaround ************************ > > Reducing recursion eliminates the problem. > > unionfs_statfs part: > > old (with the problem): > --------------------------------------------------------------- > > struct unionfs_mount *ump; > int error; > struct statfs mstat; > uint64_t lbsize; > > ump = MOUNTTOUNIONFSMOUNT(mp); > > UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", > (void *)mp, (void *)ump->um_lowervp, (void > *)ump->um_uppervp); > > bzero(&mstat, sizeof(mstat)); > > error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); > > ----------------------------------------------------------------------- > > new (without crashes): > ----------------------------------------------------------------------- > struct unionfs_mount *ump; > int error; > struct statfs mstat; > uint64_t lbsize; > > struct unionfs_mount *ump_aavzz; /*AAVZZ*/ > > /*ump = MOUNTTOUNIONFSMOUNT(mp);*/ /*AAVZZ*/ > ump_aavzz = MOUNTTOUNIONFSMOUNT(mp); /*AAVZZ*/ > > > UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", > (void *)mp, (void *)ump->um_lowervp, (void > *)ump->um_uppervp); > > bzero(&mstat, sizeof(mstat)); > > /*Dirty hack to fast forward*/ > while (! > strcmp(ump_aavzz->um_lowervp->v_mount->mnt_stat.f_fstypename, > "unionfs")) { > > ump_aavzz=MOUNTTOUNIONFSMOUNT(ump_aavzz->um_lowervp->v_mount); > } > ump=ump_aavzz; > /*end of dirty hack*/ > > error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); > > ------------------------------------------------------------------------------- > > > **************************** Considerations ************************** > > I'm sure that the above is not the way to treat the problem. But > I do not have deep understanding of the internal workings of filesystems > in general and unionfs in particular and cannot come up with anything > better. > > Probably this growing recursion should not take place at all, which > requires defferent handling of ump->um_lowervp->v_mount during list > creation (mount?). > > > > Regards, > > Alex > > _______________________________________________ > 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" -- Daichi GOTO From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 11:23:00 2011 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 58F561065676 for ; Mon, 18 Apr 2011 11:23:00 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id E674E8FC1C for ; Mon, 18 Apr 2011 11:22:59 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 2215B12543B; Mon, 18 Apr 2011 20:22:59 +0900 (JST) Date: Mon, 18 Apr 2011 20:22:59 +0900 From: Daichi GOTO To: freebsd-fs@freebsd.org Message-Id: <20110418202259.98f80217.daichi@freebsd.org> In-Reply-To: <1303118948.2112.40.camel@localhost> References: <1303118948.2112.40.camel@localhost> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: unionfs kernel panic while mounting (i386, R8.2) 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, 18 Apr 2011 11:23:00 -0000 That patch is wrong, correct patch this way ;) http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-cross-mount2.diff notice: above patch is too old. Please check by yourself before to use it. thanks. On Mon, 18 Apr 2011 13:29:08 +0400 Alex Zimnitsky wrote: > Hi everyone! > > > There is a problem with unionfs mount procedure > which consistently causes system crash. I observed > this behavior (freshly installed release 8.2) on > two i386 boxes one of which was an ancient laptop > with 256MB RAM and the other was a not-so-old > desktop with more than 4GB jf RAM. > > ******* How to reproduce: ************** > > mkdir /var/ftp > > mkdir /var/ftpdata1 > mkdir /var/ftpdata2 > ... > mkdir /var/ftpdata15 > > mount -t unionfs /var/ftpdata1 /var/ftp > mount -t unionfs /var/ftpdata2 /var/ftp > ... > mount -t unionfs /var/ftpdata15 /var/ftp > > mounting /var/ftpdata12 reliably caused > kernel panic on the laptop in my case > (desktop reliably crashed while mounting ftpdata10-12) > > ************ Possible cause **************** > > A little investigation revealed that this crash > happens in unionfs_statfs which lives > in /usr/src/sys/fs/unionfs/union_vfsops.c > > Debug printing showed that it calls itself > recursively n+1 times depending on the > quantity of previously mounted dirs: > > mount -t unionfs /var/ftpdata1 /var/ftp - 2 times > mount -t unionfs /var/ftpdata2 /var/ftp - 3 times > ... > mount -t unionfs /var/ftpdata10 /var/ftp - 11 times > ... > > It appears that the crash is caused by lack of system > resources (stack I guess) > > The crash itself writes something like "double fault" > or "double error" (I'm sure about that "double") > > > **************** Workaround ************************ > > Reducing recursion eliminates the problem. > > unionfs_statfs part: > > old (with the problem): > --------------------------------------------------------------- > > struct unionfs_mount *ump; > int error; > struct statfs mstat; > uint64_t lbsize; > > ump = MOUNTTOUNIONFSMOUNT(mp); > > UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", > (void *)mp, (void *)ump->um_lowervp, (void > *)ump->um_uppervp); > > bzero(&mstat, sizeof(mstat)); > > error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); > > ----------------------------------------------------------------------- > > new (without crashes): > ----------------------------------------------------------------------- > struct unionfs_mount *ump; > int error; > struct statfs mstat; > uint64_t lbsize; > > struct unionfs_mount *ump_aavzz; /*AAVZZ*/ > > /*ump = MOUNTTOUNIONFSMOUNT(mp);*/ /*AAVZZ*/ > ump_aavzz = MOUNTTOUNIONFSMOUNT(mp); /*AAVZZ*/ > > > UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", > (void *)mp, (void *)ump->um_lowervp, (void > *)ump->um_uppervp); > > bzero(&mstat, sizeof(mstat)); > > /*Dirty hack to fast forward*/ > while (! > strcmp(ump_aavzz->um_lowervp->v_mount->mnt_stat.f_fstypename, > "unionfs")) { > > ump_aavzz=MOUNTTOUNIONFSMOUNT(ump_aavzz->um_lowervp->v_mount); > } > ump=ump_aavzz; > /*end of dirty hack*/ > > error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); > > ------------------------------------------------------------------------------- > > > **************************** Considerations ************************** > > I'm sure that the above is not the way to treat the problem. But > I do not have deep understanding of the internal workings of filesystems > in general and unionfs in particular and cannot come up with anything > better. > > Probably this growing recursion should not take place at all, which > requires defferent handling of ump->um_lowervp->v_mount during list > creation (mount?). > > > > Regards, > > Alex > > _______________________________________________ > 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" -- Daichi GOTO 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 11:33:35 2011 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 B1B0D106567F for ; Mon, 18 Apr 2011 11:33:35 +0000 (UTC) (envelope-from abuse@cj-vollblutaraber.de) Received: from res7.worldserver.net (res7.worldserver.net [217.13.199.17]) by mx1.freebsd.org (Postfix) with SMTP id 006D78FC0C for ; Mon, 18 Apr 2011 11:33:34 +0000 (UTC) Received: (qmail 3905 invoked by uid 65534); 18 Apr 2011 11:22:10 -0000 Date: 18 Apr 2011 11:22:10 -0000 Message-ID: <20110418112210.3903.qmail@res7.worldserver.net> To: freebsd-fs@freebsd.org From: Dr.Ban Ki-moon. MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: Congratulation, URGENT RESPONSE IS NEEDED X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: courierservice@one.co.il List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:33:35 -0000 Congratulation, I just received a call from the Director of Scarlet Courier Service Company Nigeria that the consignment box that was sent to you was returned due to wrong address, This consignment box contained your $5.500.000.00 united state dollars, Your compensation fund.Therefore call the director (Williams Wright) on Tel: (+234705-550-1921 ) email him at: (couierservice@one.co.il) and give him your correct address and Phone number: So the Information you are Required to Reconfirm to the Agent is as Follow. (1)Your Full Name============= (2)Mobile Phone Number====== (3)Current Home Address======== (4)Occupation================= (5)Fax Number================ (6)Country==================== (7)City===================== (8)Nearest Airport ============== (9)A Copy of Your I D For Identification Use this code (XA-8550) as the subject of your mail to them for identification. Yours Truly. Dr. Ban Ki-moon. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 12:20:44 2011 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 C05781065670 for ; Mon, 18 Apr 2011 12:20:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 95D8F8FC14 for ; Mon, 18 Apr 2011 12:20:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4F97146B03; Mon, 18 Apr 2011 08:20:44 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B967C8A027; Mon, 18 Apr 2011 08:20:43 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Mon, 18 Apr 2011 08:11:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <20110409213250.00007ea9@unknown> In-Reply-To: <20110409213250.00007ea9@unknown> MIME-Version: 1.0 Message-Id: <201104180811.02684.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Apr 2011 08:20:43 -0400 (EDT) Cc: Subject: Re: Booting from freebsd-boot on gpt using zfs root on mbr 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, 18 Apr 2011 12:20:44 -0000 On Saturday, April 09, 2011 4:32:50 pm Bruce Cran wrote: > Hi, > > I'm trying to boot from gpt but with the zfs root on a mbr disk so I > can avoid overwriting the mbr bootcode on ada0. The > layout is: > > ada0s4: freebsd-zfs 80 GB (zroot) > ada1p1: freebsd-boot 128 kB > > When I enter "zroot:/boot/kernel/kernel" at the boot: prompt I get a > register dump followed by "BTX halted". Is there some way to get this > configuration to work? Which prompt is this at (the gptzfsroot prompt or the loader prompt)? Also, can you grab a snapshot of the register dump? -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 12:20:45 2011 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 3B647106564A; Mon, 18 Apr 2011 12:20:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6CE8FC16; Mon, 18 Apr 2011 12:20:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B94D146B51; Mon, 18 Apr 2011 08:20:44 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 590BE8A02A; Mon, 18 Apr 2011 08:20:44 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Mon, 18 Apr 2011 08:16:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201104172017.p3HKH57W019795@chez.mckusick.com> In-Reply-To: <201104172017.p3HKH57W019795@chez.mckusick.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201104180816.42495.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Apr 2011 08:20:44 -0400 (EDT) Cc: Kirk McKusick , Pawel Jakub Dawidek Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 18 Apr 2011 12:20:45 -0000 On Sunday, April 17, 2011 4:17:05 pm Kirk McKusick wrote: > I complete agree with Pawel's assesment. In the end, you have to have > more extensive testing to shake out the last few issues. There is plenty > of time before the 9.0 release, so if any serious issues arise, you can > change the default back. Yes, it needs to start being more widely tested now and the only real way to force that is changing the default. > Kirk McKusick > > =-=-= > > Date: Sun, 17 Apr 2011 21:08:34 +0200 > From: Pawel Jakub Dawidek > To: Rick Macklem > Cc: freebsd-fs@freebsd.org > Subject: Re: RFC: make the experimental NFS subsystem the default one > > On Fri, Apr 15, 2011 at 08:49:10AM -0400, Rick Macklem wrote: > > Hi, > > > > I think that the experimental NFS server is now ready for generic use > > and that the experimental NFS client will be soon, after some commits > > over the next week or so. > > > > How do folks feel w.r.t. making these the default? > > You should definiately do that! > > 1. The code is in the tree for a long time. > 2. Old NFS client/server stays and it is trivial to switch back to them > in case of problems. Would be nice to have UPDATING entry for this. > 3. This is FreeBSD HEAD only for now, so people should be ready for > experimental stuff in there. > 4. Would be great to have NFSv4 in FreeBSD 9.0-RELEASE. > > Really, Rick, there is nothing to wait for. :) > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://yomoli.com > _______________________________________________ > 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" > -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 12:20:45 2011 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 9A1711065676 for ; Mon, 18 Apr 2011 12:20:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6DA5F8FC17 for ; Mon, 18 Apr 2011 12:20:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 238C346B58; Mon, 18 Apr 2011 08:20:45 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B71C28A02B; Mon, 18 Apr 2011 08:20:44 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Mon, 18 Apr 2011 08:20:41 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <1369404502.72409.1302871750151.JavaMail.root@erie.cs.uoguelph.ca> <20110415140435.GA4278@icarus.home.lan> In-Reply-To: <20110415140435.GA4278@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104180820.41974.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Apr 2011 08:20:44 -0400 (EDT) Cc: Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 18 Apr 2011 12:20:45 -0000 On Friday, April 15, 2011 10:04:35 am Jeremy Chadwick wrote: > On Fri, Apr 15, 2011 at 08:49:10AM -0400, Rick Macklem wrote: > > I think that the experimental NFS server is now ready for generic use > > and that the experimental NFS client will be soon, after some commits > > over the next week or so. > > > > How do folks feel w.r.t. making these the default? > > > > My plan is to make the server the default first (the "-e" option on > > mountd and nfsd would become a no-op) and a new option on mountd and > > nfsd ("-o" sound ok?) would be needed to run what is currently the > > regular server. (I am not proposing taking out the regular client/server > > at this time, simply making them the non-default ones.) > > > > For the client, "newnfs" would become "nfs" and what is now "nfs" > > would become "oldnfs" for file system type. (This wouldn't happen > > until a series of commits bring "newnfs" in line with "nfs" for > > various things, including default mount options, plus diskless > > booting for NFSv3 gets fixed.) > > > > So, comments w.r.t. this would be appreciated, rick > > I can't speak for others, but I would feel much more comfortable if a > well-written and verbose document/web page was put up somewhere with a > full, concise list of what the changes are. Additionally, documentation > stating *exactly* what to do / provide you in the case something starts > acting wonky would be highly beneficial (commands, kernel stuff, > whatever would help you in troubleshooting). Short version: 1) It needs testing before 9.0 is released and the only real way to get that is to change the default. Users will generally not go try something new until the default changes. It can always be reverted before 9.0 is released if it blows up for some reason. 2) The old NFS code is a PITA. I can sum it up with "goto's from one macro that jump to a label defined in another macro". If you understand C at all, that should make you cry. (Thankfully, the second macro was retired a few years ago and all the 'nfsmout' labels are now explicit, but things like nfsm_request() still jump to a random label not defined in the macro on error, meaning all NFS functions have to have a single exit point, etc.) 3) NFSv4 does really matter for several folks, and it will continue to matter in the future. You will certainly care about it once it is performant as it offers far better cache consistency and the chance at far better use of locally cached data than NFSv2/3. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 17:43:50 2011 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 403801065673 for ; Mon, 18 Apr 2011 17:43:50 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id A5A178FC1A for ; Mon, 18 Apr 2011 17:43:49 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p3IHhkDZ015552 for ; Mon, 18 Apr 2011 20:43:46 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4DAC7811.3090407@ukr.net> Date: Mon, 18 Apr 2011 20:42:41 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.97 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Subject: Prompt to synchronize two volumes 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, 18 Apr 2011 17:43:50 -0000 I have 1TB of data in server1::tank1/backup. This volume should be *quickly* synchronized with server2::tank2/backup server1::tank1/backup ==> server2::tank2/backup How quickly and without having to download the channel to synchronize the both volumes. This command will transfer the entire amount of data? server1# zfs send tank1/backup | ssh server2 zfs recv tank2/backup Sync via rsync long and heavily loads the CPU :( Want to use all the facilities ZFS. -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 18:12:39 2011 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 C0F861065672 for ; Mon, 18 Apr 2011 18:12:39 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 79AD08FC17 for ; Mon, 18 Apr 2011 18:12:39 +0000 (UTC) Received: by qwc9 with SMTP id 9so3070707qwc.13 for ; Mon, 18 Apr 2011 11:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9LiVgEtLbLBghYs7qw6NfcIV869nSvQuOMZhoZ/PIXA=; b=Du8zqu6yFh43i4LYY0u/QXgIAe0M8Zy+1pgmz9oYQIQwhVVgXpuzMPeInP1ejYigS8 aPG8yWUJULfxNvGx0IRC6oxv0o7zKPzDpbTzdArYNs3DImhA8nWtHg6Cu86LyXh7OQ/j 4g/T9QlS7W1hDbrlsgb7w0nI5AEbKhyoS0AHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LXa8E6t/zUojVjLEHLVBsPI3RfyuGHCZWyLXhkuWkGyZE7ehzzHZ+tQH6KaVrhypee asaVZRRl8DYBqr13SxvzcDES8RUQH2cn2XDauCQWi24lUPB67OHeBxE/z/BDwbUsngkb 2NQaxO7aeNMVuaAtmWH5FC0dZoMDPKfsHxufo= MIME-Version: 1.0 Received: by 10.224.210.73 with SMTP id gj9mr3764711qab.225.1303150358780; Mon, 18 Apr 2011 11:12:38 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.229.221.193 with HTTP; Mon, 18 Apr 2011 11:12:38 -0700 (PDT) In-Reply-To: <4DAC7811.3090407@ukr.net> References: <4DAC7811.3090407@ukr.net> Date: Mon, 18 Apr 2011 11:12:38 -0700 X-Google-Sender-Auth: djRXBTB1UesKpXxMFLa_Zcud_o4 Message-ID: From: Artem Belevich To: "Vladislav V. Prodan" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Prompt to synchronize two volumes 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, 18 Apr 2011 18:12:39 -0000 On Mon, Apr 18, 2011 at 10:42 AM, Vladislav V. Prodan wrote: > I have 1TB of data in server1::tank1/backup. > This volume should be *quickly* synchronized with server2::tank2/backup > > =A0 =A0 =A0 =A0server1::tank1/backup =3D=3D> server2::tank2/backup > > How quickly and without having to download the channel to synchronize the > both volumes. > > This command will transfer the entire amount of data? > server1# zfs send tank1/backup | ssh server2 zfs recv tank2/backup > > Sync via rsync long and heavily loads the CPU :( > Want to use all the facilities ZFS. This page outlines ZFS replication process fairly well: http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html --Artem From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 19:55:29 2011 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 5F247106566B for ; Mon, 18 Apr 2011 19:55:29 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id C2C108FC15 for ; Mon, 18 Apr 2011 19:55:28 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p3IJtOZK026862 for ; Mon, 18 Apr 2011 22:55:24 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4DAC96EA.8080505@ukr.net> Date: Mon, 18 Apr 2011 22:54:18 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 CC: freebsd-fs@freebsd.org References: <4DAC7811.3090407@ukr.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.5 required=5.0 tests=ALL_TRUSTED,AWL, MISSING_HEADERS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.97 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Subject: Re: Prompt to synchronize two volumes 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, 18 Apr 2011 19:55:29 -0000 18.04.2011 21:12, Artem Belevich wrote: > This page outlines ZFS replication process fairly well: > http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html I do not understand why dumps snapshot to a file and then deploy on a remote machine? You can not like something is poured snapshot to another server? zfs send -i export/upload@zrep-00001 export/upload@zrep-00002 | ssh otherservername "cat > /export/save/upload@zrep-00002" cat /export/save/upload@rzrepl-00002 | zfs recv export/upload Maybe there are some pitfalls? -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 20:09:04 2011 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 EC133106564A for ; Mon, 18 Apr 2011 20:09:04 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id BC9498FC12 for ; Mon, 18 Apr 2011 20:09:04 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QBukp-000J4i-Pz; Mon, 18 Apr 2011 16:09:03 -0400 Date: Mon, 18 Apr 2011 16:09:03 -0400 From: Gary Palmer To: "Vladislav V. Prodan" Message-ID: <20110418200903.GA73035@in-addr.com> References: <4DAC7811.3090407@ukr.net> <4DAC96EA.8080505@ukr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DAC96EA.8080505@ukr.net> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-fs@freebsd.org Subject: Re: Prompt to synchronize two volumes 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, 18 Apr 2011 20:09:05 -0000 On Mon, Apr 18, 2011 at 10:54:18PM +0300, Vladislav V. Prodan wrote: > 18.04.2011 21:12, Artem Belevich wrote: > >This page outlines ZFS replication process fairly well: > >http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html > > I do not understand why dumps snapshot to a file and then deploy on a > remote machine? > You can not like something is poured snapshot to another server? > > zfs send -i export/upload@zrep-00001 export/upload@zrep-00002 | ssh > otherservername "cat > /export/save/upload@zrep-00002" > cat /export/save/upload@rzrepl-00002 | zfs recv export/upload > > Maybe there are some pitfalls? Read further down the page. Their reasoning is explained. Regards, Gary From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 20:15:19 2011 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 7783C106564A for ; Mon, 18 Apr 2011 20:15:19 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4DE8FC1E for ; Mon, 18 Apr 2011 20:15:18 +0000 (UTC) Received: by qwc9 with SMTP id 9so3142882qwc.13 for ; Mon, 18 Apr 2011 13:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Me0DG089EUD4JA+s8dETYGRbcXXC2MdUM/uJOGm+DTs=; b=rVNYw9OrcMLtObpya+Wf/96cuvzFFW+0swIC2wc/PwA5xShexAiGZes+v6B8FSRZZ6 EXVZ14xCe7zjUouJHmhjmAlBMo18LiijFZbtANxZg/wqSQbw3Hzv3FezZqcYv72QfTkl 4LCF/LTvXc9GUDH8z4hOeoQCH9TjHcpsGX6Oc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=x448twjE5r1OpjCZtTzh9ysJAuT3Pd4sj/juruPFxRib3nUBHXYWwidug/y8gkcGRC 8KwimaSwzbQoXR6I2k0LxudPosWVFhrzbgGLvTi3nmThHkEcPM0pHIV+N/P85SvPh5lW 9be0wae1fXRyvZEb7p4ybaz9V9R+rPIY0W48w= MIME-Version: 1.0 Received: by 10.229.227.3 with SMTP id iy3mr4324817qcb.38.1303157718100; Mon, 18 Apr 2011 13:15:18 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.229.221.193 with HTTP; Mon, 18 Apr 2011 13:15:17 -0700 (PDT) In-Reply-To: <4DAC96EA.8080505@ukr.net> References: <4DAC7811.3090407@ukr.net> <4DAC96EA.8080505@ukr.net> Date: Mon, 18 Apr 2011 13:15:17 -0700 X-Google-Sender-Auth: MNrnxsseObBBdMd_p7x1I2ls_hQ Message-ID: From: Artem Belevich To: "Vladislav V. Prodan" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Prompt to synchronize two volumes 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, 18 Apr 2011 20:15:19 -0000 On Mon, Apr 18, 2011 at 12:54 PM, Vladislav V. Prodan wrote: > 18.04.2011 21:12, Artem Belevich wrote: >> >> This page outlines ZFS replication process fairly well: >> http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html > > I do not understand why dumps snapshot to a file and then deploy on a remote > machine? > You can not like something is poured snapshot to another server? > > zfs send -i export/upload@zrep-00001 export/upload@zrep-00002 | ssh > otherservername "cat > /export/save/upload@zrep-00002" > cat /export/save/upload@rzrepl-00002 | zfs recv export/upload > > Maybe there are some pitfalls? They mentioned performance. mbuffer in-between receive and send makes *a lot* of difference as long as you provide few seconds worth of buffering at the rate your filesystems can sustain. I think the authors of the page above just didn't use large enough buffer. You would probably have to experiment yourself. In my case of ~3TB transfer (mostly large files), I ended up with "mbuffer -m512M". I also used mbuffer's built-in network transfer mechanism (see mbuffer's -I/-O options) as at high data rates ssh became the bottleneck. --Artem From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 20:47:29 2011 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 369361065670 for ; Mon, 18 Apr 2011 20:47:29 +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 400D98FC0C for ; Mon, 18 Apr 2011 20:47:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAKWirE2DaFvO/2dsb2JhbACET6FliG+rY4MKjWuBKYNOegSOAA X-IronPort-AV: E=Sophos;i="4.64,235,1301889600"; d="scan'208";a="117862747" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 18 Apr 2011 16:47:27 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 41A19B3F3E; Mon, 18 Apr 2011 16:47:27 -0400 (EDT) Date: Mon, 18 Apr 2011 16:47:27 -0400 (EDT) From: Rick Macklem To: Jeremy Chadwick Message-ID: <1065856259.239578.1303159647210.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110418040940.GA64222@icarus.home.lan> 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 - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 18 Apr 2011 20:47:29 -0000 > On Sun, Apr 17, 2011 at 08:45:07PM -0700, Jeremy Chadwick wrote: > > It sounds like NFSv2 and NFSv3 are basically untouched (no direct > > changes to them, but probably some indirect changes), I'm willing to > > switch over to using -e on our production cluster, while keeping the > > clients using mount_nfs *without* -o nfsv4. > > Well that didn't go well. Server is RELENG_8 dated Thu Feb 24 22:06:45 > PST 2011. rc.conf had the following: > > nfs_server_enable="yes" > nfs_server_flags="-e -u -t -n 4" > mountd_enable="yes" > You need the "-e" option on mountd as well. Running nfsuserd should be harmless, but you are correct that it is not necessary if the server will not be handling NFSv4 clients. > Note that I *did not* set nfsv4_server_enable="yes" because that > appears > to do > > mountd and nfsd were full stopped then started (in correct order). > nfsd > did not start, and this error was thrown on console: > > Apr 17 20:47:36 ra nfsd[23423]: Can't open /var/db/nfs-stablerestart > > Quickly digging through source introduced me to stablerestart(5), > which > states this: > > BUGS > If the file is empty, the NFS V4 server has no choice but to return > NFSERR_NOGRACE for all Reclaim requests. Although correct, this is a > highly undesirable occurrence, so the file should not be lost if at > all > possible. Nfsd will not create the file if it does not exist and will > simply log a failure to start, in the hopes that the file can be > recov- > ered from a backup. To move the file, you must edit the nfsd sources > and > recompile it. This was done to discourage accidental relocation of the > file. > > The first line of this BUGS section implies touch'ing the file is > insufficient. I was forced to review the source code to see what this > file contains/how it's maintained; it appears to store two raw > unsigned > 32-bit ints to the file, otherwise it throws error "Can't read stable > storage file" and exits. > > So how does one go about properly creating/initialising this file? And > what should the proper file perm/ownership be? > > My opinion is that the rc.d scripts need to somehow do this, but only > once. The nuances/complexities of this situation seem very high, as > blindly creating the (presumably 8-byte) file on startup (if it > doesn't > exist) doesn't sound like it's the correct solution. > The code in head no longer needs this. The nfsd now manages a backup copy of the file and creates them, as required. With the older code the file must be created as an empty file owned by root/wheel. This is explained in "man nfsv4", since I had assumed only folks who wanted nfsv4 would be using the server while it was "experimental". For example: # install -o root -g wheel -m 600 /dev/null /var/db/nfs-stablerestart - should do it (done as su, of course) > Also, the nfsd(8) man page needs to list stablerestart(5) in its SEE > ALSO section. > Agreed. I'll patch it. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 19 08:31:00 2011 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 6084B106564A for ; Tue, 19 Apr 2011 08:31:00 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop01.sare.net (proxypop01.sare.net [194.30.0.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1DB278FC08 for ; Tue, 19 Apr 2011 08:30:59 +0000 (UTC) Received: from [172.16.1.55] (ssglan.sare.net [192.148.167.100]) by proxypop01.sare.net (Postfix) with ESMTPA id AADD763E8D9; Tue, 19 Apr 2011 10:15:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: Date: Tue, 19 Apr 2011 10:15:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3596CB9B-7996-404B-AD34-D3A8DFD67FD4@sarenet.es> References: <4DAC7811.3090407@ukr.net> <4DAC96EA.8080505@ukr.net> To: Artem Belevich X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@freebsd.org Subject: Re: Prompt to synchronize two volumes 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: Tue, 19 Apr 2011 08:31:00 -0000 On Apr 18, 2011, at 10:15 PM, Artem Belevich wrote: > They mentioned performance. mbuffer in-between receive and send makes > *a lot* of difference as long as you provide few seconds worth of > buffering at the rate your filesystems can sustain. I think the > authors of the page above just didn't use large enough buffer. You > would probably have to experiment yourself. In my case of ~3TB > transfer (mostly large files), I ended up with "mbuffer -m512M". I > also used mbuffer's built-in network transfer mechanism (see mbuffer's > -I/-O options) as at high data rates ssh became the bottleneck. Moreover, although ZFS receive seems to be robust in case a replication = stream is interrupted, I find it much more safer to move the stream = beforehand, and start the zfs receive with a complete stream. Borja. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 19 11:08:35 2011 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 B8E71106564A for ; Tue, 19 Apr 2011 11:08:35 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 26C428FC15 for ; Tue, 19 Apr 2011 11:08:34 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p3JB8Uwo045083 for ; Tue, 19 Apr 2011 14:08:31 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4DAD6CEB.4060101@ukr.net> Date: Tue, 19 Apr 2011 14:07:23 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4DAC7811.3090407@ukr.net> <4DAC96EA.8080505@ukr.net> <3596CB9B-7996-404B-AD34-D3A8DFD67FD4@sarenet.es> In-Reply-To: <3596CB9B-7996-404B-AD34-D3A8DFD67FD4@sarenet.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.97 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Subject: Re: Prompt to synchronize two volumes 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: Tue, 19 Apr 2011 11:08:35 -0000 19.04.2011 11:15, Borja Marcos wrote: > Moreover, although ZFS receive seems to be robust in case a replication stream is interrupted, I find it much more safer to move the stream beforehand, and start the zfs receive with a complete stream. This is if there's a place on a remote server, and if not? How to transfer snapshots, then? -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Tue Apr 19 11:43:00 2011 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 34934106566B for ; Tue, 19 Apr 2011 11:43:00 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop02b.sare.net (proxypop02b.sare.net [194.30.18.100]) by mx1.freebsd.org (Postfix) with ESMTP id E5CC68FC15 for ; Tue, 19 Apr 2011 11:42:59 +0000 (UTC) Received: from [172.16.1.55] (ssglan.sare.net [192.148.167.100]) by proxypop02.sare.net (Postfix) with ESMTPA id 45E3A124E46D; Tue, 19 Apr 2011 13:43:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <4DAD6CEB.4060101@ukr.net> Date: Tue, 19 Apr 2011 13:42:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <691E4C9D-A9C5-425A-B4B0-5D8118D77A17@sarenet.es> References: <4DAC7811.3090407@ukr.net> <4DAC96EA.8080505@ukr.net> <3596CB9B-7996-404B-AD34-D3A8DFD67FD4@sarenet.es> <4DAD6CEB.4060101@ukr.net> To: Vladislav V. Prodan X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@freebsd.org Subject: Re: Prompt to synchronize two volumes 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: Tue, 19 Apr 2011 11:43:00 -0000 On Apr 19, 2011, at 1:07 PM, Vladislav V. Prodan wrote: > 19.04.2011 11:15, Borja Marcos wrote: >> Moreover, although ZFS receive seems to be robust in case a = replication stream is interrupted, I find it much more safer to move the = stream beforehand, and start the zfs receive with a complete stream. >=20 > This is if there's a place on a remote server, and if not? > How to transfer snapshots, then? Well, in that case you need a pipe. Something like zfs send blah blah | = ssh destination zfs receive blah blah But remember, you might have problems. Borja. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 19 17:58:20 2011 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 B1ABC106566B for ; Tue, 19 Apr 2011 17:58:20 +0000 (UTC) (envelope-from zack.kirsch@isilon.com) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id 93B608FC0A for ; Tue, 19 Apr 2011 17:58:20 +0000 (UTC) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 19 Apr 2011 10:46:19 -0700 Message-ID: <476FC2247D6C7843A4814ED64344560C03BB4DEC@seaxch10.desktop.isilon.com> In-Reply-To: <1369404502.72409.1302871750151.JavaMail.root@erie.cs.uoguelph.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: make the experimental NFS subsystem the default one Thread-Index: Acv7b5moJINOiFqkS1i/+Fk3iBzFoADSKQLQ References: <1369404502.72409.1302871750151.JavaMail.root@erie.cs.uoguelph.ca> From: "Zack Kirsch" To: "Rick Macklem" , Cc: Subject: RE: make the experimental NFS subsystem the default one 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, 19 Apr 2011 17:58:20 -0000 SGksDQoNClphY2sgS2lyc2NoIGZyb20gSXNpbG9uIFN5c3RlbXMgaGVyZS4gIEkganVzdCB3YW50 ZWQgdG8gbWVudGlvbiB0aGF0IHdlIGhhdmUgdGFrZW4gUmlja3MgZXhwZXJpbWVudGFsIHNlcnZl ciwgcG9ydGVkIGl0IG92ZXIgdG8gb3VyIE9uZUZTIHByb2R1Y3QgYW5kIGl0IGlzIG5vdyBvdXIg ZXhjbHVzaXZlIE5GUyBzZXJ2ZXIuICBPdXIgY3VzdG9tZXJzIGFyZSB2ZXJ5IGRlbWFuZGluZyBh cyBmYXIgYXMgc3RhYmlsaXR5IGFuZCBwZXJmb3JtYW5jZSwgYW5kIHNvIGZhciB3ZSBoYXZlbid0 IHNlZW4gcHJvYmxlbXMvcmVncmVzc2lvbnMgd2l0aCB0aGUgbmV3IHNlcnZlcidzIHN1cHBvcnQg Zm9yIE5GU3YzLg0KDQpUaGF0IHNhaWQsIHdlIGRvIGhhdmUgYSBzdWJzdGFudGlhbCBwYXRjaCAo fjI1ayBsaW5lcyBvZiBkaWZmKSBhZ2FpbnN0IHRoZSBleHBlcmltZW50YWwgc2VydmVyIHdoaWNo IHdlIHdpbGwgYmUgYXR0ZW1wdGluZyB0byB1cHN0cmVhbSBpbiB0aGUgbmV4dCBjb3VwbGUgb2Yg bW9udGhzLiAgTXVjaCBvZiB0aGUgZGlmZiBpcyB0byB0YWtlIGFkdmFudGFnZSBvZiBjbHVzdGVy ZWQgbG9ja2luZy9BQ0wgZmVhdHVyZXMgaW4gb3VyIGZpbGUgc3lzdGVtLCBvciBhZGQgTkZTdjQg ZmVhdHVyZXMsIGJ1dCBJJ20gc3VyZSB3ZSBoYXZlIHF1aXRlIGEgZmV3IGJ1Z2ZpeGVzIGluIHRo ZXJlIHRvby4gIE9uZSBxdWVzdGlvbiBhcm91bmQgb3VyIHVwc3RyZWFtaW5nIHdvcmsgaXMgaG93 IG11Y2ggdGltZSB3ZSB3aWxsIGhhdmUgYmVmb3JlIHRoZSBGcmVlQlNEIDkuMCByZWxlYXNlLg0K DQpJIGNhbid0IGNvbW1lbnQgbXVjaCBhYm91dCB0aGUgZXhwZXJpbWVudGFsIE5GUyBjbGllbnQs IGJlY2F1c2Ugb3VyIGN1c3RvbWVycyBkbyBub3QgdXNlIGl0Lg0KDQpaYWNrDQp6YWNrQGZyZWVi c2Qub3JnDQoNCg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IG93bmVy LWZyZWVic2QtZnNAZnJlZWJzZC5vcmcgW21haWx0bzpvd25lci1mcmVlYnNkLQ0KPj4gZnNAZnJl ZWJzZC5vcmddIE9uIEJlaGFsZiBPZiBSaWNrIE1hY2tsZW0NCj4+IFNlbnQ6IEZyaWRheSwgQXBy aWwgMTUsIDIwMTEgNTo0OSBBTQ0KPj4gVG86IGZyZWVic2QtZnNAZnJlZWJzZC5vcmcNCj4+IFN1 YmplY3Q6IFJGQzogbWFrZSB0aGUgZXhwZXJpbWVudGFsIE5GUyBzdWJzeXN0ZW0gdGhlIGRlZmF1 bHQgb25lDQo+PiANCj4+IEhpLA0KPj4gDQo+PiBJIHRoaW5rIHRoYXQgdGhlIGV4cGVyaW1lbnRh bCBORlMgc2VydmVyIGlzIG5vdyByZWFkeSBmb3IgZ2VuZXJpYyB1c2UNCj4+IGFuZCB0aGF0IHRo ZSBleHBlcmltZW50YWwgTkZTIGNsaWVudCB3aWxsIGJlIHNvb24sIGFmdGVyIHNvbWUgY29tbWl0 cw0KPj4gb3ZlciB0aGUgbmV4dCB3ZWVrIG9yIHNvLg0KPj4gDQo+PiBIb3cgZG8gZm9sa3MgZmVl bCB3LnIudC4gbWFraW5nIHRoZXNlIHRoZSBkZWZhdWx0Pw0KPj4gDQo+PiBNeSBwbGFuIGlzIHRv IG1ha2UgdGhlIHNlcnZlciB0aGUgZGVmYXVsdCBmaXJzdCAodGhlICItZSIgb3B0aW9uIG9uDQo+ PiBtb3VudGQgYW5kIG5mc2Qgd291bGQgYmVjb21lIGEgbm8tb3ApIGFuZCBhIG5ldyBvcHRpb24g b24gbW91bnRkIGFuZA0KPj4gbmZzZCAoIi1vIiBzb3VuZCBvaz8pIHdvdWxkIGJlIG5lZWRlZCB0 byBydW4gd2hhdCBpcyBjdXJyZW50bHkgdGhlDQo+PiByZWd1bGFyIHNlcnZlci4gKEkgYW0gbm90 IHByb3Bvc2luZyB0YWtpbmcgb3V0IHRoZSByZWd1bGFyDQo+PiBjbGllbnQvc2VydmVyDQo+PiBh dCB0aGlzIHRpbWUsIHNpbXBseSBtYWtpbmcgdGhlbSB0aGUgbm9uLWRlZmF1bHQgb25lcy4pDQo+ PiANCj4+IEZvciB0aGUgY2xpZW50LCAibmV3bmZzIiB3b3VsZCBiZWNvbWUgIm5mcyIgYW5kIHdo YXQgaXMgbm93ICJuZnMiDQo+PiB3b3VsZCBiZWNvbWUgIm9sZG5mcyIgZm9yIGZpbGUgc3lzdGVt IHR5cGUuIChUaGlzIHdvdWxkbid0IGhhcHBlbg0KPj4gdW50aWwgYSBzZXJpZXMgb2YgY29tbWl0 cyBicmluZyAibmV3bmZzIiBpbiBsaW5lIHdpdGggIm5mcyIgZm9yDQo+PiB2YXJpb3VzIHRoaW5n cywgaW5jbHVkaW5nIGRlZmF1bHQgbW91bnQgb3B0aW9ucywgcGx1cyBkaXNrbGVzcw0KPj4gYm9v dGluZyBmb3IgTkZTdjMgZ2V0cyBmaXhlZC4pDQo+PiANCj4+IFNvLCBjb21tZW50cyB3LnIudC4g dGhpcyB3b3VsZCBiZSBhcHByZWNpYXRlZCwgcmljaw0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGZyZWVic2QtZnNAZnJlZWJzZC5vcmcgbWFp bGluZyBsaXN0DQo+PiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9m cmVlYnNkLWZzDQo+PiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1m cy11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCg== From owner-freebsd-fs@FreeBSD.ORG Tue Apr 19 23:50:42 2011 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 13FDE106564A for ; Tue, 19 Apr 2011 23:50:42 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id C7C518FC13 for ; Tue, 19 Apr 2011 23:50:41 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta12.westchester.pa.mail.comcast.net with comcast id Zb6A1g0050cZkys5CbqiSw; Tue, 19 Apr 2011 23:50:42 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta10.westchester.pa.mail.comcast.net with comcast id Zbqf1g01X1t3BNj3Wbqgbq; Tue, 19 Apr 2011 23:50:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AC3059B42B; Tue, 19 Apr 2011 16:50:38 -0700 (PDT) Date: Tue, 19 Apr 2011 16:50:38 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20110419235038.GA8892@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Large number of SATA commits (MFCs) to RELENG_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, 19 Apr 2011 23:50:42 -0000 Folks who use SATA (speaking generally here because there's too much that got touched) should be aware: Within the past ~7 hours there have been a *very* large number of commits by mav@ that pertain to SATA-related storage controllers and subsystems. I would advocate that folks rebuild world/kernel and make sure there aren't any issues seen, or any quirks which were previously needed are no longer. I haven't gone through *all* of the commits yet, but I do see some controller-centric things that got MFC'd, such as disabling of NCQ support on multiport Marvell 88SX61XX to relieve I/O timeouts when doing lots of I/O (common with ZFS). Below are the commits. Users should absolutely use cvsweb or similar tools to examine the commit message and see if anything relevant to their storage subsystems was modified. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | Edit src/share/man/man4/ada.4 Add delta 1.1.2.9 2011.04.19.16.23.07 mav Edit src/share/man/man4/siis.4 Add delta 1.1.2.4 2011.04.19.16.52.36 mav Edit src/sys/cam/ata/ata_all.c Add delta 1.1.2.14 2011.04.19.16.26.55 mav Edit src/sys/cam/ata/ata_da.c Add delta 1.2.2.19 2011.04.19.16.23.07 mav Edit src/sys/cam/ata/ata_pmp.c Add delta 1.3.2.11 2011.04.19.17.41.17 mav Edit src/sys/cam/ata/ata_xpt.c Add delta 1.3.2.35 2011.04.19.17.41.17 mav Edit src/sys/cam/cam_ccb.h Add delta 1.37.2.9 2011.04.19.17.41.17 mav Edit src/sys/cam/cam_periph.c Add delta 1.80.2.10 2011.04.19.16.10.08 mav Edit src/sys/conf/options Add delta 1.687.2.12 2011.04.19.16.23.07 mav Edit src/sys/dev/ahci/ahci.c Add delta 1.1.2.45 2011.04.19.16.40.58 mav Add delta 1.1.2.46 2011.04.19.16.42.07 mav Add delta 1.1.2.47 2011.04.19.16.43.55 mav Add delta 1.1.2.48 2011.04.19.16.45.56 mav Add delta 1.1.2.49 2011.04.19.16.46.51 mav Add delta 1.1.2.50 2011.04.19.17.04.58 mav Add delta 1.1.2.51 2011.04.19.17.13.14 mav Add delta 1.1.2.52 2011.04.19.17.41.17 mav Add delta 1.1.2.53 2011.04.19.20.38.50 mav Add delta 1.1.2.54 2011.04.19.20.40.00 mav Add delta 1.1.2.55 2011.04.19.20.41.00 mav Edit src/sys/dev/ahci/ahci.h Add delta 1.1.2.12 2011.04.19.17.04.58 mav Add delta 1.1.2.13 2011.04.19.17.13.14 mav Add delta 1.1.2.14 2011.04.19.20.38.50 mav Add delta 1.1.2.15 2011.04.19.20.41.00 mav Edit src/sys/dev/ata/ata-all.c Add delta 1.308.2.20 2011.04.19.17.01.05 mav Edit src/sys/dev/ata/ata-all.h Add delta 1.146.2.15 2011.04.19.17.01.05 mav Edit src/sys/dev/ata/ata-pci.h Add delta 1.109.2.15 2011.04.19.16.40.58 mav Add delta 1.109.2.16 2011.04.19.16.42.07 mav Edit src/sys/dev/ata/chipsets/ata-intel.c Add delta 1.7.2.15 2011.04.19.16.40.58 mav Add delta 1.7.2.16 2011.04.19.16.42.07 mav Edit src/sys/dev/ichsmb/ichsmb_pci.c Add delta 1.21.2.5 2011.04.19.16.39.03 mav Add delta 1.21.2.6 2011.04.19.16.40.58 mav Add delta 1.21.2.7 2011.04.19.16.42.07 mav Edit src/sys/dev/ichwd/ichwd.c Add delta 1.17.2.7 2011.04.19.16.40.58 mav Add delta 1.17.2.8 2011.04.19.16.42.07 mav Edit src/sys/dev/ichwd/ichwd.h Add delta 1.9.2.5 2011.04.19.16.40.58 mav Add delta 1.9.2.6 2011.04.19.16.42.07 mav Edit src/sys/dev/mvs/mvs.c Add delta 1.2.2.8 2011.04.19.17.08.29 mav Add delta 1.2.2.9 2011.04.19.17.41.17 mav Add delta 1.2.2.10 2011.04.19.20.44.44 mav Edit src/sys/dev/mvs/mvs.h Add delta 1.1.2.3 2011.04.19.17.08.29 mav Add delta 1.1.2.4 2011.04.19.20.44.44 mav Edit src/sys/dev/siis/siis.c Add delta 1.1.2.33 2011.04.19.16.51.17 mav Add delta 1.1.2.34 2011.04.19.17.06.43 mav Add delta 1.1.2.35 2011.04.19.17.14.57 mav Add delta 1.1.2.36 2011.04.19.17.41.17 mav Edit src/sys/dev/siis/siis.h Add delta 1.1.2.10 2011.04.19.16.51.17 mav Add delta 1.1.2.11 2011.04.19.17.06.43 mav Edit src/sys/dev/sound/pci/hda/hdac.c Add delta 1.109.2.17 2011.04.19.16.42.07 mav Edit src/sys/modules/cam/Makefile Add delta 1.16.2.4 2011.04.19.16.23.07 mav Edit src/sys/sys/ata.h Add delta 1.41.2.9 2011.04.19.17.41.17 mav From owner-freebsd-fs@FreeBSD.ORG Wed Apr 20 12:22:13 2011 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 99904106566C; Wed, 20 Apr 2011 12:22:13 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 531188FC23; Wed, 20 Apr 2011 12:22:13 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 7E117E61D3; Wed, 20 Apr 2011 13:22:12 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=nld2eUBlmwrn SfVhpWrlJUx7sMA=; b=MfXzUMxFSb3sJ+Gxq2QIL51a0iDYo+UeoQYBW+L8/bab xwP0OVhMLNEWSP6jJYcS4DHzPEzXue0ekFKd30al8jSQ/SsocDeyg+NutIjy5HuZ NsCv5NbHSv0dpfTHQ1CuW5Nv8g1Er/KkIjdYmqnC8XK/1TXyekMJvOOE62Ava5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=hat5ha v8p5lrUBPgvOq+Kl5Dd8VqZAy1FEslsquU4Q5GKYEYOGEVicgPd4/agjreVBhL0Q bbOND4B0Qi19u+G6BdnDE6QiQrU2C46Rd80uz64e4FERQASJAMDV0El9EhmveJzO U7YNS+c04MIoR/gdYVp93gXFju+uMwZhUxIts= Received: from unknown (188-222-18-231.zone13.bethere.co.uk [188.222.18.231]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 3D0D5E61D2; Wed, 20 Apr 2011 13:22:12 +0100 (BST) Date: Wed, 20 Apr 2011 13:22:11 +0100 From: Bruce Cran To: John Baldwin Message-ID: <20110420132211.0000183a@unknown> In-Reply-To: <201104180811.02684.jhb@freebsd.org> References: <20110409213250.00007ea9@unknown> <201104180811.02684.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Booting from freebsd-boot on gpt using zfs root on mbr 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, 20 Apr 2011 12:22:13 -0000 On Mon, 18 Apr 2011 08:11:02 -0400 John Baldwin wrote: > On Saturday, April 09, 2011 4:32:50 pm Bruce Cran wrote: > > When I enter "zroot:/boot/kernel/kernel" at the boot: prompt I get a > > register dump followed by "BTX halted". Is there some way to get > > this configuration to work? > > Which prompt is this at (the gptzfsroot prompt or the loader prompt)? > Also, can you grab a snapshot of the register dump? Sorry, for some reason I was trying to load a kernel from the gptzfsboot prompt, instead of zfsloader; the loader files hadn't been installed properly, and once they were copied over again everything started working using zroot:/boot/zfsloader. -- Bruce Cran From owner-freebsd-fs@FreeBSD.ORG Wed Apr 20 18:54:04 2011 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 3FFE5106564A for ; Wed, 20 Apr 2011 18:54:04 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id DD73A8FC0C for ; Wed, 20 Apr 2011 18:54:03 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id ECFE845DD8; Wed, 20 Apr 2011 20:54:01 +0200 (CEST) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5DFF945683; Wed, 20 Apr 2011 20:53:56 +0200 (CEST) Date: Wed, 20 Apr 2011 20:53:47 +0200 From: Pawel Jakub Dawidek To: Rick Macklem Message-ID: <20110420185347.GH1907@garage.freebsd.pl> References: <337FAD9E-6973-4CA4-96E2-4A24F69916AF@3geeks.org> <1660005215.123902.1302913176495.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o71xDhNo7p97+qVi" Content-Disposition: inline In-Reply-To: <1660005215.123902.1302913176495.JavaMail.root@erie.cs.uoguelph.ca> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: question on extended attributes 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, 20 Apr 2011 18:54:04 -0000 --o71xDhNo7p97+qVi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 15, 2011 at 08:19:36PM -0400, Rick Macklem wrote: > I don't believe that resource forks are available under FreeBSD at this > time. Solaris supports the "subfile" concept, which is basically the same > as far as I know, so it seems there might be something inside ZFS, althou= gh > I suspect it isn't available for FreeBSD? >=20 > Does anyone familiar with ZFS know more? ZFS in FreeBSD supports extended attributes based on Solaris resource forks code. Take a look at the zfs_create_attrname() function in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c to see how we convert the names, etc. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --o71xDhNo7p97+qVi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk2vK7oACgkQForvXbEpPzRqLQCgk5fIx36fD08ETSppPobHtwBy GMMAoL0b1fQL7Jv/ZJEY+vrkZkKoGq0j =sNaR -----END PGP SIGNATURE----- --o71xDhNo7p97+qVi-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 20 21:45:59 2011 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 8DCC8106564A; Wed, 20 Apr 2011 21:45:59 +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 3D58E8FC19; Wed, 20 Apr 2011 21:45:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEANRTr02DaFvO/2dsb2JhbACEUaFuiG+tIpESgSmDTnoEjiI X-IronPort-AV: E=Sophos;i="4.64,247,1301889600"; d="scan'208";a="118157473" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 20 Apr 2011 17:45:58 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5A05292127; Wed, 20 Apr 2011 17:45:58 -0400 (EDT) Date: Wed, 20 Apr 2011 17:45:58 -0400 (EDT) From: Rick Macklem To: Pawel Jakub Dawidek Message-ID: <1319015176.378941.1303335958312.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110420185347.GH1907@garage.freebsd.pl> 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 - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: question on extended attributes 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, 20 Apr 2011 21:45:59 -0000 > On Fri, Apr 15, 2011 at 08:19:36PM -0400, Rick Macklem wrote: > > I don't believe that resource forks are available under FreeBSD at > > this > > time. Solaris supports the "subfile" concept, which is basically the > > same > > as far as I know, so it seems there might be something inside ZFS, > > although > > I suspect it isn't available for FreeBSD? > > > > Does anyone familiar with ZFS know more? > > ZFS in FreeBSD supports extended attributes based on Solaris resource > forks code. Take a look at the zfs_create_attrname() function in > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c to see how > we > convert the names, etc. > Hmm. NFSv4 supports the resource forks model, too. (They called them named attributes.) I suppose that there would have to be some new VOPs though. For example, the NFSv4 server needs to be able to get all the attribute names, so it can generate a reply to the client (in that ugly readdir xdr format) and I don't think there's a way in the current VFS to ask "give me all the extended attribute names", is there? Might be worth looking at someday, rick ps: I know. Slightly off topic. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 20 22:14:23 2011 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 B841B106564A for ; Wed, 20 Apr 2011 22:14:23 +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 723268FC08 for ; Wed, 20 Apr 2011 22:14:23 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAJtZr02DaFvO/2dsb2JhbACEUaFtthKRDoEpg056BI4i X-IronPort-AV: E=Sophos;i="4.64,247,1301889600"; d="scan'208";a="118160226" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 20 Apr 2011 18:14:22 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9486EB3F3F; Wed, 20 Apr 2011 18:14:22 -0400 (EDT) Date: Wed, 20 Apr 2011 18:14:22 -0400 (EDT) From: Rick Macklem To: Jeremy Chadwick Message-ID: <977321498.379779.1303337662533.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110415140435.GA4278@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 20 Apr 2011 22:14:23 -0000 > > - Has the experimental code been stress-tested? If so, how? I've heard > of people doing silly things like testing with filesystem benchmark > utilities -- which pass/work fine, but the instant someone tries > using something like rsnapshot (like we do), the thing falls apart. > Just fyi, Peter Holms (pho@) has volunteered to do some stress testing, which is now in progress. Thanks go to him for doing this, rick From owner-freebsd-fs@FreeBSD.ORG Wed Apr 20 22:25:41 2011 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 2EBEF106568B for ; Wed, 20 Apr 2011 22:25:41 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 272D38FC1D for ; Wed, 20 Apr 2011 22:25:39 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 212AA45B36; Thu, 21 Apr 2011 00:25:38 +0200 (CEST) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id F062B45C8A; Thu, 21 Apr 2011 00:25:32 +0200 (CEST) Date: Thu, 21 Apr 2011 00:25:23 +0200 From: Pawel Jakub Dawidek To: Rick Macklem Message-ID: <20110420222523.GJ1907@garage.freebsd.pl> References: <20110420185347.GH1907@garage.freebsd.pl> <1319015176.378941.1303335958312.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKy6e3LXpfmanBFM" Content-Disposition: inline In-Reply-To: <1319015176.378941.1303335958312.JavaMail.root@erie.cs.uoguelph.ca> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: question on extended attributes 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, 20 Apr 2011 22:25:41 -0000 --tKy6e3LXpfmanBFM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2011 at 05:45:58PM -0400, Rick Macklem wrote: > > On Fri, Apr 15, 2011 at 08:19:36PM -0400, Rick Macklem wrote: > > > I don't believe that resource forks are available under FreeBSD at > > > this > > > time. Solaris supports the "subfile" concept, which is basically the > > > same > > > as far as I know, so it seems there might be something inside ZFS, > > > although > > > I suspect it isn't available for FreeBSD? > > > > > > Does anyone familiar with ZFS know more? > >=20 > > ZFS in FreeBSD supports extended attributes based on Solaris resource > > forks code. Take a look at the zfs_create_attrname() function in > > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c to see how > > we > > convert the names, etc. > >=20 > Hmm. NFSv4 supports the resource forks model, too. (They called them > named attributes.) I suppose that there would have to be some new VOPs > though. For example, the NFSv4 server needs to be able to get all the > attribute names, so it can generate a reply to the client (in that ugly > readdir xdr format) and I don't think there's a way in the current VFS > to ask "give me all the extended attribute names", is there? You mean all extended attribute names in the entire file system? That doesn't seem sensible. You can still list extended attributes of the given file system object with VOP_LISTEXTATTR(9). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --tKy6e3LXpfmanBFM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk2vXVIACgkQForvXbEpPzRujQCeIp2zeUvCxlg3DF9la6e+aZl3 s0kAn0Is2JgAadw2IkrEXPA0Kd4+eXdF =gskb -----END PGP SIGNATURE----- --tKy6e3LXpfmanBFM-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 20 22:57:13 2011 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 E520D1065674; Wed, 20 Apr 2011 22:57:13 +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 8CEEA8FC1B; Wed, 20 Apr 2011 22:57:13 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEACxkr02DaFvO/2dsb2JhbACEUKFtiG+tUJEOgSmDTnoEjiI X-IronPort-AV: E=Sophos;i="4.64,248,1301889600"; d="scan'208";a="118163484" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 20 Apr 2011 18:57:12 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 798B1B3F3A; Wed, 20 Apr 2011 18:57:12 -0400 (EDT) Date: Wed, 20 Apr 2011 18:57:12 -0400 (EDT) From: Rick Macklem To: Pawel Jakub Dawidek Message-ID: <1382687340.380996.1303340232443.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110420222523.GJ1907@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: question on extended attributes 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, 20 Apr 2011 22:57:14 -0000 > > Hmm. NFSv4 supports the resource forks model, too. (They called them > > named attributes.) I suppose that there would have to be some new > > VOPs > > though. For example, the NFSv4 server needs to be able to get all > > the > > attribute names, so it can generate a reply to the client (in that > > ugly > > readdir xdr format) and I don't think there's a way in the current > > VFS > > to ask "give me all the extended attribute names", is there? > > You mean all extended attribute names in the entire file system? Nope. All for one object. > That doesn't seem sensible. You can still list extended attributes of > the given file system object with VOP_LISTEXTATTR(9). > Ok, I didn't know about this. It is probably doable then. Won't get to it for a while though. Thanks for the info, rick ps: It's a fair bit of coding, because the "list" of attributes for an object looks like a directory, then the items can be "look'd up", "open'd", "read" and "written" like ordinary files. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 20 23:44:52 2011 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 AAED8106566C; Wed, 20 Apr 2011 23:44:52 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 689858FC19; Wed, 20 Apr 2011 23:44:52 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p3KNioMm025788 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 19:44:50 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4DAF6FEA.2020004@sentex.net> Date: Wed, 20 Apr 2011 19:44:42 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <20110419235038.GA8892@icarus.home.lan> In-Reply-To: <20110419235038.GA8892@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Large number of SATA commits (MFCs) to RELENG_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: Wed, 20 Apr 2011 23:44:52 -0000 On 4/19/2011 7:50 PM, Jeremy Chadwick wrote: > I would advocate that folks rebuild world/kernel and make sure there > aren't any issues seen, or any quirks which were previously needed are > no longer. > > I haven't gone through *all* of the commits yet, but I do see some > controller-centric things that got MFC'd, such as disabling of NCQ > support on multiport Marvell 88SX61XX to relieve I/O timeouts when > doing lots of I/O (common with ZFS). > > Below are the commits. Users should absolutely use cvsweb or similar > tools to examine the commit message and see if anything relevant to > their storage subsystems was modified. Remember, this is MFC'd in that it has been in HEAD for some time. Its not like its all untested. That being said, I tested out an updated kernel from today on a test box as well as upgraded my home server at scbus0 target 0 lun 0 (pass0,ada0) at scbus0 target 1 lun 0 (pass1,ada1) at scbus0 target 2 lun 0 (pass2,ada2) at scbus0 target 3 lun 0 (pass3,ada3) at scbus0 target 15 lun 0 (pass4,pmp0) at scbus4 target 0 lun 0 (pass5,ada4) at scbus6 target 0 lun 0 (pass6,ada5) # zpool status pool: test1 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM test1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada3 ONLINE 0 0 0 label/JP2940HD0352LC ONLINE 0 0 0 errors: No known data errors all off siis0@pci0:1:0:0: class=0x010400 card=0x71321095 chip=0x31321095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'PCI Express (1x) to 2 Port SATA300 (SiI 3132)' class = mass storage subclass = RAID cap 01[54] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[5c] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint max data 128(1024) link x1(x1) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 00:34:37 2011 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 49598106566B for ; Thu, 21 Apr 2011 00:34:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id E87E58FC08 for ; Thu, 21 Apr 2011 00:34:36 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id Zyeq1g00927AodY510adT0; Thu, 21 Apr 2011 00:34:37 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.westchester.pa.mail.comcast.net with comcast id a0ab1g00r1t3BNj3f0acNX; Thu, 21 Apr 2011 00:34:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 10DDB9B418; Wed, 20 Apr 2011 17:34:34 -0700 (PDT) Date: Wed, 20 Apr 2011 17:34:34 -0700 From: Jeremy Chadwick To: Rick Macklem Message-ID: <20110421003434.GA18338@icarus.home.lan> References: <20110415140435.GA4278@icarus.home.lan> <977321498.379779.1303337662533.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <977321498.379779.1303337662533.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 21 Apr 2011 00:34:37 -0000 On Wed, Apr 20, 2011 at 06:14:22PM -0400, Rick Macklem wrote: > > - Has the experimental code been stress-tested? If so, how? I've heard > > of people doing silly things like testing with filesystem benchmark > > utilities -- which pass/work fine, but the instant someone tries > > using something like rsnapshot (like we do), the thing falls apart. > > > Just fyi, Peter Holms (pho@) has volunteered to do some stress testing, > which is now in progress. > > Thanks go to him for doing this, rick Totally awesome. Thank you both for doing this -- I can probably safely speak for the community when I say we all appreciate it. :-) Also, related yet unrelated: our production environment is running the experimental server as of ~48 hours ago, and things seem okay. Our rsync jobs have all passed w/out issue, no anomalies. The stablerestart(5) stuff needs to get dealt with before the switch-to experimental-server-as-default gets flipped on, but I know you'll get to that, Rick. If you need any testing/help from me, just let me know. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 00:43:03 2011 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 83D79106564A for ; Thu, 21 Apr 2011 00:43:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 69CF08FC16 for ; Thu, 21 Apr 2011 00:43:03 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta02.emeryville.ca.mail.comcast.net with comcast id a0h31g0030x6nqcA20j3Rk; Thu, 21 Apr 2011 00:43:03 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id a0j11g00s1t3BNj8Y0j2rx; Thu, 21 Apr 2011 00:43:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 779A59B418; Wed, 20 Apr 2011 17:43:01 -0700 (PDT) Date: Wed, 20 Apr 2011 17:43:01 -0700 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20110421004301.GA18390@icarus.home.lan> References: <20110419235038.GA8892@icarus.home.lan> <4DAF6FEA.2020004@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DAF6FEA.2020004@sentex.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Large number of SATA commits (MFCs) to RELENG_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: Thu, 21 Apr 2011 00:43:03 -0000 On Wed, Apr 20, 2011 at 07:44:42PM -0400, Mike Tancsa wrote: > On 4/19/2011 7:50 PM, Jeremy Chadwick wrote: > > I would advocate that folks rebuild world/kernel and make sure there > > aren't any issues seen, or any quirks which were previously needed are > > no longer. > > > > I haven't gone through *all* of the commits yet, but I do see some > > controller-centric things that got MFC'd, such as disabling of NCQ > > support on multiport Marvell 88SX61XX to relieve I/O timeouts when > > doing lots of I/O (common with ZFS). > > > > Below are the commits. Users should absolutely use cvsweb or similar > > tools to examine the commit message and see if anything relevant to > > their storage subsystems was modified. > > Remember, this is MFC'd in that it has been in HEAD for some time. Its > not like its all untested. Understood, however the userbase of RELENG_8 is significantly higher than that of HEAD/CURRENT, and the userbase of RELENG_8 is a lot more likely to complain en masse when something breaks. My goal was to bring to the attention of the community that a large number of storage/AHCI/SATA-related MFCs had been done, and request that people (if possible) rebuild world/kernel to make sure all of their stuff still works. Better to catch it during RELENG_8 than during RELENG_8_3. :-) > That being said, I tested out an updated kernel from today on a test > box as well as upgraded my home server I also did the same on mine. at scbus0 target 0 lun 0 (ada0,pass0) at scbus3 target 0 lun 0 (ada1,pass1) at scbus4 target 0 lun 0 (ada2,pass2) at scbus5 target 0 lun 0 (ada3,pass3) pool: backups state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM backups ONLINE 0 0 0 ada2 ONLINE 0 0 0 errors: No known data errors pool: data state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 mirror ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada3 ONLINE 0 0 0 errors: No known data errors ahci0@pci0:0:31:2: class=0x010601 card=0xd38015d9 chip=0x29228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) 6 port SATA AHCI Controller' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0x1c50, size 8, enabled bar [14] = type I/O Port, range 32, base 0x1c44, size 4, enabled bar [18] = type I/O Port, range 32, base 0x1c48, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x1c40, size 4, enabled bar [20] = type I/O Port, range 32, base 0x18e0, size 32, enabled bar [24] = type Memory, range 32, base 0xdc000800, size 2048, enabled cap 05[80] = MSI supports 16 messages enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair cap 13[b0] = PCI Advanced Features: FLR TP pass0: ATA-7 SATA 2.x device pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-7 SATA 2.x device model INTEL SSDSA2M040G2GC firmware revision 2CV102M3 serial number XXX WWN 50015179591a451a cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 78165360 sectors LBA48 supported 78165360 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) yes pass1: ATA-8 SATA 3.x device pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 3.x device model WDC WD1002FAEX-00Z3A0 firmware revision 05.01D05 serial number XXX WWN 50014ee25a001e1c cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 1953525168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management yes no 254/0xFE 128/0x80 media status notification no no power-up in Standby yes no write-read-verify no no unload no no free-fall no no data set management (TRIM) no pass2: ATA-8 SATA 2.x device pass2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 2.x device model WDC WD2001FASS-00U0B0 firmware revision 01.00101 serial number XXX WWN 50014ee6aab7bee0 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 3907029168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 7200 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 128/0x80 automatic acoustic management yes no 254/0xFE 128/0x80 media status notification no no power-up in Standby yes no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) no pass3: ATA-8 SATA 2.x device pass3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 2.x device model WDC WD1001FALS-00J7B1 firmware revision 05.00K05 serial number XXX WWN 50014ee0abfabee cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 1953525168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management yes no 254/0xFE 128/0x80 media status notification no no power-up in Standby yes no write-read-verify no no unload no no free-fall no no data set management (TRIM) no -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 00:43:11 2011 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 926E71065680 for ; Thu, 21 Apr 2011 00:43:11 +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 4B7C88FC12 for ; Thu, 21 Apr 2011 00:43:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAL98r02DaFvO/2dsb2JhbACEUKFwiG+tHZEYgSmDUH0EjiQ X-IronPort-AV: E=Sophos;i="4.64,248,1301889600"; d="scan'208";a="119045172" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 20 Apr 2011 20:43:10 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4A305B3F2B; Wed, 20 Apr 2011 20:43:10 -0400 (EDT) Date: Wed, 20 Apr 2011 20:43:10 -0400 (EDT) From: Rick Macklem To: Jeremy Chadwick Message-ID: <1167593109.383934.1303346590212.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110421003434.GA18338@icarus.home.lan> 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 - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one 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, 21 Apr 2011 00:43:11 -0000 > > The stablerestart(5) stuff needs to get dealt with before the > switch-to > experimental-server-as-default gets flipped on, but I know you'll get > to > that, Rick. If you need any testing/help from me, just let me know. > Those changes are already committed to head, which is the only place where the default will change. (I do plan on MFC'ing the stablerestart stuff.) rick From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 03:00:33 2011 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 660EA1065670 for ; Thu, 21 Apr 2011 03:00:33 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from mta02.eastlink.ca (mta02.eastlink.ca [24.224.136.13]) by mx1.freebsd.org (Postfix) with ESMTP id 3097A8FC13 for ; Thu, 21 Apr 2011 03:00:32 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ip06.eastlink.ca ([unknown] [24.222.39.84]) by mta02.eastlink.ca (Sun Java(tm) System Messaging Server 7.3-11.01 64bit (built Sep 1 2009)) with ESMTP id <0LJZ00EI3F0W0XS0@mta02.eastlink.ca> for freebsd-fs@freebsd.org; Thu, 21 Apr 2011 00:00:32 -0300 (ADT) X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=KTm0Zd9FEOPabIM+9UH3RcOan8ug7Hn5ok0IYj/PkF8= c=1 sm=1 a=e8U4T-BRE4EA:10 a=IkcTkHD0fZMA:10 a=mSvvwuuuHahiWgxFuZgA:9 a=5A4lKyET5Ks05QUivicA:7 a=QEXdDO2ut3YA:10 a=12M4PSijgPY/TTHpO+5bpg==:117 Received: from blk-222-10-85.eastlink.ca (HELO server7.acsi.ca) ([24.222.10.85]) by ip06.eastlink.ca with ESMTP; Thu, 21 Apr 2011 00:00:31 -0300 Received: from server7.acsi.ca ([192.168.9.7]) by server7.acsi.ca ([192.168.9.7]) with mapi; Thu, 21 Apr 2011 00:00:31 -0300 From: Chris Forgeron To: Rick Macklem , "freebsd-fs@freebsd.org" Date: Thu, 21 Apr 2011 00:00:32 -0300 Thread-topic: make the experimental NFS subsystem the default one Thread-index: Acv7b5qlDB8JlbJGTmmOIVzpBBScwwEXt4cA Message-id: References: <1369404502.72409.1302871750151.JavaMail.root@erie.cs.uoguelph.ca> In-reply-to: <1369404502.72409.1302871750151.JavaMail.root@erie.cs.uoguelph.ca> Accept-Language: en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Cc: Subject: RE: make the experimental NFS subsystem the default one 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, 21 Apr 2011 03:00:33 -0000 I use the NFS server in FreeBSD 9.0 pretty heavily. I drive a VMware ESX cluster off three FreeBSD 9.0-Current boxes using ZFS v28 (Yeah, I know, a bit risky, but it's more stable than OpenSolaris under my environment). While I'm a bit hesitant about any changes to what is working fairly well for me, I agree that we'll never move forward unless this is the default so it will receive more testing. With no plans from VMware for NFS 4.x in the near future, I'd say that NFS v3 will continue to be very important to the VMware crowd in FreeBSD for some time. I've hacked up the old NFS server a bit to better serve my ESX/NFS needs (forcing it to always write async so it works faster with ZFS and a ZIL). I guess I could do the same to the new code as well... ..However, if you didn't mind adding switch to force the NFS server to quietly only do an async VOP_WRITE, that would be really handy. Very dangerous for some people, but then again, so are most switches if you don't understand what they do. ESX will only opens it's files with O_SYNC, and it's not an editable option, so people like me running ESX+NFS over a ZFS share that has a ZIL are making the system do a lot of unnecessary sync writes. Yes, I know about SSD/RAM for the ZIL, but it still slows it down quite a bit over an async write. From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 03:49:19 2011 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 81DE8106566B for ; Thu, 21 Apr 2011 03:49:19 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 2BB658FC12 for ; Thu, 21 Apr 2011 03:49:18 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id D946D12543B; Thu, 21 Apr 2011 12:49:17 +0900 (JST) Date: Thu, 21 Apr 2011 12:49:19 +0900 From: Daichi GOTO To: Alex Zimnitsky Message-Id: <20110421124919.5dc64403.daichi@freebsd.org> In-Reply-To: <1303118948.2112.40.camel@localhost> References: <1303118948.2112.40.camel@localhost> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: unionfs kernel panic while mounting (i386, R8.2) 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, 21 Apr 2011 03:49:19 -0000 Hi Alex I have tried to reproduce your panic, but couldn't get a panic. Would you please try unionfs on 8-stable? ps. I do refreshing my patch to get merged into current. After some tests, I'll open my new patch for public test. thanks :) On Mon, 18 Apr 2011 13:29:08 +0400 Alex Zimnitsky wrote: > Hi everyone! > > > There is a problem with unionfs mount procedure > which consistently causes system crash. I observed > this behavior (freshly installed release 8.2) on > two i386 boxes one of which was an ancient laptop > with 256MB RAM and the other was a not-so-old > desktop with more than 4GB jf RAM. > > ******* How to reproduce: ************** > > mkdir /var/ftp > > mkdir /var/ftpdata1 > mkdir /var/ftpdata2 > ... > mkdir /var/ftpdata15 > > mount -t unionfs /var/ftpdata1 /var/ftp > mount -t unionfs /var/ftpdata2 /var/ftp > ... > mount -t unionfs /var/ftpdata15 /var/ftp > > mounting /var/ftpdata12 reliably caused > kernel panic on the laptop in my case > (desktop reliably crashed while mounting ftpdata10-12) > > ************ Possible cause **************** > > A little investigation revealed that this crash > happens in unionfs_statfs which lives > in /usr/src/sys/fs/unionfs/union_vfsops.c > > Debug printing showed that it calls itself > recursively n+1 times depending on the > quantity of previously mounted dirs: > > mount -t unionfs /var/ftpdata1 /var/ftp - 2 times > mount -t unionfs /var/ftpdata2 /var/ftp - 3 times > ... > mount -t unionfs /var/ftpdata10 /var/ftp - 11 times > ... > > It appears that the crash is caused by lack of system > resources (stack I guess) > > The crash itself writes something like "double fault" > or "double error" (I'm sure about that "double") > > > **************** Workaround ************************ > > Reducing recursion eliminates the problem. > > unionfs_statfs part: > > old (with the problem): > --------------------------------------------------------------- > > struct unionfs_mount *ump; > int error; > struct statfs mstat; > uint64_t lbsize; > > ump = MOUNTTOUNIONFSMOUNT(mp); > > UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", > (void *)mp, (void *)ump->um_lowervp, (void > *)ump->um_uppervp); > > bzero(&mstat, sizeof(mstat)); > > error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); > > ----------------------------------------------------------------------- > > new (without crashes): > ----------------------------------------------------------------------- > struct unionfs_mount *ump; > int error; > struct statfs mstat; > uint64_t lbsize; > > struct unionfs_mount *ump_aavzz; /*AAVZZ*/ > > /*ump = MOUNTTOUNIONFSMOUNT(mp);*/ /*AAVZZ*/ > ump_aavzz = MOUNTTOUNIONFSMOUNT(mp); /*AAVZZ*/ > > > UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", > (void *)mp, (void *)ump->um_lowervp, (void > *)ump->um_uppervp); > > bzero(&mstat, sizeof(mstat)); > > /*Dirty hack to fast forward*/ > while (! > strcmp(ump_aavzz->um_lowervp->v_mount->mnt_stat.f_fstypename, > "unionfs")) { > > ump_aavzz=MOUNTTOUNIONFSMOUNT(ump_aavzz->um_lowervp->v_mount); > } > ump=ump_aavzz; > /*end of dirty hack*/ > > error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); > > ------------------------------------------------------------------------------- > > > **************************** Considerations ************************** > > I'm sure that the above is not the way to treat the problem. But > I do not have deep understanding of the internal workings of filesystems > in general and unionfs in particular and cannot come up with anything > better. > > Probably this growing recursion should not take place at all, which > requires defferent handling of ump->um_lowervp->v_mount during list > creation (mount?). > > > > Regards, > > Alex > > _______________________________________________ > 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" -- Daichi GOTO From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 04:25:29 2011 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 6C723106566C for ; Thu, 21 Apr 2011 04:25:29 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0925A8FC0C for ; Thu, 21 Apr 2011 04:25:28 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 1FE9012543B; Thu, 21 Apr 2011 13:25:28 +0900 (JST) Date: Thu, 21 Apr 2011 13:25:29 +0900 From: Daichi GOTO To: Daichi GOTO Message-Id: <20110421132529.4c0aa749.daichi@freebsd.org> In-Reply-To: <20110421124919.5dc64403.daichi@freebsd.org> References: <1303118948.2112.40.camel@localhost> <20110421124919.5dc64403.daichi@freebsd.org> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: unionfs kernel panic while mounting (i386, R8.2) 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, 21 Apr 2011 04:25:29 -0000 On Thu, 21 Apr 2011 12:49:19 +0900 Daichi GOTO wrote: > Hi Alex > > I have tried to reproduce your panic, but couldn't > get a panic. Would you please try unionfs on 8-stable? Now I got a panic, ok ;) > ps. > I do refreshing my patch to get merged into current. > After some tests, I'll open my new patch for public test. > thanks :) > > On Mon, 18 Apr 2011 13:29:08 +0400 > Alex Zimnitsky wrote: > > Hi everyone! > > > > > > There is a problem with unionfs mount procedure > > which consistently causes system crash. I observed > > this behavior (freshly installed release 8.2) on > > two i386 boxes one of which was an ancient laptop > > with 256MB RAM and the other was a not-so-old > > desktop with more than 4GB jf RAM. > > > > ******* How to reproduce: ************** > > > > mkdir /var/ftp > > > > mkdir /var/ftpdata1 > > mkdir /var/ftpdata2 > > ... > > mkdir /var/ftpdata15 > > > > mount -t unionfs /var/ftpdata1 /var/ftp > > mount -t unionfs /var/ftpdata2 /var/ftp > > ... > > mount -t unionfs /var/ftpdata15 /var/ftp > > > > mounting /var/ftpdata12 reliably caused > > kernel panic on the laptop in my case > > (desktop reliably crashed while mounting ftpdata10-12) > > > > ************ Possible cause **************** > > > > A little investigation revealed that this crash > > happens in unionfs_statfs which lives > > in /usr/src/sys/fs/unionfs/union_vfsops.c > > > > Debug printing showed that it calls itself > > recursively n+1 times depending on the > > quantity of previously mounted dirs: > > > > mount -t unionfs /var/ftpdata1 /var/ftp - 2 times > > mount -t unionfs /var/ftpdata2 /var/ftp - 3 times > > ... > > mount -t unionfs /var/ftpdata10 /var/ftp - 11 times > > ... > > > > It appears that the crash is caused by lack of system > > resources (stack I guess) > > > > The crash itself writes something like "double fault" > > or "double error" (I'm sure about that "double") > > > > > > **************** Workaround ************************ > > > > Reducing recursion eliminates the problem. > > > > unionfs_statfs part: > > > > old (with the problem): > > --------------------------------------------------------------- > > > > struct unionfs_mount *ump; > > int error; > > struct statfs mstat; > > uint64_t lbsize; > > > > ump = MOUNTTOUNIONFSMOUNT(mp); > > > > UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", > > (void *)mp, (void *)ump->um_lowervp, (void > > *)ump->um_uppervp); > > > > bzero(&mstat, sizeof(mstat)); > > > > error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); > > > > ----------------------------------------------------------------------- > > > > new (without crashes): > > ----------------------------------------------------------------------- > > struct unionfs_mount *ump; > > int error; > > struct statfs mstat; > > uint64_t lbsize; > > > > struct unionfs_mount *ump_aavzz; /*AAVZZ*/ > > > > /*ump = MOUNTTOUNIONFSMOUNT(mp);*/ /*AAVZZ*/ > > ump_aavzz = MOUNTTOUNIONFSMOUNT(mp); /*AAVZZ*/ > > > > > > UNIONFSDEBUG("unionfs_statfs(mp = %p, lvp = %p, uvp = %p)\n", > > (void *)mp, (void *)ump->um_lowervp, (void > > *)ump->um_uppervp); > > > > bzero(&mstat, sizeof(mstat)); > > > > /*Dirty hack to fast forward*/ > > while (! > > strcmp(ump_aavzz->um_lowervp->v_mount->mnt_stat.f_fstypename, > > "unionfs")) { > > > > ump_aavzz=MOUNTTOUNIONFSMOUNT(ump_aavzz->um_lowervp->v_mount); > > } > > ump=ump_aavzz; > > /*end of dirty hack*/ > > > > error = VFS_STATFS(ump->um_lowervp->v_mount, &mstat); > > > > ------------------------------------------------------------------------------- > > > > > > **************************** Considerations ************************** > > > > I'm sure that the above is not the way to treat the problem. But > > I do not have deep understanding of the internal workings of filesystems > > in general and unionfs in particular and cannot come up with anything > > better. > > > > Probably this growing recursion should not take place at all, which > > requires defferent handling of ump->um_lowervp->v_mount during list > > creation (mount?). > > > > > > > > Regards, > > > > Alex > > > > _______________________________________________ > > 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" > > -- > Daichi GOTO > _______________________________________________ > 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" -- Daichi GOTO 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 05:49:47 2011 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 6FE12106564A for ; Thu, 21 Apr 2011 05:49:47 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 39EDC8FC14 for ; Thu, 21 Apr 2011 05:49:46 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 380FF12543B; Thu, 21 Apr 2011 14:49:46 +0900 (JST) Date: Thu, 21 Apr 2011 14:49:47 +0900 From: Daichi GOTO To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Message-Id: <20110421144947.b887081e.daichi@freebsd.org> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: RFC: unionfs multiple mounts, cross mounts and recursive mounts limits and manegement feature 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, 21 Apr 2011 05:49:47 -0000 Hi unionfs lovers, It is possible to mount unionfs multiple times more than once at a mount point. However, exceeding multiple mounts could consume kernel stack over its limits and lead a system panic easily. Some users reported that they got a system panic by multiple unionfs mounts. So I make a preproduction prototype to check multiple mounts, cross mounts, recursive mounts and the combination of those of unionfs and prevent that situation. http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-cross-mount3.diff It is adjustable with sysctl value 'vfs.unionfs.recursive_limit' as multiple mounts limits. The default value is 1 and it means two-layered ok. Max value of 'vfs.unionfs.recursive_limit' is 8, it is heuristic value. I couldn't get a system panic unless 'vfs.unionfs.recursive_limit' is over 8. Test reports, suggestions and new patches are always welcome. I'm considering to get merged into current if there are no issues and problems. -- Daichi GOTO From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 07:03:31 2011 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 D89B6106566B; Thu, 21 Apr 2011 07:03:31 +0000 (UTC) (envelope-from aavzz@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [95.108.130.94]) by mx1.freebsd.org (Postfix) with ESMTP id 7F5298FC08; Thu, 21 Apr 2011 07:03:31 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward12.mail.yandex.net (Yandex) with ESMTP id 8B093C20F48; Thu, 21 Apr 2011 11:03:29 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1303369409; bh=ukgUjXVdbWfnADgxUzgp3IpHXl5nB7KAM0usWPjEYZQ=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=P0p7dA9mf++Vab9BOySekbg7BSEx53OkC4ditEiVdAYQXft0PgkpbF2/aBLAEosas MtfV3Zo4NRtjqCZlosQvtR6I/EqrhNBEZdMcnOk+i6S6TJLLV5xbdUp3zVTKLKeZzz foaD0AKakfX92Vacl1rFgcrEiLySZC/1+WPzvWjs= Received: from [10.88.1.200] (unknown [91.210.24.47]) by smtp12.mail.yandex.net (Yandex) with ESMTPA id 330A1572803F; Thu, 21 Apr 2011 11:03:29 +0400 (MSD) From: Alex Zimnitsky To: Daichi GOTO In-Reply-To: <20110421144947.b887081e.daichi@freebsd.org> References: <20110421144947.b887081e.daichi@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 21 Apr 2011 11:03:30 +0400 Message-ID: <1303369410.2152.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Yandex-Spam: 1 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: RFC: unionfs multiple mounts, cross mounts and recursive mounts limits and manegement feature 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, 21 Apr 2011 07:03:31 -0000 On Thu, 2011-04-21 at 14:49 +0900, Daichi GOTO wrote: > It is adjustable with sysctl value 'vfs.unionfs.recursive_limit' as > multiple mounts limits. The default value is 1 and it means two-layered ok. > Max value of 'vfs.unionfs.recursive_limit' is 8, it is heuristic value. > I couldn't get a system panic unless 'vfs.unionfs.recursive_limit' is over 8. > Hmm, 8 is not enough for me, i need more :) On the other hand, why do we need recursion in unionfs_statfs at all? IMHO recursion in kernel is evil because it has a potencial of resource exhaustion. This recursion in unionfs_statfs is used to gather statistic (some of which is faked according to comments in the procedure) why not replace recursion with cycle? (I'm not skilled enough do do that :) and a feature request: it would be great if it was possible to umount one of multiple unionfs: mount -t unionfs /var/ftpdata1 /var/ftp mount -t unionfs /var/ftpdata2 /var/ftp how to unmount /var/ftpdata1 only? From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 08:13:24 2011 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 D6F03106564A; Thu, 21 Apr 2011 08:13:24 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id A4C598FC14; Thu, 21 Apr 2011 08:13:24 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id EDCBD12543B; Thu, 21 Apr 2011 17:13:23 +0900 (JST) Date: Thu, 21 Apr 2011 17:13:23 +0900 From: Daichi GOTO To: Alex Zimnitsky Message-Id: <20110421171323.d554000d.daichi@freebsd.org> In-Reply-To: <1303369410.2152.21.camel@localhost> References: <20110421144947.b887081e.daichi@freebsd.org> <1303369410.2152.21.camel@localhost> Organization: FreeBSD Project X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: RFC: unionfs multiple mounts, cross mounts and recursive mounts limits and manegement feature 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, 21 Apr 2011 08:13:24 -0000 On Thu, 21 Apr 2011 11:03:30 +0400 Alex Zimnitsky wrote: > On Thu, 2011-04-21 at 14:49 +0900, Daichi GOTO wrote: > > > It is adjustable with sysctl value 'vfs.unionfs.recursive_limit' as > > multiple mounts limits. The default value is 1 and it means two-layered ok. > > Max value of 'vfs.unionfs.recursive_limit' is 8, it is heuristic value. > > I couldn't get a system panic unless 'vfs.unionfs.recursive_limit' is over 8. > > > > Hmm, 8 is not enough for me, i need more :) > > On the other hand, why do we need recursion in unionfs_statfs > at all? IMHO recursion in kernel is evil because it has a potencial > of resource exhaustion. > > This recursion in unionfs_statfs is used to gather statistic (some of > which is faked according to comments in the procedure) > > why not replace recursion with cycle? (I'm not skilled enough do do > that :) Exactly. It is one of possible plans to reduce kernel stack consumption except rewriting all relative recursive code into loop treatment is slow work to complete. Rewritten into loop treatment is the next step for our unionfs implementation ;) If rewritten completed, eventually we need some general fs-to-fs communication framework to detect situation comprehensively and prevent kernel stack consumption by multiple mounts of the combination of unionfs and loopback filesystem (especially for nullfs at this time). At this moment, there is no way to communitate with other loopback filesystem from unionfs, so unionfs cannot detect kernel stack consumption situation and prevent a system panic. In follow situation, unionfs cannot detect situation comprehensively and it could lead a system panic by exceeding kernel stack consumption. unionsf -> nullfs -> unionfs -> nullfs -> unionfs -> nullfs ... > and a feature request: > it would be great if it was possible to umount one of multiple unionfs: > > mount -t unionfs /var/ftpdata1 /var/ftp > mount -t unionfs /var/ftpdata2 /var/ftp > > how to unmount /var/ftpdata1 only? I understand how you feel. It is possible to implement. Apparently intermediate unionfs unmount feature is curious and convenience. To implement intermediate unionfs unmount, first we should discuss and define how treats "whiteout" of intermediate unionfs. Got any ideas? -- Daichi GOTO From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 10:52:49 2011 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 965291065672 for ; Thu, 21 Apr 2011 10:52:49 +0000 (UTC) (envelope-from wolfgang@riegler.homeip.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 214BB8FC16 for ; Thu, 21 Apr 2011 10:52:48 +0000 (UTC) Received: from mail.cbt-l.de ([212.185.49.146]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LqacI-1PZy3N1LcI-00eJkR; Thu, 21 Apr 2011 12:40:12 +0200 Received: (qmail 31219 invoked by uid 1009); 21 Apr 2011 10:40:10 -0000 Received: from 192.168.40.62 by mail.cbt-l.de (envelope-from , uid 1008) with qmail-scanner-1.25-st-qms (clamdscan: 0.97/12658. spamassassin: 3.3.0. perlscan: 1.25-st-qms. Clear:RC:1(192.168.40.62):. Processed in 0.038834 secs); 21 Apr 2011 10:40:10 -0000 X-Antivirus-CBTL-Mail-From: wolfgang@riegler.homeip.net via mail.cbt-l.de X-Antivirus-CBTL: 1.25-st-qms (Clear:RC:1(192.168.40.62):. Processed in 0.038834 secs Process 31213) Received: from wolfgang.cbt-l.de (HELO wolfgang.localnet) (w.riegler@cbt-l.de@192.168.40.62) by mail.cbt-l.de with SMTP; 21 Apr 2011 10:40:10 -0000 From: Wolfgang Riegler To: FreeBSD Questions Mailing List Date: Thu, 21 Apr 2011 12:40:14 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.37-gentoo-r4sepp1; KDE/4.4.5; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201104211240.14357.wolfgang@riegler.homeip.net> X-Provags-ID: V02:K0:YXyZLD96aHnLZd05rv6AwPoqKuWqt5VCzlQcc3gSW2U ghp4QkgPzPOFWbljTS+WIB5wu8vaqny/+30K1WwjuTO2rhCCEb 0oJpmFA+iLm5sTVJpM5481+mo8ZgxR8WoAuWuv+mckAgIf/by6 TdKMtIrZ1gaNvhNUjccfMXTdfpx9zLd8xRDs44TsxMBtZkztbc zLN1aZjAwignJegHKa+NDEFyhT0bDwfq9OJp3wKVDM= Cc: freebsd-fs@freebsd.org Subject: Cannot boot from ZFS raidz1 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, 21 Apr 2011 10:52:49 -0000 Hi, I have used this setup guide (http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1) line by line with the 8.2-RELEASE DVD for amd64 to install a VirtualBox guest for testing. The only difference to the setup guide: I use a SAS controler, so devicename is da0, da1, da2 instead of ad0, etc. I tried it with a SATA controler as well, but no differences. After reboot, I get the following error from the loader: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS object directory Can't find root filesystem - giving up ZFS: unexpected object set type 0 ZFS: unexpected object set type 0 FreeBSD/x86 boot Default: zroot:/boot/kernel/kernel boot: ZFS: unexpected object set type 0 FreeBSD/x86 boot Default: zroot:/boot/kernel/kernel boot: I hope someone can give an hint, what's going wrong here. Thanks in advance Wolfgang From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 11:11:22 2011 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 924D71065672 for ; Thu, 21 Apr 2011 11:11:22 +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 4C1848FC19 for ; Thu, 21 Apr 2011 11:11:21 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAGkQsE2DaFvO/2dsb2JhbACEUaFviHCrCZB8gSmDUH0Ejis X-IronPort-AV: E=Sophos;i="4.64,251,1301889600"; d="scan'208";a="119079905" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 21 Apr 2011 07:11:21 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7BB93B3F28; Thu, 21 Apr 2011 07:11:21 -0400 (EDT) Date: Thu, 21 Apr 2011 07:11:21 -0400 (EDT) From: Rick Macklem To: Chris Forgeron Message-ID: <1143723691.393441.1303384281461.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: make the experimental NFS subsystem the default one 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, 21 Apr 2011 11:11:22 -0000 > > I've hacked up the old NFS server a bit to better serve my ESX/NFS > needs (forcing it to always write async so it works faster with ZFS > and a ZIL). I guess I could do the same to the new code as well... > > ..However, if you didn't mind adding switch to force the NFS server to > quietly only do an async VOP_WRITE, that would be really handy. Very > dangerous for some people, but then again, so are most switches if you > don't understand what they do. ESX will only opens it's files with > O_SYNC, and it's not an editable option, so people like me running > ESX+NFS over a ZFS share that has a ZIL are making the system do a lot > of unnecessary sync writes. Yes, I know about SSD/RAM for the ZIL, but > it still slows it down quite a bit over an async write. Have you tries the "async" mount option on the client side? (or did you say you couldn't do that above?) I would be very hesitant to do it on the server side, since it would violate the RFC (and you do run a risk of losing data, which many might not realize uptil it is too late). rick From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 16:05:40 2011 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 3FDB0106566B; Thu, 21 Apr 2011 16:05:40 +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 15C018FC1B; Thu, 21 Apr 2011 16:05:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p3LG5dgg087724; Thu, 21 Apr 2011 16:05:39 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p3LG5dMq087720; Thu, 21 Apr 2011 16:05:39 GMT (envelope-from linimon) Date: Thu, 21 Apr 2011 16:05:39 GMT Message-Id: <201104211605.p3LG5dMq087720@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/156545: [ufs] mv could break UFS on SMP systems 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, 21 Apr 2011 16:05:40 -0000 Old Synopsis: mv could break UFS on SMP systems New Synopsis: [ufs] mv could break UFS on SMP systems Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Apr 21 16:05:05 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=156545 From owner-freebsd-fs@FreeBSD.ORG Thu Apr 21 23:55:53 2011 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 95498106566B for ; Thu, 21 Apr 2011 23:55:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 1C0E08FC0A for ; Thu, 21 Apr 2011 23:55:52 +0000 (UTC) Received: from c122-106-155-58.carlnfd1.nsw.optusnet.com.au (c122-106-155-58.carlnfd1.nsw.optusnet.com.au [122.106.155.58]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p3LNtbBE007759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Apr 2011 09:55:39 +1000 Date: Fri, 22 Apr 2011 09:55:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem In-Reply-To: <1143723691.393441.1303384281461.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: <20110422075847.Y997@besplex.bde.org> References: <1143723691.393441.1303384281461.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: make the experimental NFS subsystem the default one 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, 21 Apr 2011 23:55:53 -0000 On Thu, 21 Apr 2011, Rick Macklem wrote: >> I've hacked up the old NFS server a bit to better serve my ESX/NFS >> needs (forcing it to always write async so it works faster with ZFS >> and a ZIL). I guess I could do the same to the new code as well... >> >> ..However, if you didn't mind adding switch to force the NFS server to >> quietly only do an async VOP_WRITE, that would be really handy. Very >> dangerous for some people, but then again, so are most switches if you >> don't understand what they do. ESX will only opens it's files with >> O_SYNC, and it's not an editable option, so people like me running >> ESX+NFS over a ZFS share that has a ZIL are making the system do a lot >> of unnecessary sync writes. Yes, I know about SSD/RAM for the ZIL, but >> it still slows it down quite a bit over an async write. > > Have you tries the "async" mount option on the client side? > (or did you say you couldn't do that above?) The async mount option should work quite wll for this, except in my version. It almost completely breaks O_SYNC (and fsync()). Thus applications and nfs have no way to force a sync. This is mostly fixed in my version -- O_SYNC and fsync() sync everything related to the file except possibly its directory entry (and its parent's directory entry...). Thus applications and nfs can force a not-quite-complete sync but doing so gratuitously is unnecessarily slow. > I would be very hesitant to do it on the server side, since it would > violate the RFC (and you do run a risk of losing data, which many might > not realize uptil it is too late). As you know, nfs has always had problems with syncing things, especially if the local file system is mounted async. In [Free]BSD there is just no way for the server to sync metadata independently of syncing data, although at least the v3 prootcol supports this. Syncing everything using IO_SYNC should work, but is too slow in general, and even IO_SYNC is defeated by the above brokenness. In the old nfs server, the code for this is: >From nfs.h: % /* % * The IO_METASYNC flag should be implemented for local filesystems. % * (Until then, it is nothin at all.) % */ % #ifndef IO_METASYNC % #define IO_METASYNC 0 % #endif >From nfs_serv.c: % % /* % * XXX % * The IO_METASYNC flag indicates that all metadata (and not just % * enough to ensure data integrity) mus be written to stable storage % * synchronously. % * (IO_METASYNC is not yet implemented in 4.4BSD-Lite.) % */ % if (stable == NFSV3WRITE_UNSTABLE) % ioflags = IO_NODELOCKED; % else if (stable == NFSV3WRITE_DATASYNC) % ioflags = (IO_SYNC | IO_NODELOCKED); % else % ioflags = (IO_METASYNC | IO_SYNC | IO_NODELOCKED); The experimental nfs server seems to have even less support for this: >From nfs_nfsdport.c % if (stable == NFSWRITE_UNSTABLE) % ioflags = IO_NODELOCKED; % else % ioflags = (IO_SYNC | IO_NODELOCKED); Since IO_METASYNC is 0, the new code is equivalent to the old code, but the old code would work better if IO_METASYNC actually worked. OTOH, IO_SYNC implies syncing metadata in FreeBSD, so IO_METASYNC is needed for something quite different -- to sync metadata when data is _not_ being synced. This should be done by a state between completely unstable and unstable-data. nfs is basically assuming that metadata is sync by default. This is the case with old ffs, but not always: - ffs with soft updates. Sync of metadata is delayed, and might not happen due to a crash. Only integrity of the file system is guaranteed. This rarely matters. It might matter if an application or nfs client thinks it has completed written a critical chown(). - ffs with async mounts. Now nothing is synced by default, and unless you have fixed it, almost nothing is synced by IO_SYNC. It would be useful for IO_METASYNC to sync all the metadata. This would give the same stability as the default for old ffs (sync metadata, async data). - msdosfs with with defaults. Now the most critical metadata (the FAT) is async, while less critical metadata (directory entries and pseudo- inodes) are sync. Sync FAT would be too slow, so it takes a sync mount to get it. Again IO_METASYNC (applied to the file and enough of its surrounding metadata) would be useful for giving almost the same stability as old ffs. The nfs protocol seems to be inadequate for handling various combinations of asyncness on the client and the server. E.g., suppose that the server file system is mounted async. You probably want most operations to be async. But clients know nothing of asyncness on servers, and the spec requires some operations to be sync, so clients will issue sync operations which break the default of asyncness unless the server dishonors IO_SYNC. But you want some operations like fsync() on the client to be sync, so you don't want the server to dishonor all IO_SYNCs. One way to control this would be to make async mounts on the client work (async mounts on clients are now handled bogusly by accepting them in mount options although they have no effect): async client, async server: client only asks for sync operations when the application asks for them; server uses default which keeps other operations async; server should honor IO_SYNC otherwise default client, async server: same as now -- client gets server's defaults even when they involve dishonoring IO_SYNC async client, default or sync server: client should have precedence, giving async for everything. Need another protocol stability value and more server support for it, so that the server doesn't use its configuration of sync for at least metadata, but uses the client's configuration of async everything. The NFSWRITE_UNSTABLE value permits but doesn't request the server to be unstable, but with an async client we want to request the server to be unstable :-) (really just to optimize for speed instead of stability) default client, default server: some combination of the client and server's defaults. Must include honoring the protocol and IO_SYNC and fsync() on the client sync client, async server: client should have precedence, giving sync for everything. Same as now, but quite broken if the server dishonors IO_SYNC sync client or server, default other side: as for async, explicitly asking for sync has precedence over defaults When I started writing the above (consolidating old ideas), I thought that the client would need to negotiate the [a]syncness with the server, but I now see that several useful cases can be handled by the client just expressing its preferences for async by not asking for FILESYNC or DATASYNC. Grepping for NFS.*WRITE_UNSTABLE in the new nfs client and server shows that it is now spelled without V3, except 3 comments have the old spelling. Bruce