From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 01:18:10 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 ADB84106566B for ; Sun, 6 Nov 2011 01:18:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 019E28FC0C for ; Sun, 6 Nov 2011 01:18:06 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAM7ftU6DaFvO/2dsb2JhbABBhHqVZY0bgxuCHFY1Ag0ZAqwLkFGBMIZlgRYElCGSCA X-IronPort-AV: E=Sophos;i="4.69,463,1315195200"; d="scan'208";a="142822221" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 05 Nov 2011 21:18:05 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C4888B3FD9; Sat, 5 Nov 2011 21:18:05 -0400 (EDT) Date: Sat, 5 Nov 2011 21:18:05 -0400 (EDT) From: Rick Macklem To: freebsd-fs@freebsd.org Message-ID: <1558351773.1229453.1320542285788.JavaMail.root@erie.cs.uoguelph.ca> 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 - FF3.0 (Win)/6.0.10_GA_2692) Cc: Josh Paetzel , zkirsch@freebsd.org Subject: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 06 Nov 2011 01:18:10 -0000 Hi, Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist for the new NFS server. I don't think I had spotted this before, but when I looked I saw that, when vfs.nfsrv.async is set non-zero in the old server, it returns FILESYNC (which means the write has been committed to non-volatile storage) even when it hasn't actually done that. This can improve performance, but has some negative implications: - If the server crashes before the write is committed to non-volatile storage, the file modification will be lost. (When a server replies UNSTABLE to a write, the client holds onto the data in its cache and does the write again if the server crashes/reboots before the client does a Commit RPC for the file. However, a reply of FILESYNC tells the client it can forget about the write, because it is done.) - Because of the above, replying FILESYNC when the data is not yet committed to non-volatile (also referred to as stable) storage, this is a violation of RFC1813. I wouldn't want this to be the default, but am willing to patch head based on the "backwards compatibility" argument. My concern with these types of patches is that some people will enable them without realizing the risk of data loss that they introduce. So, how do others feel with respect to whether or not this patch should be committed to head? Thanks in advance for any comments, rick ps: Here's the patch, just in case anyone is interested. --- fs/nfsserver/nfs_nfsdserv.c.sav 2011-11-05 10:29:38.000000000 -0400 +++ fs/nfsserver/nfs_nfsdserv.c 2011-11-05 10:37:40.000000000 -0400 @@ -55,6 +55,11 @@ extern int nfs_rootfhset; extern int nfsrv_enable_crossmntpt; #endif /* !APPLEKEXT */ +static int nfs_async = 0; +SYSCTL_DECL(_vfs_nfsd); +SYSCTL_INT(_vfs_nfsd, OID_AUTO, async, CTLFLAG_RW, &nfs_async, 0, + "Tell client that writes were synced even though they were not"); + /* * This list defines the GSS mechanisms supported. * (Don't ask me how you get these strings from the RFC stuff like @@ -912,7 +917,13 @@ nfsrvd_write(struct nfsrv_descript *nd, goto out; NFSM_BUILD(tl, u_int32_t *, 4 * NFSX_UNSIGNED); *tl++ = txdr_unsigned(retlen); - if (stable == NFSWRITE_UNSTABLE) + /* + * If nfs_async is set, then pretend the write was FILESYNC. + * Warning: Doing this violates RFC1813 and runs a risk + * of data written by a client being lost when the server + * crashes/reboots. + */ + if (stable == NFSWRITE_UNSTABLE && nfs_async == 0) *tl++ = txdr_unsigned(stable); else *tl++ = txdr_unsigned(NFSWRITE_FILESYNC); From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 02:02:28 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 2F9FD106564A; Sun, 6 Nov 2011 02:02:28 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id BB0338FC12; Sun, 6 Nov 2011 02:02:27 +0000 (UTC) Received: by ywt32 with SMTP id 32so5204770ywt.13 for ; Sat, 05 Nov 2011 19:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=z3ZDFIcTgxeNkcZCEJntG/adnuQpBC/830yASi5gS+Q=; b=MJRSSEm6lC4MKhgAR0SrBhLtg4c5hK15Wh6CKahg4Pu37fGbZTToyEGLEhnQ1/TKMW Tqg0LULxUiyYo6+b2KzX6Nt5+ujiuPtcslxCs5XdEBbuw0VPNtTffoCfl7hzZt3Vd0Vh Q9mv5oHeirILiUM0uaXqg/PJ/K5wKxfpQN/lA= Received: by 10.50.17.197 with SMTP id q5mr27679534igd.2.1320544946892; Sat, 05 Nov 2011 19:02:26 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id y6sm23295851pbi.5.2011.11.05.19.02.25 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 19:02:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <4E9D8FBF.3030502@FreeBSD.org> Date: Sat, 5 Nov 2011 19:02:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23A28BD1-8F02-42D3-8BE3-0F90C3702955@gmail.com> References: <4E8D7406.4090302@restart.be> <4E8D86A2.1040508@FreeBSD.org> <4E8D9F57.70506@restart.be> <4E8DAEE5.4020004@FreeBSD.org> <4E9D566F.1040104@restart.be> <4E9D8FBF.3030502@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: zfsloader 9.0 BETA3 r225759 - i/o error - all block copies unavailable 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, 06 Nov 2011 02:02:28 -0000 On Oct 18, 2011, at 7:39 AM, Andriy Gapon wrote: > on 18/10/2011 13:35 Henri Hennebert said the following: >> I upgrade another system to 9.0-RC1 and encounter the same problem, = this time >> zfsloader do not run. >>=20 >> After >>=20 >> mv /mnt/boot /mnt/Boot >> mkdir /mnt/boot >> cd /mnt/Boot >> find . | cpio -pvdmu /mnt/boot >>=20 >> FreeBSD boot OK >>=20 >>=20 >> [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 = /dev/ada1p2 >> ZFS: SPA version 28 >> pool: rpool >> config: >>=20 >> NAME STATE >> rpool ONLINE >> mirror ONLINE >> ada0p2 ONLINE >> ada1p2 ONLINE >> ZFS: i/o error - all block copies unavailable >> can't lookup >>=20 >> 10 minutes later: >>=20 >> [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 >> /dev/ada1p2|less >> ZFS: SPA version 28 >> pool: rpool >> config: >>=20 >> NAME STATE >> rpool ONLINE >> mirror ONLINE >> ada0p2 ONLINE >> ada1p2 ONLINE >> >>=20 >> it seems ok :-o >>=20 >> and a other time: >> [root@avoriaz zfsboottest]# ./zfsboottest /Boot/zfsloader /dev/ada0p2 >> segmentation fault... >>=20 >> Strange isn't it. >=20 > I think that it would be smart to not do any filesystem modifications = after the > problem is detected / reproduced. > Also, currently zfsboottest doesn't do much of a problem = self-diagnostics, so > using gdb or/and adding some printfs in the code are required to = understand a > nature of a problem. Like what kind of block gives an I/O error, if = it actual > reading that fails or checksum verification or etc, and so on. Running into the same issue with a post-RC1 kernel. 1. ZFS on root. 2. stable/9. 3. Here's my zpool status output: $ zpool status pool: sac state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM sac ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 errors: No known data errors pool: store state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM store ONLINE 0 0 0 mfid0p1 ONLINE 0 0 0 errors: No known data errors $ sudo ./zfsboottest /boot/zfsloader /dev/ada0p3=20 # Spits out the zpool status and a lot of other boot gobbledygook. If I use the new gptzfsboot, then my system becomes unbootable = with the old kernel (it can't find the zpool). gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ada0 It spits out "I/O error - all block copies unavailable" at boot; = if I manually did boot , then everything worked. So I figured it = was an environmental issue. I changed /boot/kernel from a symlink to a = kernel directory to a standard directory and things worked as expected. Your issue might be similar, but it would be nice if booting = from symlinks was either fixed or enhanced to work properly with = gptzfsboot. Thanks, -Garrett From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 03:03: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 0EFE2106566C for ; Sun, 6 Nov 2011 03:03:48 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7F48FC17 for ; Sun, 6 Nov 2011 03:03:47 +0000 (UTC) Received: by qyk9 with SMTP id 9so3299668qyk.13 for ; Sat, 05 Nov 2011 20:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=elJ/UP0pleKJ6RiTnkvB8uKyqxCBciQAS2y6FVptKYc=; b=b9fVOfSHxcLCG25h5215Xrh55NuyHJc7gMlFHKxxauY3appl+M9w4XmhplVD0fYy4O dxmx/VbEkzPFczEFpmTWJTyE6dnjk47YheKZbKTIVaGlK3LtDyV9R8x3MN9uQxS4wyZJ jptHmC9rkmlBU/nUmHwJtXxthd1cgBObLJRU0= MIME-Version: 1.0 Received: by 10.229.61.96 with SMTP id s32mr834216qch.46.1320548625193; Sat, 05 Nov 2011 20:03:45 -0700 (PDT) Received: by 10.229.1.233 with HTTP; Sat, 5 Nov 2011 20:03:44 -0700 (PDT) In-Reply-To: <1558351773.1229453.1320542285788.JavaMail.root@erie.cs.uoguelph.ca> References: <1558351773.1229453.1320542285788.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 5 Nov 2011 20:03:44 -0700 Message-ID: From: Xin LI To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Josh Paetzel , zkirsch@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 06 Nov 2011 03:03:48 -0000 Hi, Rick, On Sat, Nov 5, 2011 at 6:18 PM, Rick Macklem wrote: > Hi, > > Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > for the new NFS server. > > I don't think I had spotted this before, but when I looked I > saw that, when vfs.nfsrv.async is set non-zero in the old server, > it returns FILESYNC (which means the write has been committed to > non-volatile storage) even when it hasn't actually done that. > > This can improve performance, but has some negative implications: > - If the server crashes before the write is committed to > =C2=A0non-volatile storage, the file modification will be lost. > =C2=A0(When a server replies UNSTABLE to a write, the client holds > =C2=A0 onto the data in its cache and does the write again if the > =C2=A0 server crashes/reboots before the client does a Commit RPC > =C2=A0 for the file. However, a reply of FILESYNC tells the client > =C2=A0 it can forget about the write, because it is done.) > - Because of the above, replying FILESYNC when the data is not > =C2=A0yet committed to non-volatile (also referred to as stable) > =C2=A0storage, this is a violation of RFC1813. > > I wouldn't want this to be the default, but am willing to > patch head based on the "backwards compatibility" argument. > My concern with these types of patches is that some people > will enable them without realizing the risk of data loss > that they introduce. > > So, how do others feel with respect to whether or not this > patch should be committed to head? I think the default of old NFS server was async=3D0? In general I'd prefer seeing this as an option but disabled by default, so administrators can override the option. Having async=3D1 by default doesn't seem to be a good idea in my opinion. Another thought is the async flag should be a per-mountpoint flag rather than a global flag, but that might be over-complicating things so just my $0.02. Cheers, --=20 Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 13:31: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 056BE106564A; Sun, 6 Nov 2011 13:31:04 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out3.tiscali.nl (smtp-out3.tiscali.nl [195.241.79.178]) by mx1.freebsd.org (Postfix) with ESMTP id B92A98FC08; Sun, 6 Nov 2011 13:31:03 +0000 (UTC) Received: from [212.182.167.131] (helo=sjakie.klop.ws) by smtp-out3.tiscali.nl with esmtp (Exim) (envelope-from ) id 1RN2Vn-0001eP-CR; Sun, 06 Nov 2011 14:11:47 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 9ABD84097; Sun, 6 Nov 2011 14:11:33 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org, "Rick Macklem" References: <1558351773.1229453.1320542285788.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 06 Nov 2011 14:11:33 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: <1558351773.1229453.1320542285788.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Opera Mail/11.52 (FreeBSD) Content-Transfer-Encoding: quoted-printable Cc: Josh Paetzel , zkirsch@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 06 Nov 2011 13:31:04 -0000 On Sun, 06 Nov 2011 02:18:05 +0100, Rick Macklem =20 wrote: > Hi, > > Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > for the new NFS server. > > I don't think I had spotted this before, but when I looked I > saw that, when vfs.nfsrv.async is set non-zero in the old server, > it returns FILESYNC (which means the write has been committed to > non-volatile storage) even when it hasn't actually done that. > > This can improve performance, but has some negative implications: > - If the server crashes before the write is committed to > non-volatile storage, the file modification will be lost. > (When a server replies UNSTABLE to a write, the client holds > onto the data in its cache and does the write again if the > server crashes/reboots before the client does a Commit RPC > for the file. However, a reply of FILESYNC tells the client > it can forget about the write, because it is done.) > - Because of the above, replying FILESYNC when the data is not > yet committed to non-volatile (also referred to as stable) > storage, this is a violation of RFC1813. Just out of curiosity. Why would lying about FILESYNC improve performance= =20 over UNSTABLE? The server does the same work. Only the client holds data = =20 longer in memory. I only see impact if the client has just a little bit o= f =20 memory. Ronald. From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 15:34:10 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 4883C1065670; Sun, 6 Nov 2011 15:34:10 +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 CA72B8FC1D; Sun, 6 Nov 2011 15:34:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAIiotk6DaFvO/2dsb2JhbABChHqmIYFyAQEFI1YbGAICDRkCWQYTqweQeIEwhmWBFgSIC4wWkgo X-IronPort-AV: E=Sophos;i="4.69,464,1315195200"; d="scan'208";a="144386883" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 06 Nov 2011 10:34:08 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E5928B3F07; Sun, 6 Nov 2011 10:34:08 -0500 (EST) Date: Sun, 6 Nov 2011 10:34:08 -0500 (EST) From: Rick Macklem To: Ronald Klop Message-ID: <1391798614.1239830.1320593648931.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 - FF3.0 (Win)/6.0.10_GA_2692) Cc: Josh Paetzel , freebsd-fs@freebsd.org, zkirsch@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 06 Nov 2011 15:34:10 -0000 Ronald Klop wrote: > On Sun, 06 Nov 2011 02:18:05 +0100, Rick Macklem > > wrote: > > > Hi, > > > > Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > > for the new NFS server. > > > > I don't think I had spotted this before, but when I looked I > > saw that, when vfs.nfsrv.async is set non-zero in the old server, > > it returns FILESYNC (which means the write has been committed to > > non-volatile storage) even when it hasn't actually done that. > > > > This can improve performance, but has some negative implications: > > - If the server crashes before the write is committed to > > non-volatile storage, the file modification will be lost. > > (When a server replies UNSTABLE to a write, the client holds > > onto the data in its cache and does the write again if the > > server crashes/reboots before the client does a Commit RPC > > for the file. However, a reply of FILESYNC tells the client > > it can forget about the write, because it is done.) > > - Because of the above, replying FILESYNC when the data is not > > yet committed to non-volatile (also referred to as stable) > > storage, this is a violation of RFC1813. > > Just out of curiosity. Why would lying about FILESYNC improve > performance > over UNSTABLE? The server does the same work. Only the client holds > data > longer in memory. I only see impact if the client has just a little > bit of > memory. > > Ronald. Well, I'm not sure I have an answer. Josh noted that it makes a big difference for them. Maybe he can elaborate? One additional effect is that the client in head must do a synchronous write (with FILESYNC and waiting for the RPC reply) before it can modify a non-continuous region of the same buffer with respect to the old dirty byte region. (This happens frequently during builds, done mostly by the loader, I think?) If the server replies FILESYNC, then the old dirty byte region is done (ie. no longer a dirty byte region) so the client doesn't have to do the synchronous write described above. I hope that the experimental patch I made available a few days ago, along with work jhb@ is doing will eventually fix this for the FreeBSD client, but it won't be in head anytime soon (and who knows what other clients do?). rick From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 16:02:21 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 3EEB91065675; Sun, 6 Nov 2011 16:02:21 +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 B29E38FC13; Sun, 6 Nov 2011 16:02:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEmvtk6DaFvO/2dsb2JhbABChHqmIYFyAQEEASNWBRYYAgINGQJZBhOIAqJ7kHIEgTCGZYEWBIgLjBaSCg X-IronPort-AV: E=Sophos;i="4.69,464,1315195200"; d="scan'208";a="142856602" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 06 Nov 2011 11:01:55 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C51BCB3F1E; Sun, 6 Nov 2011 11:01:55 -0500 (EST) Date: Sun, 6 Nov 2011 11:01:55 -0500 (EST) From: Rick Macklem To: Xin LI Message-ID: <858445532.1240736.1320595315792.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, Josh Paetzel , zkirsch@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 06 Nov 2011 16:02:21 -0000 Xin Li wrote: > Hi, Rick, >=20 > On Sat, Nov 5, 2011 at 6:18 PM, Rick Macklem > wrote: > > Hi, > > > > Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > > for the new NFS server. > > > > I don't think I had spotted this before, but when I looked I > > saw that, when vfs.nfsrv.async is set non-zero in the old server, > > it returns FILESYNC (which means the write has been committed to > > non-volatile storage) even when it hasn't actually done that. > > > > This can improve performance, but has some negative implications: > > - If the server crashes before the write is committed to > > =C2=A0non-volatile storage, the file modification will be lost. > > =C2=A0(When a server replies UNSTABLE to a write, the client holds > > =C2=A0 onto the data in its cache and does the write again if the > > =C2=A0 server crashes/reboots before the client does a Commit RPC > > =C2=A0 for the file. However, a reply of FILESYNC tells the client > > =C2=A0 it can forget about the write, because it is done.) > > - Because of the above, replying FILESYNC when the data is not > > =C2=A0yet committed to non-volatile (also referred to as stable) > > =C2=A0storage, this is a violation of RFC1813. > > > > I wouldn't want this to be the default, but am willing to > > patch head based on the "backwards compatibility" argument. > > My concern with these types of patches is that some people > > will enable them without realizing the risk of data loss > > that they introduce. > > > > So, how do others feel with respect to whether or not this > > patch should be committed to head? >=20 > I think the default of old NFS server was async=3D0? In general I'd > prefer seeing this as an option but disabled by default, so > administrators can override the option. Having async=3D1 by default > doesn't seem to be a good idea in my opinion. >=20 Yes, I agree. If I commit it, it will definitely not be enabled by default. The question I was asking was "Should it be committed at all?". > Another thought is the async flag should be a per-mountpoint flag > rather than a global flag, but that might be over-complicating things > so just my $0.02. >=20 Well, since it doesn't affect server file system behaviour and only the reply the NFS server sends to the client, I don't see it as a per-mountpoin= t flag on server file systems, but I'm really looking for what others think? > Cheers, > -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 16:41: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 C6C29106566C for ; Sun, 6 Nov 2011 16:41:22 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE158FC0A for ; Sun, 6 Nov 2011 16:41:22 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id F41F721294; Sun, 6 Nov 2011 11:25:16 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 06 Nov 2011 11:25:17 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=zhO4xGW00KmwljTsF7moQB k4K10=; b=JRuE8aN5aYOmcscGQf+nr7/B1WdDUzfsfnrdo9qeRJTmU3gR0ND6rX 8EyuPhozU9IRSBbcDdlEDNIhm5RyOwwuFozhOgNb/1oppuwxFGSxSV3t3/J9u71J yUtXmMfUxDy7Odr7o5NmGv32HhTDklv0dWbHHl9tOmBkjrbzAWyB8= X-Sasl-enc: Z2nFPsszflqr+i2nNYkDV6r3FTeD3y4O0lmS1+C6XyJ1 1320596716 Received: from roadrash.tcbug.org (unknown [216.139.7.151]) by mail.messagingengine.com (Postfix) with ESMTPSA id 2C86F8E105F; Sun, 6 Nov 2011 11:25:16 -0500 (EST) Message-ID: <4EB6B4E9.1000804@tcbug.org> Date: Sun, 06 Nov 2011 08:25:13 -0800 From: Josh Paetzel User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Rick Macklem References: <1391798614.1239830.1320593648931.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1391798614.1239830.1320593648931.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Josh Paetzel , freebsd-fs@freebsd.org, zkirsch@freebsd.org, Ronald Klop Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 06 Nov 2011 16:41:22 -0000 On 11/06/11 07:34, Rick Macklem wrote: > Ronald Klop wrote: >> On Sun, 06 Nov 2011 02:18:05 +0100, Rick Macklem >> >> wrote: >> >>> Hi, >>> >>> Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist >>> for the new NFS server. >>> >>> I don't think I had spotted this before, but when I looked I >>> saw that, when vfs.nfsrv.async is set non-zero in the old server, >>> it returns FILESYNC (which means the write has been committed to >>> non-volatile storage) even when it hasn't actually done that. >>> >>> This can improve performance, but has some negative implications: >>> - If the server crashes before the write is committed to >>> non-volatile storage, the file modification will be lost. >>> (When a server replies UNSTABLE to a write, the client holds >>> onto the data in its cache and does the write again if the >>> server crashes/reboots before the client does a Commit RPC >>> for the file. However, a reply of FILESYNC tells the client >>> it can forget about the write, because it is done.) >>> - Because of the above, replying FILESYNC when the data is not >>> yet committed to non-volatile (also referred to as stable) >>> storage, this is a violation of RFC1813. >> >> Just out of curiosity. Why would lying about FILESYNC improve >> performance >> over UNSTABLE? The server does the same work. Only the client holds >> data >> longer in memory. I only see impact if the client has just a little >> bit of >> memory. >> >> Ronald. > Well, I'm not sure I have an answer. Josh noted that it makes a big > difference for them. Maybe he can elaborate? > I'll test it out and report back in the next week or so. In 8.x, setting the async sysctl was the difference between 80-100MB/sec and 800 MB/sec (Yes, MegaBytes!) using a variety of different clients, including the VMWare ESXi 4.x client, Xen 5.6 client, various linux clients and the FreeBSD client. I'll note that 800MB/sec is getting close to the underlying filesystem performance, so it's likely that the gate to performance is in the filesystem in that case. 80-100MB/sec is basically gigE performance. I can make hardware available if anyone is curious at poking at this, we have the ability to set up tests with quad gigE LACP, 10 gigE, and numerous clients. > One additional effect is that the client in head must do a synchronous > write (with FILESYNC and waiting for the RPC reply) before it can > modify a non-continuous region of the same buffer with respect to > the old dirty byte region. (This happens > frequently during builds, done mostly by the loader, I think?) > If the server replies FILESYNC, then the old dirty byte region is done > (ie. no longer a dirty byte region) so the client doesn't > have to do the synchronous write described above. > I hope that the experimental patch I made available a few days ago, > along with work jhb@ is doing will eventually fix this for the FreeBSD > client, but it won't be in head anytime soon (and who knows what > other clients do?). > > rick > -- Thanks, Josh Paetzel From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 19:41:28 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 8ACFA106566B for ; Sun, 6 Nov 2011 19:41:28 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50B438FC12 for ; Sun, 6 Nov 2011 19:41:27 +0000 (UTC) Received: by gyd5 with SMTP id 5so4731751gyd.13 for ; Sun, 06 Nov 2011 11:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=as04IsXK+gTU8b238butOWQ6VLMhmtZk7qk0UK5S4oQ=; b=CYl+A2aBHKy+6cEJ6Mgp+qRH7UY0vhU484YXu4EoUPoKjQuyB7K5GQvYRqe/90QDfO fiyZCc5kou7efD/9yng5ISSlD47uTpPXpCdfWIUh4uX+cBg3RO1z/gRLbm/MYDbJZfND dbGY8dwhABjNVHc1emZ7LLnvUbrRALq8GvhMM= MIME-Version: 1.0 Received: by 10.100.15.30 with SMTP id 30mr208965ano.60.1320607060342; Sun, 06 Nov 2011 11:17:40 -0800 (PST) Received: by 10.100.143.13 with HTTP; Sun, 6 Nov 2011 11:17:40 -0800 (PST) Date: Sun, 6 Nov 2011 14:17:40 -0500 Message-ID: From: Robert Simmons To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: rpc.umntall error on boot 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, 06 Nov 2011 19:41:28 -0000 I'm getting the following error on a new install with NFS: kernel: rpc.umntall: kernel: fileserver: MOUNTPROG: RPC: Program not registered kernel: kernel: rpc.umntall: kernel: localhost: MOUNTPROG: RPC: Program not registered kernel: kernel: rpc.umntall: kernel: fileserver: MOUNTPROG: RPC: Program not registered My /etc/rc.conf contains the following: nfs_server_enable="YES" nfs_client_enable="YES" rpcbind_enable="YES" and /etc/exports is the following (for testing): /storage -maproot=root 127.0.0.1 Even if I run the NFSv4 experimental server that does not use rpcbind (so I set it ="NO"), the error is still there. This problem does not seem to affect mounting or NFS functions. What could be causing this error? Rob From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 20:51:24 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 AFBC4106564A; Sun, 6 Nov 2011 20:51:24 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 88B3C8FC08; Sun, 6 Nov 2011 20:51:24 +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 pA6KpOMo052965; Sun, 6 Nov 2011 20:51:24 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA6KpOWB052961; Sun, 6 Nov 2011 20:51:24 GMT (envelope-from ae) Date: Sun, 6 Nov 2011 20:51:24 GMT Message-Id: <201111062051.pA6KpOWB052961@freefall.freebsd.org> To: yar@FreeBSD.org, ae@FreeBSD.org, freebsd-fs@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: bin/145309: bsdlabel: Editing disk label invalidates the whole device 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, 06 Nov 2011 20:51:24 -0000 Synopsis: bsdlabel: Editing disk label invalidates the whole device State-Changed-From-To: open->feedback State-Changed-By: ae State-Changed-When: Sun Nov 6 20:50:17 UTC 2011 State-Changed-Why: Do you still able to reproduce this problem on recent releases? http://www.freebsd.org/cgi/query-pr.cgi?pr=145309 From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 21:14:13 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 405A2106566B; Sun, 6 Nov 2011 21:14:13 +0000 (UTC) Date: Sun, 6 Nov 2011 21:14:13 +0000 From: Alexander Best To: Chris Rees Message-ID: <20111106211413.GA80882@freebsd.org> References: <5C156A63-D86D-4C1B-AFC4-DC5EA09494F6@xerq.net> <4EB3C63F.2060805@quip.cz> <20111104141626.GA28925@freebsd.org> <20111104160421.GA43288@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: "freebsd-fs@freebsd.org" , Ivan Voras Subject: Re: Default inode number too low in FFS nowadays? 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, 06 Nov 2011 21:14:13 -0000 On Fri Nov 4 11, Chris Rees wrote: > On 4 Nov 2011 16:05, "Alexander Best" wrote: > > > > On Fri Nov 4 11, Chris Rees wrote: > > > On 4 November 2011 14:16, Alexander Best wrote: > > > > On Fri Nov 4 11, Miroslav Lachman wrote: > > > >> Matt Connor wrote: > > > >> > > > > >> >On Nov 3, 2011, at 5:43 AM, Ivan Voras wrote: > > > >> > > > > >> >>On 02/11/2011 12:57, Borja Marcos wrote: > > > >> > > > >> [...] > > > >> > > > >> >>Did you forget to do "make clean" after "make install" on several > large > > > >> >>ports? > > > >> >> > > > >> >>But yes, the ports tree is getting a bit unwieldy. On the other > hand, > > > >> >>did you fsck the file system lately? > > > >> >> > > > >> > > > > >> >cd /usr/ports/ports-mgmt/portupgrade&& make install clean > > > >> > > > > >> >portsclean -CD > > > >> > > > > >> >That's a quick way to clean out all the clutter. > > > >> > > > >> Installing ruby and portupgrade is really big overhead to simple > task, > > > >> which can be done by: > > > >> > > > >> cd /usr/ports && make clean > > > >> > > > >> or with find: > > > >> > > > >> find /usr/ports/ -depth 3 -name "work" -exec rm -r {} + > > > > > > > > ...or with 'rm -rf /usr/ports/*/*/work' > > > > > > > > > > I almost had the strength of mind to stay out of this.... > > > > > > BUT you could well run into argument list too long issues there > > > (considering the insane number of inodes used), so you're probably > > > better off getting around that using the builtin echo: > > > > > > # echo /usr/ports/*/*/work | xargs rm -r > > > > right i forgot about long argument lists. will -prune speed up the above > > find(1) command invocation? > > > > cheers. > > alex > > > > -depth 3 deals with that. ah thanks. the find(1) man page only states that -prune has not effect, when -d was also specified. maybe it should also mention that the same behavior takes place, when the -depth primary was used. cheers. alex > > Chris From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 22:04:43 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 7A0BE1065673; Sun, 6 Nov 2011 22:04:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 964B0179520; Sun, 6 Nov 2011 22:04:13 +0000 (UTC) Message-ID: <4EB7126C.3030809@FreeBSD.org> Date: Sun, 06 Nov 2011 15:04:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Alexander Best References: <5C156A63-D86D-4C1B-AFC4-DC5EA09494F6@xerq.net> <4EB3C63F.2060805@quip.cz> <20111104141626.GA28925@freebsd.org> In-Reply-To: <20111104141626.GA28925@freebsd.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" , Ivan Voras Subject: Re: Default inode number too low in FFS nowadays? 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, 06 Nov 2011 22:04:43 -0000 On 11/04/2011 07:16, Alexander Best wrote: > On Fri Nov 4 11, Miroslav Lachman wrote: >> Matt Connor wrote: >>> >>> On Nov 3, 2011, at 5:43 AM, Ivan Voras wrote: >>> >>>> On 02/11/2011 12:57, Borja Marcos wrote: >> >> [...] >> >>>> Did you forget to do "make clean" after "make install" on several large >>>> ports? >>>> >>>> But yes, the ports tree is getting a bit unwieldy. On the other hand, >>>> did you fsck the file system lately? >>>> >>> >>> cd /usr/ports/ports-mgmt/portupgrade&& make install clean >>> >>> portsclean -CD >>> >>> That's a quick way to clean out all the clutter. >> >> Installing ruby and portupgrade is really big overhead to simple task, >> which can be done by: >> >> cd /usr/ports && make clean >> >> or with find: >> >> find /usr/ports/ -depth 3 -name "work" -exec rm -r {} + > > ...or with 'rm -rf /usr/ports/*/*/work' This comes up periodically, and for some reason no one pays attention to all the work that's been done in the past to verify that the fastest method is: find /usr/ports -maxdepth 3 -type d -name -work -exec rm -rf {} \; Of course, the best solution by far is to set WRKDIRPREFIX to a path with adequate space, preferably something other than /usr/obj. hth, Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 22:27:52 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 30520106566C; Sun, 6 Nov 2011 22:27:52 +0000 (UTC) Date: Sun, 6 Nov 2011 22:27:52 +0000 From: Alexander Best To: Doug Barton Message-ID: <20111106222752.GA88092@freebsd.org> References: <5C156A63-D86D-4C1B-AFC4-DC5EA09494F6@xerq.net> <4EB3C63F.2060805@quip.cz> <20111104141626.GA28925@freebsd.org> <4EB7126C.3030809@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB7126C.3030809@FreeBSD.org> Cc: "freebsd-fs@freebsd.org" , Ivan Voras Subject: Re: Default inode number too low in FFS nowadays? 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, 06 Nov 2011 22:27:52 -0000 On Sun Nov 6 11, Doug Barton wrote: > On 11/04/2011 07:16, Alexander Best wrote: > > On Fri Nov 4 11, Miroslav Lachman wrote: > >> Matt Connor wrote: > >>> > >>> On Nov 3, 2011, at 5:43 AM, Ivan Voras wrote: > >>> > >>>> On 02/11/2011 12:57, Borja Marcos wrote: > >> > >> [...] > >> > >>>> Did you forget to do "make clean" after "make install" on several large > >>>> ports? > >>>> > >>>> But yes, the ports tree is getting a bit unwieldy. On the other hand, > >>>> did you fsck the file system lately? > >>>> > >>> > >>> cd /usr/ports/ports-mgmt/portupgrade&& make install clean > >>> > >>> portsclean -CD > >>> > >>> That's a quick way to clean out all the clutter. > >> > >> Installing ruby and portupgrade is really big overhead to simple task, > >> which can be done by: > >> > >> cd /usr/ports && make clean > >> > >> or with find: > >> > >> find /usr/ports/ -depth 3 -name "work" -exec rm -r {} + > > > > ...or with 'rm -rf /usr/ports/*/*/work' > > This comes up periodically, and for some reason no one pays attention to > all the work that's been done in the past to verify that the fastest > method is: > > find /usr/ports -maxdepth 3 -type d -name -work -exec rm -rf {} \; 1) -work ? 2) i like -depth 3 better, because it will not touch my /usr/ports/work directory, where i keep my latest ports stuff (theoretically). 3) are you sure \; is "faster" than + ? cheers. alex > > Of course, the best solution by far is to set WRKDIRPREFIX to a path > with adequate space, preferably something other than /usr/obj. > > > hth, > > Doug > > -- > > "We could put the whole Internet into a book." > "Too practical." > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 22:36:32 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A2BB9106564A; Sun, 6 Nov 2011 22:36:32 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7BECD14E0AE; Sun, 6 Nov 2011 22:36:32 +0000 (UTC) Message-ID: <4EB719FF.1070403@FreeBSD.org> Date: Sun, 06 Nov 2011 15:36:31 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Alexander Best References: <5C156A63-D86D-4C1B-AFC4-DC5EA09494F6@xerq.net> <4EB3C63F.2060805@quip.cz> <20111104141626.GA28925@freebsd.org> <4EB7126C.3030809@FreeBSD.org> <20111106222752.GA88092@freebsd.org> In-Reply-To: <20111106222752.GA88092@freebsd.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" , Ivan Voras Subject: Re: Default inode number too low in FFS nowadays? 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, 06 Nov 2011 22:36:32 -0000 On 11/06/2011 14:27, Alexander Best wrote: > On Sun Nov 6 11, Doug Barton wrote: >> On 11/04/2011 07:16, Alexander Best wrote: >>> On Fri Nov 4 11, Miroslav Lachman wrote: >>>> Matt Connor wrote: >>>>> >>>>> On Nov 3, 2011, at 5:43 AM, Ivan Voras wrote: >>>>> >>>>>> On 02/11/2011 12:57, Borja Marcos wrote: >>>> >>>> [...] >>>> >>>>>> Did you forget to do "make clean" after "make install" on several large >>>>>> ports? >>>>>> >>>>>> But yes, the ports tree is getting a bit unwieldy. On the other hand, >>>>>> did you fsck the file system lately? >>>>>> >>>>> >>>>> cd /usr/ports/ports-mgmt/portupgrade&& make install clean >>>>> >>>>> portsclean -CD >>>>> >>>>> That's a quick way to clean out all the clutter. >>>> >>>> Installing ruby and portupgrade is really big overhead to simple task, >>>> which can be done by: >>>> >>>> cd /usr/ports && make clean >>>> >>>> or with find: >>>> >>>> find /usr/ports/ -depth 3 -name "work" -exec rm -r {} + >>> >>> ...or with 'rm -rf /usr/ports/*/*/work' >> >> This comes up periodically, and for some reason no one pays attention to >> all the work that's been done in the past to verify that the fastest >> method is: >> >> find /usr/ports -maxdepth 3 -type d -name -work -exec rm -rf {} \; > > 1) -work ? Typo, obviously. > 2) i like -depth 3 better, because it will not touch my /usr/ports/work > directory, where i keep my latest ports stuff (theoretically). You're probably right, but that variant hasn't been tested. Although it's likely to be only slightly faster, the more important bit is -type d, which avoids testing files since there are many more of those than there are directories. The use of either -maxdepth or -depth to avoid recursing into the work directories themselves will be the thing that saves you the most time. > 3) are you sure \; is "faster" than + ? The last time this came up the xargs version was tested (which + basically emulates) and it was either not faster, or slower. If you think about how the disk access is likely to work, the reason this is true should be obvious. Rather than theorizing about it further, why don't you do some actual testing. :) Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 22:36: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 15FDB106566C; Sun, 6 Nov 2011 22:36:53 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id B4CE38FC17; Sun, 6 Nov 2011 22:36:52 +0000 (UTC) Received: by ggnk3 with SMTP id k3so4188184ggn.13 for ; Sun, 06 Nov 2011 14:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=AOnJ4XCh/RdfSEUWSEdqDoCRIuQeL2JUHLaEeywGycQ=; b=TzLtM+cMZAGTzt67/hyyzOP8DEt2h8I1LiRnA6ynoX2VhiwLONQFGUIfdZFWPRHIXh xx7nVxMZ2Hcaz9m40XfXTfrhc4Wk9/Ri62LRSWheUglXr7GjIUMpFJTCt0J5oLiUgsd6 /tcrAnv6CpWLi61xWCnMFNINkeBiGoGHfn9bQ= Received: by 10.101.166.12 with SMTP id t12mr5403275ano.150.1320619012101; Sun, 06 Nov 2011 14:36:52 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.58.9 with HTTP; Sun, 6 Nov 2011 14:36:11 -0800 (PST) In-Reply-To: <4EB7126C.3030809@FreeBSD.org> References: <5C156A63-D86D-4C1B-AFC4-DC5EA09494F6@xerq.net> <4EB3C63F.2060805@quip.cz> <20111104141626.GA28925@freebsd.org> <4EB7126C.3030809@FreeBSD.org> From: Ivan Voras Date: Sun, 6 Nov 2011 23:36:11 +0100 X-Google-Sender-Auth: fldA65NM1NbmNrILDF0ScfCjcTQ Message-ID: To: Doug Barton Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-fs@freebsd.org" , Alexander Best Subject: Re: Default inode number too low in FFS nowadays? 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, 06 Nov 2011 22:36:53 -0000 On 7 November 2011 00:04, Doug Barton wrote: > This comes up periodically, and for some reason no one pays attention to > all the work that's been done in the past to verify that the fastest > method is: > > find /usr/ports -maxdepth 3 -type d -name -work -exec rm -rf {} \; So... time to add it to fortune/datfiles/freebsd-tips ? From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 22:40:22 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 2CC0E1065670; Sun, 6 Nov 2011 22:40:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8FBA617A937; Sun, 6 Nov 2011 22:39:56 +0000 (UTC) Message-ID: <4EB71ACB.6060100@FreeBSD.org> Date: Sun, 06 Nov 2011 15:39:55 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ivan Voras References: <5C156A63-D86D-4C1B-AFC4-DC5EA09494F6@xerq.net> <4EB3C63F.2060805@quip.cz> <20111104141626.GA28925@freebsd.org> <4EB7126C.3030809@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" , Alexander Best Subject: Re: Default inode number too low in FFS nowadays? 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, 06 Nov 2011 22:40:22 -0000 On 11/06/2011 14:36, Ivan Voras wrote: > On 7 November 2011 00:04, Doug Barton wrote: > >> This comes up periodically, and for some reason no one pays attention to >> all the work that's been done in the past to verify that the fastest >> method is: >> >> find /usr/ports -maxdepth 3 -type d -name work -exec rm -rf {} \; > > So... time to add it to fortune/datfiles/freebsd-tips ? Sure, go ahead. :) Of course please be sure to include the bit about WRKDIRPREFIX being the preferred solution. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 22:45: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 271F5106566B; Sun, 6 Nov 2011 22:45:50 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id C4E7A8FC08; Sun, 6 Nov 2011 22:45:49 +0000 (UTC) Received: by ywt32 with SMTP id 32so6086617ywt.13 for ; Sun, 06 Nov 2011 14:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=0BZl29xv+MF2HekK/vOjTJxssD20JV1azx27FhXGOcY=; b=xxz34ukTsT0CeIjIs5mBRkNm2SS/k0Lg4g/BYmFc8me8D4I7vUSZxj+LHwYucNpPi3 3hXwJuwXrrSxa8ll9pQHHkj+q26YjwfbaMmfXBV2DE3BUR9KYp6rqPK7KXbH+EYHjzT4 uzLL6hzsZEMAopAQO/Vh4a3QGgKHUzpfo21E4= Received: by 10.100.118.11 with SMTP id q11mr4646960anc.84.1320619549065; Sun, 06 Nov 2011 14:45:49 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.58.9 with HTTP; Sun, 6 Nov 2011 14:45:08 -0800 (PST) In-Reply-To: <4EB71ACB.6060100@FreeBSD.org> References: <5C156A63-D86D-4C1B-AFC4-DC5EA09494F6@xerq.net> <4EB3C63F.2060805@quip.cz> <20111104141626.GA28925@freebsd.org> <4EB7126C.3030809@FreeBSD.org> <4EB71ACB.6060100@FreeBSD.org> From: Ivan Voras Date: Sun, 6 Nov 2011 23:45:08 +0100 X-Google-Sender-Auth: 1jX_frreAHfL4YFQCqEWv12RCoA Message-ID: To: Doug Barton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-fs@freebsd.org" Subject: Re: Default inode number too low in FFS nowadays? 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, 06 Nov 2011 22:45:50 -0000 On 7 November 2011 00:39, Doug Barton wrote: > On 11/06/2011 14:36, Ivan Voras wrote: >> On 7 November 2011 00:04, Doug Barton wrote: >> >>> This comes up periodically, and for some reason no one pays attention t= o >>> all the work that's been done in the past to verify that the fastest >>> method is: >>> >>> find /usr/ports -maxdepth 3 -type d -name work -exec rm -rf {} \; >> >> So... time to add it to fortune/datfiles/freebsd-tips ? > > Sure, go ahead. :) =C2=A0Of course please be sure to include the bit abou= t > WRKDIRPREFIX being the preferred solution. > Well, I would have to add one of you on this thread as the author so it doesn't really make sense for me to do it... anyway, though more correct, my colour of the bikeshed disagrees with WRKDIRPREFIX since it's a "tip" for an easy trick, not a Handbook replacement :) From owner-freebsd-fs@FreeBSD.ORG Sun Nov 6 22:48: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 2534E106564A for ; Sun, 6 Nov 2011 22:48:11 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 0D81A8FC15 for ; Sun, 6 Nov 2011 22:48:10 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 9AA815081A for ; Sun, 6 Nov 2011 14:48:10 -0800 (PST) To: freebsd-fs@freebsd.org Date: Sun, 06 Nov 2011 14:48:10 -0800 Message-ID: <11704.1320619690@tristatelogic.com> From: "Ronald F. Guilmette" Subject: extended attributes limits 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, 06 Nov 2011 22:48:11 -0000 On a UFS2 filesystem, how many bytes worth of extended attributes data can be stored? Is there a per-file limit on this, or is the limit per-filesystem? I know that there must be some limit, but I have not seen it documented anywhere. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 00:44:46 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 45CCF106566B for ; Mon, 7 Nov 2011 00:44:46 +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 026D48FC15 for ; Mon, 7 Nov 2011 00:44:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0EAIApt06DaFvO/2dsb2JhbABDhHqjYoIlgXIBAQEEAQEBICsgCxsOCgICDRkCKQEJJgYIBwQBHASHaaM1kHqBMIIXhE6BFgSIC4l5gh2SCg X-IronPort-AV: E=Sophos;i="4.69,466,1315195200"; d="scan'208";a="144414335" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 06 Nov 2011 19:44:45 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 19574B3F36; Sun, 6 Nov 2011 19:44:45 -0500 (EST) Date: Sun, 6 Nov 2011 19:44:45 -0500 (EST) From: Rick Macklem To: Robert Simmons Message-ID: <1508064123.1257002.1320626685087.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 - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: rpc.umntall error on boot 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, 07 Nov 2011 00:44:46 -0000 Robert Simmons wrote: > I'm getting the following error on a new install with NFS: > > kernel: rpc.umntall: > kernel: fileserver: MOUNTPROG: RPC: Program not registered > kernel: > kernel: rpc.umntall: > kernel: localhost: MOUNTPROG: RPC: Program not registered > kernel: > kernel: rpc.umntall: > kernel: fileserver: MOUNTPROG: RPC: Program not registered > > My /etc/rc.conf contains the following: > nfs_server_enable="YES" > nfs_client_enable="YES" > rpcbind_enable="YES" > Well, if your server isn't also a client (doesn't do mounts from other NFS servers), you can just set nfs_client_enable="NO" and the message will go away. Otherwise, I don't know how to get rid of it, but it's pretty harmless. What happens is that /etc/rc.d/nfsclient is executed before /etc/rc.d/mountd. It finds /var/db/mountdtab non-empty and tries to get a port from rpcbind for mountd. Since mountd isn't running yet, so it fails. Since telling the server on the same machine to clear out /var/db/mountdtab for the client is basically meaningless, failing shouldn't be a problem. Although mountd maintains /var/db/mountdtab, it is only used for replying to "showmount" and doesn't affect the function of actual mounts. (The NFS protocol really has no concept of a "mount". The unmount RPC for the mountd protocol just updates /var/db/mountdtab and doesn't affect NFS.) rpc.umntall is just meant to clean up /var/db/mountdtab after a client reboot. rick > and /etc/exports is the following (for testing): > /storage -maproot=root 127.0.0.1 > > Even if I run the NFSv4 experimental server that does not use rpcbind > (so I set it ="NO"), the error is still there. > > This problem does not seem to affect mounting or NFS functions. What > could be causing this error? > > Rob > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 00:47:17 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 AD76C106564A; Mon, 7 Nov 2011 00:47:17 +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 318D78FC14; Mon, 7 Nov 2011 00:47:16 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAIApt06DaFvO/2dsb2JhbABDhHqjN4JQgXIBAQUjVhsYAgINGQJLDgYTqz+QeoEwhmWBFgSIC4wWkgo X-IronPort-AV: E=Sophos;i="4.69,466,1315195200"; d="scan'208";a="144414471" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 06 Nov 2011 19:47:16 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4D4B1B3F42; Sun, 6 Nov 2011 19:47:16 -0500 (EST) Date: Sun, 6 Nov 2011 19:47:16 -0500 (EST) From: Rick Macklem To: Josh Paetzel Message-ID: <1093662212.1257099.1320626836299.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4EB6B4E9.1000804@tcbug.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Josh Paetzel , freebsd-fs@freebsd.org, zkirsch@freebsd.org, Ronald Klop Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 07 Nov 2011 00:47:17 -0000 Josh Paetzel wrote: > On 11/06/11 07:34, Rick Macklem wrote: > > Ronald Klop wrote: > >> On Sun, 06 Nov 2011 02:18:05 +0100, Rick Macklem > >> > >> wrote: > >> > >>> Hi, > >>> > >>> Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > >>> for the new NFS server. > >>> > >>> I don't think I had spotted this before, but when I looked I > >>> saw that, when vfs.nfsrv.async is set non-zero in the old server, > >>> it returns FILESYNC (which means the write has been committed to > >>> non-volatile storage) even when it hasn't actually done that. > >>> > >>> This can improve performance, but has some negative implications: > >>> - If the server crashes before the write is committed to > >>> non-volatile storage, the file modification will be lost. > >>> (When a server replies UNSTABLE to a write, the client holds > >>> onto the data in its cache and does the write again if the > >>> server crashes/reboots before the client does a Commit RPC > >>> for the file. However, a reply of FILESYNC tells the client > >>> it can forget about the write, because it is done.) > >>> - Because of the above, replying FILESYNC when the data is not > >>> yet committed to non-volatile (also referred to as stable) > >>> storage, this is a violation of RFC1813. > >> > >> Just out of curiosity. Why would lying about FILESYNC improve > >> performance > >> over UNSTABLE? The server does the same work. Only the client holds > >> data > >> longer in memory. I only see impact if the client has just a little > >> bit of > >> memory. > >> > >> Ronald. > > Well, I'm not sure I have an answer. Josh noted that it makes a big > > difference for them. Maybe he can elaborate? > > > > I'll test it out and report back in the next week or so. > > In 8.x, setting the async sysctl was the difference between > 80-100MB/sec > and 800 MB/sec (Yes, MegaBytes!) using a variety of different clients, > including the VMWare ESXi 4.x client, Xen 5.6 client, various linux > clients and the FreeBSD client. I'll note that 800MB/sec is getting > close to the underlying filesystem performance, so it's likely that > the > gate to performance is in the filesystem in that case. 80-100MB/sec is > basically gigE performance. > Just wondering...are these tests writing a file larger than the buffer cache can hold? rick > I can make hardware available if anyone is curious at poking at this, > we > have the ability to set up tests with quad gigE LACP, 10 gigE, and > numerous clients. > > > One additional effect is that the client in head must do a > > synchronous > > write (with FILESYNC and waiting for the RPC reply) before it can > > modify a non-continuous region of the same buffer with respect to > > the old dirty byte region. (This happens > > frequently during builds, done mostly by the loader, I think?) > > If the server replies FILESYNC, then the old dirty byte region is > > done > > (ie. no longer a dirty byte region) so the client doesn't > > have to do the synchronous write described above. > > I hope that the experimental patch I made available a few days ago, > > along with work jhb@ is doing will eventually fix this for the > > FreeBSD > > client, but it won't be in head anytime soon (and who knows what > > other clients do?). > > > > rick > > > > > -- > Thanks, > > Josh Paetzel From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 03:07: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 C7F69106564A for ; Mon, 7 Nov 2011 03:07:58 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 89DA48FC0A for ; Mon, 7 Nov 2011 03:07:58 +0000 (UTC) Received: by ggnk3 with SMTP id k3so4448212ggn.13 for ; Sun, 06 Nov 2011 19:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0mvsSNB2gPvrjJIAkONgv6z19Hi0u9DZlPWLWP1OuVY=; b=k9sHu52EeEJgV9eqQUfyDKanXT4jyW83XRbieB2wvkAe0TPLIoqsO5/leO7rsOLY1O FXDeQO0vdpJnSHy5aNw02SJbSl0umrG16WSL+xy+h42zXwut/IZ906ZKiSiAwhv27rEi L1OkR8/7zZdQsrubo+i5AYxlltq9791XdpuEc= MIME-Version: 1.0 Received: by 10.101.80.8 with SMTP id h8mr5459981anl.16.1320635278063; Sun, 06 Nov 2011 19:07:58 -0800 (PST) Received: by 10.100.143.13 with HTTP; Sun, 6 Nov 2011 19:07:57 -0800 (PST) In-Reply-To: <1508064123.1257002.1320626685087.JavaMail.root@erie.cs.uoguelph.ca> References: <1508064123.1257002.1320626685087.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 6 Nov 2011 22:07:57 -0500 Message-ID: From: Robert Simmons To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: rpc.umntall error on boot 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, 07 Nov 2011 03:07:58 -0000 On Sun, Nov 6, 2011 at 7:44 PM, Rick Macklem wrote: > What happens is that /etc/rc.d/nfsclient is executed before > /etc/rc.d/mountd. It finds /var/db/mountdtab non-empty and tries to > get a port from rpcbind for mountd. Since mountd isn't running yet, > so it fails. Since telling the server on the same machine to clear > out /var/db/mountdtab for the client is basically meaningless, failing > shouldn't be a problem. Would there be any drawbacks to moving /etc/rc.d/nfsclient to later in the process so that mountd is already running? Rob From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 07:26:01 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 4B312106564A; Mon, 7 Nov 2011 07:26:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 64ED58FC16; Mon, 7 Nov 2011 07:25:59 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA20873; Mon, 07 Nov 2011 09:25:57 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RNJaf-0004ST-Kb; Mon, 07 Nov 2011 09:25:57 +0200 Message-ID: <4EB78803.7060102@FreeBSD.org> Date: Mon, 07 Nov 2011 09:25:55 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Doug Barton References: <5C156A63-D86D-4C1B-AFC4-DC5EA09494F6@xerq.net> <4EB3C63F.2060805@quip.cz> <20111104141626.GA28925@freebsd.org> <4EB7126C.3030809@FreeBSD.org> In-Reply-To: <4EB7126C.3030809@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" Subject: Re: Default inode number too low in FFS nowadays? 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, 07 Nov 2011 07:26:01 -0000 on 07/11/2011 01:04 Doug Barton said the following: > Of course, the best solution by far is to set WRKDIRPREFIX to a path > with adequate space, preferably something other than /usr/obj. Why is that? Just because portmaster tries to do some magic under ${WRKDIRPREFIX} as opposed to ${WRKDIRPREFIX}/${PORTSDIR:-/usr/ports} ? :-) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 07:27:33 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 8D3001065672; Mon, 7 Nov 2011 07:27:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6201E14FB1E; Mon, 7 Nov 2011 07:27:33 +0000 (UTC) Message-ID: <4EB78865.8080106@FreeBSD.org> Date: Sun, 06 Nov 2011 23:27:33 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <5C156A63-D86D-4C1B-AFC4-DC5EA09494F6@xerq.net> <4EB3C63F.2060805@quip.cz> <20111104141626.GA28925@freebsd.org> <4EB7126C.3030809@FreeBSD.org> <4EB78803.7060102@FreeBSD.org> In-Reply-To: <4EB78803.7060102@FreeBSD.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" Subject: Re: Default inode number too low in FFS nowadays? 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, 07 Nov 2011 07:27:33 -0000 On 11/06/2011 23:25, Andriy Gapon wrote: > on 07/11/2011 01:04 Doug Barton said the following: >> Of course, the best solution by far is to set WRKDIRPREFIX to a path >> with adequate space, preferably something other than /usr/obj. > > Why is that? Just because portmaster tries to do some magic under > ${WRKDIRPREFIX} as opposed to ${WRKDIRPREFIX}/${PORTSDIR:-/usr/ports} ? :-) Partly, yes. Mostly because mixing src stuff and ports stuff is a bad idea. -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 07:39: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 5C613106564A; Mon, 7 Nov 2011 07:39:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 76DB08FC0C; Mon, 7 Nov 2011 07:39:02 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA21077; Mon, 07 Nov 2011 09:39:01 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RNJnJ-0004TF-D7; Mon, 07 Nov 2011 09:39:01 +0200 Message-ID: <4EB78B14.1060309@FreeBSD.org> Date: Mon, 07 Nov 2011 09:39:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Doug Barton References: <5C156A63-D86D-4C1B-AFC4-DC5EA09494F6@xerq.net> <4EB3C63F.2060805@quip.cz> <20111104141626.GA28925@freebsd.org> <4EB7126C.3030809@FreeBSD.org> <4EB78803.7060102@FreeBSD.org> <4EB78865.8080106@FreeBSD.org> In-Reply-To: <4EB78865.8080106@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" Subject: Re: Default inode number too low in FFS nowadays? 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, 07 Nov 2011 07:39:04 -0000 on 07/11/2011 09:27 Doug Barton said the following: > On 11/06/2011 23:25, Andriy Gapon wrote: >> on 07/11/2011 01:04 Doug Barton said the following: >>> Of course, the best solution by far is to set WRKDIRPREFIX to a path >>> with adequate space, preferably something other than /usr/obj. >> >> Why is that? Just because portmaster tries to do some magic under >> ${WRKDIRPREFIX} as opposed to ${WRKDIRPREFIX}/${PORTSDIR:-/usr/ports} ? :-) > > Partly, yes. Mostly because mixing src stuff and ports stuff is a bad idea. Well, I've never had issues distinguishing between /usr/obj/usr/ports and /usr/obj/ here, but, of course, that's just me. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 08:48:43 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69303106566C; Mon, 7 Nov 2011 08:48:43 +0000 (UTC) (envelope-from Karli.Sjoberg@slu.se) Received: from Edge1-3.slu.se (edge1-3.slu.se [193.10.100.98]) by mx1.freebsd.org (Postfix) with ESMTP id B8D288FC17; Mon, 7 Nov 2011 08:48:42 +0000 (UTC) Received: from Exchange1.ad.slu.se (193.10.100.94) by Edge1-3.slu.se (193.10.100.98) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 7 Nov 2011 09:48:39 +0100 Received: from exmbx3.ad.slu.se ([193.10.100.93]) by Exchange1.ad.slu.se ([193.10.100.94]) with mapi; Mon, 7 Nov 2011 09:48:39 +0100 From: =?iso-8859-1?Q?Karli_Sj=F6berg?= To: Jeremy Chadwick Date: Mon, 7 Nov 2011 09:48:37 +0100 Thread-Topic: AOC-USAS2-L8i zfs panics and SCSI errors in messages Thread-Index: AcydKgshssCJtxGcRfKbhNyvhT7O9w== Message-ID: <75BDE9FA-6130-4BB4-8518-275D68BB3E49@slu.se> References: <82B38DBF-DD3A-46CD-93F6-02CDB6506E05@slu.se> <20111025193302.GA30409@nargothrond.kdm.org> <20111026101602.GA9768@icarus.home.lan> In-Reply-To: <20111026101602.GA9768@icarus.home.lan> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-scsi@freebsd.org" , "Kenneth D. Merry" , "fs@freebsd.org" Subject: Re: AOC-USAS2-L8i zfs panics and SCSI errors in messages 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, 07 Nov 2011 08:48:43 -0000 As a test, I have copied in about 1.5TB and scrubbed several times without = any panic. It stayed solid until periodic weekly:( Same panic as with daily= . /Karli Sj=F6berg 26 okt 2011 kl. 12.16 skrev Jeremy Chadwick: On Wed, Oct 26, 2011 at 11:36:44AM +0200, Karli Sj?berg wrote: Hi all, I tracked down what causes the panics! I got a tip from aragon and phoenix at the forum about /etc/periodic/security/100.chksetuid And to put: daily_status_security_chksetuid_enable=3D"NO" into /etc/periodic.conf This is not truly the cause of the panic, it simply exacerbates it. Many of the periodic scripts will do things like iterate over all files on the filesystem looking for specific attributes, etc.. This tends to stress filesystems heavily. This isn't the only one. :-) I can now run periodic daily without any panics. I?m still wondering about the cause of this, the explanation from the forum was that that phase is too demanding for multi TB systems. But I have several multi TB servers with FreeBSD and ZFS, and none of them has ever behaved this way. Besides, the panic is instantaneous, not degenerative. I imagine that a run like that would start out OK and then just get worse and worse, getting gradually slower and slower until it just wouldn?t cope any more and hang. This feels more like hitting a wall. As if it found something that is couldn?t deal with and has no choice but to panic immediately. It may be possible that you have some underlying filesystem corruption that triggers this situation. Have you actually tried doing a "zpool scrub" of your pools and seeing if any errors happen or if the panic occurs there? I'm inclined to think what you're experiencing is probably a bug or "quirk" in the storage controller driver you're using. There are other drivers that have had fixes applied to them "to make them work decently with ZFS", meaning the kind of stressful I/O ZFS puts on them results in the controller driver behaving oddly or freaking out, case in point. It could also be a controller firmware bug/quirk/design issue. Seriously. I believe the AOC-USAS2-L8i controller has been discussed on freebsd-stable, re: mps(4) driver problems or equivalent, but I'm not going to CC that list given that there would be 3 cross-posted lists involved and that is liable to upset some folks. You should search the mailing lists for discussion of Supermicro controllers that work reliably with FreeBSD. It would be worthwhile to discuss this condition on -stable, mainly with something like "Anyone else using the AOC-USAS2-L8i reliably with ZFS?" You get the idea. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | Med V=E4nliga H=E4lsningar ---------------------------------------------------------------------------= ---- Karli Sj=F6berg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kron=E5sv=E4gen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 09:22:53 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 482F91065670; Mon, 7 Nov 2011 09:22:53 +0000 (UTC) (envelope-from rincebrain@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 CBB6E8FC24; Mon, 7 Nov 2011 09:22:52 +0000 (UTC) Received: by qadb12 with SMTP id b12so2346282qad.13 for ; Mon, 07 Nov 2011 01:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=7tlGToQ+TyuJS4hlFip2dDFGqpO3lkVwaCsHg3eIWPY=; b=fJfw5AGM1634meM2INBzq+9WoGzfirbQh3IvnTkSqVMLf4GDTNNkXLumQmOGCORmub u5GXDlHFAOV38JpWPpBA7sPCbqx2pnFd8Fac0V29xJFqinv46TILw8S7zZa5usipB+hS 5b6UrxPoMtYAPT5aV4mDEsw/oEvOGAQ5EKhbE= MIME-Version: 1.0 Received: by 10.229.65.27 with SMTP id g27mr2359222qci.288.1320656174318; Mon, 07 Nov 2011 00:56:14 -0800 (PST) Sender: rincebrain@gmail.com Received: by 10.229.138.14 with HTTP; Mon, 7 Nov 2011 00:56:14 -0800 (PST) In-Reply-To: <75BDE9FA-6130-4BB4-8518-275D68BB3E49@slu.se> References: <82B38DBF-DD3A-46CD-93F6-02CDB6506E05@slu.se> <20111025193302.GA30409@nargothrond.kdm.org> <20111026101602.GA9768@icarus.home.lan> <75BDE9FA-6130-4BB4-8518-275D68BB3E49@slu.se> Date: Mon, 7 Nov 2011 03:56:14 -0500 X-Google-Sender-Auth: zmMH5-mOzoXy4iUoPfLnn9EKedo Message-ID: From: Rich To: =?ISO-8859-1?Q?Karli_Sj=F6berg?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-scsi@freebsd.org" , "Kenneth D. Merry" , "fs@freebsd.org" Subject: Re: AOC-USAS2-L8i zfs panics and SCSI errors in messages 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, 07 Nov 2011 09:22:53 -0000 Observation - the LSI SAS expanders, in my experience, sometimes misbehave when there are drives which respond slower than some timeout to commands (as far as I've seen it's only SATA drives it does this for, but I don't have many SAS drives for comparison), leading to all further commands to that drive for a bit not working, and then what happens depending on the OS varies dramatically. If you could try without an expander (e.g. with 1->4 SAS->SATA fanout cables), you may be surprised (and/or annoyed) to find your life gets better. - Rich On Mon, Nov 7, 2011 at 3:48 AM, Karli Sj=F6berg wrot= e: > As a test, I have copied in about 1.5TB and scrubbed several times withou= t any panic. It stayed solid until periodic weekly:( Same panic as with dai= ly. > > /Karli Sj=F6berg > > 26 okt 2011 kl. 12.16 skrev Jeremy Chadwick: > > On Wed, Oct 26, 2011 at 11:36:44AM +0200, Karli Sj?berg wrote: > Hi all, > > I tracked down what causes the panics! > > I got a tip from aragon and phoenix at the forum about > /etc/periodic/security/100.chksetuid > > And to put: > daily_status_security_chksetuid_enable=3D"NO" > into /etc/periodic.conf > > This is not truly the cause of the panic, it simply exacerbates it. > > Many of the periodic scripts will do things like iterate over all files > on the filesystem looking for specific attributes, etc.. =A0This tends to > stress filesystems heavily. =A0This isn't the only one. =A0:-) > > I can now run periodic daily without any panics. I?m still wondering > about the cause of this, the explanation from the forum was that that > phase is too demanding for multi TB systems. But I have several multi > TB servers with FreeBSD and ZFS, and none of them has ever behaved > this way. Besides, the panic is instantaneous, not degenerative. I > imagine that a run like that would start out OK and then just get > worse and worse, getting gradually slower and slower until it just > wouldn?t cope any more and hang. This feels more like hitting a wall. > As if it found something that is couldn?t deal with and has no choice > but to panic immediately. > > It may be possible that you have some underlying filesystem corruption > that triggers this situation. =A0Have you actually tried doing a "zpool > scrub" of your pools and seeing if any errors happen or if the panic > occurs there? > > I'm inclined to think what you're experiencing is probably a bug or > "quirk" in the storage controller driver you're using. =A0There are other > drivers that have had fixes applied to them "to make them work decently > with ZFS", meaning the kind of stressful I/O ZFS puts on them results in > the controller driver behaving oddly or freaking out, case in point. =A0I= t > could also be a controller firmware bug/quirk/design issue. =A0Seriously. > > I believe the AOC-USAS2-L8i controller has been discussed on > freebsd-stable, re: mps(4) driver problems or equivalent, but I'm not > going to CC that list given that there would be 3 cross-posted lists > involved and that is liable to upset some folks. =A0You should search the > mailing lists for discussion of Supermicro controllers that work > reliably with FreeBSD. > > It would be worthwhile to discuss this condition on -stable, mainly with > something like "Anyone else using the AOC-USAS2-L8i reliably with ZFS?" > You get the idea. > > -- > | Jeremy Chadwick =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0jdc at parodius.com | > | Parodius Networking =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.parodius.com/ | > | UNIX Systems Administrator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mountain= View, CA, US | > | Making life hard for others since 1977. =A0 =A0 =A0 =A0 =A0 =A0 =A0 PGP= 4BD6C0CB | > > > > > Med V=E4nliga H=E4lsningar > -------------------------------------------------------------------------= ------ > Karli Sj=F6berg > Swedish University of Agricultural Sciences > Box 7079 (Visiting Address Kron=E5sv=E4gen 8) > S-750 07 Uppsala, Sweden > Phone: =A0+46-(0)18-67 15 66 > karli.sjoberg@slu.se > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 11:07:10 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 02F341065672 for ; Mon, 7 Nov 2011 11:07:10 +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 E54948FC19 for ; Mon, 7 Nov 2011 11:07:09 +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 pA7B79qP078665 for ; Mon, 7 Nov 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA7B79eE078663 for freebsd-fs@FreeBSD.org; Mon, 7 Nov 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Nov 2011 11:07:09 GMT Message-Id: <201111071107.pA7B79eE078663@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, 07 Nov 2011 11:07:10 -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/162083 fs [zfs] [panic] zfs unmount -f pool o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161674 fs [ufs] snapshot on journaled ufs doesn't work o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161511 fs [unionfs] Filesystem deadlocks when using multiple uni o kern/161493 fs [nfs] NFS v3 directory structure update slow o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs Random UFS root filesystem corruption with SU+J [regre o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159971 fs [ffs] [panic] panic with soft updates journaling durin o kern/159930 fs [ufs] [panic] kernel core o kern/159418 fs [tmpfs] [panic] tmpfs kernel panic: recursing on non r o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159233 fs [ext2fs] [patch] fs/ext2fs: finish reallocblk implemen o kern/159232 fs [ext2fs] [patch] fs/ext2fs: merge ext2_readwrite into o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs [amd] amd(8) ICMP storm and unkillable process. o kern/158711 fs [ffs] [panic] panic in ffs_blkfree and ffs_valloc o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157722 fs [geli] unable to newfs a geli encrypted partition o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs 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 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/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/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/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/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/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 multibyte inter 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 f kern/127375 fs [zfs] If vm.kmem_size_max>"1073741823" then write spee 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 f sparc/123566 fs [zfs] zpool import issue: EOVERFLOW o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/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 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/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 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 260 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 14:32:16 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 04505106566B for ; Mon, 7 Nov 2011 14:32:16 +0000 (UTC) (envelope-from otnaccess@hotmail.com) Received: from snt0-omc1-s42.snt0.hotmail.com (snt0-omc1-s42.snt0.hotmail.com [65.54.61.79]) by mx1.freebsd.org (Postfix) with ESMTP id CDF508FC0C for ; Mon, 7 Nov 2011 14:32:15 +0000 (UTC) Received: from SNT126-DS16 ([65.55.90.7]) by snt0-omc1-s42.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 06:20:14 -0800 X-Originating-IP: [88.132.147.213] X-Originating-Email: [otnaccess@hotmail.com] Message-ID: From: =?iso-8859-1?Q?G=E1bor_S.?= To: , Date: Mon, 7 Nov 2011 15:19:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcydWFMy5RAy73p0SP6ocwGNlQOS2w== Content-Language: en-us X-OriginalArrivalTime: 07 Nov 2011 14:20:14.0765 (UTC) FILETIME=[5E0F5DD0:01CC9D58] Cc: Subject: Symbolic link with absolute target path in UDF - not working properly? 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, 07 Nov 2011 14:32:16 -0000 Hi everybody, Preamble: the presumed misbehavior is exhibited by both operating systems - although in different forms; that's why I'm crossposting to the file system mailing list of both operating systems now. I recently wanted to archive a bunch of data from my (well, Linux) box faithfully, that is keeping not only the hard links but also the symbolic links present. I wanted to directly represent the files on a DVD, so I opted for creating a disc (image actually) in UDF format instead of creating a tgz archive or similar and burn that to a DVD. The next step was to find an application to build the UDF image with symbolic links. A short googling led me to mkisofs (from cdrtools 3.01) and I created an image containing both ISO9660 and UDF file systems with that. Then I mounted the image (because I had the premonition that symbolic links in UDF are less commonly used) - and got pretty surprised since the symbolic links with absolute target path were not working as I expected. For the rest, let us assume that the image contains a file called mounttab which was linking to /etc/mounttab on the source from which the image was created. - On Linux (kernel 3.0.4): the slash (/) at the beginning is omitted. So mounttab actually points to etc/mounttab which is not absolute. - On FreeBSD (GhostBSD 2.5 BETA 3): the names of the path components are simply pasted together without any directory separator (/). So mounttab actually points to /etcmounttab which is obviously erroneous. What I experienced made me also suspicious that mkisofs might be at fault. So I set up another Unix-like OS and mounted the image... - On Oracle Solaris (Oracle Solaris 11 Express 2010.11, LiveCD): all the symbolic links including the ones with absolute target path work as expected. To investigate what is going on I had a look into the UDF specification (ECMA 167) and the source code of the UDF writer of mkisofs and the UDF file system drivers of the above mentioned operating systems. The result is... - According to the UDF specification: the target of the symbolic links is broken into path components (/, etc, mounttab in the example) and that target is basically represented as a sequence of those, where the root directory is represented in a special manner, as so called component type 1 or 2. (While standard path components such as etc and mounttab have a type of 5.) - mkisofs represents the root directory of the absolute target path as component type 2. - Linux expects the root directory of the absolute target path be represented as component type 1. Component type 2 is simply ignored. - FreeBSD (see http://svnweb.freebsd.org/base/release/8.2.0/sys/fs/udf/udf_vnops.c?view=mar kup) processes component type 2 (and bails out finding component type 1 actually). Upon processing the flag root is set to true which is meant (I think) to suppress appending a slash after the component name to avoid double slashes at the beginning of an absolute target path (which is used to separate the component names otherwise). However, the flag root does not get cleared because the corresponding code part gets executed only from the second path component only. - OpenSolaris (see http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/ udfs/udf_vnops.c) processes component type 2 as / itself and component type 1 as the root directory of the medium itself. (And in the UDF file system creator part: the root directory is actually represented as component type 2 just as mkisofs does.) This is too my interpretation of the standard... What do you think? Are Solaris and mkisofs right? Or Linux? FreeBSD's implementation of the symbolic links on the UDF file system is difficult to explain for sure... Thanks, Gabor Suranyi From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 15:36:27 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A505106566B; Mon, 7 Nov 2011 15:36:27 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 310F68FC16; Mon, 7 Nov 2011 15:36:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id 0AFB02041B9; Mon, 7 Nov 2011 16:36:24 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMCwAQ3dzoTw; Mon, 7 Nov 2011 16:36:19 +0100 (CET) Received: from [192.168.48.66] (ip-180.53.99.216.dsl-cust.ca.inter.net [216.99.53.180]) by smtp.infotech.no (Postfix) with ESMTPA id C66352041B1; Mon, 7 Nov 2011 16:36:17 +0100 (CET) Message-ID: <4EB7FAEF.30505@interlog.com> Date: Mon, 07 Nov 2011 10:36:15 -0500 From: Douglas Gilbert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Rich References: <82B38DBF-DD3A-46CD-93F6-02CDB6506E05@slu.se> <20111025193302.GA30409@nargothrond.kdm.org> <20111026101602.GA9768@icarus.home.lan> <75BDE9FA-6130-4BB4-8518-275D68BB3E49@slu.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-scsi@freebsd.org" , "Kenneth D. Merry" , "fs@freebsd.org" , =?ISO-8859-1?Q?Karli_Sj=F6berg?= Subject: Re: AOC-USAS2-L8i zfs panics and SCSI errors in messages X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dgilbert@interlog.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 15:36:27 -0000 On 11-11-07 03:56 AM, Rich wrote: > Observation - the LSI SAS expanders, in my experience, sometimes > misbehave when there are drives which respond slower than some timeout > to commands (as far as I've seen it's only SATA drives it does this > for, but I don't have many SAS drives for comparison), leading to all > further commands to that drive for a bit not working, and then what > happens depending on the OS varies dramatically. > > If you could try without an expander (e.g. with 1->4 SAS->SATA fanout > cables), you may be surprised (and/or annoyed) to find your life gets > better. SAS-2 expanders are better than the original generation. [LSI makes both.] SAS-2 added the CONFIGURE GENERAL SMP function which contains various timeout tweaks for the STP protocol (i.e. the protocol that tunnels (S)ATA commands between a SAS HBA (initiator) and an expander). If you are using SAS-2 expanders and FreeBSD 9.0 then you can fetch my smp_utils package and use the smp_conf_general utility to change those timeout settings. If you have SAS-2 expanders but an older version of FreeBSD then you will need Solaris or Linux to run my smp_utils package in order to change those timeout values on the expander. Doug Gilbert BTW smp_rep_general will show the current settings of those STP timeouts. > On Mon, Nov 7, 2011 at 3:48 AM, Karli Sjφberg wrote: >> As a test, I have copied in about 1.5TB and scrubbed several times without any panic. It stayed solid until periodic weekly:( Same panic as with daily. >> >> /Karli Sjφberg >> >> 26 okt 2011 kl. 12.16 skrev Jeremy Chadwick: >> >> On Wed, Oct 26, 2011 at 11:36:44AM +0200, Karli Sj?berg wrote: >> Hi all, >> >> I tracked down what causes the panics! >> >> I got a tip from aragon and phoenix at the forum about >> /etc/periodic/security/100.chksetuid >> >> And to put: >> daily_status_security_chksetuid_enable="NO" >> into /etc/periodic.conf >> >> This is not truly the cause of the panic, it simply exacerbates it. >> >> Many of the periodic scripts will do things like iterate over all files >> on the filesystem looking for specific attributes, etc.. This tends to >> stress filesystems heavily. This isn't the only one. :-) >> >> I can now run periodic daily without any panics. I?m still wondering >> about the cause of this, the explanation from the forum was that that >> phase is too demanding for multi TB systems. But I have several multi >> TB servers with FreeBSD and ZFS, and none of them has ever behaved >> this way. Besides, the panic is instantaneous, not degenerative. I >> imagine that a run like that would start out OK and then just get >> worse and worse, getting gradually slower and slower until it just >> wouldn?t cope any more and hang. This feels more like hitting a wall. >> As if it found something that is couldn?t deal with and has no choice >> but to panic immediately. >> >> It may be possible that you have some underlying filesystem corruption >> that triggers this situation. Have you actually tried doing a "zpool >> scrub" of your pools and seeing if any errors happen or if the panic >> occurs there? >> >> I'm inclined to think what you're experiencing is probably a bug or >> "quirk" in the storage controller driver you're using. There are other >> drivers that have had fixes applied to them "to make them work decently >> with ZFS", meaning the kind of stressful I/O ZFS puts on them results in >> the controller driver behaving oddly or freaking out, case in point. It >> could also be a controller firmware bug/quirk/design issue. Seriously. >> >> I believe the AOC-USAS2-L8i controller has been discussed on >> freebsd-stable, re: mps(4) driver problems or equivalent, but I'm not >> going to CC that list given that there would be 3 cross-posted lists >> involved and that is liable to upset some folks. You should search the >> mailing lists for discussion of Supermicro controllers that work >> reliably with FreeBSD. >> >> It would be worthwhile to discuss this condition on -stable, mainly with >> something like "Anyone else using the AOC-USAS2-L8i reliably with ZFS?" >> You get the idea. >> >> -- >> | Jeremy Chadwick jdc at parodius.com | >> | Parodius Networking http://www.parodius.com/ | >> | UNIX Systems Administrator Mountain View, CA, US | >> | Making life hard for others since 1977. PGP 4BD6C0CB | >> >> >> >> >> Med Vδnliga Hδlsningar >> ------------------------------------------------------------------------------- >> Karli Sjφberg >> Swedish University of Agricultural Sciences >> Box 7079 (Visiting Address Kronεsvδgen 8) >> S-750 07 Uppsala, Sweden >> Phone: +46-(0)18-67 15 66 >> karli.sjoberg@slu.se >> >> _______________________________________________ >> 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" >> > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 17:45:25 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 ED9CF106564A for ; Mon, 7 Nov 2011 17:45:24 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id BB8938FC0A for ; Mon, 7 Nov 2011 17:45:24 +0000 (UTC) Received: by pzk32 with SMTP id 32so14425098pzk.3 for ; Mon, 07 Nov 2011 09:45:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=PR/Khn7qJjFw+6MlLger/T8SBxj7bR8FUwBVIY8YTXc=; b=jbV47CEFKuctTONK4PjWEEqj5k1gmNcOBxCshVpfOZveyMnuS/cb0K8wosmFnHzRuC QymkC4hrnbmDCkpmCWfvlMaJfVWj1+peme8puR0j0OG7Z1cm8T223dPOpdvQKQN4OWaJ DRvIymabZDOT2rzaOmrJ4b2MEDoKryzo22M4A= MIME-Version: 1.0 Received: by 10.68.15.232 with SMTP id a8mr544306pbd.129.1320686298975; Mon, 07 Nov 2011 09:18:18 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.49.35 with HTTP; Mon, 7 Nov 2011 09:18:18 -0800 (PST) In-Reply-To: <60946.1320475599@tristatelogic.com> References: <60946.1320475599@tristatelogic.com> Date: Mon, 7 Nov 2011 09:18:18 -0800 X-Google-Sender-Auth: UHd5uOSl288UQkp9KbCOUjWxqUY Message-ID: From: mdf@FreeBSD.org To: "Ronald F. Guilmette" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: write access to various times 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, 07 Nov 2011 17:45:25 -0000 On Fri, Nov 4, 2011 at 11:46 PM, Ronald F. Guilmette wrote: > It would appear that in 8.2-RELEASE, at least, each "struct stat" contain= s > four fields, each of type "timespec", and having the following names: > > =A0 =A0st_atimespec > =A0 =A0st_mtimespec > =A0 =A0st_ctimespec > =A0 =A0st_birthtimespec > > I already know that if I want to modify either (or both) of the first > two fields listed above, I should call utimes(2). =A0But what do I do if = I need > to modify the values of either or both of the other two fields? =A0(I may= want > to do this, e.g. if I am trying to restore all of the struct stat fields > from a backed-up representation of some original filesystem entry.) > > The current man page for utimes(2) says (among other things): > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > =A0 =A0 ... > =A0 =A0 If times is non-NULL, it is assumed to point to an array of two t= imeval > =A0 =A0 structures. =A0The access time is set to the value of the first e= lement, > =A0 =A0 and the modification time is set to the value of the second eleme= nt. =A0For > =A0 =A0 file systems that support file birth (creation) times (such as UF= S2), the > =A0 =A0 birth time will be set to the value of the second element if the = second > =A0 =A0 element is older than the currently set birth time. =A0To set bot= h a birth > =A0 =A0 time and a modification time, two calls are required; the first t= o set > =A0 =A0 the birth time and the second to set the (presumably newer) modif= ication > =A0 =A0 time. =A0Ideally a new system call will be added that allows the = setting of > =A0 =A0 all three times at once... > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > Is there any ETA for this postulated new system call? To my knowledge, no. I think this was a hopeful statement on the original author's part. AFAIK no one is working on this change. We have a patch at $WORK that adds a vtimes(2) syscall with support for setting birthtime as well as mtime and atime. Some day [1] I may be able to upstream this functionality back to FreeBSD. [1] predicated on continued employment, change of roles at $WORK, time, and community acceptance of the changes. A rough estimate would be sometime in the middle or end of 2012. Cheers, matthew > Also, of course, although the method described above for setting the valu= e of > the st_birthtimespec field is rather clumsey and inefficient, at least th= ere > _is_ a way to set that field. =A0I am concerned however because I persona= lly > still know of no way whatsoever to set the value of the st_ctimespec fiel= d. > Is there any way to do that? > > It would be most helpful to have that too. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 19:35:51 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 6DC6C1065677 for ; Mon, 7 Nov 2011 19:35:51 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id F0EDE8FC0C for ; Mon, 7 Nov 2011 19:35:50 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RNUyx-0000Zf-4Q for freebsd-fs@freebsd.org; Mon, 07 Nov 2011 20:35:47 +0100 Received: from ib-jtotz.ib.ic.ac.uk ([155.198.110.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Nov 2011 20:35:47 +0100 Received: from jtotz by ib-jtotz.ib.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Nov 2011 20:35:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Mon, 07 Nov 2011 19:35:34 +0000 Lines: 41 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ib-jtotz.ib.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 In-Reply-To: Subject: Re: ZFS question - clones vs dedupe 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, 07 Nov 2011 19:35:51 -0000 On 31/10/2011 10:34, Ivan Natchkov wrote: > Hello to everyone, > > I have the following situation. EVA 4000 with 3T disk space and one > oracle DB 1,2T on a different storage. On our EVA we must keep copy of > this DB with non stop applying of archive logs. In addition we need > 3-4 development DB's plus 3-4 test DB's which are copies of the > original 1,2T DB and are stored on the EVA. We are thinking about 2 > scenarios. 1) 8 clonings with keeping differences between the clonings > 2) to have 8 different DB made with zfs send/receive on the same > storage with deduplication switch ON. > > In both scenario we want the DB with applying logs to be with dedupe > switched off because of the performance issues. > > I have 20 Gigs of RAM and the DDT table is possible to be kept in it > with some tuning of sysctl. > > Which scenario would you recommend in terms of performance? I don't understand your requirement, so cannot give a recommendation. However, I've been playing with dedup for the past few weeks and so far I have mixed feelings about it. There are some stability issues (zfs bits keeps live-locking sometimes) and write-performance kinda sucks. Especially deleting larger sets of data (like snapshots or big files) takes ages, up to a point that makes SSH logins take a few minutes. Also, after a crash it takes very long to boot up again, maybe because it's rolling back some transactions or something... I have about 1.5 TB of data, dedup ratio is around 1.7. The machine only has 6 GB of RAM, and I've increased the metadata limit to 4 GB. However, I log actual arc-size periodically and very often it's nowhere near its limit... Oh yeah, and there's lzjb compression as well. This prob adds a bit of trouble, see compression thread from a few weeks ago. Johannes From owner-freebsd-fs@FreeBSD.ORG Mon Nov 7 20:40:09 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 2F1EB106564A for ; Mon, 7 Nov 2011 20:40:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1F71C8FC16 for ; Mon, 7 Nov 2011 20:40:09 +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 pA7Ke8UV010653 for ; Mon, 7 Nov 2011 20:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA7Ke8dF010652; Mon, 7 Nov 2011 20:40:08 GMT (envelope-from gnats) Date: Mon, 7 Nov 2011 20:40:08 GMT Message-Id: <201111072040.pA7Ke8dF010652@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Romain Garbage Cc: Subject: Re: kern/131441: [unionfs] [nullfs] unionfs and/or nullfs not combineable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Romain Garbage List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 20:40:09 -0000 The following reply was made to PR kern/131441; it has been noted by GNATS. From: Romain Garbage To: bug-followup@FreeBSD.org, freebsd@soulrebel.in-berlin.de Cc: Subject: Re: kern/131441: [unionfs] [nullfs] unionfs and/or nullfs not combineable Date: Mon, 7 Nov 2011 21:06:18 +0100 It seems that this is not only true for nullfs but also for ufs and zfs: # mkdir -p /tmp/testdir/{ufs,zfs} # mount /dev/ufs/test /tmp/testdir/ufs # zfs create -o mountpoint=/tmp/testdir/zfs pool/test # touch /tmp/testdir/zfs/testfile # touch /tmp/testdir/ufs/testfile # ls /tmp/testdir/ufs testfile # ls /tmp/testdir/zfs testfile # mkdir /tmp/testdir2 # mount_unionfs /tmp/testdir2 /tmp/testdir # ls /tmp/testdir/ufs # ls /tmp/testdir/zfs # Submounts are not accessible if a unionfs is mounted on a directory. Regards, Romain From owner-freebsd-fs@FreeBSD.ORG Tue Nov 8 01:10:01 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 3E5F0106564A for ; Tue, 8 Nov 2011 01:10:01 +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 EF01C8FC12 for ; Tue, 8 Nov 2011 01:10:00 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKSAuE6DaFvO/2dsb2JhbABDhHumAIFyAQEFI1YbDgoCAg0ZAlkGE64BkjGBMIIXhE6BFgSIC4wWkgo X-IronPort-AV: E=Sophos;i="4.69,473,1315195200"; d="scan'208";a="143026268" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 07 Nov 2011 20:09:59 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EBE67B3F0F; Mon, 7 Nov 2011 20:09:59 -0500 (EST) Date: Mon, 7 Nov 2011 20:09:59 -0500 (EST) From: Rick Macklem To: Robert Simmons Message-ID: <1275468075.1341984.1320714599943.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 - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: rpc.umntall error on boot 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, 08 Nov 2011 01:10:01 -0000 Robert Simmons wrote: > On Sun, Nov 6, 2011 at 7:44 PM, Rick Macklem > wrote: > > What happens is that /etc/rc.d/nfsclient is executed before > > /etc/rc.d/mountd. It finds /var/db/mountdtab non-empty and tries to > > get a port from rpcbind for mountd. Since mountd isn't running yet, > > so it fails. Since telling the server on the same machine to clear > > out /var/db/mountdtab for the client is basically meaningless, > > failing > > shouldn't be a problem. > > Would there be any drawbacks to moving /etc/rc.d/nfsclient to later in > the process so that mountd is already running? > I don't quite know how to do that. nfsclient can be set to require mountd to be done first, but most clients won't want mountd to be done at all. I think the only time this happens is when an NFS server has mounted file systems on itself. Although some do this (for testing?), I don't think this is a practical configuration for production use. As such, I don't see the message as an issue? rick From owner-freebsd-fs@FreeBSD.ORG Tue Nov 8 10:42:21 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 8DAC2106566C for ; Tue, 8 Nov 2011 10:42:21 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id CC6CB8FC1A for ; Tue, 8 Nov 2011 10:42:20 +0000 (UTC) Received: from higson.cam.lispworks.com (higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id pA8AVIFc046305; Tue, 8 Nov 2011 10:31:18 GMT (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id pA8AVFUP023386; Tue, 8 Nov 2011 10:31:15 GMT Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id pA8AVFg0023383; Tue, 8 Nov 2011 10:31:15 GMT Date: Tue, 8 Nov 2011 10:31:15 GMT Message-Id: <201111081031.pA8AVFg0023383@higson.cam.lispworks.com> From: Martin Simmons To: "Ronald F. Guilmette" In-reply-to: <60946.1320475599@tristatelogic.com> (rfg@tristatelogic.com) References: <60946.1320475599@tristatelogic.com> Cc: freebsd-fs@freebsd.org Subject: Re: write access to various times 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, 08 Nov 2011 10:42:21 -0000 >>>>> On Fri, 04 Nov 2011 23:46:39 -0700, Ronald F Guilmette said: > > I am concerned however because I personally > still know of no way whatsoever to set the value of the st_ctimespec field. > Is there any way to do that? No, the ctime can only be set to the current time by the kernel in response to other changes. __Martin From owner-freebsd-fs@FreeBSD.ORG Tue Nov 8 12:13:27 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 17F2D106564A; Tue, 8 Nov 2011 12:13:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF168FC16; Tue, 8 Nov 2011 12:13:25 +0000 (UTC) Received: by wwp14 with SMTP id 14so558991wwp.31 for ; Tue, 08 Nov 2011 04:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bVInmB15V5d/S/QFTdomLYJ4cUCoE4bV+Mv6bfmm850=; b=eqgwxZB/x6SLQTQynygVL0H+lCvlvTQlgrKlzSUZaoYVOY+/OFtrlGQFQwALYJrkYI RZfVmVMr5K10U3AnMRnkVlJQpXNRtOKdw4BEHC1w8SOdIBM7U5X0Jr5+fBEc7jftdv4T h6zSPBbIpem6i7kjvu+YiXf34aiK9a050HFTs= MIME-Version: 1.0 Received: by 10.227.198.140 with SMTP id eo12mr32596432wbb.20.1320754405096; Tue, 08 Nov 2011 04:13:25 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Tue, 8 Nov 2011 04:13:25 -0800 (PST) In-Reply-To: <201111081018.pA8AI7ha027020@svn.freebsd.org> References: <201111081018.pA8AI7ha027020@svn.freebsd.org> Date: Tue, 8 Nov 2011 13:13:25 +0100 X-Google-Sender-Auth: AeKyKV7w0IkfNv45encLOKw1atM Message-ID: From: Attilio Rao To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, FreeBSD FS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: svn commit: r227333 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/kern sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf 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, 08 Nov 2011 12:13:27 -0000 2011/11/8 Attilio Rao : > Author: attilio > Date: Tue Nov =C2=A08 10:18:07 2011 > New Revision: 227333 > URL: http://svn.freebsd.org/changeset/base/227333 > > Log: > =C2=A0Introduce the option VFS_ALLOW_NONMPSAFE and turn it on by default = on > =C2=A0all the architectures. > =C2=A0The option allows to mount non-MPSAFE filesystem. Without it, the > =C2=A0kernel will refuse to mount a non-MPSAFE filesytem. > > =C2=A0This patch is part of the effort of killing non-MPSAFE filesystems > =C2=A0from the tree. This is just a gentle reminder in order to point you further to the "official" page: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS and encourage once again people in adopting a dying FS if it really matters to them. So far, unfortunately, I didn't see a lot of activity in this area but I hope that this would change soon. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-fs@FreeBSD.ORG Tue Nov 8 19:19:07 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 C89F3106566B for ; Tue, 8 Nov 2011 19:19:07 +0000 (UTC) (envelope-from skirge84@o2.pl) Received: from tur.go2.pl (tur.go2.pl [193.17.41.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2FA8FC0C for ; Tue, 8 Nov 2011 19:19:07 +0000 (UTC) Received: from moh2-ve2.go2.pl (moh2-ve2.go2.pl [193.17.41.200]) by tur.go2.pl (Postfix) with ESMTP id 4EABA231480 for ; Tue, 8 Nov 2011 20:02:20 +0100 (CET) Received: from moh2-ve2.go2.pl (unknown [10.0.0.200]) by moh2-ve2.go2.pl (Postfix) with ESMTP id 1968DDA4012 for ; Tue, 8 Nov 2011 20:02:16 +0100 (CET) Received: from unknown (unknown [10.0.0.142]) by moh2-ve2.go2.pl (Postfix) with SMTP for ; Tue, 8 Nov 2011 20:02:15 +0100 (CET) Received: from mail-bw0-f54.google.com [209.85.214.54] by poczta.o2.pl with ESMTP id jCCbtY; Tue, 08 Nov 2011 20:02:14 +0100 Received: by bkbzs8 with SMTP id zs8so990983bkb.13 for ; Tue, 08 Nov 2011 11:02:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.174.106 with SMTP id br10mr10339535obc.40.1320778933149; Tue, 08 Nov 2011 11:02:13 -0800 (PST) Received: by 10.182.111.4 with HTTP; Tue, 8 Nov 2011 11:02:13 -0800 (PST) Date: Tue, 8 Nov 2011 20:02:13 +0100 Message-ID: From: Sebastian Chmielewski To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org X-O2-Trust: 2, 66 X-O2-SPF: neutral Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ZFS: invalid zap_type=134218628 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, 08 Nov 2011 19:19:07 -0000 I've got following error after upgrading my 9.0-RC1 to RC2 using source and got this error at loader prompt: ZFS: invalid zap_type=134218628 when I tried zfsboottest from 9.0-STABLE it failed ./zfsboottest /boot/kernel/kernel /dev/ada0p4 returns pool status correctly but ends with the same message zfsboottest from 10.0-CURRENT returns pool status, zfsboottest.sh zroot printed OK message at the end (very useful zfsboottest.sh wasn't yet merged from current to stable). I've installed gptzfsboot, zfsloader, loader from -CURRENT and it boots fine. I'm running ZFS on GPT partitions, zfs version 28 with dedup on. File system can be successfully mount using FreeBSD memstick. I think that patches for boot should be merged to 9.0-RELEASE otherwise users may have the same problems I had. best regards, From owner-freebsd-fs@FreeBSD.ORG Tue Nov 8 20:16: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 92E52106566B for ; Tue, 8 Nov 2011 20:16:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DFB9A8FC13 for ; Tue, 8 Nov 2011 20:16:08 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA27919; Tue, 08 Nov 2011 22:16:06 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RNs5W-0008Kt-29; Tue, 08 Nov 2011 22:16:06 +0200 Message-ID: <4EB98E05.4070900@FreeBSD.org> Date: Tue, 08 Nov 2011 22:16:05 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Florian Wagner References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> In-Reply-To: <20111019182130.27446750@naclador.mos32.de> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config 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, 08 Nov 2011 20:16:09 -0000 on 19/10/2011 19:21 Florian Wagner said the following: >> [...] >> >>> The only thing I was a bit confused by is that on the boot prompt only >>> the pool and filename to be booted are printed. >> >> Do you mean the (gpt)zfsboot prompt? > > Yes. For a boot.config with "rpool:root/something:" it prints: > > Booting from Hard Disk... /boot.config: rpool FreeBSD/x86 boot Default: > rpool:/boot/zfsloader boot: Thank you very much for your testing and reports! Please see these additional changes: http://people.freebsd.org/~avg/zfsboot.fixes.diff -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Nov 9 11:12:01 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 22DC31065686 for ; Wed, 9 Nov 2011 11:12:01 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (yamagi.overkill.yamagi.org [178.63.70.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE588FC18 for ; Wed, 9 Nov 2011 11:11:53 +0000 (UTC) Received: from happy.home.yamagi.org (unknown [IPv6:2001:5c0:150f:8700:16da:e9ff:fe0f:8071]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.overkill.yamagi.org (Postfix) with ESMTPSA id 80FC61666333 for ; Wed, 9 Nov 2011 09:47:51 +0100 (CET) Date: Wed, 9 Nov 2011 09:47:44 +0100 From: Yamagi Burmeister To: freebsd-fs@freebsd.org Message-Id: <20111109094744.f7f11220.lists@yamagi.org> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__9_Nov_2011_09_47_44_+0100_2O.Gub+MXpHyCqtb" Subject: Panic with SU+J and snapshots on RELENG_9 from november 7 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, 09 Nov 2011 11:12:01 -0000 --Signature=_Wed__9_Nov_2011_09_47_44_+0100_2O.Gub+MXpHyCqtb Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, on RELENG_9 built at november 7 it's easy to panic the box by creating snapshots on an SU+J enabled UFS2 file system when there's some load=20 on the filesystem.=20 ---- To reproduce: % mount /dev/ada0p2 on / (ufs, local, journaled soft-updates) # create some load % cp -r /usr/src /tmp # Switch to another tty and create a snapshot % mksnap_ffs / /.snap/foo1 Repeat this until the box crashes. ---- Some information: root@vbox:pts/0 /crash> kgdb /boot/kernel/kernel vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: snapacct_ufs2: bad block cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 snapacct_ufs2() at snapacct_ufs2+0x14c indiracct_ufs2() at indiracct_ufs2+0x2d5 indiracct_ufs2() at indiracct_ufs2+0x28a expunge_ufs2() at expunge_ufs2+0x361 ffs_snapshot() at ffs_snapshot+0xe78 ffs_mount() at ffs_mount+0xa24 vfs_donmount() at vfs_donmount+0xddc sys_nmount() at sys_nmount+0x63 amd64_syscall() at amd64_syscall+0x3ac Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (378, FreeBSD ELF64, sys_nmount), rip =3D 0x8008a1ecc, rsp =3D 0x7fffffffd398, rbp =3D 0x7fffffffddf5 --- KDB: enter: panic Dumping 211 out of 2027 MB:..8%..16%..23%..31%..46%..53%..61%..76%..84%..91% Reading symbols from /boot/kernel/vesa.ko...Reading symbols from /boot/kernel/vesa.ko.symbols...done. done. Loaded symbols for /boot/kernel/vesa.ko #0 doadump (textdump=3D2077113264) at /usr/src/sys/kern/kern_shutdown.c:260 260 if (textdump && textdump_pending) { (kgdb) bt #0 doadump (textdump=3D2077113264) at /usr/src/sys/kern/kern_shutdown.c:260 #1 0xffffffff802f95ec in db_fncall (dummy1=3DVariable "dummy1" is not avai= lable. ) at /usr/src/sys/ddb/db_command.c:572 #2 0xffffffff802f9921 in db_command (last_cmdp=3D0xffffffff810ec5c0, cmd_t= able=3DVariable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:448 #3 0xffffffff802f9b70 in db_command_loop () at /usr/src/sys/ddb/db_command= .c:501 #4 0xffffffff802fbcc9 in db_trap (type=3DVariable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff8085b6f1 in kdb_trap (type=3D3, code=3D0, tf=3D0xffffff807bce= 3de0) at /usr/src/sys/kern/subr_kdb.c:620 #6 0xffffffff80b0e756 in trap (frame=3D0xffffff807bce3de0) at /usr/src/sys= /amd64/amd64/trap.c:590 #7 0xffffffff80af8bef in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:228 #8 0xffffffff8085b49b in kdb_enter (why=3D0xffffffff80d2695b "panic", msg= =3D0x80
) at cpufunc.h:63 #9 0xffffffff80825f20 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:599 #10 0xffffffff80a3785c in snapacct_ufs2 (vp=3DVariable "vp" is not availabl= e. ) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1499 #11 0xffffffff80a37025 in indiracct_ufs2 (snapvp=3D0xfffffe0065a36780, canc= elvp=3D0xfffffe0002930000, level=3D0, blkno=3DVariable "blkno" is not avail= able. ) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1414 #12 0xffffffff80a36fda in indiracct_ufs2 (snapvp=3D0xfffffe0065a36780, canc= elvp=3D0xfffffe0002930000, level=3D0, blkno=3DVariable "blkno" is not avail= able. ) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1424 #13 0xffffffff80a37c41 in expunge_ufs2 (snapvp=3D0xfffffe0065a36780, cancel= ip=3D0xfffffe000292adc8, fs=3D0xfffffe00028a9000,=20 acctfunc=3D0xffffffff80a37710 , expungetype=3D2, clearmode=3DVariable "clearmode" is not available. ) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1346 #14 0xffffffff80a3a6e8 in ffs_snapshot (mp=3D0xfffffe000289dc00, snapfile= =3DVariable "snapfile" is not available. ) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:712 #15 0xffffffff80a55784 in ffs_mount (mp=3D0xfffffe000289dc00) at /usr/src/s= ys/ufs/ffs/ffs_vfsops.c:474 #16 0xffffffff808b89bc in vfs_donmount (td=3DVariable "td" is not available. ) at /usr/src/sys/kern/vfs_mount.c:925 #17 0xffffffff808b9223 in sys_nmount (td=3D0xfffffe0002c22000, uap=3D0xffff= ff807bce4bc0) at /usr/src/sys/kern/vfs_mount.c:410 #18 0xffffffff80b0dacc in amd64_syscall (td=3D0xfffffe0002c22000, traced=3D= 0) at subr_syscall.c:131 #19 0xffffffff80af8ed7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:387 #20 0x00000008008a1ecc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 10 #10 0xffffffff80a3785c in snapacct_ufs2 (vp=3DVariable "vp" is not availabl= e. ) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1499 1499 panic("snapacct_ufs2: bad block"); (kgdb) list 1494 if (expungetype =3D=3D BLK_SNAP && *blkp =3D=3D BLK_NOCOPY) { 1495 if (lbn >=3D NDADDR) 1496 brelse(ibp); 1497 } else { 1498 if (*blkp !=3D 0) 1499 panic("snapacct_ufs2: bad block"); 1500 *blkp =3D expungetype; 1501 if (lbn >=3D NDADDR) 1502 bdwrite(ibp); 1503 } ---- A screenshot of the panic can be found here: http://deponie.yamagi.org/freebsd/snapshots_panic/panic2.png I still have the core so further information can be provided, if necessary. Thanks, Yamagi --=20 Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Signature=_Wed__9_Nov_2011_09_47_44_+0100_2O.Gub+MXpHyCqtb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk66PjUACgkQWTjlg++8y8v9wgCeOW5r9s76XerKaHDsUHsZjXRn M0oAn28eOpKVWD4BLCuQ5XpZO8sNcqLp =dFWi -----END PGP SIGNATURE----- --Signature=_Wed__9_Nov_2011_09_47_44_+0100_2O.Gub+MXpHyCqtb-- From owner-freebsd-fs@FreeBSD.ORG Wed Nov 9 14:20:21 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 2A3F4106567A for ; Wed, 9 Nov 2011 14:20:21 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id A908E8FC21 for ; Wed, 9 Nov 2011 14:20:20 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RO90l-0002nb-7A for freebsd-fs@freebsd.org; Wed, 09 Nov 2011 15:20:19 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Nov 2011 15:20:19 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Nov 2011 15:20:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Wed, 09 Nov 2011 15:20:05 +0100 Lines: 50 Message-ID: References: <1558351773.1229453.1320542285788.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig35D83D6A50AA795B73594029" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111004 Thunderbird/7.0.1 In-Reply-To: <1558351773.1229453.1320542285788.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.1.2 Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 09 Nov 2011 14:20:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig35D83D6A50AA795B73594029 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/11/2011 02:18, Rick Macklem wrote: > Hi, >=20 > Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > for the new NFS server. >=20 > I don't think I had spotted this before, but when I looked I > saw that, when vfs.nfsrv.async is set non-zero in the old server, > it returns FILESYNC (which means the write has been committed to > non-volatile storage) even when it hasn't actually done that. Do I understand this correctly: the server normally (for async=3D0) does = a fsync after any writes and returns FILESYNC status to the client? This seems too extreme... doesn't NFSv4 have its own fsync()-like RPC that does that manually? If it does, then I don't think there are any differences between doing a write() on a local file system with e.g. soft-updates enabled and doing a write on a NFS file system - in both cases, no data is even remotely guaranteed to survive a crash unless a fsync (or equivalent operation) was issued. On 06/11/2011 17:25, Josh Paetzel wrote: > In 8.x, setting the async sysctl was the difference between 80-100MB/se= c > and 800 MB/sec (Yes, MegaBytes!) using a variety of different clients, Yup, this is in any case too big not to add the async mode. --------------enig35D83D6A50AA795B73594029 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk66jBUACgkQldnAQVacBchbtwCgk7wbUqaY08vOSwU+OYYvWuqr XtMAoJWCJgg2AkWcrrQ8TyEpHt1JAR99 =LcwZ -----END PGP SIGNATURE----- --------------enig35D83D6A50AA795B73594029-- From owner-freebsd-fs@FreeBSD.ORG Wed Nov 9 15:48:28 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 4B4EE106566B for ; Wed, 9 Nov 2011 15:48:28 +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 E7FEC8FC24 for ; Wed, 9 Nov 2011 15:48:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EACuguk6DaFvO/2dsb2JhbABChH2jAYMlgXIBAQQBI1YFFg4KAgINGQJZBogVpV2SQYEwhzmBFgSIDIwZkhA X-IronPort-AV: E=Sophos;i="4.69,484,1315195200"; d="scan'208";a="143272235" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 09 Nov 2011 10:48:26 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E4325B409C; Wed, 9 Nov 2011 10:48:26 -0500 (EST) Date: Wed, 9 Nov 2011 10:48:26 -0500 (EST) From: Rick Macklem To: Ivan Voras Message-ID: <253830504.1455813.1320853706898.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 - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 09 Nov 2011 15:48:28 -0000 Ivan Voras wrote: > On 06/11/2011 02:18, Rick Macklem wrote: > > Hi, > > > > Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > > for the new NFS server. > > > > I don't think I had spotted this before, but when I looked I > > saw that, when vfs.nfsrv.async is set non-zero in the old server, > > it returns FILESYNC (which means the write has been committed to > > non-volatile storage) even when it hasn't actually done that. > > Do I understand this correctly: the server normally (for async=0) does > a > fsync after any writes and returns FILESYNC status to the client? > No, the server only does an "fsync" if the client specifies FILESYNC. In normal (async==0) writes are done UNSTABLE (which means the server has the data but has not yet committed it to stable storage like a disk), unless the client specifies FILESYNC. The server then replies UNSTABLE to the client, so the client knows that it must keep the modified data in its cache until it does a Commit RPC. When async!=0, the only difference is that the server lies and replies FILESYNC, even though it hasn't done that. > This seems too extreme... doesn't NFSv4 have its own fsync()-like RPC > that does that manually? If it does, then I don't think there are any > differences between doing a write() on a local file system with e.g. > soft-updates enabled and doing a write on a NFS file system - in both > cases, no data is even remotely guaranteed to survive a crash unless a > fsync (or equivalent operation) was issued. > The handling of writes is essentially the same for NFSv3 and NFSv4. The client requests writes be either FILESYNC (everything committed to stable storage before the server replies) or UNSTABLE (where the data is only cached in the server and could be lost if the server crashes). For the UNSTABLE case, the client must do a subsequent Commit RPC (which can cover all UNSTABLE writes for a file and is essentially an fsync) before assuming the data is safely stored in the server. (NFSv4.1 adds the optional capability of pNFS, where the client can do I/O against a separate Data Server, but we aren't there yet.) The trouble with "async!=0" is that a Commit RPC may never happen, since the server has lied and told the client it doesn't need to do one. Most servers will commit changes to stable storage sooner or later, but there is no guarantee that is the case. > On 06/11/2011 17:25, Josh Paetzel wrote: > > In 8.x, setting the async sysctl was the difference between > > 80-100MB/sec > > and 800 MB/sec (Yes, MegaBytes!) using a variety of different > > clients, > > Yup, this is in any case too big not to add the async mode. Ok, I understand this as a vote for committing it. If that isn't the case, please email again, clarifying it. Thanks, rick From owner-freebsd-fs@FreeBSD.ORG Wed Nov 9 16:09: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 AC5F7106566C; Wed, 9 Nov 2011 16:09:29 +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 555268FC08; Wed, 9 Nov 2011 16:09:28 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EADyluk6DaFvO/2dsb2JhbABChH2mJoFyAQYjBFIbDgwCDRkCWQata5JBgTCHOYEWBIgMjBmSEA X-IronPort-AV: E=Sophos;i="4.69,484,1315195200"; d="scan'208";a="144795374" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 09 Nov 2011 11:09:28 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3DFEBB3FD0; Wed, 9 Nov 2011 11:09:28 -0500 (EST) Date: Wed, 9 Nov 2011 11:09:28 -0500 (EST) From: Rick Macklem To: Ivan Voras Message-ID: <364937844.1458624.1320854968216.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 - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 09 Nov 2011 16:09:29 -0000 Ivan Voras wrote: [good stuff snipped for brevity] > > This seems too extreme... doesn't NFSv4 have its own fsync()-like RPC > that does that manually? If it does, then I don't think there are any > differences between doing a write() on a local file system with e.g. > soft-updates enabled and doing a write on a NFS file system - in both > cases, no data is even remotely guaranteed to survive a crash unless a > fsync (or equivalent operation) was issued. > I think you have to be a bit careful when an assumption about loss of data after a crash is applied to a file server. If a client crashes, everyone pretty much assumes that recently written data might have been lost (in a Unix-like world, at least) and the crash is visible to users. However, take the following scenario: - User on desktop client edits a document for an hour, then saves it. --> NFS server crashes/reboots just after the "save". - User on desktop client goes off reading email for an hour, using a mail system not affected by the NFS server crash/reboot. - User goes back to document and finds an old damaged document file. --> User is very upset... My point is that a user on a client may not even realize the server crashed/rebooted. The above case can happen if async!=0, but not if async==0. rick From owner-freebsd-fs@FreeBSD.ORG Thu Nov 10 05:27: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 C59B4106564A for ; Thu, 10 Nov 2011 05:27:19 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) by mx1.freebsd.org (Postfix) with ESMTP id A5F608FC15 for ; Thu, 10 Nov 2011 05:27:19 +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 pAA5RGOQ055907; Wed, 9 Nov 2011 21:27:16 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201111100527.pAA5RGOQ055907@chez.mckusick.com> To: mdf@freebsd.org In-reply-to: Date: Wed, 09 Nov 2011 21:27:16 -0800 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 Subject: Re: write access to various times 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, 10 Nov 2011 05:27:19 -0000 I am the one that added birthtime and the text that you quote on how to set it. I deliberately did not add a new system call to add all three (atime, mtime, and birthtime) because programs using the new system call would not compile/run on any system other than FreeBSD. Those that followed the admittedly cumbersome double system call would compile/run on all systems and those with birthtime would get it set correctly. UNIX has never allowed the ctime to be set because backup utilities such as dump depend on it being correct. A file loaded onto the system today needs to be dumped at the next backup even if its atime, mtime, and birthtime all claim that it has been around for years. If ctime could be set, none of the backup systems would be reliable. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Thu Nov 10 12:17: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 492311065670 for ; Thu, 10 Nov 2011 12:17:03 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 07C0F8FC16 for ; Thu, 10 Nov 2011 12:17:02 +0000 (UTC) Received: by ggnk3 with SMTP id k3so4091083ggn.13 for ; Thu, 10 Nov 2011 04:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=aKEnAalb+1MPgR7/Yo93iUZcyh23rViAP3PW5Aes5Rs=; b=NLlU85J8nZo81dRZanCIoXWozZZ+ZA/DTIlNIiudkFZ5pIrUGSaM4eOqp8YuddPwoy YhqCwPTu7E4EYAWKtCmjb/1lcq/Koys23agNphEy9TSBAJLKCVAU6Ro9wI+ZX+fUhCI0 LqkM2uoSwdzdxvy2TMO/4nMwZ9Ww3Uo3nvVHE= Received: by 10.101.37.14 with SMTP id p14mr3190186anj.111.1320927422121; Thu, 10 Nov 2011 04:17:02 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.214.13 with HTTP; Thu, 10 Nov 2011 04:16:21 -0800 (PST) In-Reply-To: <364937844.1458624.1320854968216.JavaMail.root@erie.cs.uoguelph.ca> References: <364937844.1458624.1320854968216.JavaMail.root@erie.cs.uoguelph.ca> From: Ivan Voras Date: Thu, 10 Nov 2011 13:16:21 +0100 X-Google-Sender-Auth: 5QOTENtMiX-fPCTevUMFeZl5eGU Message-ID: To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 10 Nov 2011 12:17:03 -0000 On 9 November 2011 17:09, Rick Macklem wrote: > Ivan Voras wrote: > [good stuff snipped for brevity] >> >> This seems too extreme... doesn't NFSv4 have its own fsync()-like RPC >> that does that manually? If it does, then I don't think there are any >> differences between doing a write() on a local file system with e.g. >> soft-updates enabled and doing a write on a NFS file system - in both >> cases, no data is even remotely guaranteed to survive a crash unless a >> fsync (or equivalent operation) was issued. >> > I think you have to be a bit careful when an assumption about loss of > data after a crash is applied to a file server. If a client crashes, > everyone pretty much assumes that recently written data might have been > lost (in a Unix-like world, at least) and the crash is visible to users. > > However, take the following scenario: > - User on desktop client edits a document for an hour, then saves it. > =C2=A0--> NFS server crashes/reboots just after the "save". > - User on desktop client goes off reading email for an hour, using a > =C2=A0mail system not affected by the NFS server crash/reboot. > - User goes back to document and finds an old damaged document file. > =C2=A0--> User is very upset... > > My point is that a user on a client may not even realize the server > crashed/rebooted. The above case can happen if async!=3D0, but not if > async=3D=3D0. Thank you for the excellent explanation! I see the problem but I think it is still well within the judgement call of the system administrator. It should probably not be the default (though I recall from some benchmarks way back that it might be the default on Linux) but it should definitely exist as an option. Thanks again! From owner-freebsd-fs@FreeBSD.ORG Thu Nov 10 12:32:32 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52A161065670 for ; Thu, 10 Nov 2011 12:32:32 +0000 (UTC) (envelope-from Lee@dilkie.com) Received: from spock.dilkie.com (spock.dilkie.com [142.46.160.214]) by mx1.freebsd.org (Postfix) with ESMTP id CA7258FC15 for ; Thu, 10 Nov 2011 12:32:31 +0000 (UTC) Received: from [IPv6:2001:470:8900:0:b094:230f:4a04:ac56] ([IPv6:2001:470:8900:0:b094:230f:4a04:ac56]) (authenticated bits=0) by spock.dilkie.com (8.14.5/8.14.5) with ESMTP id pAACJPHI002741 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 Nov 2011 07:19:25 -0500 (EST) (envelope-from Lee@dilkie.com) X-DKIM: Sendmail DKIM Filter v2.8.3 spock.dilkie.com pAACJPHI002741 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dilkie.com; s=mail; t=1320927565; bh=FFwNusHENO/lp7iyAxNBN38ir/qzUgGfR4vLC+CtU60=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=nNqosYoR/YhDB7SMWSE/Fnk8yvDeMhD4H0XdBF+hSrSeOjHUJvp5ERAL4gbE362ZQ 2tfhvwjWKME7hkUrD3bVTtSnCLEhB9pZn2hZ9nFjHIZezwhgkNejCZFNlO3PMiT Message-ID: <4EBBC14E.8010200@dilkie.com> Date: Thu, 10 Nov 2011 07:19:26 -0500 From: Lee Dilkie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: "fs@freebsd.org" X-Scanned-By: MIMEDefang 2.72 on IPv6:2001:470:8900::40 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: GEOM_CONCAT log on boot 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, 10 Nov 2011 12:32:32 -0000 Hi, I just created a gconcat of a gmirror ( only one drive involved here, more to add later ) and it seems to be working fine except I see the following log in /var/messages when I boot up. Nov 10 06:23:55 spock kernel: ad10: 76319MB at ata5-master SATA150 Nov 10 06:23:55 spock kernel: GEOM_MIRROR: Device mirror/gm10 launched (1/1). Nov 10 06:23:55 spock kernel: GEOM_CONCAT: Device gc10 created (id=252087182). Nov 10 06:23:55 spock kernel: GEOM_CONCAT: Disk mirror/gm10 attached to gc10. Nov 10 06:23:55 spock kernel: GEOM_CONCAT: Device gc10 activated. *Nov 10 06:23:55 spock kernel: GEOM_CONCAT: Cannot add disk ufsid/4ebb0c7b223ec4fe to gc10 (error=17)*. I had done a glabel of the drive before I added it to the gmirror (don't know if that's necessary as gmirror seems to find drives even if they move). $ glabel list Geom name: ad4 Providers: 1. Name: label/4T-1 Mediasize: 4000787029504 (3.7T) Sectorsize: 512 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 7814037167 length: 4000787029504 index: 0 Consumers: 1. Name: ad4 Mediasize: 4000787030016 (3.7T) Sectorsize: 512 Mode: r1w1e2 $ gmirror list Geom name: gm10 State: COMPLETE Components: 1 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 1244094028 Providers: 1. Name: mirror/gm10 Mediasize: 4000787028992 (3.7T) Sectorsize: 512 Mode: r1w1e2 Consumers: 1. Name: label/4T-1 Mediasize: 4000787029504 (3.7T) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY, HARDCODED GenID: 0 SyncID: 1 ID: 3404476183 $ gconcat list Geom name: gc10 State: UP Status: Total=1, Online=1 Type: AUTOMATIC ID: 252087182 Providers: 1. Name: concat/gc10 Mediasize: 4000787028480 (3.7T) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: mirror/gm10 Mediasize: 4000787028992 (3.7T) Sectorsize: 512 Mode: r1w1e2 Start: 0 End: 4000787028480 $ uname -a FreeBSD spock.dilkie.com 7.4-STABLE FreeBSD 7.4-STABLE #0: Mon Sep 12 09:20:00 EDT 2011 root@spock.dilkie.com:/usr/obj/usr/src/sys/SPOCK i386 $ ll /dev/ufsid/ total 1 dr-xr-xr-x 2 root wheel - 512 Nov 10 06:23 ./ dr-xr-xr-x 8 root wheel - 512 Nov 10 01:23 ../ there is, indeed, no ufsid to match.. none at all in fact. so the question is. Can this log be ignored or have I done something wrong. Oh, when I created my array, I use the raw disks, no bsdlabel or slices or anything. TIA, -lee From owner-freebsd-fs@FreeBSD.ORG Thu Nov 10 15:05:36 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 389361065670; Thu, 10 Nov 2011 15:05:36 +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 CB8938FC12; Thu, 10 Nov 2011 15:05:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAHnnu06DaFvO/2dsb2JhbABEhH2mLoFyAQEFIwRSGw4KAgINGQJZBhOuH5ISgTCHOIEWBIgPjBmSEw X-IronPort-AV: E=Sophos;i="4.69,489,1315195200"; d="scan'208";a="144943941" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 10 Nov 2011 10:05:34 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A218EB3F6F; Thu, 10 Nov 2011 10:05:34 -0500 (EST) Date: Thu, 10 Nov 2011 10:05:34 -0500 (EST) From: Rick Macklem To: Ivan Voras Message-ID: <989957230.1531261.1320937534611.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? 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, 10 Nov 2011 15:05:36 -0000 Ivan Voras wrote: > On 9 November 2011 17:09, Rick Macklem wrote: > > Ivan Voras wrote: > > [good stuff snipped for brevity] > >> > >> This seems too extreme... doesn't NFSv4 have its own fsync()-like > >> RPC > >> that does that manually? If it does, then I don't think there are > >> any > >> differences between doing a write() on a local file system with > >> e.g. > >> soft-updates enabled and doing a write on a NFS file system - in > >> both > >> cases, no data is even remotely guaranteed to survive a crash > >> unless a > >> fsync (or equivalent operation) was issued. > >> > > I think you have to be a bit careful when an assumption about loss > > of > > data after a crash is applied to a file server. If a client crashes, > > everyone pretty much assumes that recently written data might have > > been > > lost (in a Unix-like world, at least) and the crash is visible to > > users. > > > > However, take the following scenario: > > - User on desktop client edits a document for an hour, then saves > > it. > > =C2=A0--> NFS server crashes/reboots just after the "save". > > - User on desktop client goes off reading email for an hour, using a > > =C2=A0mail system not affected by the NFS server crash/reboot. > > - User goes back to document and finds an old damaged document file. > > =C2=A0--> User is very upset... > > > > My point is that a user on a client may not even realize the server > > crashed/rebooted. The above case can happen if async!=3D0, but not if > > async=3D=3D0. >=20 > Thank you for the excellent explanation! I see the problem but I think > it is still well within the judgement call of the system > administrator. It should probably not be the default (though I recall > from some benchmarks way back that it might be the default on Linux) > but it should definitely exist as an option. >=20 Yes, agreed. I think the trick is making sure the sysadmins understand what the option does, so they can make the call. Unless others jump up and say otherwise, I'll probably commit the patch to head once I here from Josh that it works. Have fun with it, rick From owner-freebsd-fs@FreeBSD.ORG Fri Nov 11 10:52:01 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 A5B6A1065673; Fri, 11 Nov 2011 10:52:01 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5AC098FC08; Fri, 11 Nov 2011 10:52:01 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id D94EF555; Fri, 11 Nov 2011 11:51:58 +0100 (CET) Date: Fri, 11 Nov 2011 11:51:08 +0100 From: Pawel Jakub Dawidek To: Sebastian Chmielewski Message-ID: <20111111105107.GB1659@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS: invalid zap_type=134218628 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 10:52:01 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 08, 2011 at 08:02:13PM +0100, Sebastian Chmielewski wrote: > I've got following error after upgrading my 9.0-RC1 to RC2 using source a= nd > got this error at loader prompt: >=20 > ZFS: invalid zap_type=3D134218628 >=20 > when I tried zfsboottest from 9.0-STABLE it failed > ./zfsboottest /boot/kernel/kernel /dev/ada0p4 > returns pool status correctly but ends with the same message >=20 > zfsboottest from 10.0-CURRENT returns pool status, zfsboottest.sh zroot > printed OK message at the end > (very useful zfsboottest.sh wasn't yet merged from current to stable). > I've installed gptzfsboot, zfsloader, loader from -CURRENT and it boots > fine. >=20 > I'm running ZFS on GPT partitions, zfs version 28 with dedup on. > File system can be successfully mount using FreeBSD memstick. >=20 > I think that patches for boot should be merged to 9.0-RELEASE otherwise > users may have the same problems I had. Yes, I plan to include those fixes in 9.0-RELEASE. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk68/hsACgkQForvXbEpPzRerACgzYix0ViD+VoWafOPlMLb3FKE Bi4An35Q88RKGkStQDmH+ddtqsrgo7tu =Bd9Y -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-fs@FreeBSD.ORG Fri Nov 11 14:31: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 405E3106566B; Fri, 11 Nov 2011 14:31:43 +0000 (UTC) (envelope-from kickbsd@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [IPv6:2a02:6b8:0:801::5]) by mx1.freebsd.org (Postfix) with ESMTP id B33968FC12; Fri, 11 Nov 2011 14:31:42 +0000 (UTC) Received: from web148.yandex.ru (web148.yandex.ru [95.108.131.163]) by forward15.mail.yandex.net (Yandex) with ESMTP id 2C4609E4174; Fri, 11 Nov 2011 18:31:41 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321021901; bh=LLNR6BAZ63aLsUrcMg7HEz3H/oQcY12fIB3+20QD6KU=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=aPjdx5hsq7dpC2XrhIg3X6tLjy8zg4MXmm5N9qADhR9RjwrAsSO5F6a8Q5JPRUwoW X2vTzyrQo3OvImZDjignLYEtQhxjYM63A5BQ8Vp6BbmGuGzZ0sJ6ZNLeH6vuD2JHGR Mgp4aU+6Rr3c5q5q36RHSz21n5R6te3eiQ7PctXs= Received: from localhost (localhost.localdomain [127.0.0.1]) by web148.yandex.ru (Yandex) with ESMTP id F300329D8073; Fri, 11 Nov 2011 18:31:40 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321021901; bh=LLNR6BAZ63aLsUrcMg7HEz3H/oQcY12fIB3+20QD6KU=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=aPjdx5hsq7dpC2XrhIg3X6tLjy8zg4MXmm5N9qADhR9RjwrAsSO5F6a8Q5JPRUwoW X2vTzyrQo3OvImZDjignLYEtQhxjYM63A5BQ8Vp6BbmGuGzZ0sJ6ZNLeH6vuD2JHGR Mgp4aU+6Rr3c5q5q36RHSz21n5R6te3eiQ7PctXs= X-Yandex-Spam: 1 Received: from leo.de.teleglobe.net (leo.de.teleglobe.net [64.86.53.146]) by web148.yandex.ru with HTTP; Fri, 11 Nov 2011 18:31:40 +0400 From: Darren Baginski To: freebsd-fs@freebsd.org,freebsd-current@freebsd.org MIME-Version: 1.0 Message-Id: <598941321021900@web148.yandex.ru> Date: Fri, 11 Nov 2011 18:31:40 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: Subject: Unable to boot from zfsroot 9.0-RC2 (while 9.0-RC1 boots fine) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 14:31:43 -0000 Hi! I'm having troubles booting today's 9.0-RC2 from zfsroot, I'm getting 'unknown filesystem' error. But 9.0-RC1 from Tue Nov 8 2011 boots fine. Here is output with 9.0-RC1 kernel: # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zroot 5.97G 2.85G 3.11G 47% 1.00x ONLINE - # zfs list NAME USED AVAIL REFER MOUNTPOINT zroot 2.85G 3.02G 2.85G legacy # cat /boot/loader.conf zfs_load="YES" vfs.root.mountfrom="zfs:zroot" Originally that box with installed with FreeBSD 8.x, but continuously updated up to today's version, so : VER FILESYSTEM --- ------------ 4 zroot VER POOL --- ------------ 15 zroot Any suggestions ? What could be the problem? From owner-freebsd-fs@FreeBSD.ORG Fri Nov 11 16:36: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 E4B291065674 for ; Fri, 11 Nov 2011 16:36:47 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id A28068FC08 for ; Fri, 11 Nov 2011 16:36:47 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1ROu5u-0003u3-B6 for freebsd-fs@freebsd.org; Fri, 11 Nov 2011 17:36:46 +0100 Received: from dyn1240-121.vpn.ic.ac.uk ([129.31.240.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Nov 2011 17:36:46 +0100 Received: from jtotz by dyn1240-121.vpn.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Nov 2011 17:36:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Fri, 11 Nov 2011 16:36:29 +0000 Lines: 32 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dyn1240-121.vpn.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 Subject: backing up zfs dataset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 16:36:48 -0000 Hi, To back up a zfs dataset there are a few possibilities: 1) rsync file data to another machine 2) zfs-send to another machine, into a zfs dataset 3) zfs-send to another machine, dumping the stream to a file The first one works alright but you loose admin info, properties set on the dataset, etc The second is prefered but requires another machine which runs zfs. The third is bad. So far I have been doing (3), for daily short-term backups, works, tested, everything is peachy. However, I dont like it anymore for obvious reasons. Ideally, I would like to go with (2). But I dont have another zfs-capable machine, or the machine that I would like to backup onto will not ever run zfs. So I came up with another crazy idea, assuming the remote machine exports a block device (somehow): 4) zpool-attach the remote block dev as a mirror, let it resilver, offline it during the day, at night online it, resilver, and so on 5) create a pool on the block dev locally on the to-be-backed-up-machine and periodically zfs-send stuff over I would go for (4), it seems to be the mostly automatic. Any thoughts on this? Should I expect things to go titsup if there's network issues? Johannes From owner-freebsd-fs@FreeBSD.ORG Fri Nov 11 18:34: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 DE67A106566B for ; Fri, 11 Nov 2011 18:34:31 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5D38FC17 for ; Fri, 11 Nov 2011 18:34:31 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2oX8drk23mtcml51sKj X-RZG-CLASS-ID: mo05 Received: from [192.168.179.42] (hmbg-5f7617ab.pool.mediaWays.net [95.118.23.171]) by smtp.strato.de (cohen mo1) (RZmta 26.10 AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e03c27nABGTNPH for ; Fri, 11 Nov 2011 19:34:25 +0100 (MET) Message-ID: <4EBD6AAF.5020401@brockmann-consult.de> Date: Fri, 11 Nov 2011 19:34:23 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <598941321021900@web148.yandex.ru> In-Reply-To: <598941321021900@web148.yandex.ru> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Unable to boot from zfsroot 9.0-RC2 (while 9.0-RC1 boots fine) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 18:34:31 -0000 Darren, Did you try the normal procedure, or is it something specific to version 9? *normal procedure:* From a boot cd, do something like this: import, and if it fails, go ahead and use -f # zpool import -o altroot=/z -o cachefile=/tmp/zpool.cache zroot # zfs set mountpoint=/ zroot # cp /tmp/zpool.cache /z/boot/zfs/zpool.cache Optionally here you set mountpoint back to legacy (which is what you showed in your message). # zfs umount -a zroot # zfs set mountpoint=legacy zroot (As you can see I have not exported the pool, which is mandatory [I think it is considered a bug and was supposed to be fixed in 9]. Also note I left the mount point as "/" rather than "legacy", which is optional. At this point, I rebooted and removed the original to test.) Here is a reference to a very similar solution... scroll down to mm's post, or search for the text "Therefore I suggest" http://freebsd.1045724.n5.nabble.com/Difficulties-to-use-ZFS-root-ROOT-MOUNT-ERROR-td4771828.html *and also another note*, you need to make sure your first zfs slice on the disk is the root one. eg. This will definitely not boot if the log and cache are for another pool. I think they also might not boot if they are log and cache for zroot: # gpart show -l => 34 500118125 da5 GPT (238G) 34 2014 - free - (1M) 2048 128 1 (null) (64k) 2176 1920 - free - (960k) 4096 1048576 2 swap0 (512M) 168824832 8388608 3 log0 (4.0G) 177213440 322904064 4 cache0 (154G) 1052672 167772160 5 root0 (80G) 500117504 655 - free - (327k) (note I edited the above... the numbers don't make sense, just the order) Peter Am 11.11.2011 15:31, schrieb Darren Baginski: > Hi! > > I'm having troubles booting today's 9.0-RC2 from zfsroot, I'm getting 'unknown filesystem' error. > But 9.0-RC1 from Tue Nov 8 2011 boots fine. > > Here is output with 9.0-RC1 kernel: > > # zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > zroot 5.97G 2.85G 3.11G 47% 1.00x ONLINE - > > > # zfs list > NAME USED AVAIL REFER MOUNTPOINT > zroot 2.85G 3.02G 2.85G legacy > > # cat /boot/loader.conf > zfs_load="YES" > vfs.root.mountfrom="zfs:zroot" > > Originally that box with installed with FreeBSD 8.x, but continuously updated up to today's version, so : > > VER FILESYSTEM > --- ------------ > 4 zroot > > VER POOL > --- ------------ > 15 zroot > > > Any suggestions ? What could be the problem? > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Nov 11 19:10:25 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 0E2471065670 for ; Fri, 11 Nov 2011 19:10:25 +0000 (UTC) (envelope-from kickbsd@yandex.ru) Received: from forward13.mail.yandex.net (forward13.mail.yandex.net [IPv6:2a02:6b8:0:801::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3A1CE8FC1E for ; Fri, 11 Nov 2011 19:10:24 +0000 (UTC) Received: from web140.yandex.ru (web140.yandex.ru [95.108.130.8]) by forward13.mail.yandex.net (Yandex) with ESMTP id 09843141EAF; Fri, 11 Nov 2011 23:10:19 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321038619; bh=43ZTE2C1yxfVBhHuW96+7HisdBRchSNUddXeRyJ1Ohg=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=FItlibRlhrKc5I1FdwbyoJzwGYHkoGMeZqHxRNiOCF5Pxl52FCXewdcpK72dj4ky+ J4OlDR/VynfDVgP95Q0NnHtcgS0PapEQKBysmbRxBXFZ/t4trViQw4n0Dv9RO/hLuE 2YaH2EZ1POFUNQovZavl19tVA+3yYgVShgIoB4yQ= Received: from localhost (localhost.localdomain [127.0.0.1]) by web140.yandex.ru (Yandex) with ESMTP id C81B84990040; Fri, 11 Nov 2011 23:10:18 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321038618; bh=43ZTE2C1yxfVBhHuW96+7HisdBRchSNUddXeRyJ1Ohg=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=kJsCYusHEFHjmtxTQJIrbPZAwTuHUVh7RMZm4S8/fbNxDv8vDwKLjVdg/xrjXeKLx UGSfI2wPD8kU/QxCn6DtcC0sggLeyw6LfvU/1n+hP5Gv4S3OG+24BNueaCb6rrFbHC iEtaAu//Lg0zRoIB2xAACJynk6Ns97C5jrWHkVgU= X-Yandex-Spam: 1 Received: from leo.de.teleglobe.net (leo.de.teleglobe.net [64.86.53.146]) by web140.yandex.ru with HTTP; Fri, 11 Nov 2011 23:10:18 +0400 From: Darren Baginski To: Peter Maloney In-Reply-To: <4EBD6AAF.5020401@brockmann-consult.de> References: <598941321021900@web148.yandex.ru> <4EBD6AAF.5020401@brockmann-consult.de> MIME-Version: 1.0 Message-Id: <67971321038618@web140.yandex.ru> Date: Fri, 11 Nov 2011 23:10:18 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: freebsd-fs@freebsd.org Subject: Re: Unable to boot from zfsroot 9.0-RC2 (while 9.0-RC1 boots fine) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 19:10:25 -0000 I did 'mfs' install years back . Please note, I'm not talking about *clean* install, but rather setup which worked for 8.0, 8.1, 8.2, 9.0-beta1, 9.0-beta2, 9.0-beta3, 9.0-RC1 up to November 8 (I csup-ing frequently on that box). But suddenly, today's 9.0-RC2 kernel from won't boot. I'm considering that as a regression, if something worked for so long time and stopped. Was there any changes related to subject in kernel ? 11.11.2011, 22:34, "Peter Maloney" : > Darren, > > Did you try the normal procedure, or is it something specific to version 9? > > *normal procedure:* > šFrom a boot cd, do something like this: > > import, and if it fails, go ahead and use -f > # zpool import -o altroot=/z -o cachefile=/tmp/zpool.cache zroot > > # zfs set mountpoint=/ zroot > > # cp /tmp/zpool.cache /z/boot/zfs/zpool.cache > > Optionally here you set mountpoint back to legacy (which is what you > showed in your message). > # zfs umount -a zroot > # zfs set mountpoint=legacy zroot > > (As you can see I have not exported the pool, which is mandatory [I > think šit is considered a bug and was supposed to be fixed in 9]. > Also note I left the mount point as "/" rather than "legacy", which is > optional. > At this point, I rebooted and removed the original to test.) > > Here is a reference to a very similar solution... scroll down to mm's > post, or search for the text "Therefore I suggest" > > http://freebsd.1045724.n5.nabble.com/Difficulties-to-use-ZFS-root-ROOT-MOUNT-ERROR-td4771828.html > > *and also another note*, you need to make sure your first zfs slice on > the disk is the root one. > > eg. This will definitely not boot if the log and cache are for another > pool. I think they also might not boot if they are log and cache for zroot: > > # gpart show -l > => šššššš34 š500118125 šda5 šGPT š(238G) > šššššššššš34 šššššš2014 šššššš- free - š(1M) > šššššššš2048 ššššššš128 ššš1 š(null) š(64k) > šššššššš2176 šššššš1920 šššššš- free - š(960k) > šššššššš4096 ššš1048576 ššš2 šswap0 š(512M) > ššš168824832 ššš8388608 ššš3 šlog0 š(4.0G) > ššš177213440 š322904064 ššš4 šcache0 š(154G) > ššššš1052672 š167772160 ššš5 šroot0 š(80G) > ššš500117504 ššššššš655 šššššš- free - š(327k) > (note I edited the above... the numbers don't make sense, just the order) > > Peter > > Am 11.11.2011 15:31, schrieb Darren Baginski: > >> šHi! >> >> šI'm having troubles booting today's 9.0-RC2 from zfsroot, I'm getting 'unknown filesystem' error. >> šBut š9.0-RC1 from Tue Nov š8 2011 boots fine. >> >> šHere is output with 9.0-RC1 kernel: >> >> š# zpool list >> šNAME šššSIZE šALLOC ššFREE šššCAP šDEDUP šHEALTH šALTROOT >> šzroot š5.97G š2.85G š3.11G ššš47% š1.00x šONLINE š- >> >> š# zfs list >> šNAME šššššššššššššššššššššUSED šAVAIL šREFER šMOUNTPOINT >> šzroot ššššššššššššššššššš2.85G š3.02G š2.85G šlegacy >> >> š# cat /boot/loader.conf >> šzfs_load="YES" >> švfs.root.mountfrom="zfs:zroot" >> >> šOriginally that box with installed with FreeBSD 8.x, but continuously updated up to today's version, so : >> >> šVER šFILESYSTEM >> š--- š------------ >> ššš4 ššzroot >> >> šVER šPOOL >> š--- š------------ >> š15 ššzroot >> >> šAny suggestions ? What could be the problem? >> š_______________________________________________ >> š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" > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Nov 11 20:40:36 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 9F4AC106564A for ; Fri, 11 Nov 2011 20:40:36 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 61BD58FC08 for ; Fri, 11 Nov 2011 20:40:36 +0000 (UTC) Received: by vws11 with SMTP id 11so5492132vws.13 for ; Fri, 11 Nov 2011 12:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AeTOq0njp2o1MvZvyK4APd0DQWABVmrAUSGaCArE0cM=; b=WgBD8nTtqnK9sFZJkcYQ2yUBA367joMqATTB7t5RqwN5Da2coIf0tVjhQqUh6tw99V 61f1EgOQcTcOzVluBP71YOAl4mQsQjF33HVRbOYCGbmQTG+zTuHsquZmzj8DYjbyhBsP dA9JZsce0JEf39BYTuPVtICL3Qq5zaU9yYT+s= MIME-Version: 1.0 Received: by 10.229.40.10 with SMTP id i10mr2171347qce.123.1321044035486; Fri, 11 Nov 2011 12:40:35 -0800 (PST) Received: by 10.229.212.4 with HTTP; Fri, 11 Nov 2011 12:40:35 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Nov 2011 12:40:35 -0800 Message-ID: From: Xin LI To: Johannes Totz Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: backing up zfs dataset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 20:40:36 -0000 On Fri, Nov 11, 2011 at 8:36 AM, Johannes Totz wrote: > Hi, > > To back up a zfs dataset there are a few possibilities: > 1) rsync file data to another machine > 2) zfs-send to another machine, into a zfs dataset > 3) zfs-send to another machine, dumping the stream to a file > > The first one works alright but you loose admin info, properties set on the > dataset, etc > The second is prefered but requires another machine which runs zfs. > The third is bad. > > So far I have been doing (3), for daily short-term backups, works, tested, > everything is peachy. However, I dont like it anymore for obvious reasons. > Ideally, I would like to go with (2). But I dont have another zfs-capable > machine, or the machine that I would like to backup onto will not ever run > zfs. > > So I came up with another crazy idea, assuming the remote machine exports a > block device (somehow): > 4) zpool-attach the remote block dev as a mirror, let it resilver, offline > it during the day, at night online it, resilver, and so on > 5) create a pool on the block dev locally on the to-be-backed-up-machine and > periodically zfs-send stuff over > > I would go for (4), it seems to be the mostly automatic. > Any thoughts on this? > Should I expect things to go titsup if there's network issues? I think this is not a good idea. Could you please try if zstreamdump would fulfill your need? Cheers, -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-fs@FreeBSD.ORG Sat Nov 12 00:29:55 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 C993D1065672; Sat, 12 Nov 2011 00:29:55 +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 A12DB8FC0C; Sat, 12 Nov 2011 00:29:55 +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 pAC0TtVN002271; Sat, 12 Nov 2011 00:29:55 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAC0Ttc3002267; Sat, 12 Nov 2011 00:29:55 GMT (envelope-from linimon) Date: Sat, 12 Nov 2011 00:29:55 GMT Message-Id: <201111120029.pAC0Ttc3002267@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162362: [snapshots] [panic] ufs with snapshot(s) panics when getting full X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 00:29:55 -0000 Old Synopsis: ufs with snapshot(s) panics when getting full New Synopsis: [snapshots] [panic] ufs with snapshot(s) panics when getting full Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sat Nov 12 00:29:26 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162362 From owner-freebsd-fs@FreeBSD.ORG Sat Nov 12 15:12: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 50977106564A for ; Sat, 12 Nov 2011 15:12:58 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D2A798FC16 for ; Sat, 12 Nov 2011 15:12:57 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RPFGK-0003a5-34 for freebsd-fs@freebsd.org; Sat, 12 Nov 2011 16:12:56 +0100 Received: from dyn1240-121.vpn.ic.ac.uk ([129.31.240.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 12 Nov 2011 16:12:56 +0100 Received: from jtotz by dyn1240-121.vpn.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 12 Nov 2011 16:12:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Sat, 12 Nov 2011 15:12:43 +0000 Lines: 40 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dyn1240-121.vpn.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Subject: Re: backing up zfs dataset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 15:12:58 -0000 On 11/11/2011 20:40, Xin LI wrote: > On Fri, Nov 11, 2011 at 8:36 AM, Johannes Totz wrote: >> Hi, >> >> To back up a zfs dataset there are a few possibilities: >> 1) rsync file data to another machine >> 2) zfs-send to another machine, into a zfs dataset >> 3) zfs-send to another machine, dumping the stream to a file >> >> The first one works alright but you loose admin info, properties set on the >> dataset, etc >> The second is prefered but requires another machine which runs zfs. >> The third is bad. >> >> So far I have been doing (3), for daily short-term backups, works, tested, >> everything is peachy. However, I dont like it anymore for obvious reasons. >> Ideally, I would like to go with (2). But I dont have another zfs-capable >> machine, or the machine that I would like to backup onto will not ever run >> zfs. >> >> So I came up with another crazy idea, assuming the remote machine exports a >> block device (somehow): >> 4) zpool-attach the remote block dev as a mirror, let it resilver, offline >> it during the day, at night online it, resilver, and so on >> 5) create a pool on the block dev locally on the to-be-backed-up-machine and >> periodically zfs-send stuff over >> >> I would go for (4), it seems to be the mostly automatic. >> Any thoughts on this? >> Should I expect things to go titsup if there's network issues? > > I think this is not a good idea. Could you please try if zstreamdump > would fulfill your need? How do you mean? I didn't have a chance to test it yet but from looking at examples online, it dumps the stream-headers. Should I be trying this in combination with rsync to preserve properties? I could just pipe zfs get all to a file. However, restore should be as automatic as possible. This is where (4) would be quite nice: I could just dd the remote block dev into a new HDD. From owner-freebsd-fs@FreeBSD.ORG Sat Nov 12 15:35:28 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 DEDAA106564A for ; Sat, 12 Nov 2011 15:35:27 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from nm14-vm0.access.bullet.mail.mud.yahoo.com (nm14-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.15]) by mx1.freebsd.org (Postfix) with SMTP id A53448FC08 for ; Sat, 12 Nov 2011 15:35:27 +0000 (UTC) Received: from [66.94.237.198] by nm14.access.bullet.mail.mud.yahoo.com with NNFMP; 12 Nov 2011 15:21:23 -0000 Received: from [98.139.221.68] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 12 Nov 2011 15:21:23 -0000 Received: from [127.0.0.1] by smtp105.rog.mail.bf1.yahoo.com with NNFMP; 12 Nov 2011 15:21:22 -0000 X-Yahoo-Newman-Id: 968268.57319.bm@smtp105.rog.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: HX1InGYVM1kFwaAhJoQ3HKtN0yi6VF68tgke_Xc.R5D5QHJ v8v.Z4AofkLAouijTbepVbEJgRE_iyTau4VCfpORJG.nyuIT03T18MM8k2JE QAMtWs6VwCzMDWmlywBUF.wMCRgkp_SUL2e0adX.N2B2Y7.lBwuIn21pEx5M Z_JmENov_DT5pnwqCWrL52SJS6NBPtUoTetrd3YVzqSzAL0O03bcby6auzhs OZnUTGze7s8qIOZLu.WCY.6ZKv5qnYun4P8I3r6Lvr8MrMqdVgDcGhi1skda iqLO3tjPcUxV6WCIfsAtIKLMAtpBzShbRNA8p_qJZl2V.7UR7MqaWIQUZFF1 6iCJTfitbAj8IXCLuifFVr1lpUFHOVZOYHr0LSDAP4VYA2CacWRkOIzzGnzz QZlJbYf_A_p66VDB0MKSoVQ-- X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- Received: from smtp.irbisnet.com (andriy@174.113.73.248 with login) by smtp105.rog.mail.bf1.yahoo.com with SMTP; 12 Nov 2011 07:21:22 -0800 PST Received: from pollux.irbisnet.lan (pollux.local [192.168.0.6]) by smtp.irbisnet.com (Postfix) with ESMTPSA id 06030296D8; Sat, 12 Nov 2011 10:21:22 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Andriy Bakay In-Reply-To: Date: Sat, 12 Nov 2011 10:21:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <89025E71-B020-406A-BA58-BAF6529974A1@irbisnet.com> References: To: Johannes Totz X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-fs@freebsd.org Subject: Re: backing up zfs dataset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 15:35:28 -0000 On 2011-11-11, at 11:36 , Johannes Totz wrote: > Hi, >=20 > To back up a zfs dataset there are a few possibilities: > 1) rsync file data to another machine > 2) zfs-send to another machine, into a zfs dataset > 3) zfs-send to another machine, dumping the stream to a file >=20 > The first one works alright but you loose admin info, properties set = on the dataset, etc > The second is prefered but requires another machine which runs zfs. > The third is bad. >=20 > So far I have been doing (3), for daily short-term backups, works, = tested, everything is peachy. However, I dont like it anymore for = obvious reasons. Ideally, I would like to go with (2). But I dont have = another zfs-capable machine, or the machine that I would like to backup = onto will not ever run zfs. >=20 > So I came up with another crazy idea, assuming the remote machine = exports a block device (somehow): > 4) zpool-attach the remote block dev as a mirror, let it resilver, = offline it during the day, at night online it, resilver, and so on > 5) create a pool on the block dev locally on the = to-be-backed-up-machine and periodically zfs-send stuff over >=20 > I would go for (4), it seems to be the mostly automatic. > Any thoughts on this? > Should I expect things to go titsup if there's network issues? >=20 >=20 >=20 > Johannes >=20 > _______________________________________________ > 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" I am using the following schema: sparse file + GGATE + GELI + ZFS. The = destination (remote) machine export/share sparse file through GGATE. The = source/local machine attach GGATE block device, encrypted with GELI and = on top of it create "local" ZFS pool. You can skip GELI and/or instead = sparse file you can use any block device. In this scenario = destination/remote machine does not even know what inside that sparse = file and does not need to support ZFS. You could periodically attach = GGATE/GELI, import ZFS pool and zfs-send/zfs-receive snapshot(s). NOTE: GELI will provide storage security, but I am not sure will it be = secure in terms of transmission. Basically you need to make sure your = GGATE layer go through secure/trusted (VPN, SSH tunnel, trusted LAN) = link. You could mirror to remote GGATE devices, but it could lead to some = problems (try to search it in mailing list). In this case I recommend = you to consider HAST.