From owner-freebsd-fs@FreeBSD.ORG Sun May 29 21:00:23 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 1A54F106566B for ; Sun, 29 May 2011 21:00:23 +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 075278FC19 for ; Sun, 29 May 2011 21:00:23 +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 p4TL0M9s036616 for ; Sun, 29 May 2011 21:00:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4TL0MSv036613; Sun, 29 May 2011 21:00:22 GMT (envelope-from gnats) Date: Sun, 29 May 2011 21:00:22 GMT Message-Id: <201105292100.p4TL0MSv036613@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/157365: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 21:00:23 -0000 The following reply was made to PR kern/157365; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/157365: commit references a PR Date: Sun, 29 May 2011 20:55:36 +0000 (UTC) Author: rmacklem Date: Sun May 29 20:55:23 2011 New Revision: 222464 URL: http://svn.freebsd.org/changeset/base/222464 Log: Add a check for MNTK_UNMOUNTF at the beginning of nfs_sync() in the old NFS client so that a forced dismount doesn't get stuck in the VFS_SYNC() call that happens before VFS_UNMOUNT() in dounmount(). Analagous to r222329 for the new NFS client. An additional change is needed before forced dismounts will work. PR: kern/157365 MFC after: 2 weeks Modified: head/sys/nfsclient/nfs_vfsops.c Modified: head/sys/nfsclient/nfs_vfsops.c ============================================================================== --- head/sys/nfsclient/nfs_vfsops.c Sun May 29 20:46:53 2011 (r222463) +++ head/sys/nfsclient/nfs_vfsops.c Sun May 29 20:55:23 2011 (r222464) @@ -1408,10 +1408,20 @@ nfs_sync(struct mount *mp, int waitfor) td = curthread; + MNT_ILOCK(mp); + /* + * If a forced dismount is in progress, return from here so that + * the umount(2) syscall doesn't get stuck in VFS_SYNC() before + * calling VFS_UNMOUNT(). + */ + if ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0) { + MNT_IUNLOCK(mp); + return (EBADF); + } + /* * Force stale buffer cache information to be flushed. */ - MNT_ILOCK(mp); loop: MNT_VNODE_FOREACH(vp, mp, mvp) { VI_LOCK(vp); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sun May 29 21:20:11 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 288F51065670 for ; Sun, 29 May 2011 21:20:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 197858FC0A for ; Sun, 29 May 2011 21:20:11 +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 p4TLKAvw055240 for ; Sun, 29 May 2011 21:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4TLKAB8055239; Sun, 29 May 2011 21:20:10 GMT (envelope-from gnats) Date: Sun, 29 May 2011 21:20:10 GMT Message-Id: <201105292120.p4TLKAB8055239@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/157365: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 21:20:11 -0000 The following reply was made to PR kern/157365; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/157365: commit references a PR Date: Sun, 29 May 2011 21:14:07 +0000 (UTC) Author: rmacklem Date: Sun May 29 21:13:53 2011 New Revision: 222466 URL: http://svn.freebsd.org/changeset/base/222466 Log: Modify the umount(8) command so that it doesn't do a sync(2) syscall before unmount(2) for the "-f" case. This avoids a forced dismount from getting stuck for an NFS mountpoint in sync() when the server is not responsive. With this commit, forced dismounts should normally work for the NFS clients, but can take up to about 1minute to complete. PR: kern/157365 Reviewed by: kib MFC after: 2 weeks Modified: head/sbin/umount/umount.c Modified: head/sbin/umount/umount.c ============================================================================== --- head/sbin/umount/umount.c Sun May 29 21:03:40 2011 (r222465) +++ head/sbin/umount/umount.c Sun May 29 21:13:53 2011 (r222466) @@ -90,9 +90,6 @@ main(int argc, char *argv[]) struct statfs *mntbuf, *sfs; struct addrinfo hints; - /* Start disks transferring immediately. */ - sync(); - all = errs = 0; while ((ch = getopt(argc, argv, "AaF:fh:t:v")) != -1) switch (ch) { @@ -127,6 +124,10 @@ main(int argc, char *argv[]) argc -= optind; argv += optind; + /* Start disks transferring immediately. */ + if ((fflag & MNT_FORCE) == 0) + sync(); + if ((argc == 0 && !all) || (argc != 0 && all)) usage(); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sun May 29 21:25:57 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 4B2F5106566C; Sun, 29 May 2011 21:25:57 +0000 (UTC) (envelope-from rmacklem@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 243A98FC14; Sun, 29 May 2011 21:25:57 +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 p4TLPvYs063276; Sun, 29 May 2011 21:25:57 GMT (envelope-from rmacklem@freefall.freebsd.org) Received: (from rmacklem@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4TLPuTT063272; Sun, 29 May 2011 21:25:56 GMT (envelope-from rmacklem) Date: Sun, 29 May 2011 21:25:56 GMT Message-Id: <201105292125.p4TLPuTT063272@freefall.freebsd.org> To: eugene@zhegan.in, rmacklem@FreeBSD.org, freebsd-fs@FreeBSD.org From: rmacklem@FreeBSD.org Cc: Subject: Re: kern/157365: [nfs] cannot umount an nfs from dead 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, 29 May 2011 21:25:57 -0000 Synopsis: [nfs] cannot umount an nfs from dead server State-Changed-From-To: open->feedback State-Changed-By: rmacklem State-Changed-When: Sun May 29 21:23:22 UTC 2011 State-Changed-Why: The commits r222464, r222466 should fix the old/regular NFS client w.r.t. doinf forced dismounts against a dead server. They will be MFC'd to stable/8 in 2 weeks. http://www.freebsd.org/cgi/query-pr.cgi?pr=157365 From owner-freebsd-fs@FreeBSD.ORG Sun May 29 21:44:59 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06FB3106564A for ; Sun, 29 May 2011 21:44:59 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id A9FFD8FC16 for ; Sun, 29 May 2011 21:44:58 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta07.westchester.pa.mail.comcast.net with comcast id pZh41g0011swQuc57Zkycc; Sun, 29 May 2011 21:44:58 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.westchester.pa.mail.comcast.net with comcast id pZkx1g00A1t3BNj3bZkxTi; Sun, 29 May 2011 21:44:58 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A6251102C19; Sun, 29 May 2011 14:44:55 -0700 (PDT) Date: Sun, 29 May 2011 14:44:55 -0700 From: Jeremy Chadwick To: rmacklem@freebsd.org Message-ID: <20110529214455.GA61419@icarus.home.lan> References: <201105292120.p4TLKAB8055239@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105292120.p4TLKAB8055239@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/157365: commit references a PR 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, 29 May 2011 21:44:59 -0000 On Sun, May 29, 2011 at 09:20:10PM +0000, dfilter service wrote: > The following reply was made to PR kern/157365; it has been noted by GNATS. > > From: dfilter@FreeBSD.ORG (dfilter service) > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/157365: commit references a PR > Date: Sun, 29 May 2011 21:14:07 +0000 (UTC) > > Author: rmacklem > Date: Sun May 29 21:13:53 2011 > New Revision: 222466 > URL: http://svn.freebsd.org/changeset/base/222466 > > Log: > Modify the umount(8) command so that it doesn't do > a sync(2) syscall before unmount(2) for the "-f" case. > This avoids a forced dismount from getting stuck for > an NFS mountpoint in sync() when the server is not > responsive. With this commit, forced dismounts should > normally work for the NFS clients, but can take up to > about 1minute to complete. > > PR: kern/157365 > Reviewed by: kib > MFC after: 2 weeks > > Modified: > head/sbin/umount/umount.c > > Modified: head/sbin/umount/umount.c > ============================================================================== > --- head/sbin/umount/umount.c Sun May 29 21:03:40 2011 (r222465) > +++ head/sbin/umount/umount.c Sun May 29 21:13:53 2011 (r222466) > @@ -90,9 +90,6 @@ main(int argc, char *argv[]) > struct statfs *mntbuf, *sfs; > struct addrinfo hints; > > - /* Start disks transferring immediately. */ > - sync(); > - > all = errs = 0; > while ((ch = getopt(argc, argv, "AaF:fh:t:v")) != -1) > switch (ch) { > @@ -127,6 +124,10 @@ main(int argc, char *argv[]) > argc -= optind; > argv += optind; > > + /* Start disks transferring immediately. */ > + if ((fflag & MNT_FORCE) == 0) > + sync(); > + > if ((argc == 0 && !all) || (argc != 0 && all)) > usage(); IMHO: the "60-second" behaviour needs to be documented in umount(8). Administrators who are issuing "umount -f" will (understandably) expect the unmount to happen immediately. If umount(8) blocks for 60 seconds while an unmount of an NFS mount happens, that may be more reasonable, but I imagine most administrators are going to Ctrl-C the umount citing "it wasn't doing anything". Since printing a message during "umount -f" is not ideal (the implications may break system scripts, etc.), the behaviour should really be documented in the man page. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sun May 29 22:10:25 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 809561065674; Sun, 29 May 2011 22:10:25 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 59F3A8FC22; Sun, 29 May 2011 22:10:25 +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 p4TMAPhV001781; Sun, 29 May 2011 22:10:25 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4TMAPVt001772; Sun, 29 May 2011 22:10:25 GMT (envelope-from gavin) Date: Sun, 29 May 2011 22:10:25 GMT Message-Id: <201105292210.p4TMAPVt001772@freefall.freebsd.org> To: gavin@FreeBSD.org, kmacy@FreeBSD.org, freebsd-fs@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: sparc64/123566: [zfs] zpool import issue: EOVERFLOW 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, 29 May 2011 22:10:25 -0000 Synopsis: [zfs] zpool import issue: EOVERFLOW Responsible-Changed-From-To: kmacy->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Sun May 29 22:09:04 UTC 2011 Responsible-Changed-Why: kmacy has asked for all of his PRs to be reassigned back to the pool. To submitter: feedback on this was requested. If you did provide feedback then it doesn't appear to have made it into the PR trail - could you please resend it? http://www.freebsd.org/cgi/query-pr.cgi?pr=123566 From owner-freebsd-fs@FreeBSD.ORG Sun May 29 22:11:56 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 BF52F106566B; Sun, 29 May 2011 22:11:56 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 98A338FC16; Sun, 29 May 2011 22:11:56 +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 p4TMBu9X007674; Sun, 29 May 2011 22:11:56 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4TMBudG007670; Sun, 29 May 2011 22:11:56 GMT (envelope-from gavin) Date: Sun, 29 May 2011 22:11:56 GMT Message-Id: <201105292211.p4TMBudG007670@freefall.freebsd.org> To: gavin@FreeBSD.org, kmacy@FreeBSD.org, freebsd-fs@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/130133: [panic] [zfs] 'kmem_map too small' caused by make clean 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, 29 May 2011 22:11:56 -0000 Synopsis: [panic] [zfs] 'kmem_map too small' caused by make clean Responsible-Changed-From-To: kmacy->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Sun May 29 22:10:27 UTC 2011 Responsible-Changed-Why: kmacy has asked for all of his PRs to be reassigned back to the pool. To submitter: It is believed that this was fixed some years back, and feedback on this was requested. If you did provide feedback then it doesn't appear to have made it into the PR trail - could you please resend it? http://www.freebsd.org/cgi/query-pr.cgi?pr=130133 From owner-freebsd-fs@FreeBSD.ORG Sun May 29 22:12:32 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 1F21C1065674; Sun, 29 May 2011 22:12:32 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EB7878FC21; Sun, 29 May 2011 22:12:31 +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 p4TMCVC0007780; Sun, 29 May 2011 22:12:31 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4TMCV3N007776; Sun, 29 May 2011 22:12:31 GMT (envelope-from gavin) Date: Sun, 29 May 2011 22:12:31 GMT Message-Id: <201105292212.p4TMCV3N007776@freefall.freebsd.org> To: gavin@FreeBSD.org, kmacy@FreeBSD.org, freebsd-fs@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/127375: [zfs] If vm.kmem_size_max>"1073741823" then write speed to ZFS pool decrease 3-5 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: Sun, 29 May 2011 22:12:32 -0000 Synopsis: [zfs] If vm.kmem_size_max>"1073741823" then write speed to ZFS pool decrease 3-5 times. Responsible-Changed-From-To: kmacy->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Sun May 29 22:11:58 UTC 2011 Responsible-Changed-Why: kmacy has asked for all of his PRs to be reassigned back to the pool. To submitter: feedback on this was requested. If you did provide feedback then it doesn't appear to have made it into the PR trail - could you please resend it? http://www.freebsd.org/cgi/query-pr.cgi?pr=127375 From owner-freebsd-fs@FreeBSD.ORG Sun May 29 22:14:20 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 5E979106566C; Sun, 29 May 2011 22:14:20 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 377058FC15; Sun, 29 May 2011 22:14:20 +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 p4TMEK3e009003; Sun, 29 May 2011 22:14:20 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4TMEKK0008999; Sun, 29 May 2011 22:14:20 GMT (envelope-from gavin) Date: Sun, 29 May 2011 22:14:20 GMT Message-Id: <201105292214.p4TMEKK0008999@freefall.freebsd.org> To: gavin@FreeBSD.org, kmacy@FreeBSD.org, freebsd-fs@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/120210: [zfs] [panic] reboot after panic: solaris assert: arc_buf_remove_ref 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, 29 May 2011 22:14:20 -0000 Synopsis: [zfs] [panic] reboot after panic: solaris assert: arc_buf_remove_ref Responsible-Changed-From-To: kmacy->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Sun May 29 22:12:33 UTC 2011 Responsible-Changed-Why: kmacy has asked for all of his PRs to be reassigned back to the pool. It seems likely that this is fixed in 8+. To submitter: feedback on this was requested. If you did provide feedback then it doesn't appear to have made it into the PR trail - could you please resend it? http://www.freebsd.org/cgi/query-pr.cgi?pr=120210 From owner-freebsd-fs@FreeBSD.ORG Sun May 29 22:15:49 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 61DF5106564A; Sun, 29 May 2011 22:15:49 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0178FC1C; Sun, 29 May 2011 22:15:49 +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 p4TMFnl1009359; Sun, 29 May 2011 22:15:49 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4TMFn4E009355; Sun, 29 May 2011 22:15:49 GMT (envelope-from gavin) Date: Sun, 29 May 2011 22:15:49 GMT Message-Id: <201105292215.p4TMFn4E009355@freefall.freebsd.org> To: gavin@FreeBSD.org, kmacy@FreeBSD.org, freebsd-fs@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/118126: [nfs] [patch] Poor NFS server write performance 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, 29 May 2011 22:15:49 -0000 Old Synopsis: [nfs] Poor NFS server write performance New Synopsis: [nfs] [patch] Poor NFS server write performance Responsible-Changed-From-To: kmacy->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Sun May 29 22:14:21 UTC 2011 Responsible-Changed-Why: kmacy has asked for all of his PRs to be reassigned back to the pool. http://www.freebsd.org/cgi/query-pr.cgi?pr=118126 From owner-freebsd-fs@FreeBSD.ORG Sun May 29 22:33:36 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 81F81106566B; Sun, 29 May 2011 22:33:36 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5AB7F8FC13; Sun, 29 May 2011 22:33:36 +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 p4TMXakL028388; Sun, 29 May 2011 22:33:36 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4TMXaOH028384; Sun, 29 May 2011 22:33:36 GMT (envelope-from gavin) Date: Sun, 29 May 2011 22:33:36 GMT Message-Id: <201105292233.p4TMXaOH028384@freefall.freebsd.org> To: gavin@FreeBSD.org, kmacy@FreeBSD.org, freebsd-fs@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/126703: [panic] [zfs] _mtx_lock_sleep: recursed on non-recursive mutex vnode interlock 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, 29 May 2011 22:33:36 -0000 Synopsis: [panic] [zfs] _mtx_lock_sleep: recursed on non-recursive mutex vnode interlock Responsible-Changed-From-To: kmacy->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Sun May 29 22:32:13 UTC 2011 Responsible-Changed-Why: kmacy has asked for all of his PRs to be reassigned back to the pool. To submitter: feedback on this was requested. If you did provide feedback then it doesn't appear to have made it into the PR trail - could you please resend it? http://www.freebsd.org/cgi/query-pr.cgi?pr=126703 From owner-freebsd-fs@FreeBSD.ORG Sun May 29 23:38:50 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 28CC6106564A; Sun, 29 May 2011 23:38:50 +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 01B3A8FC08; Sun, 29 May 2011 23:38:50 +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 p4TNcnSg083721; Sun, 29 May 2011 23:38:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4TNcnbg083717; Sun, 29 May 2011 23:38:49 GMT (envelope-from linimon) Date: Sun, 29 May 2011 23:38:49 GMT Message-Id: <201105292338.p4TNcnbg083717@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/157399: [zfs] trouble with: mdconfig force delete && zfs stripe 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, 29 May 2011 23:38:50 -0000 Old Synopsis: [bug] trouble with: mdconfig force delete && zfs stripe New Synopsis: [zfs] trouble with: mdconfig force delete && zfs stripe Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 29 23:37:56 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=157399 From owner-freebsd-fs@FreeBSD.ORG Mon May 30 00:36:01 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 99A5B106566B; Mon, 30 May 2011 00:36:01 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 080F98FC0A; Mon, 30 May 2011 00:36:00 +0000 (UTC) Received: from [IPv6:2001:470:28:140:20be:fae7:248b:9d98] ([IPv6:2001:470:28:140:20be:fae7:248b:9d98]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p4U0ZtcP015217; Mon, 30 May 2011 03:35:56 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4DE2E666.7040905@ukr.net> Date: Mon, 30 May 2011 03:35:50 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-bugs@freebsd.org References: <201105292338.p4TNcnbg083717@freefall.freebsd.org> In-Reply-To: <201105292338.p4TNcnbg083717@freefall.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-95.5 required=5.0 tests=FILL_THIS_FORM, FREEMAIL_FROM, FSL_RU_URL, RDNS_NONE, SPF_SOFTFAIL, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Mon, 30 May 2011 03:35:59 +0300 (EEST) Cc: fs@freebsd.org Subject: Re: kern/157399: [zfs] trouble with: mdconfig force delete && zfs stripe 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, 30 May 2011 00:36:01 -0000 Error occurs in 8.2-CURRENT [3:27]vm1:root->/root# mdconfig -a -t malloc -s 100M md0 [3:28]vm1:root->/root# mdconfig -a -t malloc -s 100M md1 [3:28]vm1:root->/root# zpool create testpools md0 md1 [3:28]vm1:root->/root# dd if=/dev/random of=/testpools/myfile.dat bs=1M count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 1.610346 secs (65114947 bytes/sec) [3:28]vm1:root->/root# mdconfig -d -u 0 -o force [3:28]vm1:root->/root# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 gpt/disk-ada0 ONLINE 0 0 0 errors: No known data errors pool: test-tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM test-tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 gpt/disk5 ONLINE 0 0 0 errors: No known data errors pool: testpools state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM testpools ONLINE 0 0 0 md0 ONLINE 0 0 0 md1 ONLINE 0 0 0 errors: No known data errors [3:29]vm1:root->/root# mdconfig -d -u 0 -o force mdconfig: ioctl(/dev/mdctl): No such file or directory [3:29]vm1:root->/root# mdconfig -d -u 0 -o force mdconfig: ioctl(/dev/mdctl): No such file or directory [3:29]vm1:root->/root# mdconfig -d -u 1 -o force [3:29]vm1:root->/root# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 gpt/disk-ada0 ONLINE 0 0 0 errors: No known data errors pool: test-tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM test-tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 gpt/disk5 ONLINE 0 0 0 errors: No known data errors pool: testpools state: UNAVAIL scrub: none requested config: NAME STATE READ WRITE CKSUM testpools UNAVAIL 0 0 0 insufficient replicas md0 REMOVED 0 0 0 md1 ONLINE 0 0 0 errors: No known data errors [3:29]vm1:root->/root# mdconfig -d -u 1 -o force mdconfig: ioctl(/dev/mdctl): No such file or directory not responding... After hard reboot: [3:34]vm1:root->/root# uname -a FreeBSD vm1.local 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri May 27 02:30:57 EEST 2011 root@vm1.local:/usr/obj/usr/src/sys/virtualbox.2 amd64 [3:34]vm1:root->/root# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 gpt/disk-ada0 ONLINE 0 0 0 errors: No known data errors pool: test-tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM test-tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 gpt/disk5 ONLINE 0 0 0 errors: No known data errors pool: testpools state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scrub: none requested config: NAME STATE READ WRITE CKSUM testpools UNAVAIL 0 0 0 insufficient replicas md0 UNAVAIL 0 0 0 cannot open md1 UNAVAIL 0 0 0 cannot open -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Mon May 30 11:06:58 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A97C1065677 for ; Mon, 30 May 2011 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4972A8FC0A for ; Mon, 30 May 2011 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4UB6wQR050367 for ; Mon, 30 May 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4UB6vHp050365 for freebsd-fs@FreeBSD.org; Mon, 30 May 2011 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 May 2011 11:06:57 GMT Message-Id: <201105301106.p4UB6vHp050365@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, 30 May 2011 11:06:58 -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/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip f kern/157365 fs [nfs] cannot umount an nfs from dead server o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156933 fs [zfs] ZFS receive after read on readonly=on filesystem 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/156168 fs [nfs] [panic] Kernel panic under concurrent access ove o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs o kern/155484 fs [ufs] GPT + UFS boot don't work well together o kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 o kern/154447 fs [zfs] [panic] Occasional panics - solaris assert somew 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/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an o bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs f kern/130133 fs [panic] [zfs] 'kmem_map too small' caused by make clea 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 f kern/126703 fs [panic] [zfs] _mtx_lock_sleep: recursed on non-recursi 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/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 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 f kern/120210 fs [zfs] [panic] reboot after panic: solaris assert: arc_ 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 f kern/116170 fs [panic] Kernel panic when mounting /tmp o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro f kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 232 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon May 30 11:30:19 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 4780B106564A for ; Mon, 30 May 2011 11:30:19 +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 372CA8FC08 for ; Mon, 30 May 2011 11:30:19 +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 p4UBUI8A071499 for ; Mon, 30 May 2011 11:30:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4UBUIwI071490; Mon, 30 May 2011 11:30:18 GMT (envelope-from gnats) Date: Mon, 30 May 2011 11:30:18 GMT Message-Id: <201105301130.p4UBUIwI071490@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Vladislav V. Prodan" Cc: Subject: Re: kern/157399: [zfs] trouble with: mdconfig force delete && zfs stripe X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Vladislav V. Prodan" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 11:30:19 -0000 The following reply was made to PR kern/157399; it has been noted by GNATS. From: "Vladislav V. Prodan" To: FreeBSD-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/157399: [zfs] trouble with: mdconfig force delete && zfs stripe Date: Mon, 30 May 2011 14:28:38 +0300 Error occurs in 8.2-CURRENT, ZFS v15 [3:27]vm1:root->/root# mdconfig -a -t malloc -s 100M md0 [3:28]vm1:root->/root# mdconfig -a -t malloc -s 100M md1 [3:28]vm1:root->/root# zpool create testpools md0 md1 [3:28]vm1:root->/root# dd if=/dev/random of=/testpools/myfile.dat bs=1M count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 1.610346 secs (65114947 bytes/sec) [3:28]vm1:root->/root# mdconfig -d -u 0 -o force [3:28]vm1:root->/root# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 gpt/disk-ada0 ONLINE 0 0 0 errors: No known data errors pool: test-tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM test-tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 gpt/disk5 ONLINE 0 0 0 errors: No known data errors pool: testpools state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM testpools ONLINE 0 0 0 md0 ONLINE 0 0 0 md1 ONLINE 0 0 0 errors: No known data errors [3:29]vm1:root->/root# mdconfig -d -u 0 -o force mdconfig: ioctl(/dev/mdctl): No such file or directory [3:29]vm1:root->/root# mdconfig -d -u 0 -o force mdconfig: ioctl(/dev/mdctl): No such file or directory [3:29]vm1:root->/root# mdconfig -d -u 1 -o force [3:29]vm1:root->/root# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 gpt/disk-ada0 ONLINE 0 0 0 errors: No known data errors pool: test-tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM test-tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 gpt/disk5 ONLINE 0 0 0 errors: No known data errors pool: testpools state: UNAVAIL scrub: none requested config: NAME STATE READ WRITE CKSUM testpools UNAVAIL 0 0 0 insufficient replicas md0 REMOVED 0 0 0 md1 ONLINE 0 0 0 errors: No known data errors [3:29]vm1:root->/root# mdconfig -d -u 1 -o force mdconfig: ioctl(/dev/mdctl): No such file or directory not responding... After hard reboot: [3:34]vm1:root->/root# uname -a FreeBSD vm1.local 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri May 27 02:30:57 EEST 2011 root@vm1.local:/usr/obj/usr/src/sys/virtualbox.2 amd64 [3:34]vm1:root->/root# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 gpt/disk-ada0 ONLINE 0 0 0 errors: No known data errors pool: test-tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM test-tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 gpt/disk5 ONLINE 0 0 0 errors: No known data errors pool: testpools state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scrub: none requested config: NAME STATE READ WRITE CKSUM testpools UNAVAIL 0 0 0 insufficient replicas md0 UNAVAIL 0 0 0 cannot open md1 UNAVAIL 0 0 0 cannot open -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Mon May 30 14:21: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 6EDD7106564A for ; Mon, 30 May 2011 14:21:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id C57FD8FC1C for ; Mon, 30 May 2011 14:21:24 +0000 (UTC) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p4UCFnvh021526 for ; Mon, 30 May 2011 22:15:49 +1000 Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p4UCFbfp018598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 May 2011 22:15:38 +1000 Date: Mon, 30 May 2011 22:15:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Artem Belevich In-Reply-To: Message-ID: <20110530210943.Y3265@besplex.bde.org> References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2106762154-1306757737=:3265" Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 30 May 2011 14:21:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2106762154-1306757737=:3265 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 26 May 2011, Artem Belevich wrote: > On Thu, May 26, 2011 at 6:46 PM, David P Discher wro= te: >> Hello FS list: >> >> We've been using ZFS v3, storage pool v14 with FreeBSD 8.1-RELEASE with = fairly good results for over a year. =A0We have been moving more and more o= f our storage to ZFS. =A0Last week, I believe we hit another issue with LBO= LT. >> >> The original which was first reported by Artem Belevich for l2arc_feed_t= hread : >> >> =A0- http://lists.freebsd.org/pipermail/freebsd-fs/2011-January/010558.h= tml >> >> But this also affects the arc_reclaim_thread as well. The guys over at i= X Systems helped out and pointed me to this patch : >> >> =A0- http://people.freebsd.org/~delphij/misc/218180.diff >> >> which typedef's clock_t to int64_t. I think that patch is unusable and didn't get used. clock_t is a (bogusly) machine-dependent system type that cannot be declared in a cddl header (except possibly to hide bugs by making it different from the system type in some places only). >> However, the arc_reclaim_thread does not have a ~24 day rollover - it do= es not use clock_t. =A0I think this rollover in the integer results in LBOL= T going negative, after about 106-107 days. =A0We haven't noticed this unti= l actually 112-115 days of uptime. =A0I think it is also related to L1 ARC = sizing, and load. =A0Our systems with arc set to min-max of =A0512M/2G ARC = haven't developed the issue - at least the CPU hogging thread - but the sys= tems with 12G+ of ARC, and lots of rsync and du activity along side of rand= om reads from the zpool develop the issue. >> >> The problem is slight different, and possibly more harmful than the l2ar= c feeder issue seen with LBOLT. >> >> in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, the arc_evict()= function, under "evict_start:" has this loop to walk the arc cache page li= st: [unreadable non-text with hard \xa0's deleted] >> Now, when LBOLT is negative, with some degree of jitter/randomness, this= loop short-circuts, resulting in high CPU usage. =A0Also the ARC buffers m= ay not get evicted on-time, or possibly at all. =A0One system I had, all pr= ocesses to the zpool where waiting on D-state, and the arc_reclaim_thread w= as stuck at 100%. =A0du and rysnc seem to help aggravate this issue. =A0On = an affected system : >> ... >> After chatting with someone else well respected in the community, he pro= posed an alternative fix. =A0I'm vetting here to make sure there isn't some= thing deeper in the code that could get bitten by, as well as some clarific= ation : >> >> in: >> ./sys/cddl/compat/opensolaris/sys/time.h >> >> the relevant parts are: >> >> =A0 =A0 =A0 =A0 41 #define LBOLT =A0 ((gethrtime() * hz) / NANOSEC) Might work if gethrtime() is a 64-bit type, but as you pointed out, it is almost perfectly passimized. >> =A0 =A0 =A0 =A0 ... >> >> =A0 =A0 =A0 =A0 54 static __inline hrtime_t Not clear what its type is. >> =A0 =A0 =A0 =A0 55 gethrtime(void) { >> =A0 =A0 =A0 =A0 56 >> =A0 =A0 =A0 =A0 57 =A0 =A0 =A0 =A0 struct timespec ts; >> =A0 =A0 =A0 =A0 58 =A0 =A0 =A0 =A0 hrtime_t nsec; >> =A0 =A0 =A0 =A0 59 >> =A0 =A0 =A0 =A0 60 #if 1 >> =A0 =A0 =A0 =A0 61 =A0 =A0 =A0 =A0 getnanouptime(&ts); >> =A0 =A0 =A0 =A0 62 #else >> =A0 =A0 =A0 =A0 63 =A0 =A0 =A0 =A0 nanouptime(&ts); >> =A0 =A0 =A0 =A0 64 #endif The ifdef prevents more perfect pessimization -- we will scale to hz ticks, so we don't want to extra accuracy and overheads from using nanouptime(). >> =A0 =A0 =A0 =A0 65 =A0 =A0 =A0 =A0 nsec =3D (hrtime_t)ts.tv_sec * NANOSE= C + ts.tv_nsec; > > Yup. This would indeed overflow in ~106.75 days. Apparently hr_time_t is 64 bits signed, and hz =3D 1000. 64 bits unsigned would overflow after twice as long (after a further multiplication by hz in LBOLT). Use hz =3D much larger or much smaller than 1000 to change the overflow point. >> QUESTION - what units is LBOLT suppose to be ? =A0If gethrtime() is retu= rning nanoseconds, why is nanoseconds getting multiplied by hz ? =A0If LBOL= T is suppose to be clock-ticks (which is what arc.c looks like it wants it = in) then it really should be : >> >> =A0 =A0 =A0 =A0 #define LBOLT =A0 ( (gethrtime() / NANOSEC) * hz ) >> >> But if that is case, then why make the call to getnanouptime() at all ? = =A0If LBOLT is number of clock ticks, then can't this just be a query to up= time in seconds ? =A0So how about something like this: >> >> =A0 =A0 =A0 =A0#define LBOLT =A0 (time_uptime * hz) This is similar to FreBSD's `ticks', and overflows at a similar point: - `ticks' is int, and int is int32_t on all supported arches, so `ticks' overflows at 2**31 / hz on all supported arches. This was 248 days if hz is correctly configured as 100. The default misconfiguration of hz =3D 1000 gives overflow after 24.8 days. - time_uptime is time_t, so the above overflows at TIME_T_MAX / hz. - on i386 and powerpc, time_t is int32_t, so the above overflows at the same point as does `ticks' on these arches. - on all other arches, time_t is int64_t, so the above overflows after 2**32 times as long. > I believe lbolt used to hold number of ticks on solaris, though they > switched to tickless kernel some time back and got rid of lbolt. Yes, LBOLT in solaris seems to correspond to `ticks' in FreeBSD, except it might not overflow like `ticks' does. (`lbolt' in FreeBSD was a dummy sleep address with value always 0.) >> I've applied this changed locally, and did a basic stress test with our = load generator in the lab, thrashing the arc cache. (96GB RAM, 48G min/max = for ARC) It seems to have no ill effects - though, will have to wait 4-mont= hs before declaring the actual issue here fixed. =A0I'm hoping to put this = in production next week. Won't work on i386. >> It would seem, the same optimization could be done here too: >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#define ddi_get_lbolt() =A0 =A0 =A0 =A0 (= time_uptime * hz) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#define ddi_get_lbolt64() =A0 =A0 =A0 (in= t64_t)(time_uptime * hz) To fix the overflow it has to be: #define ddi_get_lbolt64()=09((int64_t)time_uptime * hz) >> With saving the call to getnanouptime() a multiple and divide, there sho= uld be a couple hundred cycle performance improvement here. =A0I don't clai= m this would be noticeable, but seems like a simple, straight forward optim= ization. Should only be a couple of ten cycle performance improvement. getnanouptime() is very fast. > The side effect is that it limits bolt resolution to hz units. With > HZ=3D100, that will be 10ms. Whether it's good enough or too coarse I > have no idea. Perhaps we can compromise and update lbolt in > microseconds. That should give us few hundred years until the > overflow. No, it actually limits the resolution to seconds units, and that seems too coarse. Using getnanupotime() already limited the resolution to hz/tc_tick inverse-units (tc_tick =3D 1 for hz <=3D ~1000, but above that getnanouptime() provides less than hz inverse-units). `ticks' would be the right thing to use if it didn't overflow. Some networking code (e.g., in tcp_output.c) still uses `ticks', and at least used to have bugs from this use when `ticks' overflowed. Blindly increasing hz of course made the bugs more frequent. Bruce --0-2106762154-1306757737=:3265-- From owner-freebsd-fs@FreeBSD.ORG Mon May 30 19:25: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 D6D43106566B for ; Mon, 30 May 2011 19:25:46 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 79E188FC12 for ; Mon, 30 May 2011 19:25:46 +0000 (UTC) Received: (qmail 31833 invoked from network); 30 May 2011 18:59:04 -0000 Received: from unknown (HELO ?10.50.50.207?) (spawk@64.147.100.2) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 30 May 2011 18:59:04 -0000 Message-ID: <4DE3E924.3030900@acm.poly.edu> Date: Mon, 30 May 2011 14:59:48 -0400 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110408 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Requesting __FreeBSD_version bump for ZFSv28 MFC 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, 30 May 2011 19:25:46 -0000 Hi. A while ago I had requested that __FreeBSD_version be bumped for future ZFS userland API changes (http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008459.html), since I guess I am the only other user of the userland API aside from the official tools. There was at least one change in the transition from 15 to 28 that broke my code, and __FreeBSD_version doesn't look like it was bumped for the v28 import into -CURRENT. Can it please be bumped for the MFC to 8? Thank you. -Boris From owner-freebsd-fs@FreeBSD.ORG Tue May 31 08:40:05 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 EAE5F1065673 for ; Tue, 31 May 2011 08:40:05 +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 D0AA68FC1C for ; Tue, 31 May 2011 08:40:05 +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 p4V8e57C073271 for ; Tue, 31 May 2011 08:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4V8e5GM073270; Tue, 31 May 2011 08:40:05 GMT (envelope-from gnats) Date: Tue, 31 May 2011 08:40:05 GMT Message-Id: <201105310840.p4V8e5GM073270@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Alexey Dokuchaev Cc: Subject: Re: kern/133174: [msdosfs] [patch] msdosfs must support utf-encoded international characters in filr names X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexey Dokuchaev List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 08:40:06 -0000 The following reply was made to PR kern/133174; it has been noted by GNATS. From: Alexey Dokuchaev To: bug-followup@FreeBSD.org Cc: Xin LI Subject: Re: kern/133174: [msdosfs] [patch] msdosfs must support utf-encoded international characters in filr names Date: Tue, 31 May 2011 15:35:16 +0700 I confirm that msdosfs patch (ntfs one is no longer accessible) applies to my recent 8.2-STABLE and fixes display of Chinese characters with my local ru_RU.UTF-8 locale. Discussion on fs@ was followed up Yoshihiro Ota [1] which reported these is someone else working on the same or similar. [2] I fully agree with Yoshihiro-san in his question: Is anyone intend to work on this issue? We have a patch, we have reports that it works, and it seems that all is missing is review of msdosfs expert. And I know we have those. ;-) [1] http://docs.freebsd.org/cgi/mid.cgi?20090216000044.d77fec80.ota [2] http://docs.freebsd.org/cgi/mid.cgi?courier.44DE0FB1.0001160E From owner-freebsd-fs@FreeBSD.ORG Tue May 31 15:24:05 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48F971065673; Tue, 31 May 2011 15:24:05 +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 13DD58FC17; Tue, 31 May 2011 15:24:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA13437; Tue, 31 May 2011 18:24:01 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE50811.5060606@FreeBSD.org> Date: Tue, 31 May 2011 18:24:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Artem Belevich , David P Discher References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 31 May 2011 15:24:05 -0000 Artem and David, I am replying to both of you, so meaning of 'you' below depends on quoting context. on 27/05/2011 07:06 Artem Belevich said the following: > On Thu, May 26, 2011 at 6:46 PM, David P Discher wrote: [snip] >> However, the arc_reclaim_thread does not have a ~24 day rollover - it does not use clock_t. I think this rollover in the integer results in LBOLT going negative, after about 106-107 days. We haven't noticed this until actually 112-115 days of uptime. I think it is also related to L1 ARC sizing, and load. Our systems with arc set to min-max of 512M/2G ARC haven't developed the issue - at least the CPU hogging thread - but the systems with 12G+ of ARC, and lots of rsync and du activity along side of random reads from the zpool develop the issue. >> >> The problem is slight different, and possibly more harmful than the l2arc feeder issue seen with LBOLT. >> >> in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, the arc_evict() function, under "evict_start:" has this loop to walk the arc cache page list: >> >> 1708 for (ab = list_tail(list); ab; ab = ab_prev) { >> 1709 ab_prev = list_prev(list, ab); >> 1710 bytes_remaining -= (ab->b_size * ab->b_datacnt); >> 1711 /* prefetch buffers have a minimum lifespan */ >> 1712 if (HDR_IO_IN_PROGRESS(ab) || >> 1713 (spa && ab->b_spa != spa) || >> 1714 (ab->b_flags & (ARC_PREFETCH|ARC_INDIRECT) && >> 1715 LBOLT - ab->b_arc_access < arc_min_prefetch_lifespan)) { >> 1716 skipped++; >> 1717 continue; >> 1718 } >> >> >> Now, when LBOLT is negative, with some degree of jitter/randomness, this loop short-circuts, resulting in high CPU usage. Also the ARC buffers may not get evicted on-time, or possibly at all. One system I had, all processes to the zpool where waiting on D-state, and the arc_reclaim_thread was stuck at 100%. du and rysnc seem to help aggravate this issue. On an affected system : >> >>> top -SHb 500 | grep arc_reclaim_thr >> 95 root -8 - 0K 60K arc_re 3 102.9H 96.39% {arc_reclaim_thre} >> >> Conveniently, "skipped++" is surfaced via a sysctl, here's two queries to it on this system with the arc reclaim thread running hot (a du going too at the same time ), 60 seconds in between : >> >> kstat.zfs.misc.arcstats.evict_skip: 4117714520450 >> kstat.zfs.misc.arcstats.evict_skip: 4118188257434 >> >>> uptime >> 3:51PM up 116 days, 23:48, 3 users, load averages: 1.30, 0.96, 0.64 >> >> After chatting with someone else well respected in the community, he proposed an alternative fix. I'm vetting here to make sure there isn't something deeper in the code that could get bitten by, as well as some clarification : >> >> in: >> ./sys/cddl/compat/opensolaris/sys/time.h >> >> the relevant parts are: >> >> 41 #define LBOLT ((gethrtime() * hz) / NANOSEC) >> ... >> 54 static __inline hrtime_t >> 55 gethrtime(void) { >> 56 >> 57 struct timespec ts; >> 58 hrtime_t nsec; >> 59 >> 60 #if 1 >> 61 getnanouptime(&ts); >> 62 #else >> 63 nanouptime(&ts); >> 64 #endif >> 65 nsec = (hrtime_t)ts.tv_sec * NANOSEC + ts.tv_nsec; > > Yup. This would indeed overflow in ~106.75 days. Have you referred to the LBOLT above? gethrtime() should have several hundred years before overflowing. >> 66 return (nsec); >> 67 } >> >> QUESTION - what units is LBOLT suppose to be ? If gethrtime() is returning nanoseconds, why is nanoseconds getting multiplied by hz ? If LBOLT is suppose to be clock-ticks (which is what arc.c looks like it wants it in) then it really should be : It should be ticks, no doubt. >> #define LBOLT ( (gethrtime() / NANOSEC) * hz ) This definitely is a bad idea, division by NANOSEC would limit resolution to 1 second. It's obvious that what is defined above would jump from N * hz to (N + 1) * hz. Please see below. >> But if that is case, then why make the call to getnanouptime() at all ? If LBOLT is number of clock ticks, then can't this just be a query to uptime in seconds ? So how about something like this: >> >> #define LBOLT (time_uptime * hz) Exactly the same problem as above. BTW, we already have 'ticks' variable that should be more or less equivalent to the old Solaris LBOLT. Except that ticks is int and LBOLT was clock_t. > I believe lbolt used to hold number of ticks on solaris, though they > switched to tickless kernel some time back and got rid of lbolt. Yes and (kind of) no. They still use ddi_get_lbolt and ddi_get_lbolt64 where lbolt was previously used and it was easier to keep thinking in 'ticks' rather than to rewrite code more radically: http://fxr.watson.org/fxr/source/common/os/sunddi.c?v=OPENSOLARIS#L5634 Both ddi_get_lbolt and ddi_get_lbolt64 just call lbolt_hybrid function pointer. There is some interesting read about it here: http://fxr.watson.org/fxr/source/common/os/clock.c?v=OPENSOLARIS#L244 Long story short, when in "event driven mode" they do the following: ts = gethrtime(); ASSERT(ts > 0); ASSERT(nsec_per_tick > 0); lb = (ts/nsec_per_tick); >> I've applied this changed locally, and did a basic stress test with our load generator in the lab, thrashing the arc cache. (96GB RAM, 48G min/max for ARC) It seems to have no ill effects - though, will have to wait 4-months before declaring the actual issue here fixed. I'm hoping to put this in production next week. >> >> All this above is on 8.1-RELEASE. ZFS v28 changed some of this, but still didn't improve lbolt: >> >> - http://svnweb.freebsd.org/base/head/sys/cddl/compat/opensolaris/sys/time.h?revision=221991&view=markup >> >> 65 #define ddi_get_lbolt() ((gethrtime() * hz) / NANOSEC) Please note that unlike OpenSolaris where ddi_get_lbolt is a function with return type of clock_t, we have a macro, so resulting type of the above expression will be the same as return type of gethrtime(), that is int64_t, because it is the widest type in the expression. To be entirely compatible with Solaris we should have a clock_t cast here (but our clock_t is defined differently from theirs). >> 66 #define ddi_get_lbolt64() (int64_t)((gethrtime() * hz) / NANOSEC) Actually, the cast in the second definition shouldn't affect generated machine code as described above. >> It would seem, the same optimization could be done here too: >> >> #define ddi_get_lbolt() (time_uptime * hz) >> #define ddi_get_lbolt64() (int64_t)(time_uptime * hz) Already discussed above. >> With saving the call to getnanouptime() a multiple and divide, there should be a couple hundred cycle performance improvement here. I don't claim this would be noticeable, but seems like a simple, straight forward optimization. > > The side effect is that it limits bolt resolution to hz units. With > HZ=100, that will be 10ms. Whether it's good enough or too coarse I Nope, I think you did your your math wrong here. As shown above it limits the resolution to hz ticks, i.e. hz * 1/hz seconds :) > have no idea. Perhaps we can compromise and update lbolt in > microseconds. That should give us few hundred years until the > overflow. Well, we can either use the ticks variable, since we are not switching to tickless mode yet. But we would need to make it 64-bit to avoid early overflows. Or, perhaps, to be somewhat future-friendly we could do approximately what OpenSolaris [upstream :-)] code does: gethrtime() / (NANOSEC / hz) Or, given that NANOSEC is constant and hz is invariant, we could apply extended invariant division by multiplication approach to get precise and fast result without overflowing. But likely that's an overkill here. Though we definitely should pre-calculate, store and re-use (NANOSEC / hz) value just like OpenSolaris does it. >> clock_t will still need the typedef'ed to 64bit to still address the l2arc usage of LBOLT. Hm, I see that OpenSolaris defines clock_t to long, while we use int32_t. So, I think that it means two things: - i386 OpenSolaris (if it exists) should be affected by the problem as well - we should not use our native clock_t definition for ported OpenSolaris code Maybe we should fix our clock_t to be something wider at least for 64-bit platforms. But I am not prepared to discuss this. To summarize: 1. We must fix ddi_get_lbolt*() to avoid unnecessary overflow in multiplication 2. We could fix 31-bit clock_t overflow by using Solaris-compatible definition of it (long), but that still won't help on i386. Maybe we should bring up this issue to the attention of upstream ZFS developers. Universally using ddi_get_lbolt64() seems like a safer bet. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue May 31 15:40: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 D83C21065674 for ; Tue, 31 May 2011 15:40:46 +0000 (UTC) (envelope-from patpro@patpro.net) Received: from rack.patpro.net (rack.patpro.net [193.30.227.216]) by mx1.freebsd.org (Postfix) with ESMTP id 3F3978FC0A for ; Tue, 31 May 2011 15:40:46 +0000 (UTC) Received: from rack.patpro.net (localhost [127.0.0.1]) by rack.patpro.net (Postfix) with ESMTP id 52FF01CC038 for ; Tue, 31 May 2011 17:21:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at patpro.net Received: from amavis-at-patpro.net ([127.0.0.1]) by rack.patpro.net (rack.patpro.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rkg-elBwE0V for ; Tue, 31 May 2011 17:21:27 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by rack.patpro.net (Postfix) with ESMTP for ; Tue, 31 May 2011 17:21:27 +0200 (CEST) From: Patrick Proniewski Content-Type: multipart/signed; boundary=Apple-Mail-4--16922292; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 31 May 2011 17:21:15 +0200 Message-Id: <7DA2CB2F-FA87-427D-903E-514882EE6068@patpro.net> To: FreeBSD Filesystems Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: No physical znode address 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, 31 May 2011 15:40:47 -0000 --Apple-Mail-4--16922292 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I'm running a FreeBSD 8.2 server, with Apache 2.2 hosting around 260 web = sites. It's a virtual machine, running on top of ESXi and a SAN storage. The OS is installed on UFS, and a dedicated ZFS disk holds every web = sites. Each web site is a ZFS volume created from the zpool "tank". # zpool list =20 NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 149G 53.6G 95.4G 35% ONLINE - # zpool status =20 pool: tank state: ONLINE scrub: scrub completed after 0h19m with 0 errors on Fri May 13 22:57:10 = 2011 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 da1 ONLINE 0 0 0 errors: No known data errors Today, I've noticed an httpd process, stuck, using 100% CPU for hours. = It looks like the process has opened non-existing files. Here is a part = of the output of lsof: # lsof -p 10453 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME httpd 10453 www cwd No = physical znode address: 0xffffff0013019c60 httpd 10453 www rtd VDIR 0,87 512 2 / httpd 10453 www txt VREG 0,87 1321703 406618 = /usr/local/sbin/httpd httpd 10453 www txt VREG 0,87 246776 235521 = /libexec/ld-elf.so.1 httpd 10453 www txt VREG 0,87 154320 659461 = /lib/libm.so.5 ../.. httpd 10453 www 120r No = physical znode address: 0xffffff00132e2840 httpd 10453 www 121r No = physical znode address: 0xffffff0013019c60 httpd 10453 www 122r No = physical znode address: 0xffffff00132e2840 httpd 10453 www 123r No = physical znode address: 0xffffff0013019c60 httpd 10453 www 124r No = physical znode address: 0xffffff00132e2840 httpd 10453 www 125r No = physical znode address: 0xffffff0013019c60 httpd 10453 www 126r No = physical znode address: 0xffffff00132e2840 httpd 10453 www 127r No = physical znode address: 0xffffff0013019c60 httpd 10453 www 128r No = physical znode address: 0xffffff00132e2840 httpd 10453 www 129r No = physical znode address: 0xffffff0013019c60 httpd 10453 www 130r No = physical znode address: 0xffffff00132e2840 httpd 10453 www 131r No = physical znode address: 0xffffff0013019c60 ../.. Reading a part of lsof's source code, it seems to relate to ZFS = (dnode2.c - FreeBSD ZFS node functions for lsof). Using truss, I've discovered that the process is trying to stat a = non-existing file, with a way too long path. truss output is a infinite = repetition of: = stat("/Sites/sites//spip-core/sites/spip-core/sites/spip-core/sites/spip-c= ore/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/= spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/= sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip= -core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/site= s/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-cor= e/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/sp= ip-core-vh/sites/edhum/bd/.Trashes////////////////////////////////////////= //////////////////////////////////////////////////////////////////////////= //////////////////////////////////////////////////////////////////////////= //////////////////////////////////////////////////////////////////////////= //////////////////////////////////////////////////////////////////////////= //////////////////////////////////////////////////////////////////////////= ////////////////////////////////////////////////////////////////////",0x7f= ffffffcc90) ERR#63 'File name too long' (I had to kill -9 truss process...) Obviously, there is something wrong with this particular web site. But = I'm afraid it could come from the file system, or impact the FS.=20 Any idea is welcome. patpro --Apple-Mail-4--16922292-- From owner-freebsd-fs@FreeBSD.ORG Tue May 31 16:06: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 41380106567A for ; Tue, 31 May 2011 16:06:50 +0000 (UTC) (envelope-from ef@math.uni-bonn.de) Received: from ems.math.uni-bonn.de (ems.math.uni-bonn.de [131.220.132.179]) by mx1.freebsd.org (Postfix) with ESMTP id BB9878FC08 for ; Tue, 31 May 2011 16:06:49 +0000 (UTC) Received: from gumme.math.uni-bonn.de (gumme.math.uni-bonn.de [131.220.182.239]) by ems.math.uni-bonn.de (Postfix) with ESMTP id 14553BC9A8 for ; Tue, 31 May 2011 17:50:47 +0200 (CEST) Received: by gumme.math.uni-bonn.de (Postfix, from userid 108) id D46218437; Tue, 31 May 2011 17:50:46 +0200 (CEST) Date: Tue, 31 May 2011 17:50:46 +0200 From: Edgar =?iso-8859-1?B?RnXf?= To: freebsd-fs@freebsd.org Message-ID: <20110531155046.GB9327@gumme.math.uni-bonn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: softdep-related panic (allocdirect_merge) 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, 31 May 2011 16:06:50 -0000 I hope this is the right place to ask. I'm experiencing softdep-related panics on NetBSD and am trying to find out whether they may be due to a FreeBSD fix not having been ported over. On a NetBSD-4.0.1/amd NFS server which has happily been runnig soft updates for years without problems, suddenly, presumably because of having updated the ~150 clients, I was struck with two nearly identical panics within hours. The panics were allocdirect_merge: ob 0 != nb 244139088 || lbn 12 >= 12 || osize 0 != nsize 16384 with only the nb value different between the two. The second time, I successfully took a dump. However, I can't possibly make that public because it contains user data. Of course, I can look up whatever may help in analysing the problem. I'm not expecting much help from the NetBSD side because they are phasing out softdeps in favour of WAPBL. It looks like older unresolved softdep-related PRs have been closed in that course. I've found two related FreeBSD PRs, namely kern/126089 and kern/23258. Unfortunally, the former has been closed due to feedback timeout and with the later, only the locking-against-myself error is mentioned in the comments. The system in question is UP. The filesystem in question was nowhere close to being full when the panic happened. However, it may be that someone is exceeding his quota limit. There were no snapshots active or taken on the filesystem at the time of the panic. I've browsed through the CVS history of ffs_softdep.c, but haven't found any commit that looks obviously relevant to my problem. I'm aware that the root cause needn't to be in that code. Is anyone aware of a fix in the FreeBSD code that has fixed a similar problem? I could then check whether that fix has been ported to NetBSD. Thank you P.S. For the time being, I've mounted the relevant filesystem non-softdep. From owner-freebsd-fs@FreeBSD.ORG Tue May 31 16:09:12 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 F37E6106564A; Tue, 31 May 2011 16:09:11 +0000 (UTC) (envelope-from prvs=11320824c3=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 07F9C8FC08; Tue, 31 May 2011 16:09:10 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 31 May 2011 16:57:51 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 31 May 2011 16:57:47 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013430624.msg; Tue, 31 May 2011 16:57:45 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11320824c3=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <7F79B120F4ED415F8BB9EB7A4483AF8D@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" , "Artem Belevich" , "David P Discher" References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> Date: Tue, 31 May 2011 16:57:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 31 May 2011 16:09:12 -0000 ----- Original Message ----- > However, the arc_reclaim_thread does not have a ~24 day rollover - it > does not use clock_t. I think this rollover in the integer results > in LBOLT going negative, after about 106-107 days. We haven't noticed > this until actually 112-115 days of uptime. I think it is also related > to L1 ARC sizing, and load. Our systems with arc set to min-max of > 512M/2G ARC haven't developed the issue - at least the CPU hogging thread > - but the systems with 12G+ of ARC, and lots of rsync and du activity > along side of random reads from the zpool develop the issue. Looks like we had this on machine today which had only been up 66 days. A reboot cleared it, but 66 days up time is nearly half previously reported making it a bit more serious. last pid: 9562; load averages: 1.35, 2.12, 1.93 up 66+20:01:35 10:48:19 172 processes: 10 running, 143 sleeping, 19 waiting CPU: 0.0% user, 0.0% nice, 12.2% system, 0.0% interrupt, 87.8% idle Mem: 14M Active, 2812K Inact, 6394M Wired, 1596K Cache, 9448M Free Swap: 24G Total, 122M Used, 24G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 8 171 ki31 0K 128K CPU0 0 ??? 704.35% idle 6 root 4 -8 - 0K 60K tx->tx 0 1031.9 100.00% zfskern 18 root 1 44 - 0K 16K syncer 0 167:04 0.10% syncer Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RELEASE #1: Fri Mar 25 14:23:21 UTC 2011 root@... amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X5355 @ 2.66GHz (2666.68-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Family = 6 Model = f Stepping = 7 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 18253611008 (17408 MB) avail memory = 16509063168 (15744 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) > zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 9.06T 4.55T 4.51T 50% ONLINE - > zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 da0p3 ONLINE 0 0 0 cache ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 errors: No known data errors ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue May 31 16:29:33 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A52AD1065679 for ; Tue, 31 May 2011 16:29:33 +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 F0E758FC14 for ; Tue, 31 May 2011 16:29:32 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA14556; Tue, 31 May 2011 19:29:29 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE51769.9060907@FreeBSD.org> Date: Tue, 31 May 2011 19:29:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Steven Hartland References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> <7F79B120F4ED415F8BB9EB7A4483AF8D@multiplay.co.uk> In-Reply-To: <7F79B120F4ED415F8BB9EB7A4483AF8D@multiplay.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 31 May 2011 16:29:34 -0000 on 31/05/2011 18:57 Steven Hartland said the following: > ----- Original Message ----- >> However, the arc_reclaim_thread does not have a ~24 day rollover - it >> does not use clock_t. I think this rollover in the integer results >> in LBOLT going negative, after about 106-107 days. We haven't noticed >> this until actually 112-115 days of uptime. I think it is also related >> to L1 ARC sizing, and load. Our systems with arc set to min-max of >> 512M/2G ARC haven't developed the issue - at least the CPU hogging thread >> - but the systems with 12G+ of ARC, and lots of rsync and du activity >> along side of random reads from the zpool develop the issue. > > > Looks like we had this on machine today which had only been up 66 days. Sorry, but 'looks' is not very definitive. > A reboot cleared it, but 66 days up time is nearly half previously reported > making it a bit more serious. It could have been some other bug or something else altogether. Without proper debugging/investigation it's impossible to tell. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue May 31 16:31:59 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D53AE1065670; Tue, 31 May 2011 16:31:59 +0000 (UTC) (envelope-from artemb@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 7A8058FC0C; Tue, 31 May 2011 16:31:59 +0000 (UTC) Received: by gyg13 with SMTP id 13so2723264gyg.13 for ; Tue, 31 May 2011 09:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mBInYgpRYcKtF/0YKImkxCLx1v9FhbJ6lszTLJso7L4=; b=LRctKs+PIbv8PKi48sgk+DNgpKwJdhzHItcziTTOQbNYG2dGLoAAs5AbqE4CMuLPzc mGkmJFQ0RT31qo1de5pESnUGh4WgH2srsHkLXmDqa6NoUCoJ72qecFlt8WUykhc0rM7A NNLGWS1Jj+rtyjME44nAPt7ncunQlobXowYOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=a88SffdlWyBW+0UpaF3vYKpDP3dd2rD/xFy2+NoutjfQsILSafEbkTTLfBPuGy37mi m44gan5SabpV6POWFK8AEY8PWGT2PrToheHbpNPmPZm24cEvTU5cwOIvzJWcpWbrsKvA Be6oBdLJ4YjKpiZG3d6QPZfyBzDVyGVtfF+LU= MIME-Version: 1.0 Received: by 10.236.78.99 with SMTP id f63mr6875874yhe.518.1306859518483; Tue, 31 May 2011 09:31:58 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.208.70 with HTTP; Tue, 31 May 2011 09:31:58 -0700 (PDT) In-Reply-To: <7F79B120F4ED415F8BB9EB7A4483AF8D@multiplay.co.uk> References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> <7F79B120F4ED415F8BB9EB7A4483AF8D@multiplay.co.uk> Date: Tue, 31 May 2011 09:31:58 -0700 X-Google-Sender-Auth: UfMplu5EA-FkC0q2h2PDE6PcbUo Message-ID: From: Artem Belevich To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, Andriy Gapon Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 31 May 2011 16:31:59 -0000 On Tue, May 31, 2011 at 8:57 AM, Steven Hartland wrote: > Looks like we had this on machine today which had only been up 66 days. > A reboot cleared it, but 66 days up time is nearly half previously reported > making it a bit more serious. What does 'sysctl kern.hz' show on your box? Overflow rate depends on hz. Estimate of 106 days is based on hz=1000. --Artem From owner-freebsd-fs@FreeBSD.ORG Tue May 31 16:44: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 96B951065670 for ; Tue, 31 May 2011 16:44:11 +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 A7DC08FC0C for ; Tue, 31 May 2011 16:44:10 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA14763; Tue, 31 May 2011 19:43:47 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE51AC3.7090700@FreeBSD.org> Date: Tue, 31 May 2011 19:43:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Patrick Proniewski References: <7DA2CB2F-FA87-427D-903E-514882EE6068@patpro.net> In-Reply-To: <7DA2CB2F-FA87-427D-903E-514882EE6068@patpro.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Filesystems Subject: Re: No physical znode address 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, 31 May 2011 16:44:11 -0000 on 31/05/2011 18:21 Patrick Proniewski said the following: > Hi all, > > I'm running a FreeBSD 8.2 server, with Apache 2.2 hosting around 260 web sites. It's a virtual machine, running on top of ESXi and a SAN storage. > The OS is installed on UFS, and a dedicated ZFS disk holds every web sites. Each web site is a ZFS volume created from the zpool "tank". > > # zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > tank 149G 53.6G 95.4G 35% ONLINE - > > # zpool status > pool: tank > state: ONLINE > scrub: scrub completed after 0h19m with 0 errors on Fri May 13 22:57:10 2011 > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > da1 ONLINE 0 0 0 > > errors: No known data errors > > Today, I've noticed an httpd process, stuck, using 100% CPU for hours. It looks like the process has opened non-existing files. Here is a part of the output of lsof: > > # lsof -p 10453 > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > httpd 10453 www cwd No physical znode address: 0xffffff0013019c60 > httpd 10453 www rtd VDIR 0,87 512 2 / > httpd 10453 www txt VREG 0,87 1321703 406618 /usr/local/sbin/httpd > httpd 10453 www txt VREG 0,87 246776 235521 /libexec/ld-elf.so.1 > httpd 10453 www txt VREG 0,87 154320 659461 /lib/libm.so.5 > ../.. > httpd 10453 www 120r No physical znode address: 0xffffff00132e2840 > httpd 10453 www 121r No physical znode address: 0xffffff0013019c60 > httpd 10453 www 122r No physical znode address: 0xffffff00132e2840 > httpd 10453 www 123r No physical znode address: 0xffffff0013019c60 > httpd 10453 www 124r No physical znode address: 0xffffff00132e2840 > httpd 10453 www 125r No physical znode address: 0xffffff0013019c60 > httpd 10453 www 126r No physical znode address: 0xffffff00132e2840 > httpd 10453 www 127r No physical znode address: 0xffffff0013019c60 > httpd 10453 www 128r No physical znode address: 0xffffff00132e2840 > httpd 10453 www 129r No physical znode address: 0xffffff0013019c60 > httpd 10453 www 130r No physical znode address: 0xffffff00132e2840 > httpd 10453 www 131r No physical znode address: 0xffffff0013019c60 > ../.. > > Reading a part of lsof's source code, it seems to relate to ZFS (dnode2.c - FreeBSD ZFS node functions for lsof). I wonder if fstat would have worked any differently from lsof here. > Using truss, I've discovered that the process is trying to stat a non-existing file, with a way too long path. truss output is a infinite repetition of: > > stat("/Sites/sites//spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core/sites/spip-core-vh/sites/edhum/bd/.Trashes//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////",0x7fffffffcc90) ERR#63 'File name too long' > > (I had to kill -9 truss process...) I wonder if with ktrace/kdump you wouldn't have to use kill. > Obviously, there is something wrong with this particular web site. But I'm afraid it could come from the file system, or impact the FS. > Any idea is welcome. Unfortunately, nothing for such a mysterious problem. Maybe you could investigate why apache tries to use that overlong path in the first place. Like some undesirable recursion... -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue May 31 16:48: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 BAAC2106564A; Tue, 31 May 2011 16:48:27 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5F0488FC08; Tue, 31 May 2011 16:48:27 +0000 (UTC) Received: by yxl31 with SMTP id 31so2743280yxl.13 for ; Tue, 31 May 2011 09:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=B2Wc9BffubrUM4MQFd0HEdOa1KFPzOZZJXR+YqgmzGo=; b=l93dipYSrSKqeNcpG2+SYR+OBI7uITfY/O2H9Onhv0rc2pODHjRve1WYnme7CvHPl7 faH2dR/EChd9HDI7/PyKlMrEZBrwiPGc7+a3bRah2qt1ZnrWbGEss6JaLTm4QjYj8ycy Act5BSJjC/jAXwkjDxqhZoTPP7mcRKqwpoqoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cddq9fr1V9taFJMNmhcNdihL7sUNsqWyEQPI4cqQdqx0zBwEVVBV8QjhiNk4UyHmST 698zYCTYqn0/Uhe0hftuEBuq2Bh5iFSR2sSII35Ai3kdUBTxncMgLJlDbBP5spZcf4mJ a4ugoqt9r0JTQ+rSDyWUdLPhZb676qAqdD504= MIME-Version: 1.0 Received: by 10.236.138.161 with SMTP id a21mr2248741yhj.49.1306860506591; Tue, 31 May 2011 09:48:26 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.208.70 with HTTP; Tue, 31 May 2011 09:48:26 -0700 (PDT) In-Reply-To: <4DE50811.5060606@FreeBSD.org> References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> Date: Tue, 31 May 2011 09:48:26 -0700 X-Google-Sender-Auth: 4NHHWxA5PfZLQuw5wMsJflfr69w Message-ID: From: Artem Belevich To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 31 May 2011 16:48:27 -0000 On Tue, May 31, 2011 at 8:24 AM, Andriy Gapon wrote: >>> =A0 =A0 =A0 =A0 65 =A0 =A0 =A0 =A0 nsec =3D (hrtime_t)ts.tv_sec * NANOS= EC + ts.tv_nsec; >> >> Yup. This would indeed overflow in ~106.75 days. > > Have you referred to the LBOLT above? > gethrtime() should have several hundred years before overflowing. hrtime_t is 64-bit. NANOSEC=3D1000000000. When it's time to use LBOLT, we further multiply number of seconds by HZ: >> 41 #define LBOLT ((gethrtime() * hz) / NANOSEC) In the end we want 64-bit scalar to hold number of seconds times 10e12. 0x7fffffffffffffff/1000000000000 =3D 9223372 # number of seconds before signed overflow 9223372/(24*60*60) --> 106 # .. or about 106 days >> The side effect is that it limits bolt resolution to hz units. With >> HZ=3D100, that will be 10ms. Whether it's good enough or too coarse I > > Nope, I think you did your your math wrong here. > As shown above it limits the resolution to hz ticks, i.e. hz * 1/hz secon= ds :) Point taken. > >> have no idea. Perhaps we can compromise and update lbolt in >> microseconds. That should give us few hundred years until the >> overflow. > > Well, we can either use the ticks variable, since we are not switching to= tickless > mode yet. =A0But we would need to make it 64-bit to avoid early overflows= . > Or, perhaps, to be somewhat future-friendly we could do approximately wha= t > OpenSolaris [upstream :-)] code does: > > gethrtime() / (NANOSEC / hz) > > Or, given that NANOSEC is constant and hz is invariant, we could apply ex= tended > invariant division by multiplication approach to get precise and fast res= ult > without overflowing. =A0But likely that's an overkill here. =A0Though we = definitely > should pre-calculate, store and re-use (NANOSEC / hz) value just like Ope= nSolaris > does it. This should work. > >>> clock_t will still need the typedef'ed to 64bit to still address the l2= arc usage of LBOLT. > > Hm, I see that OpenSolaris defines clock_t to long, while we use int32_t. > So, I think that it means two things: > - i386 OpenSolaris (if it exists) should be affected by the problem as we= ll > - we should not use our native clock_t definition for ported OpenSolaris = code > > Maybe we should fix our clock_t to be something wider at least for 64-bit > platforms. =A0But I am not prepared to discuss this. > > To summarize: > 1. We must fix ddi_get_lbolt*() to avoid unnecessary overflow in multipli= cation Agreed. > 2. We could fix 31-bit clock_t overflow by using Solaris-compatible defin= ition of > it (long), but that still won't help on i386. =A0Maybe we should bring up= this issue > to the attention of upstream ZFS developers. =A0Universally using ddi_get= _lbolt64() > seems like a safer bet. FYI, we've already changed clock_t for opensolaris code to int64_t in r218169 regardless of $MACHINE. --Artem From owner-freebsd-fs@FreeBSD.ORG Tue May 31 16:56:54 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 2FDC6106564A; Tue, 31 May 2011 16:56:54 +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 499F58FC0C; Tue, 31 May 2011 16:56:52 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA15032; Tue, 31 May 2011 19:56:51 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE51DD3.6040602@FreeBSD.org> Date: Tue, 31 May 2011 19:56:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Artem Belevich References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 31 May 2011 16:56:54 -0000 on 31/05/2011 19:48 Artem Belevich said the following: > On Tue, May 31, 2011 at 8:24 AM, Andriy Gapon wrote: >>>> 65 nsec = (hrtime_t)ts.tv_sec * NANOSEC + ts.tv_nsec; >>> >>> Yup. This would indeed overflow in ~106.75 days. >> >> Have you referred to the LBOLT above? >> gethrtime() should have several hundred years before overflowing. > > hrtime_t is 64-bit. NANOSEC=1000000000. > > When it's time to use LBOLT, we further multiply number of seconds by HZ: >>> 41 #define LBOLT ((gethrtime() * hz) / NANOSEC) > > In the end we want 64-bit scalar to hold number of seconds times 10e12. > 0x7fffffffffffffff/1000000000000 = 9223372 # number of seconds before > signed overflow > 9223372/(24*60*60) --> 106 # .. or about 106 days Basically you used that many words to say "yes, I meant overflow in LBOLT"? :-) Because gethrtime alone would overflow in about 1000 * 100 days (~300 years). >> To summarize: >> 1. We must fix ddi_get_lbolt*() to avoid unnecessary overflow in multiplication > > Agreed. Okey. >> 2. We could fix 31-bit clock_t overflow by using Solaris-compatible definition of >> it (long), but that still won't help on i386. Maybe we should bring up this issue >> to the attention of upstream ZFS developers. Universally using ddi_get_lbolt64() >> seems like a safer bet. > > FYI, we've already changed clock_t for opensolaris code to int64_t in > r218169 regardless of $MACHINE. I think that's a good solution. I hope that we don't have any place where osol clock_t would somehow mix with fbsd clock_t with detrimental effects. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue May 31 17:40:12 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 4D57710656A5 for ; Tue, 31 May 2011 17:40:12 +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 7DB848FC19 for ; Tue, 31 May 2011 17: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 p4VHe9TD069636 for ; Tue, 31 May 2011 17:40:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4VHe9S1069633; Tue, 31 May 2011 17:40:09 GMT (envelope-from gnats) Date: Tue, 31 May 2011 17:40:09 GMT Message-Id: <201105311740.p4VHe9S1069633@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Alexey Dokuchaev Cc: Subject: Re: kern/133174: [msdosfs] [patch] msdosfs must support utf-encoded international characters in filr names X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexey Dokuchaev List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:40:12 -0000 The following reply was made to PR kern/133174; it has been noted by GNATS. From: Alexey Dokuchaev To: bug-followup@FreeBSD.org Cc: Xin LI Subject: Re: kern/133174: [msdosfs] [patch] msdosfs must support utf-encoded international characters in filr names Date: Wed, 1 Jun 2011 00:32:05 +0700 I've attached a patch (cleaned up some style issues) and fixed typos in subject/synopsis and audit log. From owner-freebsd-fs@FreeBSD.ORG Tue May 31 18:25:40 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 7486B106564A; Tue, 31 May 2011 18:25:40 +0000 (UTC) (envelope-from prvs=11320824c3=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 66DFC8FC0C; Tue, 31 May 2011 18:25:39 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 31 May 2011 19:25:09 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 31 May 2011 19:25:06 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013432003.msg; Tue, 31 May 2011 19:25:05 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11320824c3=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <6369E29ADE744AA4A63D49C46B1C9DBC@multiplay.co.uk> From: "Steven Hartland" To: "Artem Belevich" References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com><4DE50811.5060606@FreeBSD.org><7F79B120F4ED415F8BB9EB7A4483AF8D@multiplay.co.uk> Date: Tue, 31 May 2011 19:25:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: freebsd-fs@freebsd.org, Andriy Gapon Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 31 May 2011 18:25:40 -0000 ----- Original Message ----- From: "Artem Belevich" > On Tue, May 31, 2011 at 8:57 AM, Steven Hartland > wrote: >> Looks like we had this on machine today which had only been up 66 days. >> A reboot cleared it, but 66 days up time is nearly half previously reported >> making it a bit more serious. > > What does 'sysctl kern.hz' show on your box? Overflow rate depends on > hz. Estimate of 106 days is based on hz=1000. Its 1000, does it also depend on the number of cores at all? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue May 31 18: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 BD9D7106566B; Tue, 31 May 2011 18:41:28 +0000 (UTC) (envelope-from artemb@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 61B798FC19; Tue, 31 May 2011 18:41:28 +0000 (UTC) Received: by gyg13 with SMTP id 13so2804397gyg.13 for ; Tue, 31 May 2011 11:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0ZgZZHzVmvAXR06DhP6B8v7WN1qnQS1Bk7dXYxgDJsE=; b=UbgX3OXuSKvausCwilcHTq/glnr5diZzSiQqtW208OEJFgH3tG3IQY0A/wuy5TG0Mk YyIuuri8NRjkNrGuAtjcz70TWuJv2Uklv/7/mBN+YO6wD298yznNlXv1JF+W8WykAB0c x1ZqUDTYFbj3EGBp0ugUROrJ9PFyfkqI9dASw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mzDWtVKGNUnSNTT2FpE/tyMdT+gV2JgtTkjSaCzP50Wu4pIIGI+ZxRpW6Pnci9L62R 6ZGgITzfl35B4ekzcvKFuSgvN903Kyqz55QIwmv5/tdXIFlisxQS/87nqBHG6crMd2aR 01GFuqBvMsx8kQ1Dtq5g5npCr55JSfdkoRDx8= MIME-Version: 1.0 Received: by 10.236.32.164 with SMTP id o24mr7125918yha.116.1306867287407; Tue, 31 May 2011 11:41:27 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.208.70 with HTTP; Tue, 31 May 2011 11:41:27 -0700 (PDT) In-Reply-To: <4DE51DD3.6040602@FreeBSD.org> References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> <4DE51DD3.6040602@FreeBSD.org> Date: Tue, 31 May 2011 11:41:27 -0700 X-Google-Sender-Auth: TzfZCHmr8HY9sApN6Vk60aeMOlQ Message-ID: From: Artem Belevich To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 31 May 2011 18:41:28 -0000 On Tue, May 31, 2011 at 9:56 AM, Andriy Gapon wrote: > on 31/05/2011 19:48 Artem Belevich said the following: >> On Tue, May 31, 2011 at 8:24 AM, Andriy Gapon wrote: >>>>> =A0 =A0 =A0 =A0 65 =A0 =A0 =A0 =A0 nsec =3D (hrtime_t)ts.tv_sec * NAN= OSEC + ts.tv_nsec; >>>> >>>> Yup. This would indeed overflow in ~106.75 days. >>> >>> Have you referred to the LBOLT above? >>> gethrtime() should have several hundred years before overflowing. >> >> hrtime_t is 64-bit. NANOSEC=3D1000000000. >> >> When it's time to use LBOLT, we further multiply number of seconds by HZ= : >>>> =A0 =A0 =A0 =A0 41 #define LBOLT =A0 ((gethrtime() * hz) / NANOSEC) >> >> In the end we want 64-bit scalar to hold number of seconds times 10e12. >> 0x7fffffffffffffff/1000000000000 =3D 9223372 =A0# number of seconds befo= re >> signed overflow >> 9223372/(24*60*60) --> 106 =A0 # .. or about 106 days > > Basically you used that many words to say "yes, I meant overflow in LBOLT= "? :-) Yes. It took a lot of willpower on my part to limit my yes to just few lines. I've got three-volume draft variant if you're interested. :-) >> FYI, we've already changed clock_t for opensolaris code to int64_t in >> r218169 regardless of $MACHINE. > > I think that's a good solution. > I hope that we don't have any place where osol clock_t would somehow mix = with fbsd > clock_t with detrimental effects. That is a potential source of trouble and the point had been raised when r218169 was discussed before commit. At the moment of commit there were only few places in cddl code that used clock_t and those were for internal use only. That was pre-ZFSv28 commit, though. --Artem From owner-freebsd-fs@FreeBSD.ORG Tue May 31 19:07:40 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 A916E1065679; Tue, 31 May 2011 19:07:40 +0000 (UTC) (envelope-from dpd@bitgravity.com) Received: from mail1.sjc1.bitgravity.com (mail1.sjc1.bitgravity.com [209.131.97.19]) by mx1.freebsd.org (Postfix) with ESMTP id 8C45C8FC16; Tue, 31 May 2011 19:07:40 +0000 (UTC) Received: from mail-pw0-f45.google.com ([209.85.160.45]) by mail1.sjc1.bitgravity.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QRUI0-000Ewr-7Z; Tue, 31 May 2011 12:07:40 -0700 Received: by pwi6 with SMTP id 6so2768205pwi.18 for ; Tue, 31 May 2011 12:07:34 -0700 (PDT) Received: by 10.142.247.34 with SMTP id u34mr1028412wfh.48.1306868854574; Tue, 31 May 2011 12:07:34 -0700 (PDT) Received: from netops-173.sfo1.bitgravity.com (netops-173.sfo1.bitgravity.com [209.131.110.173]) by mx.google.com with ESMTPS id c5sm260706pbj.57.2011.05.31.12.07.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 12:07:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: David P Discher In-Reply-To: <4DE51DD3.6040602@FreeBSD.org> Date: Tue, 31 May 2011 12:07:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> <4DE51DD3.6040602@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@FreeBSD.org, Artem Belevich Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 31 May 2011 19:07:40 -0000 On May 31, 2011, at 9:56 AM, Andriy Gapon wrote: >>=20 >> FYI, we've already changed clock_t for opensolaris code to int64_t in >> r218169 regardless of $MACHINE. >=20 > I think that's a good solution. > I hope that we don't have any place where osol clock_t would somehow = mix with fbsd > clock_t with detrimental effects. Well, clock_t to int64_t only fixes l2arc_reclaim_thread. If you look at lines 1712-1725 in = sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, the arc_evict(), = (8.1-release), you'll see that clock_t is not use. So, yes, clock_t = will fix the l2arc issue, but not the arc_reclaim/arc evict issue of the = signed 64bit int overflowing for LBOLT. And from the conversation on this thread, there isn't any agreement on = how to really fix it. Someone please explain to me the units of LBOLT? =20 hz is cycles per second right ? #define LBOLT ((gethrtime() * hz) / NANOSEC) gethrtime() is returning nanoseconds. How is LBOLT in ticks-per-second = ? In sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c : 152 /* number of seconds before growing cache again */ 153 static int arc_grow_retry =3D 60; ... 2255 /* reset the growth delay for every = reclaim */ 2256 growtime =3D LBOLT + (arc_grow_retry * = hz); LBOLT is then clearly using it math with ticks-per-second. I'm I just = crazy ? It seems to me that in this case, line 2256 ... can't be added = together.=20 --- David P. Discher dpd@bitgravity.com * AIM: bgDavidDPD BITGRAVITY * http://www.bitgravity.com From owner-freebsd-fs@FreeBSD.ORG Tue May 31 19:21:34 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 C44D4106566C; Tue, 31 May 2011 19:21:34 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6651C8FC13; Tue, 31 May 2011 19:21:34 +0000 (UTC) Received: by yxl31 with SMTP id 31so2837763yxl.13 for ; Tue, 31 May 2011 12:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KgF7aG9NGFf0CLgWBH1Z4bdlgtNcRZThbICQE2AgFzw=; b=Pz/H9B27WONxs7j+mRaM9DCF5FGtsDpSy9MQatttbO9H8pEQELz0DBi8oyamaEA3ba u1YS29FaSohb+mlBq1jHKZAVKoyQtF4tKftLWa+mPIJq/5Et22AKbad1e4ufapvoXWqW 6RVek35Q9qF927wsQPmAbCXvUXhsNYJQ0PfYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YSdAa/RdVgqwJv1jcdwNRYXaBoeok4RaIG5YAGkdon5+nfJyQvAQsgAsix293G5B1S 90lrSSwe7rK1HtBOUJzp9Wxo5Ova0U+b8QukgZ+YijeXmtREYuu9rxyzz1z/aoSr4pC4 nH6MmcoJ8O2QepC4V7UQNCZ/FQhjJvlOOQ98c= MIME-Version: 1.0 Received: by 10.236.187.100 with SMTP id x64mr8069682yhm.317.1306869693497; Tue, 31 May 2011 12:21:33 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.208.70 with HTTP; Tue, 31 May 2011 12:21:33 -0700 (PDT) In-Reply-To: References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> <4DE51DD3.6040602@FreeBSD.org> Date: Tue, 31 May 2011 12:21:33 -0700 X-Google-Sender-Auth: dAqwjHPBbM_crSUM1o93-bGoJkI Message-ID: From: Artem Belevich To: David P Discher Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Andriy Gapon Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 31 May 2011 19:21:34 -0000 On Tue, May 31, 2011 at 12:07 PM, David P Discher wrot= e: > > On May 31, 2011, at 9:56 AM, Andriy Gapon wrote: > >>> >>> FYI, we've already changed clock_t for opensolaris code to int64_t in >>> r218169 regardless of $MACHINE. >> >> I think that's a good solution. >> I hope that we don't have any place where osol clock_t would somehow mix= with fbsd >> clock_t with detrimental effects. > > Well, clock_t to int64_t only fixes l2arc_reclaim_thread. > > If you look at lines 1712-1725 in sys/cddl/contrib/opensolaris/uts/common= /fs/zfs/arc.c, the arc_evict(), (8.1-release), you'll see that clock_t is n= ot use. =A0So, yes, clock_t will fix the l2arc issue, but not the arc_recla= im/arc evict issue of the signed 64bit int overflowing for LBOLT. No disagreement there. The way LBOLT is implemented now would indeed cause the overflow that leads to CPU hogging you've reported. > And from the conversation on this thread, there isn't any agreement on ho= w to really fix it. Andriy has proposed potential fix that would eliminate multiplication of gethrtime result by hz and would delay overflow by few hundred years. Should be good enough. > Someone please explain to me the units of LBOLT? HZ ticks per second. > > hz is cycles per second right ? > > =A0 =A0#define =A0 =A0 LBOLT =A0 ((gethrtime() * hz) / NANOSEC) > > > gethrtime() is returning nanoseconds. =A0 How is LBOLT in ticks-per-secon= d ? gethrtime is indeed nanoseconds. After division by NANOSES it becomes old good seconds. Multiplication by hz (which is ticks/sec) the whole thing represents just 'ticks' > > In sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c : > > =A0 =A0152 /* number of seconds before growing cache again */ > =A0 =A0153 static int =A0 =A0 =A0 =A0 =A0 =A0 =A0arc_grow_retry =3D 60; That would be in seconds. > =A0 =A0... > =A0 =A02255 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* reset the = growth delay for every reclaim */ > =A0 =A02256 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 growtime =3D = LBOLT + (arc_grow_retry * hz); (arc_grow_retry in seconds * hz in ticks/sec) --> ticks > > > LBOLT is then clearly using it math with ticks-per-second. =A0 I'm I just= crazy ? =A0It seems to me that in this case, line 2256 ... can't be added = together. LBOLT is in 'ticks', not ticks/sec. --Artem From owner-freebsd-fs@FreeBSD.ORG Tue May 31 19:22: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 0CCAE1065670; Tue, 31 May 2011 19:22:58 +0000 (UTC) (envelope-from artemb@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 A728D8FC08; Tue, 31 May 2011 19:22:57 +0000 (UTC) Received: by gxk28 with SMTP id 28so2830644gxk.13 for ; Tue, 31 May 2011 12:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mwIuCx00LF+UMWeDV3jDeyiksoURRxnal9wjQdpGv/U=; b=d7XpV8Di1S5DJWYmdOWARi2ZD/2riHeDbwl5jKw7SqMd0unzAUEoM9gxk/KN+k7L+S 40mLntFnp2w9yFhWI+k0j7uqjm8iJAPZzq8yQN+oHIJdFyRe5+uvy+usa/Dc8J9hx+5x 3mPG4qFs7faNv2vDUSInHnrJug3yCrVeeiwFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=G/UXSjQ6HtCuQiAaX7FilRk6GPYivYGMWAPdiPotbYkAWcUJSr7oe0qAriebdn1RsC lWn4XbceBtqRnU4iJYWNIQOH+mEFPB1ajj0LoFo7uhwDDuaKanTVcUJX3iCfZOtnJsOl E/lcDeNc3X6G43vYQ50eu10ZxPQYbdeVun2Xo= MIME-Version: 1.0 Received: by 10.236.193.105 with SMTP id j69mr4830008yhn.384.1306869776773; Tue, 31 May 2011 12:22:56 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.208.70 with HTTP; Tue, 31 May 2011 12:22:56 -0700 (PDT) In-Reply-To: References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> <4DE51DD3.6040602@FreeBSD.org> Date: Tue, 31 May 2011 12:22:56 -0700 X-Google-Sender-Auth: KdTadHibrOxiyD4QCa8sB1zXFRc Message-ID: From: Artem Belevich To: David P Discher Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, Andriy Gapon Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 31 May 2011 19:22:58 -0000 On Tue, May 31, 2011 at 12:21 PM, Artem Belevich wrote: >> Someone please explain to me the units of LBOLT? > > HZ ticks per second. Oops. It's just 'ticks'. --Artem From owner-freebsd-fs@FreeBSD.ORG Tue May 31 20:42: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 17546106566C for ; Tue, 31 May 2011 20:42:43 +0000 (UTC) (envelope-from pvz@itassistans.se) Received: from zcs1.itassistans.net (zcs1.itassistans.net [212.112.191.37]) by mx1.freebsd.org (Postfix) with ESMTP id C39D18FC0C for ; Tue, 31 May 2011 20:42:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs1.itassistans.net (Postfix) with ESMTP id A7003C0222 for ; Tue, 31 May 2011 22:42:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at zcs1.itassistans.net Received: from zcs1.itassistans.net ([127.0.0.1]) by localhost (zcs1.itassistans.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXo8ZNr2wbNW for ; Tue, 31 May 2011 22:42:38 +0200 (CEST) Received: from [192.168.1.239] (c213-89-160-61.bredband.comhem.se [213.89.160.61]) by zcs1.itassistans.net (Postfix) with ESMTPSA id 40A04C01FC for ; Tue, 31 May 2011 22:42:38 +0200 (CEST) From: Per von Zweigbergk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 31 May 2011 22:42:37 +0200 Message-Id: To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: Storing revisions of large files using ZFS snapshots 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, 31 May 2011 20:42:43 -0000 I'm currently looking at the option of using a FreeBSD server using ZFS = to store offsite backups. The primary backup product used (Veeam Backup & Replication) stores its = backups in what's called reverse-incremental mode. Basically, this means = storing backups as a huge VBK file (one for each job) containing a = deduplicated and compressed dump of all the virtual machine files being = backed up. The system will also store what are known as "reverse = incrementals", i.e. anything it overwrites on a backup pass will be = preserved in a file, similar to a traditional incremental backup, except = in the other direction. Since this product does not have any real solutions for offsite backup = replication, after considering a few different options, I'm seriously = considering using a combination of ZFS snapshots and rsync. Basically what would happen is that every night after the backup = completes, rsync would be run, synchronizing over the differences = between the synthetic full backup from the previous day. Historic copies = of the full backup images as synchronized by rsync would be kept using = ZFS snapshots. After our retention window closes, I'd just nuke the = oldest snapshots from the server. We're talking about a file that's around 1 TB big or so even after the = backup software does its own inline compression and deduplication (and = is likely to grow bigger as our environment grows) which is kind of = impractical to send in its entirety even over our current 100 Mbit/s = leased line to our datacenter.=20 First of all, will ZFS will do copy-on-write on a block level when it = comes to snapshots, or is copy-on-write on ZFS snapshots done on a = whole-file level? It would seem that block-level COW would be required = for this to even have a chance of working. Please note that I'm not = talking about deduplication in ZFS itself, but rather using snapshots as = a means to perform a crude kind of deduplication. Second, are there any other caveats that I'm likely to run into as I go = down this path for storing backups? Obviously, I'd prefer just trucking over plain old incremental backups, = and doing a consolidation job off-site, but the backup software doesn't = have any image management software that could consolidate a full backup = plus its incrementals into a synthetic full backup. It'll only do it as = part of a backup job. Grmbl. But then I wouldn't get to play with the = idea of actually storing full backup images for every restore point = using filesystem level snapshots. :)= From owner-freebsd-fs@FreeBSD.ORG Tue May 31 22:57:54 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 40E80106564A for ; Tue, 31 May 2011 22:57:54 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id D6DFE8FC19 for ; Tue, 31 May 2011 22:57:53 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id p4VMvquR001365; Tue, 31 May 2011 17:57:52 -0500 (CDT) Date: Tue, 31 May 2011 17:57:52 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Per von Zweigbergk In-Reply-To: Message-ID: References: User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Tue, 31 May 2011 17:57:52 -0500 (CDT) Cc: freebsd-fs@freebsd.org Subject: Re: Storing revisions of large files using ZFS snapshots 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, 31 May 2011 22:57:54 -0000 On Tue, 31 May 2011, Per von Zweigbergk wrote: > > Basically what would happen is that every night after the backup > completes, rsync would be run, synchronizing over the differences > between the synthetic full backup from the previous day. Historic > copies of the full backup images as synchronized by rsync would be > kept using ZFS snapshots. After our retention window closes, I'd > just nuke the oldest snapshots from the server. This is feasable using rsync's "--inplace --no-whole-file" options, and is what I use as part of my daily backup strategy so that each backup cycle only consumes disk space for the changed blocks. It works fantastically. There is of course some risk associated with these rsync options since if rsync fails, the backup file may only be partially updated. Of course you can re-try the rsync a number of times during the backup interval if rsync fails. If the rsync previously failed (or perhaps always), it is necessary to also supply the expensive --checksum option so that rsync will definitely assure that the file content is correct. This option is expensive since it will force all blocks to be read on both sides. > First of all, will ZFS will do copy-on-write on a block level when > it comes to snapshots, or is copy-on-write on ZFS snapshots done on > a whole-file level? It would seem that block-level COW would be > required for this to even have a chance of working. Please note that > I'm not talking about deduplication in ZFS itself, but rather using > snapshots as a means to perform a crude kind of deduplication. ZFS does copy-on-write for file blocks when the file is updated. There is surely some copy-on-write of zfs metadata when a snapshot is taken, but surely vastly less than the amount of data consumed by the file. Remember that filesystem volumes look like files and they snapshot nicely. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 00:52:23 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B096106566C for ; Wed, 1 Jun 2011 00:52:23 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 81B338FC08 for ; Wed, 1 Jun 2011 00:52:23 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta11.emeryville.ca.mail.comcast.net with comcast id qQns1g0050lTkoCABQsNrM; Wed, 01 Jun 2011 00:52:22 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta04.emeryville.ca.mail.comcast.net with comcast id qQsK1g00T1t3BNj8QQsLL9; Wed, 01 Jun 2011 00:52:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0E418102C19; Tue, 31 May 2011 17:52:19 -0700 (PDT) Date: Tue, 31 May 2011 17:52:19 -0700 From: Jeremy Chadwick To: Per von Zweigbergk Message-ID: <20110601005219.GA11776@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Storing revisions of large files using ZFS snapshots 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, 01 Jun 2011 00:52:23 -0000 On Tue, May 31, 2011 at 10:42:37PM +0200, Per von Zweigbergk wrote: > I'm currently looking at the option of using a FreeBSD server using ZFS to store offsite backups. > > The primary backup product used (Veeam Backup & Replication) stores its backups in what's called reverse-incremental mode. Basically, this means storing backups as a huge VBK file (one for each job) containing a deduplicated and compressed dump of all the virtual machine files being backed up. The system will also store what are known as "reverse incrementals", i.e. anything it overwrites on a backup pass will be preserved in a file, similar to a traditional incremental backup, except in the other direction. > > Since this product does not have any real solutions for offsite backup replication, after considering a few different options, I'm seriously considering using a combination of ZFS snapshots and rsync. > > Basically what would happen is that every night after the backup completes, rsync would be run, synchronizing over the differences between the synthetic full backup from the previous day. Historic copies of the full backup images as synchronized by rsync would be kept using ZFS snapshots. After our retention window closes, I'd just nuke the oldest snapshots from the server. > > [snip] > > Second, are there any other caveats that I'm likely to run into as I go down this path for storing backups? > > Obviously, I'd prefer just trucking over plain old incremental backups, and doing a consolidation job off-site, but the backup software doesn't have any image management software that could consolidate a full backup plus its incrementals into a synthetic full backup. It'll only do it as part of a backup job. Grmbl. But then I wouldn't get to play with the idea of actually storing full backup images for every restore point using filesystem level snapshots. :) Speaking strictly about rsync (in any situation): Please be aware that rsync will destroy your atimes (on both the source and the destination). The --atimes patch doesn't fix this problem either; it copies the atimes from the source to the destination, but destroys the atimes on the source. Why this matters: if you have any software that relies on atimes -- the big one is classic UNIX mail spools (atime is used for new mail detection) -- then your atimes will be lost, and your shell users who use things like mailx/elm/pine/mutt/alpine will start complaining that they had new mail but weren't informed of it. Just something to keep in mind. We live with this problem (in our production infrastructure) despite that. Speaking strictly about ZFS snapshots: The mentality of ZFS snapshots seems very similar to that of UFS snapshots, in the sense that the design/model seems to be oriented towards "bare-metal" restoration. That works generally okay (depends on your view) for administrators, but depending on your demographic, it almost certainly won't work for users. We've found that in most cases, a user will overwrite or rm a file which they didn't mean to and wish to restore just that file. They need to do so quickly and easily. ZFS and UFS snapshots don't make this easy for them to accomplish (ZFS is easier than UFS in this regard, absolutely). In our case, we use rsnapshot (which relies on rsync) to perform backups of systems on a dedicated network, and each system NFS mounts the backup server (mount is read-only). Users totally understand this: $ cd /backups $ ls -l total 60 drwxr-xr-x 16 root wheel 22 May 31 03:59 daily.0/ drwxr-xr-x 16 root wheel 22 May 30 04:02 daily.1/ drwxr-xr-x 16 root wheel 22 May 21 03:57 daily.10/ drwxr-xr-x 16 root wheel 22 May 20 03:59 daily.11/ drwxr-xr-x 16 root wheel 22 May 19 03:58 daily.12/ drwxr-xr-x 16 root wheel 22 May 18 03:59 daily.13/ drwxr-xr-x 16 root wheel 22 May 17 03:57 daily.14/ drwxr-xr-x 16 root wheel 22 May 16 03:59 daily.15/ drwxr-xr-x 16 root wheel 22 May 15 03:58 daily.16/ drwxr-xr-x 16 root wheel 22 May 14 03:58 daily.17/ drwxr-xr-x 16 root wheel 22 May 13 03:57 daily.18/ drwxr-xr-x 16 root wheel 22 May 12 03:57 daily.19/ drwxr-xr-x 16 root wheel 22 May 29 03:58 daily.2/ drwxr-xr-x 16 root wheel 22 May 11 03:59 daily.20/ drwxr-xr-x 16 root wheel 22 May 10 03:59 daily.21/ drwxr-xr-x 16 root wheel 22 May 9 04:02 daily.22/ drwxr-xr-x 16 root wheel 22 May 8 03:58 daily.23/ drwxr-xr-x 16 root wheel 22 May 7 03:56 daily.24/ drwxr-xr-x 16 root wheel 22 May 6 03:58 daily.25/ drwxr-xr-x 16 root wheel 22 May 5 03:59 daily.26/ drwxr-xr-x 16 root wheel 22 May 4 03:56 daily.27/ drwxr-xr-x 16 root wheel 22 May 3 04:00 daily.28/ drwxr-xr-x 16 root wheel 22 May 2 04:02 daily.29/ drwxr-xr-x 16 root wheel 22 May 28 03:58 daily.3/ drwxr-xr-x 16 root wheel 22 May 27 03:59 daily.4/ drwxr-xr-x 16 root wheel 22 May 26 03:58 daily.5/ drwxr-xr-x 16 root wheel 22 May 25 03:59 daily.6/ drwxr-xr-x 16 root wheel 22 May 24 03:58 daily.7/ drwxr-xr-x 16 root wheel 22 May 23 04:01 daily.8/ drwxr-xr-x 16 root wheel 22 May 22 03:57 daily.9/ $ cd daily.9 $ cd home/myaccount/public_html $ cp mywebdocument.html ~/public_html I spent almost 2 months, off and on, trying to explain to one of our customers how to use "restore -i" effectively. The above method is simple and "makes sense", and said customer has used it many, MANY times -- without my assistance. I would also advocate that you review the freebsd-fs and freebsd-stable archives since, say, January of this year, and look for problem reports or issues with ZFS snapshots or zfs send/recv. This is not FUD or attempt to spread misinformation -- each incident/situation is different, yes -- but get an idea of what you *could* encounter and weigh pros/cons. Finally, if you plan on using ZFS at all, please run RELENG_8 and don't stick with the present -RELEASE branch. There are lots of fixes in RELENG_8 which won't exist until 8.3-RELEASE, obviously. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 01:12:06 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37831106566C for ; Wed, 1 Jun 2011 01:12:06 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id F2B838FC1C for ; Wed, 1 Jun 2011 01:12:05 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id p511C4Mr001830; Tue, 31 May 2011 20:12:04 -0500 (CDT) Date: Tue, 31 May 2011 20:12:04 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Jeremy Chadwick In-Reply-To: <20110601005219.GA11776@icarus.home.lan> Message-ID: References: <20110601005219.GA11776@icarus.home.lan> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Tue, 31 May 2011 20:12:04 -0500 (CDT) Cc: freebsd-fs@freebsd.org Subject: Re: Storing revisions of large files using ZFS snapshots 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, 01 Jun 2011 01:12:06 -0000 On Tue, 31 May 2011, Jeremy Chadwick wrote: > > We've found that in most cases, a user will overwrite or rm a file which > they didn't mean to and wish to restore just that file. They need to do > so quickly and easily. ZFS and UFS snapshots don't make this easy for > them to accomplish (ZFS is easier than UFS in this regard, absolutely). It seems easy enough to restore the file from .zfs/snapshot. If users find this too difficult, then a small shell script or GUI program can make it easy. The main annoyance with restoring the file from .zfs/snapshot is that restoring the files in this way may consume more disk space. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 07:10: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 F1E18106564A for ; Wed, 1 Jun 2011 07:10:16 +0000 (UTC) (envelope-from negasi@decayingorbits.com) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by mx1.freebsd.org (Postfix) with ESMTP id C97ED8FC08 for ; Wed, 1 Jun 2011 07:10:16 +0000 (UTC) Received: from panthro.decayingorbits.com ([unknown] [68.48.133.194]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LM300J75L4OEH30@vms173005.mailsrvcs.net> for freebsd-fs@freebsd.org; Wed, 01 Jun 2011 01:10:05 -0500 (CDT) Received: from panthro.decayingorbits.com (panthro [192.168.20.61]) by panthro.decayingorbits.com (Postfix) with ESMTP id 3729EF376 for ; Wed, 01 Jun 2011 02:19:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at decayingorbits.com Received: from panthro.decayingorbits.com ([192.168.20.61]) by panthro.decayingorbits.com (panthro.decayingorbits.com [192.168.20.61]) (amavisd-new, port 10024) with LMTP id cSPvPrcjx3Ag for ; Wed, 01 Jun 2011 02:19:01 -0400 (EDT) Received: from [192.168.20.47] (e5510.decayingorbits.com [192.168.20.47]) by panthro.decayingorbits.com (Postfix) with ESMTPSA id 1871CF369 for ; Wed, 01 Jun 2011 02:19:00 -0400 (EDT) Message-id: <4DE5D7B1.5040902@decayingorbits.com> Date: Wed, 01 Jun 2011 02:09:53 -0400 From: Negasi Gerima User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-version: 1.0 To: freebsd-fs@freebsd.org Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Subject: ZFS on 4K drives - Expanding zpool and adding spares (gnop method) 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, 01 Jun 2011 07:10:17 -0000 Hello, I apologize if this topic is redundant, but I couldn't find an exact answer to my specific question. So here goes. I recently decided to expand the storage in my home server with a bunch of 1.5Tb Samsung 4K hard drives. Using the guide at the following link I was able to use the "gnop method" in order to align the drives for use with 4K sectors: http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.html My question to the list is this, now that my new zpool is created and I've made sure the drives are using the correct layout, how would I go about expanding the zpool in the future with additional drives and/or spares? I emailed the author of the article but received a reply that I found terse at best. I'm assuming that I would have to create a new gnop device for each additional hard drive, and then add those gnop devices to the pool. For example, if I had a pool called 'datastore' and three additional drives /dev/ad10, /dev/ad12, & /dev/ad14. I'm assuming I should use the following steps to achieve my goal: 1. Create the gnop devices /dev/ad10.nop, /dev/ad12.nop, and /dev/ad14.nop, 2. Add these devices to the zpool with 'zpool add datastore /dev/ad10.nop /dev/ad12.nop' 3. Export the zpool with 'zpool export datastore' 4. Destroy gnop devices with 'gnop destroy /dev/da10.nop /dev/da12.nop /dev/da14.nop' 5. Re-import the zpool data with 'zpool import datastore' Can someone please confirm that this method is correct, or if there is a more streamlined method for achieving the desired goal? Thanks in advance, NG From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 08:19:42 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34503106566C for ; Wed, 1 Jun 2011 08:19:42 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id BAB8A8FC34 for ; Wed, 1 Jun 2011 08:19:41 +0000 (UTC) Received: from outgoing.leidinger.net (p5B155DF9.dip.t-dialin.net [91.21.93.249]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id E7087844010; Wed, 1 Jun 2011 10:19:27 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 2A0CC33E0; Wed, 1 Jun 2011 10:19:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1306916365; bh=shvIaJugg/Lm7k465HqiPoGsF7+wTaOfyLdY0D9P8Gs=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=fTSAW+82QqTcY8piuQTYcFppW7F7a4eR6rxyxFURnywoWTXH/JPb5W0wvIXGPim0e U1yH9tL0GXTMZw7ElgAwXVsNzzeS3Z7BbyxrZoGfy6ghQo5YCRmN2JTj0WNsyfFZbG mojwVUVYQhkIc6AyO6YxdTYaqZXDg7OA7lzveoT8cvvyMHgHWkRLNXEFnoJBictgMB 0C1XTvUamJVfTBMDcLuKkcSO698akyBo57VBpeAf9jtzYp15f4OiG9bQ+leEj52Kos e1bmSFrMg85Y1oi8kA+acYXiBfaQq27MUQVJfK0+4/mH1TGiiaBAofA+UN0wFzVJw6 YUK1mbke9+Zvw== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.14.4/Submit) id p518JOs5063679; Wed, 1 Jun 2011 10:19:24 +0200 (CEST) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 01 Jun 2011 10:19:24 +0200 Message-ID: <20110601101924.11334wftbjfrvor0@webmail.leidinger.net> Date: Wed, 01 Jun 2011 10:19:24 +0200 From: Alexander Leidinger To: Negasi Gerima References: <4DE5D7B1.5040902@decayingorbits.com> In-Reply-To: <4DE5D7B1.5040902@decayingorbits.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: E7087844010.A0CDB X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.054, required 6, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, TW_ZD 0.08, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1307521168.89268@SQu9F5RP2TtpahR9Iv17BA X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org Subject: Re: ZFS on 4K drives - Expanding zpool and adding spares (gnop method) 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, 01 Jun 2011 08:19:42 -0000 Quoting Negasi Gerima (from Wed, 01 Jun 2011 02:09:53 -0400): > Hello, > > I apologize if this topic is redundant, but I couldn't find an exact > answer to my specific question. So here goes. > > I recently decided to expand the storage in my home server with a > bunch of 1.5Tb Samsung 4K hard drives. Using the guide at the > following link I was able to use the "gnop method" in order to align > the drives for use with 4K sectors: > > http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.html > > My question to the list is this, now that my new zpool is created > and I've made sure the drives are using the correct layout, how > would I go about expanding the zpool in the future with additional > drives and/or spares? I emailed the author of the article but > received a reply that I found terse at best. > > I'm assuming that I would have to create a new gnop device for each > additional hard drive, and then add those gnop devices to the pool. The 4k-sector part results in a pool specific config setting. I would expect that if you add additional drives (no matter if 4k or not), that the pool will continue to use 4k sectors. So I would expect that you do not need gnop to expend an existing pool, but I have not tested/verified this. You could test this with md(4) devices where you use gnop for the initial creation and no gnop during extending it. When it is extended you just run zdp For example, if I had a pool called 'datastore' and three additional > drives /dev/ad10, /dev/ad12, & /dev/ad14. I'm assuming I should use > the following steps to achieve my goal: > > 1. Create the gnop devices /dev/ad10.nop, /dev/ad12.nop, and /dev/ad14.nop, In general (I'm not sure if it applies to ZFS): If you use ad10pX.nop instead, it should work. If you use gnop on the entire disks instead of on partitions, you may get in trouble depending on where some important metadata is kept (e.g. gpt/gmirror/glabel/... save metadata in the last sector, but the last 4k-gnoped-sector is the 4th last 512b-sector). See http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ for how I create a 4k-safe pool. > 2. Add these devices to the zpool with 'zpool add datastore > /dev/ad10.nop /dev/ad12.nop' > > 3. Export the zpool with 'zpool export datastore' > > 4. Destroy gnop devices with 'gnop destroy /dev/da10.nop > /dev/da12.nop /dev/da14.nop' > > 5. Re-import the zpool data with 'zpool import datastore' > > Can someone please confirm that this method is correct, or if there > is a more streamlined method for achieving the desired goal? This (with partitions instead of the whole disks) is the safe way to do it. Technically it is not necessary to export the pool and destroy the gnop devices. The next reboot will not create the gnop devices and ZFS will pick up the drives based upon a zfs-meta-data search on all geom-providers. Bye, Alexander. -- There is nothing so easy but that it becomes difficult when you do it reluctantly. -- Publius Terentius Afer (Terence) http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 08:26: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 07AC3106566B for ; Wed, 1 Jun 2011 08:26:28 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 89AF48FC14 for ; Wed, 1 Jun 2011 08:26:27 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p518QGsH065038 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 1 Jun 2011 11:26:21 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DE5F7A8.6020300@digsys.bg> Date: Wed, 01 Jun 2011 11:26:16 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110519 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4DE5D7B1.5040902@decayingorbits.com> <20110601101924.11334wftbjfrvor0@webmail.leidinger.net> In-Reply-To: <20110601101924.11334wftbjfrvor0@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS on 4K drives - Expanding zpool and adding spares (gnop method) 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, 01 Jun 2011 08:26:28 -0000 On 01.06.11 11:19, Alexander Leidinger wrote: > > The 4k-sector part results in a pool specific config setting. I would > expect that if you add additional drives (no matter if 4k or not), > that the pool will continue to use 4k sectors. So I would expect that > you do not need gnop to expend an existing pool, but I have not > tested/verified this. > > The ashift property is per-vdev, so you have to use gnop for each new vdev you add to the zpool. You also do not need to create gnop devices for all new drives -- the vdev will use the largest sector size of any member to calculate it's ashift value. For example, creating the pool gnop create -S 4096 disk0 zpool create test mirror disk0.nop disk1 zpool export test gnop destroy disk0.nop zpool import test adding another vdev gnop create -S 4096 disk2 zpool add test mirror disk2.nop disk3 zpool export test gnop destroy disk2.nop zpool import test Daniel From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 11:10:18 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 F146B106564A for ; Wed, 1 Jun 2011 11:10:18 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id AC31D8FC0A for ; Wed, 1 Jun 2011 11:10:18 +0000 (UTC) Received: by yxl31 with SMTP id 31so3236740yxl.13 for ; Wed, 01 Jun 2011 04:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e1LtNq2JyWcYheSs1cvH9Ha6ITi86RpRbGi2ywJGzz0=; b=BLntE23kfrZom5mQvfYfHC7eAc/GnRt2iTcVkuwCZEm5N6FGXtdJY92CNTy8LRwiFY J6SEqM+250jGiQZWTPzHJYQbzY9SSdMJmD63CXUPakbGIH9HKmaOmav/bvCvCspok/WW tUyBgLzQAymbLwnuM9gnYigr1BV5vvQ50aX/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=d+SLnB4zC1B5SjBX8eX1/2SlWg415OaAr9FhYy1IXLyKjFKPXH+YdOpvcJwZzzXj2C j5FcC4/Cmj50mvqGnr+KkOmbod+EUwKxC4eJqB0ray1+Hzt9N2G0RMutT+p81bgIniVw KfYqncNdNq32P9lCbvFU+ASpk4Aa9hOd7j3GE= MIME-Version: 1.0 Received: by 10.236.189.69 with SMTP id b45mr8499677yhn.293.1306926617781; Wed, 01 Jun 2011 04:10:17 -0700 (PDT) Received: by 10.236.110.144 with HTTP; Wed, 1 Jun 2011 04:10:17 -0700 (PDT) In-Reply-To: <4DE5F7A8.6020300@digsys.bg> References: <4DE5D7B1.5040902@decayingorbits.com> <20110601101924.11334wftbjfrvor0@webmail.leidinger.net> <4DE5F7A8.6020300@digsys.bg> Date: Wed, 1 Jun 2011 12:10:17 +0100 Message-ID: From: krad To: Daniel Kalchev Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS on 4K drives - Expanding zpool and adding spares (gnop method) 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, 01 Jun 2011 11:10:19 -0000 On 1 June 2011 09:26, Daniel Kalchev wrote: > > > On 01.06.11 11:19, Alexander Leidinger wrote: > >> >> The 4k-sector part results in a pool specific config setting. I would >> expect that if you add additional drives (no matter if 4k or not), that the >> pool will continue to use 4k sectors. So I would expect that you do not need >> gnop to expend an existing pool, but I have not tested/verified this. >> >> >> The ashift property is per-vdev, so you have to use gnop for each new > vdev you add to the zpool. You also do not need to create gnop devices for > all new drives -- the vdev will use the largest sector size of any member to > calculate it's ashift value. > > For example, creating the pool > > gnop create -S 4096 disk0 > zpool create test mirror disk0.nop disk1 > zpool export test > gnop destroy disk0.nop > zpool import test > > adding another vdev > > gnop create -S 4096 disk2 > zpool add test mirror disk2.nop disk3 > zpool export test > gnop destroy disk2.nop > zpool import test > > Daniel > > _______________________________________________ > 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 concur always use the gnop trick for new devices and you will be ok. Also make sure the gpt layout is 4k aligned From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 11:20:40 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 751C0106566B for ; Wed, 1 Jun 2011 11:20:40 +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 AAB898FC18 for ; Wed, 1 Jun 2011 11:20:39 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA02978; Wed, 01 Jun 2011 14:20:27 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE6207A.4030703@FreeBSD.org> Date: Wed, 01 Jun 2011 14:20:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: krad References: <4DE5D7B1.5040902@decayingorbits.com> <20110601101924.11334wftbjfrvor0@webmail.leidinger.net> <4DE5F7A8.6020300@digsys.bg> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS on 4K drives - Expanding zpool and adding spares (gnop method) 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, 01 Jun 2011 11:20:40 -0000 BTW, you might find this interesting: http://svnweb.freebsd.org/base?view=revision&revision=222520 -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 08:03: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 B84461065672 for ; Wed, 1 Jun 2011 08:03:17 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4D01B8FC1D for ; Wed, 1 Jun 2011 08:03:17 +0000 (UTC) Received: from outgoing.leidinger.net (p5B155DF9.dip.t-dialin.net [91.21.93.249]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 5F755844010; Wed, 1 Jun 2011 10:03:02 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTP id A90E833DE; Wed, 1 Jun 2011 10:02:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1306915379; bh=RK5beXdD6Kqq+xvH3FKBo21pgGgPaaz1OkzrVYPXhMY=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=PcUOCFRnm9wtZ2F9Jn70MCw2m+wTGuBmTil5hrioVx/6aoxHWW9oewiMnoFgAALMx sdjhHfETSk0oGFp2343JBvtBmZjrhDCSzXF1q9NqbziU2KErjhjSpTkJhPJ7D5y91z YEwT9ULEbqVNfpCeEPE2wrwf3jmybCKa3M1QEio7fRbsxF+cLyachB0kOleug+SEh+ e7snkKqI1Xum088sqXLBU8lGKcDj9d6PVCQfQRqsAKfKIgENja+VM1mub69FWg4OhL zCKWkNyroPj57hQBffLW0RAfgbbPrYOVqOBeGy2Wh264PBS52Lc8OMOm5X18hx5TZq +KCsDgqiuWfhA== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.14.4/Submit) id p5182wCa063121; Wed, 1 Jun 2011 10:02:58 +0200 (CEST) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 01 Jun 2011 10:02:58 +0200 Message-ID: <20110601100258.13973yayckqlukvm@webmail.leidinger.net> Date: Wed, 01 Jun 2011 10:02:58 +0200 From: Alexander Leidinger To: Jeremy Chadwick References: <20110601005219.GA11776@icarus.home.lan> In-Reply-To: <20110601005219.GA11776@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 5F755844010.AF434 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.023, required 6, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1307520182.95214@k+qRlncsbzoas76I74rm1g X-EBL-Spam-Status: No X-Mailman-Approved-At: Wed, 01 Jun 2011 11:30:17 +0000 Cc: freebsd-fs@freebsd.org Subject: Re: Storing revisions of large files using ZFS snapshots 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, 01 Jun 2011 08:03:17 -0000 Quoting Jeremy Chadwick (from Tue, 31 May 2011 17:52:19 -0700): > Speaking strictly about ZFS snapshots: > > The mentality of ZFS snapshots seems very similar to that of UFS > snapshots, in the sense that the design/model seems to be oriented > towards "bare-metal" restoration. > > That works generally okay (depends on your view) for administrators, > but depending on your demographic, it almost certainly won't work for > users. > > We've found that in most cases, a user will overwrite or rm a file which > they didn't mean to and wish to restore just that file. They need to do > so quickly and easily. ZFS and UFS snapshots don't make this easy for > them to accomplish (ZFS is easier than UFS in this regard, absolutely). What's hard about doing a cp /path/to/fs/.zfs/snapshot/snap_name/subdir/file /path/to/fs/subdir/ ? If it is hard for the user to determine what is the base dataset for his current place, you could provide a zfs restore script (requirement of the following, feel free to adapt: user is in the dir where he wants to restore, commands not really tested, errors not handled): - zfsrestore list -> base=$(df . | awk '/Mounted on/ {next} {print $6}') -> echo Available snapshots -> ls -1 ${base}/.zfs/snapshot - zfs restore -> base=$(df . | awk '/Mounted on/ {next} {print $6}') -> reminder=$(echo $PWD | sed -e "s:${base}/::g") -> cp -v ${base}/.zfs/snapshot/$arg1/${reminder}/$arg2 . Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 14:31: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 B96911065670; Wed, 1 Jun 2011 14:31:36 +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 D71A38FC0A; Wed, 1 Jun 2011 14:31:35 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA06935; Wed, 01 Jun 2011 17:31:34 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE64D45.5060100@FreeBSD.org> Date: Wed, 01 Jun 2011 17:31:33 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Artem Belevich References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> <4DE51DD3.6040602@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 01 Jun 2011 14:31:36 -0000 on 31/05/2011 22:21 Artem Belevich said the following: > On Tue, May 31, 2011 at 12:07 PM, David P Discher wrote: >> And from the conversation on this thread, there isn't any agreement on how to really fix it. > Andriy has proposed potential fix that would eliminate multiplication > of gethrtime result by hz and would delay overflow by few hundred > years. Should be good enough. Yeah, and here is a patch that implements the proposal (for head): http://people.freebsd.org/~avg/osol-lbolt.diff -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 14:55:54 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 76F06106564A; Wed, 1 Jun 2011 14:55:54 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1ADCE8FC14; Wed, 1 Jun 2011 14:55:53 +0000 (UTC) Received: by gwb15 with SMTP id 15so3367449gwb.13 for ; Wed, 01 Jun 2011 07:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ul/33iDx1oNPNA9nayXMqeU41vdtz2lbtCITGakEVA4=; b=aJ3gI4WdEAuik+kVTRNJlMHestauvv0jm2gZ3APha6ezApKSSX9nkY3cVNRayI23YM Pfa5e48E1QhckRybLcM6VhyNCyfefxzJ4glkjYoSOH40uP0crKb5DthH67g6VqU/a9lO wkzS9EqtJQ9if/4wRnvIEnBYNLUjWc/HSYSyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=a5rM6+0efI0TJ7KX9Anus/QVyKktsWg5V3buHDun7zw4A6ItcNErsncrVFqpnFR8D0 wpxB/9TDkG884xvDij40p/J519N2vvmN2inmcMTofo1G9TOA6JmE/VLej2+wOM1wbm/C r0xn6ncVzcZtr09lO6OWGT206IfFhxaLI0l5s= MIME-Version: 1.0 Received: by 10.236.193.105 with SMTP id j69mr6003032yhn.384.1306940153095; Wed, 01 Jun 2011 07:55:53 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.208.70 with HTTP; Wed, 1 Jun 2011 07:55:53 -0700 (PDT) In-Reply-To: <4DE64D45.5060100@FreeBSD.org> References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> <4DE51DD3.6040602@FreeBSD.org> <4DE64D45.5060100@FreeBSD.org> Date: Wed, 1 Jun 2011 07:55:53 -0700 X-Google-Sender-Auth: u-yUCLhvlA86JexNR39zUYDDb2o Message-ID: From: Artem Belevich To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 01 Jun 2011 14:55:54 -0000 On Wed, Jun 1, 2011 at 7:31 AM, Andriy Gapon wrote: > on 31/05/2011 22:21 Artem Belevich said the following: >> On Tue, May 31, 2011 at 12:07 PM, David P Discher wrote: >>> And from the conversation on this thread, there isn't any agreement on how to really fix it. >> Andriy has proposed potential fix that would eliminate multiplication >> of gethrtime result by hz and would delay overflow by few hundred >> years. Should be good enough. > > Yeah, and here is a patch that implements the proposal (for head): > http://people.freebsd.org/~avg/osol-lbolt.diff I would keep nsec_per_tick as a static local variable in ddi_get_lbolt64 and init it conditionally if it's zero for the sake of keeping all the magic in once place. I have a hypothetical question. In a non-tickless kernel there is a natural limit on hz imposed by overhead of processing periodis interrupts. Now that we're event-driven, is there any chance that hz could grow larger than 1000000? --Artem From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 16:10:12 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 66C2E1065675; Wed, 1 Jun 2011 16:10:12 +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 807828FC15; Wed, 1 Jun 2011 16:10:11 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA08418; Wed, 01 Jun 2011 19:10:09 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DE66461.6040202@FreeBSD.org> Date: Wed, 01 Jun 2011 19:10:09 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Artem Belevich References: <0EFD28CD-F2E9-4AE2-B927-1D327EC99DB9@bitgravity.com> <4DE50811.5060606@FreeBSD.org> <4DE51DD3.6040602@FreeBSD.org> <4DE64D45.5060100@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: arc_reclaim_thread running 100%, 8.1-RELEASE, LBOLT related 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, 01 Jun 2011 16:10:12 -0000 on 01/06/2011 17:55 Artem Belevich said the following: > On Wed, Jun 1, 2011 at 7:31 AM, Andriy Gapon wrote: >> on 31/05/2011 22:21 Artem Belevich said the following: >>> On Tue, May 31, 2011 at 12:07 PM, David P Discher wrote: >>>> And from the conversation on this thread, there isn't any agreement on how to really fix it. >>> Andriy has proposed potential fix that would eliminate multiplication >>> of gethrtime result by hz and would delay overflow by few hundred >>> years. Should be good enough. >> >> Yeah, and here is a patch that implements the proposal (for head): >> http://people.freebsd.org/~avg/osol-lbolt.diff > > I would keep nsec_per_tick as a static local variable in > ddi_get_lbolt64 and init it conditionally if it's zero for the sake of > keeping all the magic in once place. I don't like having a static variable in a static inline function (used over many files even). > I have a hypothetical question. In a non-tickless kernel there is a > natural limit on hz imposed by overhead of processing periodis > interrupts. > Now that we're event-driven, We are not completely there yet, I think. > is there any chance that hz could grow > larger than 1000000? In a completely event driven system hz just doesn't make any sense. It can be provided for transitioning some old code, which still goes back and forth between ticks and actual time. In that case one can probably set hz to almost an arbitrary value, but I don't see what could be gained with increasing it. But I see where it can hurt :) In other words, I won't be bothered to worry about this now. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Jun 1 17:00:23 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 D008B106564A for ; Wed, 1 Jun 2011 17:00:23 +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 A6A318FC13 for ; Wed, 1 Jun 2011 17:00:23 +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 p51H0Ngf085601 for ; Wed, 1 Jun 2011 17:00:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p51H0NHK085600; Wed, 1 Jun 2011 17:00:23 GMT (envelope-from gnats) Date: Wed, 1 Jun 2011 17:00:23 GMT Message-Id: <201106011700.p51H0NHK085600@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/155484: [ufs] GPT + UFS boot don't work well together X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 17:00:23 -0000 The following reply was made to PR kern/155484; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, rarehawk@gmail.com Cc: Subject: Re: kern/155484: [ufs] GPT + UFS boot don't work well together Date: Wed, 01 Jun 2011 19:57:40 +0300 I have tried with 8GB swap partition size and still couldn't reproduce the problem. I am going to close this PR. Layout of my test setup: $ gpart show zvol/pond/zvol5 => 34 20971453 zvol/pond/zvol5 GPT (10G) 34 128 1 freebsd-boot (64k) 162 16777216 2 freebsd-swap (8.0G) 16777378 4194109 3 freebsd-ufs (2G) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 01:10:12 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 1E63D106564A for ; Thu, 2 Jun 2011 01:10:12 +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 1052B8FC08 for ; Thu, 2 Jun 2011 01:10:12 +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 p521ABnZ033016 for ; Thu, 2 Jun 2011 01:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p521ABjN033015; Thu, 2 Jun 2011 01:10:11 GMT (envelope-from gnats) Date: Thu, 2 Jun 2011 01:10:11 GMT Message-Id: <201106020110.p521ABjN033015@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Ryan Steinmetz Cc: Subject: Re: kern/144929: [lor] vfs_bio.c + ufs_dirhash.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ryan Steinmetz List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 01:10:12 -0000 The following reply was made to PR kern/144929; it has been noted by GNATS. From: Ryan Steinmetz To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/144929: [lor] vfs_bio.c + ufs_dirhash.c Date: Wed, 1 Jun 2011 21:02:26 -0400 This is from FreeBSD-9.0-CURRENT-201105, under ESX4i: freebsd9# uname -a FreeBSD freebsd9 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu May 12 11:28:09 UTC 2011 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Jun 2 00:52:39 freebsd9 kernel: lock order reversal: Jun 2 00:52:39 freebsd9 kernel: 1st 0xc2a3aaf8 isofs (isofs) @ /usr/src/sys/kern/vfs_mount.c:1193 Jun 2 00:52:39 freebsd9 kernel: 2nd 0xc2a3c168 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1267 Jun 2 00:52:39 freebsd9 kernel: KDB: stack backtrace: Jun 2 00:52:39 freebsd9 kernel: db_trace_self_wrapper(c0e8047a,7366662f,7366765f,2e73706f,32313a63,...) at db_trace_self_wrapper+0x26 Jun 2 00:52:39 freebsd9 kernel: kdb_backtrace(c09ddcdb,c0e83cff,c2568a48,c25689e0,c739e9ac,...) at kdb_backtrace+0x2a Jun 2 00:52:39 freebsd9 kernel: _witness_debugger(c0e83cff,c2a3c168,c0e6b68b,c25689e0,c0eb124c,...) at _witness_debugger+0x25 Jun 2 00:52:39 freebsd9 kernel: witness_checkorder(c2a3c168,9,c0eb124c,4f3,c2a3c188,...) at witness_checkorder+0x839 Jun 2 00:52:39 freebsd9 kernel: __lockmgr_args(c2a3c168,80400,c2a3c188,0,0,...) at __lockmgr_args+0x804 Jun 2 00:52:39 freebsd9 kernel: vop_stdlock(c739eacc,c2a3c1bc,c739eac4,80400,c2a3c110,...) at vop_stdlock+0x62 Jun 2 00:52:39 freebsd9 kernel: VOP_LOCK1_APV(c0f85ec0,c739eacc,c299f000,c0fca6a0,c2a3c110,...) at VOP_LOCK1_APV+0xb5 Jun 2 00:52:39 freebsd9 kernel: _vn_lock(c2a3c110,80400,c0eb124c,4f3,c27c5400,...) at _vn_lock+0x5e Jun 2 00:52:39 freebsd9 kernel: ffs_flushfiles(c28e5510,2,c28ce5c0,59f,3,...) at ffs_flushfiles+0xa7 Jun 2 00:52:39 freebsd9 kernel: softdep_flushfiles(c28e5510,2,c28ce5c0,0,c0fca6c0,...) at softdep_flushfiles+0x2e Jun 2 00:52:39 freebsd9 kernel: ffs_unmount(c28e5510,80000,c739ebc0,4ee,c739ebcc,...) at ffs_unmount+0x149 Jun 2 00:52:39 freebsd9 kernel: dounmount(c28e5510,80000,c28ce5c0,c221762c,0,...) at dounmount+0x466 Jun 2 00:52:39 freebsd9 kernel: vfs_unmountall(c0e7c3b9,0,c0e7c307,12f,c28ce5c0,...) at vfs_unmountall+0x4e Jun 2 00:52:39 freebsd9 kernel: kern_reboot(0,0,c0e7c307,b2,c28c8000,...) at kern_reboot+0x450 Jun 2 00:52:39 freebsd9 kernel: reboot(c28ce5c0,c739ecec,c739ed80,c739ec88,0,...) at reboot+0x6c Jun 2 00:52:39 freebsd9 kernel: syscallenter(c28ce5c0,c739ece4,c0ccb2f6,3,c10148c0,...) at syscallenter+0x263 Jun 2 00:52:39 freebsd9 kernel: syscall(c739ed28) at syscall+0x34 Jun 2 00:52:39 freebsd9 kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21 Jun 2 00:52:39 freebsd9 kernel: --- syscall (55, FreeBSD ELF32, reboot), eip = 0x280b8ccb, esp = 0xbfbfec8c, ebp = 0xbfbfedd8 --- Jun 2 00:58:38 freebsd9 kernel: lock order reversal: Jun 2 00:58:38 freebsd9 kernel: 1st 0xc225db78 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 Jun 2 00:58:38 freebsd9 kernel: 2nd 0xc2721800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 Jun 2 00:58:38 freebsd9 kernel: KDB: stack backtrace: Jun 2 00:58:38 freebsd9 kernel: db_trace_self_wrapper(c0e8047a,7366752f,7366752f,7269645f,68736168,...) at db_tra Jun 2 00:58:38 freebsd9 kernel: ce_self_wrapper+0x26 Jun 2 00:58:38 freebsd9 kernel: kdb_backtrace(c09ddcdb,c0e83cff,c25652a0,c2568b18,ccffd7e8,...) at Jun 2 00:58:38 freebsd9 kernel: kdb_backtrace+0x2a Jun 2 00:58:38 freebsd9 kernel: _witness_debugger(c0e83cff,c2721800,c0eb20ae,c2568b18,c0eb1d33,...) at Jun 2 00:58:38 freebsd9 kernel: _witness_debugger+0x25 Jun 2 00:58:38 freebsd9 kernel: witness_checkorder(c2721800,9,c0eb1d33,11c,0,...) at witness_checkorder+0x839 Jun 2 00:58:38 freebsd9 kernel: _ Jun 2 00:58:38 freebsd9 kernel: sx_xlock(c2721800,0,c0eb1d33,11c,c2bf015c,...) at _s Jun 2 00:58:38 freebsd9 kernel: x_xlock+0x85 Jun 2 00:58:38 freebsd9 kernel: ufsdirhash_acquire(c225db18,c8138800,200,c8138814,ccffd8b8,...) at ufsdirhash_acq Jun 2 00:58:38 freebsd9 kernel: uire+0x35 Jun 2 00:58:38 freebsd9 kernel: ufsdirhash_add(c2bf015c,ccffd914,814,ccffd8a4,ccffd8a8,...) at ufsdirhash_add+0x13 Jun 2 00:58:38 freebsd9 kernel: ufs_direnter(c2bf9990,c2c27440,ccffd914,ccffdba4,0,...) at ufs_direnter+0x6f9 Jun 2 00:58:38 freebsd9 kernel: ufs_makeinode(ccffdba4,0,ccffdb00,ccffda5c,c0cecb55,...) at ufs_makeinode+0x557 Jun 2 00:58:38 freebsd9 kernel: ufs_create(ccffdb00,ccffdb18,0,0,ccffdb78,...) at ufs_create+0x30 Jun 2 00:58:38 freebsd9 kernel: VOP_CREATE_APV(c0faf7c0,ccffdb00,ccffdba4,ccffda98,0,...) at VOP_CREATE_APV+0xa5 Jun 2 00:58:38 freebsd9 kernel: vn_open_cred(ccffdb78,ccffdc2c,1a4,0,c2bcd500,...) at vn_open_cred+0x215 Jun 2 00:58:38 freebsd9 kernel: vn_open(ccffdb78,ccffdc2c,1a4,c2909070,0,...) at vn_open+0x3b Jun 2 00:58:38 freebsd9 kernel: kern_openat(c2a9ab80,ffffff9c,28414180,0,a02,...) at kern_openat+0x12f Jun 2 00:58:38 freebsd9 kernel: kern_open(c2a9ab80,28414180,0,a01,1a4,...) at kern_open+0x35 Jun 2 00:58:38 freebsd9 kernel: open(c2a9ab80,ccffdcec,ccffdd28,c0e825f6,0,...) at open+0x30 Jun 2 00:58:38 freebsd9 kernel: syscallenter(c2a9ab80,ccffdce4,ccffdce4,2,c10148c0,...) at syscallenter+0x263 Jun 2 00:58:38 freebsd9 kernel: syscall(ccffdd28) at syscall+0x34 Jun 2 00:58:38 freebsd9 kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21 Jun 2 00:58:38 freebsd9 kernel: --- syscall (5, FreeBSD ELF32, open), eip = 0x283706a3, esp = 0xbfbfe6dc, ebp = 0xbfbfe708 --- From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 09:16: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 173571065676; Thu, 2 Jun 2011 09:16:22 +0000 (UTC) (envelope-from yurius.r@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id DF25A8FC13; Thu, 2 Jun 2011 09:16:21 +0000 (UTC) Received: by pvg11 with SMTP id 11so388129pvg.13 for ; Thu, 02 Jun 2011 02:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=qvrrlF+6TZkGxp8YGqe+BPvbWmCy8YFyPDHmcNuYcdg=; b=RRX3j0r/MWQkpDqQxU9z3zS2abHiTkkLZXF0SLnIipebiDBsDT/w4f84jSW/lCL6T9 EjlwEJ5PIjtyfEUenr6i9Zn8ChGU9MjagPnRXKMY4ARl+ZyrrSXpwLoAstXip+WNiS97 LjbnUZRit1pALF9s15YzalyMVK7pXnih+vnhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=fmNtBn/hZiBDLLCKlxZP2cjBAy9CuWT02I37LgYttu1O1Bgj+x1Z0Pvd5Vd4RAN4ez tGarSzGkscjef1J9CyQQAqpGQoxOxOiwoYf3pyLEO4vtqwKx4lU4L824/zkC56i3s37F a73MP9vTmgzYjp5Nk9aDrpCRLgW7xO6h4YB90= Received: by 10.143.154.11 with SMTP id g11mr89502wfo.38.1307004466101; Thu, 02 Jun 2011 01:47:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.111.7 with HTTP; Thu, 2 Jun 2011 01:47:26 -0700 (PDT) From: Yurius Radomskyi Date: Thu, 2 Jun 2011 11:47:26 +0300 Message-ID: To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: hast syncronization speed issue 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, 02 Jun 2011 09:16:22 -0000 Hi, I have a HAST device set up between two systems. I experience very low speed with dirty blocks synchronization after split-brain condition been recovered: it's 200KB/s average on 1Gbit link. On the other side, when i copy a big file to the zfs partition that is created on top of the hast device the synchronization speed between the host is 50MB/s (wich is not too high for 1Gbit link, but acceptable.) uname -a FreeBSD rest 8.2-STABLE FreeBSD 8.2-STABLE #3: Tue May 31 18:51:19 EEST 2011 root@rest:/usr/obj/usr/src/sys/GENERIC amd64 Both systems have the same hardware and FreeBSD version. cat /etc/hast.conf resource mirror0 { local /dev/mfid0s3 on rest2 { remote 192.168.1.51 } on rest { remote 192.168.1.52 } } hastctl status mirror0: role: primary provname: mirror0 localpath: /dev/mfid0s3 extentsize: 2097152 (2.0MB) keepdirty: 64 remoteaddr: 192.168.3.53 replication: fullsync status: complete dirty: 26944208896 (25GB) df -h Filesystem Size Used Avail Capacity Mounted on failover 34G 31G 2.9G 91% /failover The /dev/mfid0s3 size is 34G, and synchronization has been running for 19 hours and still 25G remaining. That's terribly slow! What could be the reason of that? The other question that bothers me is that i filled the partition to 91% and it was written to the secondary host (at list the data was transfered to the secondary host at rate 50MB/s), but hast still showed all 34G of data as dirty after the copying. Why is that so? P.S. I am not in the list, so please, CC From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 13:49:20 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9430106564A; Thu, 2 Jun 2011 13:49:20 +0000 (UTC) (envelope-from a.smith@ukgrid.net) Received: from mx1.ukgrid.net (mx1.ukgrid.net [89.107.22.36]) by mx1.freebsd.org (Postfix) with ESMTP id 950B08FC13; Thu, 2 Jun 2011 13:49:20 +0000 (UTC) Received: from [89.21.28.38] (port=13796 helo=omicron.ukgrid.net) by mx1.ukgrid.net with esmtp (Exim 4.74; FreeBSD) envelope-from a.smith@ukgrid.net id 1QS8H1-0008CY-3k; Thu, 02 Jun 2011 14:49:19 +0100 Received: from 39757.net (39757.net [89.107.23.11]) by webmail2.ukgrid.net (Horde Framework) with HTTP; Thu, 02 Jun 2011 14:49:18 +0100 Message-ID: <20110602144918.84967ciu5vlp66o8@webmail2.ukgrid.net> Date: Thu, 02 Jun 2011 14:49:18 +0100 From: a.smith@ukgrid.net To: avg@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) / FreeBSD-8.1 Cc: freebsd-fs@freebsd.org Subject: RE: ZFS on 4K drives - Expanding zpool and adding spares (gnop method) 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, 02 Jun 2011 13:49:20 -0000 > BTW, you might find this interesting: > http://svnweb.freebsd.org/base?view=revision&revision=222520 Thanks Andriy. So will this cause any identified ada disk to be treated as 4K by FreeBSD for all operations? Ie under UFS, ZFS etc? Will be great! cheers Andy. From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 14:12:02 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 212AC1065670; Thu, 2 Jun 2011 14:12:02 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EEE4B8FC12; Thu, 2 Jun 2011 14:12:01 +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 p52EC14G090991; Thu, 2 Jun 2011 14:12:01 GMT (envelope-from avg@freefall.freebsd.org) Received: (from avg@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p52EC1BA090987; Thu, 2 Jun 2011 14:12:01 GMT (envelope-from avg) Date: Thu, 2 Jun 2011 14:12:01 GMT Message-Id: <201106021412.p52EC1BA090987@freefall.freebsd.org> To: rarehawk@gmail.com, avg@FreeBSD.org, freebsd-fs@FreeBSD.org From: avg@FreeBSD.org Cc: Subject: Re: kern/155484: [ufs] GPT + UFS boot don't work well together 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, 02 Jun 2011 14:12:02 -0000 Synopsis: [ufs] GPT + UFS boot don't work well together State-Changed-From-To: open->closed State-Changed-By: avg State-Changed-When: Thu Jun 2 14:11:44 UTC 2011 State-Changed-Why: Works for me. http://www.freebsd.org/cgi/query-pr.cgi?pr=155484 From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 14:13:35 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69436106568C for ; Thu, 2 Jun 2011 14:13:35 +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 26CF98FC19 for ; Thu, 2 Jun 2011 14:13:35 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QS8eU-0001ZJ-52 for freebsd-fs@freebsd.org; Thu, 02 Jun 2011 16:13:34 +0200 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 ; Thu, 02 Jun 2011 16:13:34 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Jun 2011 16:13:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Thu, 02 Jun 2011 16:13:18 +0200 Lines: 15 Message-ID: References: <20110602144918.84967ciu5vlp66o8@webmail2.ukgrid.net> 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: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <20110602144918.84967ciu5vlp66o8@webmail2.ukgrid.net> X-Enigmail-Version: 1.1.2 Subject: Re: ZFS on 4K drives - Expanding zpool and adding spares (gnop method) 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, 02 Jun 2011 14:13:35 -0000 On 02/06/2011 15:49, a.smith@ukgrid.net wrote: >> BTW, you might find this interesting: >> http://svnweb.freebsd.org/base?view=revision&revision=222520 > > > Thanks Andriy. > > So will this cause any identified ada disk to be treated as 4K by > FreeBSD for all operations? Ie under UFS, ZFS etc? Will be great! No, it's a first step but file systems need to be adapted to use it. On the other hand, UFS has been modified to use 4K by default, and gpart will probably get support for warnings in case of misalignment very soon. From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 15:19:12 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 8C209106566C for ; Thu, 2 Jun 2011 15:19:12 +0000 (UTC) (envelope-from a.smith@ukgrid.net) Received: from mx0.ukgrid.net (mx0.ukgrid.net [89.21.28.41]) by mx1.freebsd.org (Postfix) with ESMTP id 5243C8FC1F for ; Thu, 2 Jun 2011 15:19:12 +0000 (UTC) Received: from [89.21.28.38] (port=16726 helo=omicron.ukgrid.net) by mx0.ukgrid.net with esmtp (Exim 4.74; FreeBSD) envelope-from a.smith@ukgrid.net envelope-to freebsd-fs@freebsd.org id 1QS9fy-000J4O-Fd; Thu, 02 Jun 2011 16:19:10 +0100 Received: from 39757.net (39757.net [89.107.23.11]) by webmail2.ukgrid.net (Horde Framework) with HTTP; Thu, 02 Jun 2011 16:19:10 +0100 Message-ID: <20110602161910.12495tpvv262q2kg@webmail2.ukgrid.net> Date: Thu, 02 Jun 2011 16:19:10 +0100 From: a.smith@ukgrid.net To: freebsd-fs@freebsd.org References: <20110602144918.84967ciu5vlp66o8@webmail2.ukgrid.net> In-Reply-To: <20110602144918.84967ciu5vlp66o8@webmail2.ukgrid.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) / FreeBSD-8.1 Subject: RE: ZFS on 4K drives - Expanding zpool and adding spares (gnop method) 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, 02 Jun 2011 15:19:12 -0000 Quoting ivoras at freebsd.org: > No, it's a first step but file systems need to be adapted to use it. > Ok, well I think it should be very simple to update ZFS as ZFS is already 4K compatible, it just doesn't expect the disks to lie about their real sector size. Bold statement from someone who hasn't studied any ZFS code maybe! lol Fingers crossed it can get done soonish! thanks Andy. From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 17:39: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 3197C106564A for ; Thu, 2 Jun 2011 17:39:28 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 575168FC08 for ; Thu, 2 Jun 2011 17:39:27 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QSBE0-0000aU-Eg for freebsd-fs@freebsd.org; Thu, 02 Jun 2011 18:58:36 +0200 Message-ID: <4DE7C122.2040004@it4pro.pl> Date: Thu, 02 Jun 2011 18:58:10 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.0 X-Spam-Score-Int: -79 X-Exim-Version: 4.76 (build at 12-May-2011 10:41:54) X-Date: 2011-06-02 18:58:36 X-Connected-IP: 78.8.144.74:49615 X-Message-Linecount: 655 X-Body-Linecount: 644 X-Message-Size: 30795 X-Body-Size: 30324 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [ZFSv28] Loader hangs, import failes, zfs filesystem 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: Thu, 02 Jun 2011 17:39:28 -0000 Hi list, Today I needed to shut down my home server (FreeSBD9-CURRENT, 3 x 40GB ATA HDD in RADZ1, ZFS only, GPT, i386) for a moment. After power up, loader started to spin cursor indifinitely, and didn't load the kernel. No error messages, no hints, just spinning cursor. I tried booting from other HDDs in case that bootstrap area errors on single hdd but no luck. I wanted to play with latest current LiveFS snapshot (with ZFSv28 support), but apparently latest one is from february?? Finally I ended with mfsBSD from http://mfsbsd.vx.sk/ I've downloaded "8.2-RELEASE-i386 with ZFSv28 special edition " iso, burned it and booted machine. Here's what happened when i was trying to import zpool: mfsbsd# zpool status no pools available mfsbsd# zpool import pool: zroot id: 16074929158756467860 state: ONLINE status: The pool was last accessed by another system. action: The pool can be imported using its name or numeric identifier and the '-f' flag. see: http://www.sun.com/msg/ZFS-8000-EY config: zroot ONLINE raidz1-0 ONLINE gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE mfsbsd# zpool import -f zroot cannot import 'zroot': one or more devices is currently unavailable There was also some kernel messages while running zpool commands, they are visible at the end of dmesg output: mfsbsd# dmesg Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RELEASE #2 r219081M: Wed Mar 2 10:29:25 CET 2011 root@www4:/usr/obj/i386/usr/src_v28/sys/GENERIC i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: mobile AMD Athlon(tm) XP 2200+ (1800.08-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Family = 6 Model = 8 Stepping = 1 Features=0x383fbff AMD Features=0xc0480800 real memory = 2147483648 (2048 MB) avail memory = 2053263360 (1958 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 128M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xdfe80000-0xdfefffff,0xd0000000-0xd7ffffff irq 16 at device 0.0 on pci1 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xec00-0xec7f mem 0xdfffff80-0xdfffffff irq 17 at device 6.0 on pci0 miibus0: on xl0 xlphy0: <3Com internal media interface> PHY 24 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, auto, auto-flow xl0: Ethernet address: 00:50:da:d8:23:cd xl0: [ITHREAD] rl0: port 0xe800-0xe8ff mem 0xdffffe00-0xdffffeff irq 18 at device 7.0 on pci0 miibus1: on rl0 rlphy0: PHY 0 on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:40:f4:b4:e9:3c rl0: [ITHREAD] uhci0: port 0xdc00-0xdc1f irq 21 at device 16.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xe000-0xe01f irq 21 at device 16.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0xe400-0xe41f irq 21 at device 16.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xdffffd00-0xdffffdff irq 21 at device 16.3 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 17.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 17.6 (no driver attached) acpi_button1: on acpi0 fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc9fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 acpi_throttle0: on cpu0 powernow0: on cpu0 device_attach: powernow0 attach returned 6 Timecounter "TSC" frequency 1800078810 Hz quality 800 Timecounters tick every 1.000 msec md0: Preloaded image 33923072 bytes at 0xc0fd9834 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ad0: 39205MB at ata0-master UDMA133 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ad1: 38166MB at ata0-slave UDMA100 ad2: 39205MB at ata1-master UDMA133 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered acd0: DVDROM at ata1-slave UDMA33 uhub3: 6 ports with 6 removable, self powered acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 Trying to mount root from ufs:/dev/md0 ZFS NOTICE: Prefetch is disabled by default on i386 -- to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. ZFS filesystem version 5 ZFS storage pool version 28 log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented And here is gpart output: mfsbsd# gpart show => 34 80293181 ad0 GPT (38G) 34 128 1 freebsd-boot (64K) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) 78165327 2127888 - free - (1.0G) => 34 78165293 ad1 GPT (37G) 34 128 1 freebsd-boot (64K) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) => 34 80293181 ad2 GPT (38G) 34 128 1 freebsd-boot (64K) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) 78165327 2127888 - free - (1.0G) Any idea what happened to the pool, why I am unable to boot and import it, and what can I do to investigate or fix this issue? -- Bartosz Stec From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 18:21: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 A935F1065783 for ; Thu, 2 Jun 2011 18:21:01 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id CD3158FC15 for ; Thu, 2 Jun 2011 18:21:00 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QSCVl-0000pK-Aa for freebsd-fs@freebsd.org; Thu, 02 Jun 2011 20:20:59 +0200 Message-ID: <4DE7D47A.5070105@it4pro.pl> Date: Thu, 02 Jun 2011 20:20:42 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4DE7C122.2040004@it4pro.pl> In-Reply-To: <4DE7C122.2040004@it4pro.pl> X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.76 (build at 12-May-2011 10:41:54) X-Date: 2011-06-02 20:20:59 X-Connected-IP: 78.8.144.74:51043 X-Message-Linecount: 980 X-Body-Linecount: 967 X-Message-Size: 35749 X-Body-Size: 35191 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: [ZFSv28] Loader hangs, import failes, zfs filesystem 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: Thu, 02 Jun 2011 18:21:01 -0000 W dniu 2011-06-02 18:58, Bartosz Stec pisze: > Hi list, > Today I needed to shut down my home server (FreeSBD9-CURRENT, 3 x 40GB > ATA HDD in RADZ1, ZFS only, GPT, i386) for a moment. After power up, > loader started to spin cursor indifinitely, and didn't load the > kernel. No error messages, no hints, just spinning cursor. > I tried booting from other HDDs in case that bootstrap area errors on > single hdd but no luck. > I wanted to play with latest current LiveFS snapshot (with ZFSv28 > support), but apparently latest one is from february?? > Finally I ended with mfsBSD from http://mfsbsd.vx.sk/ > I've downloaded "8.2-RELEASE-i386 with ZFSv28 special edition > " iso, burned > it and booted machine. Here's what happened when i was trying to > import zpool: > > mfsbsd# zpool status > no pools available > mfsbsd# zpool import > pool: zroot > id: 16074929158756467860 > state: ONLINE > status: The pool was last accessed by another system. > action: The pool can be imported using its name or numeric > identifier and > the '-f' flag. > see: http://www.sun.com/msg/ZFS-8000-EY > config: > > zroot ONLINE > raidz1-0 ONLINE > gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE > gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE > gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE > mfsbsd# zpool import -f zroot > cannot import 'zroot': one or more devices is currently unavailable > > There was also some kernel messages while running zpool commands, they > are visible at the end of dmesg output: > > mfsbsd# dmesg > Copyright (c) 1992-2011 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.2-RELEASE #2 r219081M: Wed Mar 2 10:29:25 CET 2011 > root@www4:/usr/obj/i386/usr/src_v28/sys/GENERIC i386 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: mobile AMD Athlon(tm) XP 2200+ (1800.08-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x681 Family = 6 Model = 8 > Stepping = 1 > > Features=0x383fbff > AMD Features=0xc0480800 > real memory = 2147483648 (2048 MB) > avail memory = 2053263360 (1958 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: on hostb0 > agp0: aperture size is 128M > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: mem > 0xdfe80000-0xdfefffff,0xd0000000-0xd7ffffff irq 16 at device 0.0 on > pci1 > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xec00-0xec7f mem > 0xdfffff80-0xdfffffff irq 17 at device 6.0 on pci0 > miibus0: on xl0 > xlphy0: <3Com internal media interface> PHY 24 on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, auto, auto-flow > xl0: Ethernet address: 00:50:da:d8:23:cd > xl0: [ITHREAD] > rl0: port 0xe800-0xe8ff mem > 0xdffffe00-0xdffffeff irq 18 at device 7.0 on pci0 > miibus1: on rl0 > rlphy0: PHY 0 on miibus1 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > rl0: Ethernet address: 00:40:f4:b4:e9:3c > rl0: [ITHREAD] > uhci0: port 0xdc00-0xdc1f irq 21 at > device 16.0 on pci0 > uhci0: [ITHREAD] > usbus0: on uhci0 > uhci1: port 0xe000-0xe01f irq 21 at > device 16.1 on pci0 > uhci1: [ITHREAD] > usbus1: on uhci1 > uhci2: port 0xe400-0xe41f irq 21 at > device 16.2 on pci0 > uhci2: [ITHREAD] > usbus2: on uhci2 > ehci0: mem 0xdffffd00-0xdffffdff irq > 21 at device 16.3 on pci0 > ehci0: [ITHREAD] > usbus3: EHCI version 1.0 > usbus3: on ehci0 > isab0: at device 17.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 17.1 on > pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > pci0: at device 17.6 (no driver attached) > acpi_button1: on acpi0 > fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 > irq 6 drq 2 on acpi0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > uart0: [FILTER] > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on > acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: [ITHREAD] > lpt0: on ppbus0 > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > ppi0: on ppbus0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xc9fff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > acpi_throttle0: on cpu0 > powernow0: on cpu0 > device_attach: powernow0 attach returned 6 > Timecounter "TSC" frequency 1800078810 Hz quality 800 > Timecounters tick every 1.000 msec > md0: Preloaded image 33923072 bytes at 0xc0fd9834 > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ad0: 39205MB at ata0-master UDMA133 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ad1: 38166MB at ata0-slave UDMA100 > ad2: 39205MB at ata1-master UDMA133 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > acd0: DVDROM at ata1-slave UDMA33 > uhub3: 6 ports with 6 removable, self powered > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > Trying to mount root from ufs:/dev/md0 > ZFS NOTICE: Prefetch is disabled by default on i386 -- to enable, > add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. > ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable > behavior. > Consider tuning vm.kmem_size and vm.kmem_size_max > in /boot/loader.conf. > ZFS filesystem version 5 > ZFS storage pool version 28 > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > log_sysevent: type 19 is not implemented > > And here is gpart output: > > mfsbsd# gpart show > => 34 80293181 ad0 GPT (38G) > 34 128 1 freebsd-boot (64K) > 162 2097152 2 freebsd-swap (1.0G) > 2097314 76068013 3 freebsd-zfs (36G) > 78165327 2127888 - free - (1.0G) > > => 34 78165293 ad1 GPT (37G) > 34 128 1 freebsd-boot (64K) > 162 2097152 2 freebsd-swap (1.0G) > 2097314 76068013 3 freebsd-zfs (36G) > > => 34 80293181 ad2 GPT (38G) > 34 128 1 freebsd-boot (64K) > 162 2097152 2 freebsd-swap (1.0G) > 2097314 76068013 3 freebsd-zfs (36G) > 78165327 2127888 - free - (1.0G) > > > Any idea what happened to the pool, why I am unable to boot and import > it, and what can I do to investigate or fix this issue? > Update: I tried with OpenSolaris 2009.06 liveCD. Pool was visible, but import wasn't possible because ZFSv28 was too new for this realease. Then i tried with latest OpenIndiana, but unfortunately, it doesn't even see my pool. -- Bartosz Stec From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 20:39:42 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57D4B106564A for ; Thu, 2 Jun 2011 20:39:42 +0000 (UTC) (envelope-from jwd@SlowBlink.Com) Received: from nmail.slowblink.com (rrcs-24-199-145-34.midsouth.biz.rr.com [24.199.145.34]) by mx1.freebsd.org (Postfix) with ESMTP id F36838FC0C for ; Thu, 2 Jun 2011 20:39:41 +0000 (UTC) Received: from nmail.slowblink.com (localhost [127.0.0.1]) by nmail.slowblink.com (8.14.3/8.14.3) with ESMTP id p52KdejY080577; Thu, 2 Jun 2011 16:39:40 -0400 (EDT) (envelope-from jwd@nmail.slowblink.com) Received: (from jwd@localhost) by nmail.slowblink.com (8.14.3/8.14.3/Submit) id p52KdeAL080576; Thu, 2 Jun 2011 16:39:40 -0400 (EDT) (envelope-from jwd) Date: Thu, 2 Jun 2011 16:39:40 -0400 From: John To: freebsd-net@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20110602203940.GA80549@slowblink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Production use of carp? 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, 02 Jun 2011 20:39:42 -0000 Hi Folks, Posting to -net & -fs to hopefully catch the right folks. A similar posting to -current didn't seem to catch anyones interest. Please respond as approriate. I'm in the process of setting up HA/Failover ZFS server systems using carp. I seem to be running into some issues that may simply be misundersandings, or actual support issues. I'm curious to hear what you think. First off, when using carp, one must use a unique vhid in the configuration line for each system. If not, systems using the same vhid, but different passwords will see a serious amount of "jitteryness" and/or delay to their carp'd interface. This means a unique set of vhid values would need to be assigned and kept track of for every system put in place. Not something I want to do. I've already run into this problem with another group that was using carp on external interfaces to control an HA nagios setup. Instead of running carp on the external interfaces as below: ifconfig_cxgb0="inet 10.24.99.11 netmask 255.255.0.0" # System 1 physical ip ifconfig_cxgb0="inet 10.24.99.12 netmask 255.255.0.0" # System 2 physcial ip ifconfig_carp1="vhid 1 pass zfscarp1 advbase 1 advskew 100 10.24.99.13 netmask 255.255.0.0" # HA ip used by clients ... we instead connect a direct cross-over cable between the two systems providing HA/Failover and use a private (backside) network: ifconfig_cxgb1="inet 192.168.0.1 netmask 255.255.255.0" # System 1 private ip ifconfig_cxgb1="inet 192.168.0.2 netmask 255.255.255.0" # System 2 private ip ifconfig_carp1="vhid 1 pass zfscarp1 advbase 1 advskew 100 192.168.0.3 netmask 255.255.255.0" If system A is the MASTER, and I issue a 'ifconfig carp1 down' command, system B becomes the MASTER as one would expect (using scripts connected up through devd). So far, things are great. A filesystem resource can be shifted to either A or B with no impact on the clients. Other scripts hooked up via devd monitor the outgoing link and issue ifconfig carp1 up/down commands as needed (for instance if the networking cable is unplugged on head B). However, if system A is the MASTER, and system B is rebooted, the carp interface on system A will flip/flop going down and coming back up which is not what I want. This leads to my question, am I missing something simple about using carp? Should I implement my own control interface on the private network and not use carp? What are other folks doing? Thanks, John From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 22:27:24 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99997106566C; Thu, 2 Jun 2011 22:27:24 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 591938FC0C; Thu, 2 Jun 2011 22:27:24 +0000 (UTC) Received: from baby-jane.lamaiziere.net (6.176.97.84.rev.sfr.net [84.97.176.6]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 323BE63307D; Fri, 3 Jun 2011 00:10:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id C8FC773105; Fri, 3 Jun 2011 00:10:36 +0200 (CEST) Date: Fri, 3 Jun 2011 00:10:36 +0200 From: Patrick Lamaiziere To: John Message-ID: <20110603001036.5ad0ff8d@davenulle.org> In-Reply-To: <20110602203940.GA80549@slowblink.com> References: <20110602203940.GA80549@slowblink.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org Subject: Re: Production use of carp? 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, 02 Jun 2011 22:27:24 -0000 Le Thu, 2 Jun 2011 16:39:40 -0400, John a écrit : Hello, > However, if system A is the MASTER, and system B is rebooted, > the carp interface on system A will flip/flop going down and > coming back up which is not what I want. I saw this if the switch connecting the two systems takes some time to forward packets when a link is "up". This happens if the switch is doing some spanning tree protocol. (on cisco swith you should use an option "spanning tree port fast" on the switch port to avoid this) > This leads to my question, am I missing something simple about > using carp? Should I implement my own control interface on the > private network and not use carp? What are other folks doing? You may want to implement your own control because if the two hosts cannot communicate, you will have two masters. This can happen if the links on the both hosts are up, but none packet are forwarded (ie the switch connecting the two boxes is broken in some way). Instead writing your own script, you may use ifstated (in the ports tree). I've not tried FreeBSD with carp but we are very happy at $WORK with carp on OpenBSD. I guess that should work fine on FreeBSD too. Regards. From owner-freebsd-fs@FreeBSD.ORG Thu Jun 2 22:49:05 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F92C1065670 for ; Thu, 2 Jun 2011 22:49:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 27D6E8FC16 for ; Thu, 2 Jun 2011 22:49:04 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta05.emeryville.ca.mail.comcast.net with comcast id rAk41g0031smiN4A5Ap3Zq; Thu, 02 Jun 2011 22:49:03 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id rAor1g0071t3BNj8gAost7; Thu, 02 Jun 2011 22:48:53 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E5445102C19; Thu, 2 Jun 2011 15:48:58 -0700 (PDT) Date: Thu, 2 Jun 2011 15:48:58 -0700 From: Jeremy Chadwick To: Patrick Lamaiziere Message-ID: <20110602224858.GA57713@icarus.home.lan> References: <20110602203940.GA80549@slowblink.com> <20110603001036.5ad0ff8d@davenulle.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110603001036.5ad0ff8d@davenulle.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org, John Subject: Re: Production use of carp? 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, 02 Jun 2011 22:49:05 -0000 On Fri, Jun 03, 2011 at 12:10:36AM +0200, Patrick Lamaiziere wrote: > Le Thu, 2 Jun 2011 16:39:40 -0400, > John a ?crit : > > Hello, > > > However, if system A is the MASTER, and system B is rebooted, > > the carp interface on system A will flip/flop going down and > > coming back up which is not what I want. > > I saw this if the switch connecting the two systems takes some time to > forward packets when a link is "up". This happens if the switch is doing > some spanning tree protocol. (on cisco swith you should use an option > "spanning tree port fast" on the switch port to avoid this) Expanding a bit on this: This is written oddly (to me anyway). What Patrick's referring to is classic STP (Spanning Tree Protocol) taking a long time to deal with link negotiation, and for you to consider using RSTP (Rapid Spanning Tree Protocol) instead. This advice doesn't apply if spanning tree isn't enabled on your switches; whether or not it is by default is unknown to us. Please refer to your switch documentation and/or vendor. Alternately, depending on the model of switch used, there are other protocols which can cause this behaviour as well. One such protocol is LLDP (Link Layer Discovery Protocol). I ran into this issue on our HP ProCurve switches; disabling LLDP ("no lldp run") solved slow link negotiation. Other such protocols link disovery protocols are EDP, NDP (SONMP) and LLTD. Turn them all off if you don't need them. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 00:37:57 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 1952D106564A for ; Fri, 3 Jun 2011 00:37:57 +0000 (UTC) (envelope-from pvz@itassistans.se) Received: from zcs1.itassistans.net (zcs1.itassistans.net [212.112.191.37]) by mx1.freebsd.org (Postfix) with ESMTP id 650CA8FC0A for ; Fri, 3 Jun 2011 00:37:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs1.itassistans.net (Postfix) with ESMTP id B13A2C0230; Fri, 3 Jun 2011 02:37:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at zcs1.itassistans.net Received: from zcs1.itassistans.net ([127.0.0.1]) by localhost (zcs1.itassistans.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VrDGMbPKEDU; Fri, 3 Jun 2011 02:37:54 +0200 (CEST) Received: from [192.168.1.239] (c213-89-160-61.bredband.comhem.se [213.89.160.61]) by zcs1.itassistans.net (Postfix) with ESMTPSA id 04859C01FC; Fri, 3 Jun 2011 02:37:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) From: Per von Zweigbergk In-Reply-To: <20110603001036.5ad0ff8d@davenulle.org> Date: Fri, 3 Jun 2011 02:37:53 +0200 Message-Id: <2E31CF74-416A-4310-9102-FD0C86275D0E@itassistans.se> References: <20110602203940.GA80549@slowblink.com> <20110603001036.5ad0ff8d@davenulle.org> To: Patrick Lamaiziere X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org, John Subject: Re: Production use of carp? 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, 03 Jun 2011 00:37:57 -0000 3 jun 2011 kl. 00.10 skrev Patrick Lamaiziere: > You may want to implement your own control because if the two hosts > cannot communicate, you will have two masters. This can happen if the > links on the both hosts are up, but none packet are forwarded (ie the > switch connecting the two boxes is broken in some way). As a general thought that might be interesting when you're building your = HA solution: One less-documented feature of VMware ESXi is that it checks whether = it's isolated from the network by pinging the gateway on the management = network. This is how ESXi trys to avoid having a split-brain condition - by = making sure that it only considers itself to be the master if it can = reach the gateway, but cannot reach any other servers. You might = implement gating in a similar way to avoid a split-brain condition in = your HA solution.= From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 01:16: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 C8DC4106566B for ; Fri, 3 Jun 2011 01:16:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id 73FBB8FC08 for ; Fri, 3 Jun 2011 01:16:46 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta04.westchester.pa.mail.comcast.net with comcast id rDGY1g0051swQuc54DGmTy; Fri, 03 Jun 2011 01:16:46 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.westchester.pa.mail.comcast.net with comcast id rDGc1g00E1t3BNj3bDGe8R; Fri, 03 Jun 2011 01:16:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D2D3B102C19; Thu, 2 Jun 2011 18:16:34 -0700 (PDT) Date: Thu, 2 Jun 2011 18:16:34 -0700 From: Jeremy Chadwick To: Per von Zweigbergk Message-ID: <20110603011634.GA59971@icarus.home.lan> References: <20110602203940.GA80549@slowblink.com> <20110603001036.5ad0ff8d@davenulle.org> <2E31CF74-416A-4310-9102-FD0C86275D0E@itassistans.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2E31CF74-416A-4310-9102-FD0C86275D0E@itassistans.se> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org, John , Patrick Lamaiziere Subject: Re: Production use of carp? 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, 03 Jun 2011 01:16:46 -0000 On Fri, Jun 03, 2011 at 02:37:53AM +0200, Per von Zweigbergk wrote: > 3 jun 2011 kl. 00.10 skrev Patrick Lamaiziere: > > > You may want to implement your own control because if the two hosts > > cannot communicate, you will have two masters. This can happen if the > > links on the both hosts are up, but none packet are forwarded (ie the > > switch connecting the two boxes is broken in some way). > > As a general thought that might be interesting when you're building your HA solution: > > One less-documented feature of VMware ESXi is that it checks whether it's isolated from the network by pinging the gateway on the management network. > > This is how ESXi trys to avoid having a split-brain condition - by making sure that it only considers itself to be the master if it can reach the gateway, but cannot reach any other servers. You might implement gating in a similar way to avoid a split-brain condition in your HA solution. If that's indeed true, VMware ESXi is doing something Extremely Bad. Pinging the local gateway (read: A ROUTER) as a form of determining if network I/O is failing is an unwise decision. Commercial-grade routers (read: Cisco, Juniper) all implement a form of ICMP prioritisation. The router can (and will) discard/drop inbound ICMP packets directed at the router itself (e.g. a destination IP of the gateway) during high CPU utilisation. Packets destined to a router itself (e.g. destination IP is the router) are handled very, very differently. This is why network engineers always recommend that when testing for network anomalies, the client (source IP) should attempt to speak to a web server, another box, whatever -- anything as long as it's not a router -- for its destination IP. At my workplace, for quite some time our Solaris machines using mpathd were configured to ping their default gateway (a Juniper M320). After we expanded and scaled out, we found that mpath would randomly fail over to the 2nd NIC for presumably no reason. The above description was the root cause. The solution was to have mpath probe against a dedicated host (another Solaris box) rather than the network gateway. Problem solved. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 03:23: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 34030106564A for ; Fri, 3 Jun 2011 03:23:31 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id C99DD8FC14 for ; Fri, 3 Jun 2011 03:23:29 +0000 (UTC) Received: from [127.0.0.1] (kevlo@kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.3/8.14.3) with ESMTP id p532tOhT021081 for ; Fri, 3 Jun 2011 10:55:24 +0800 (CST) From: Kevin Lo To: freebsd-fs@freebsd.org Content-Type: multipart/mixed; boundary="=-7rnBXKDU+75wsC1ZYUFD" Date: Fri, 03 Jun 2011 10:55:26 +0800 Message-ID: <1307069726.2024.18.camel@nsl> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [PATCH] Set the DE_UPDATE flag on the directory node on msdosfs 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, 03 Jun 2011 03:23:31 -0000 --=-7rnBXKDU+75wsC1ZYUFD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit If you try to NFS export a fat32 formatted external usb devices, you'll notice if a new file is created, you won't see that file on the NFS client. The reason is msdosfs(5) doesn't change the modify time of the directory when an entry is created. Attached is a patch against HEAD that sets DE_UPDATE on the directory node in both createde() and removede(). Please test it, thanks. Kevin --=-7rnBXKDU+75wsC1ZYUFD-- From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 03:32:52 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACA1A1065670 for ; Fri, 3 Jun 2011 03:32:52 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 514528FC14 for ; Fri, 3 Jun 2011 03:32:51 +0000 (UTC) Received: from [127.0.0.1] (kevlo@kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.3/8.14.3) with ESMTP id p533WoeG019961 for ; Fri, 3 Jun 2011 11:32:50 +0800 (CST) From: Kevin Lo To: freebsd-fs@freebsd.org In-Reply-To: <1307069726.2024.18.camel@nsl> References: <1307069726.2024.18.camel@nsl> Content-Type: text/plain; charset="UTF-8" Date: Fri, 03 Jun 2011 11:32:53 +0800 Message-ID: <1307071973.2024.19.camel@nsl> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] Set the DE_UPDATE flag on the directory node on msdosfs 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, 03 Jun 2011 03:32:52 -0000 Kevin Lo wrote: > If you try to NFS export a fat32 formatted external usb devices, > you'll notice if a new file is created, you won't see that file > on the NFS client. The reason is msdosfs(5) doesn't change the > modify time of the directory when an entry is created. > > Attached is a patch against HEAD that sets DE_UPDATE on the > directory node in both createde() and removede(). > Please test it, thanks. > > Kevin > --- sys/fs/msdosfs/msdosfs_lookup.c.orig 2011-06-02 15:26:23.000000000 +0800 +++ sys/fs/msdosfs/msdosfs_lookup.c 2011-06-02 15:27:22.000000000 +0800 @@ -725,6 +725,8 @@ else if ((error = bwrite(bp)) != 0) return error; + ddep->de_flag |= DE_UPDATE; + /* * If they want us to return with the denode gotten. */ @@ -1027,6 +1029,7 @@ } while (!(pmp->pm_flags & MSDOSFSMNT_NOWIN95) && !(offset & pmp->pm_crbomask) && offset); + pdep->de_flag |= DE_UPDATE; return 0; } From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 08:25:13 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D964D1065673; Fri, 3 Jun 2011 08:25:13 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 78CA58FC1A; Fri, 3 Jun 2011 08:25:13 +0000 (UTC) Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p538P8ka027081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2011 18:25:11 +1000 Date: Fri, 3 Jun 2011 18:25:07 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kevin Lo In-Reply-To: <1307071973.2024.19.camel@nsl> Message-ID: <20110603173555.X994@besplex.bde.org> References: <1307069726.2024.18.camel@nsl> <1307071973.2024.19.camel@nsl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, rmacklem@freebsd.org Subject: Re: [PATCH] Set the DE_UPDATE flag on the directory node on msdosfs 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, 03 Jun 2011 08:25:13 -0000 On Fri, 3 Jun 2011, Kevin Lo wrote: > Kevin Lo wrote: >> If you try to NFS export a fat32 formatted external usb devices, >> you'll notice if a new file is created, you won't see that file >> on the NFS client. The reason is msdosfs(5) doesn't change the >> modify time of the directory when an entry is created. >> >> Attached is a patch against HEAD that sets DE_UPDATE on the >> directory node in both createde() and removede(). >> Please test it, thanks. It breaks compatibility with MSDOS and Windows. No correct fix is evident. ffs maintains the generation count va_filerev which should help, but: - ffs only increments it when a file mtime is updated. - msdosfs doesn't properly maintain it (it initializes to a non-random number related to the current time when the vnode is initialized, but never increments it). - the old nfs client doesn't use it - the new nfs client does use it for v4. I don't know if this use is sufficient (it has to get it from the server to work for this). I wonder if the problem is larger with negative caching. Negative caching also uses the ctime, and msdosfs doesn't even have a ctime (it fakes it as the mtime, but that works especially badly for directories since the mtime is never changed after birth for directoroes, and negative caching needs the time[s] to be updated especially for directories). The only reasonably correct fix seems to be to make the directory timeouts especially small for nfs mounts of remote msdosfs file systems (or any file systems that don't update mtimes for directories, or don't have ctimes). Granularity of times is also a problem. It is 1 second by default for ffs, and can be reduced, but for msdosfs it is 2 seconds and cannot be reduced. So it is fairly easy even for ffs to have changes that don't change file timestamps. Using va_filerev is the correct fix for this. Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 10:59: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 64BEF106566B; Fri, 3 Jun 2011 10:59:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D233F8FC16; Fri, 3 Jun 2011 10:59:10 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p53Ax4L9081274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2011 13:59:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p53Ax4PY012698; Fri, 3 Jun 2011 13:59:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p53Ax4Nl012697; Fri, 3 Jun 2011 13:59:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 3 Jun 2011 13:59:04 +0300 From: Kostik Belousov To: Bruce Evans Message-ID: <20110603105904.GM48734@deviant.kiev.zoral.com.ua> References: <1307069726.2024.18.camel@nsl> <1307071973.2024.19.camel@nsl> <20110603173555.X994@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p/yOlLEfnp/ZBhGR" Content-Disposition: inline In-Reply-To: <20110603173555.X994@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, rmacklem@freebsd.org Subject: Re: [PATCH] Set the DE_UPDATE flag on the directory node on msdosfs 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, 03 Jun 2011 10:59:11 -0000 --p/yOlLEfnp/ZBhGR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 03, 2011 at 06:25:07PM +1000, Bruce Evans wrote: > On Fri, 3 Jun 2011, Kevin Lo wrote: >=20 > >Kevin Lo wrote: > >>If you try to NFS export a fat32 formatted external usb devices, > >>you'll notice if a new file is created, you won't see that file > >>on the NFS client. The reason is msdosfs(5) doesn't change the > >>modify time of the directory when an entry is created. > >> > >>Attached is a patch against HEAD that sets DE_UPDATE on the > >>directory node in both createde() and removede(). > >>Please test it, thanks. >=20 > It breaks compatibility with MSDOS and Windows. >=20 > No correct fix is evident. ffs maintains the generation count va_filerev > which should help, but: > - ffs only increments it when a file mtime is updated. > - msdosfs doesn't properly maintain it (it initializes to a non-random > number related to the current time when the vnode is initialized, but > never increments it). > - the old nfs client doesn't use it > - the new nfs client does use it for v4. I don't know if this use is > sufficient (it has to get it from the server to work for this). It seems that reporter forgot to mention this, but the problem was reported for the _linux_ NFS client mounting FAT share from the FreeBSD server. --p/yOlLEfnp/ZBhGR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3ovncACgkQC3+MBN1Mb4h1uACdGiVfIoDaiIqC1giLotN5Tk3x xSUAoLNpnJEms05CTZceWpBd0Lj0799d =xFLr -----END PGP SIGNATURE----- --p/yOlLEfnp/ZBhGR-- From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 12:17: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 464C2106564A for ; Fri, 3 Jun 2011 12:17:04 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id E677C8FC1C for ; Fri, 3 Jun 2011 12:17:03 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9BCF545CDD; Fri, 3 Jun 2011 14:17:01 +0200 (CEST) Received: from localhost (58.wheelsystems.com [83.12.187.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 04A5845E93; Fri, 3 Jun 2011 14:16:55 +0200 (CEST) Date: Fri, 3 Jun 2011 14:16:25 +0200 From: Pawel Jakub Dawidek To: Bartosz Stec Message-ID: <20110603121625.GD1862@garage.freebsd.pl> References: <4DE7C122.2040004@it4pro.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KlAEzMkarCnErv5Q" Content-Disposition: inline In-Reply-To: <4DE7C122.2040004@it4pro.pl> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-3.9 required=4.5 tests=ALL_TRUSTED,BAYES_00, RCVD_IN_SORBS_DUL autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: [ZFSv28] Loader hangs, import failes, zfs filesystem 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: Fri, 03 Jun 2011 12:17:04 -0000 --KlAEzMkarCnErv5Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 02, 2011 at 06:58:10PM +0200, Bartosz Stec wrote: > Hi list, > Today I needed to shut down my home server (FreeSBD9-CURRENT, 3 x > 40GB ATA HDD in RADZ1, ZFS only, GPT, i386) for a moment. After > power up, loader started to spin cursor indifinitely, and didn't > load the kernel. No error messages, no hints, just spinning cursor. > I tried booting from other HDDs in case that bootstrap area errors > on single hdd but no luck. > I wanted to play with latest current LiveFS snapshot (with ZFSv28 > support), but apparently latest one is from february?? > Finally I ended with mfsBSD from http://mfsbsd.vx.sk/ > I've downloaded "8.2-RELEASE-i386 with ZFSv28 special edition > " iso, burned > it and booted machine. Here's what happened when i was trying to > import zpool: >=20 > mfsbsd# zpool status > no pools available > mfsbsd# zpool import > pool: zroot > id: 16074929158756467860 > state: ONLINE > status: The pool was last accessed by another system. > action: The pool can be imported using its name or numeric > identifier and > the '-f' flag. > see: http://www.sun.com/msg/ZFS-8000-EY > config: >=20 > zroot ONLINE > raidz1-0 ONLINE > gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE > gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE > gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE > mfsbsd# zpool import -f zroot > cannot import 'zroot': one or more devices is currently unavailable Is there anything that may keep any of those vdevs open? Try setting vfs.zfs.debug to 1 before import. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --KlAEzMkarCnErv5Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk3o0JkACgkQForvXbEpPzTfqQCg6F7mducSWdEMjpnSw8CTfDnw RdEAoJHxohvOyA0HqW0Xy2ObujZebGnf =pvp9 -----END PGP SIGNATURE----- --KlAEzMkarCnErv5Q-- From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 13:00:24 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B970C106567F for ; Fri, 3 Jun 2011 13:00:24 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7458FC18 for ; Fri, 3 Jun 2011 13:00:09 +0000 (UTC) Received: from [127.0.0.1] (kevlo@kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.3/8.14.3) with ESMTP id p53D071D023769; Fri, 3 Jun 2011 21:00:07 +0800 (CST) From: Kevin Lo To: Kostik Belousov In-Reply-To: <20110603105904.GM48734@deviant.kiev.zoral.com.ua> References: <1307069726.2024.18.camel@nsl> <1307071973.2024.19.camel@nsl> <20110603173555.X994@besplex.bde.org> <20110603105904.GM48734@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="UTF-8" Date: Fri, 03 Jun 2011 21:00:07 +0800 Message-ID: <1307106007.2865.8.camel@nsl> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, rmacklem@freebsd.org Subject: Re: [PATCH] Set the DE_UPDATE flag on the directory node on msdosfs 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, 03 Jun 2011 13:00:26 -0000 Kostik Belousov wrote: > On Fri, Jun 03, 2011 at 06:25:07PM +1000, Bruce Evans wrote: > > On Fri, 3 Jun 2011, Kevin Lo wrote: > > > > >Kevin Lo wrote: > > >>If you try to NFS export a fat32 formatted external usb devices, > > >>you'll notice if a new file is created, you won't see that file > > >>on the NFS client. The reason is msdosfs(5) doesn't change the > > >>modify time of the directory when an entry is created. > > >> > > >>Attached is a patch against HEAD that sets DE_UPDATE on the > > >>directory node in both createde() and removede(). > > >>Please test it, thanks. > > > > It breaks compatibility with MSDOS and Windows. > > > > No correct fix is evident. ffs maintains the generation count va_filerev > > which should help, but: > > - ffs only increments it when a file mtime is updated. > > - msdosfs doesn't properly maintain it (it initializes to a non-random > > number related to the current time when the vnode is initialized, but > > never increments it). > > - the old nfs client doesn't use it > > - the new nfs client does use it for v4. I don't know if this use is > > sufficient (it has to get it from the server to work for this). > It seems that reporter forgot to mention this, but the problem was > reported for the _linux_ NFS client mounting FAT share from the FreeBSD > server. Thank kib@ for pointing that out. Yes, the NFS clients running on Linux. I looked at the Darwin's msdosfs: http://opensource.apple.com/source/msdosfs/msdosfs-48/msdosfs.kextproj/msdosfs.kmodproj/msdosfs_lookup.c It seems the DE_UPDATE flag is also set in createde() and removede(). Kevin From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 17:39: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 4DCD0106566B for ; Fri, 3 Jun 2011 17:39:29 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id C98AD8FC0C for ; Fri, 3 Jun 2011 17:39:28 +0000 (UTC) Received: from [IPv6:2001:470:28:140:6c98:8f17:eeb3:d87e] ([IPv6:2001:470:28:140:6c98:8f17:eeb3:d87e]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p53HdNIH008319 for ; Fri, 3 Jun 2011 20:39:24 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4DE91C38.8030602@ukr.net> Date: Fri, 03 Jun 2011 20:39:04 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4DDC0D13.3030401@ukr.net> In-Reply-To: <4DDC0D13.3030401@ukr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-95.5 required=5.0 tests=FREEMAIL_FROM,FSL_RU_URL, RDNS_NONE, SPF_SOFTFAIL, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Fri, 03 Jun 2011 20:39:27 +0300 (EEST) Subject: Re: how to import raidz2, if only one disk is missing? 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, 03 Jun 2011 17:39:29 -0000 24.05.2011 22:54, Vladislav V. Prodan wrote: > how to change the status of "FAULTED" on "DEGRADED"? > Managed to partially lift the pool. # zpool status tank pool: tank state: FAULTED status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scrub: none requested config: NAME STATE READ WRITE CKSUM tank FAULTED 0 0 1 corrupted data raidz2 DEGRADED 0 0 6 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 UNAVAIL 0 0 0 cannot open gpt/disk4 ONLINE 0 0 0 ad18p1 ONLINE 0 0 0 # zdb tank version=15 txg=0 pool_guid=17628573572433446879 vdev_tree type='root' id=0 guid=17628573572433446879 bad config type 16 for stats children[0] type='raidz' id=0 guid=17179795338638175685 nparity=2 metaslab_array=14 metaslab_shift=35 ashift=9 asize=4500909195264 is_log=0 bad config type 16 for stats children[0] type='disk' id=0 guid=1193943216826871140 path='/dev/gpt/disk0' whole_disk=0 DTL=22 bad config type 16 for stats children[1] type='disk' id=1 guid=15455958051005423086 path='/dev/gpt/disk1' whole_disk=0 DTL=20 bad config type 16 for stats children[2] type='disk' id=2 guid=8664568011785700035 path='/dev/gpt/disk2' whole_disk=0 DTL=163 bad config type 16 for stats children[3] type='disk' id=3 guid=8811702962298963660 path='/dev/gpt/disk3' whole_disk=0 DTL=161 bad config type 16 for stats children[4] type='disk' id=4 guid=6754554128830363882 path='/dev/gpt/disk4' whole_disk=0 DTL=164 bad config type 16 for stats children[5] type='disk' id=5 guid=16960671095707356147 path='/dev/ad18p1' whole_disk=0 DTL=160 bad config type 16 for stats name='tank' state=0 timestamp=1306186996 hostid=143250101 hostname='mary-teresa.otrada.od.ua' zdb: can't open tank: Input/output error I put a new HDD to 2 terabytes, but the pool does not see gpt/disk3 :( # ll /dev/gpt total 0 crw-r----- 1 root operator 0, 93 3 июн 20:07 boot crw-r----- 1 root operator 0, 97 3 июн 20:07 disk-system crw-r----- 1 root operator 0, 103 3 июн 20:07 disk0 crw-r----- 1 root operator 0, 110 3 июн 20:07 disk1 crw-r----- 1 root operator 0, 119 3 июн 20:07 disk2 crw-r----- 1 root operator 0, 139 3 июн 20:15 disk3 crw-r----- 1 root operator 0, 117 3 июн 20:07 disk4 crw-r----- 1 root operator 0, 136 3 июн 20:27 disk5 crw-r----- 1 root operator 0, 95 3 июн 20:07 swap What else recommend to restore the pool? -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 20:04:24 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B095B106564A; Fri, 3 Jun 2011 20:04:24 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5878FC12; Fri, 3 Jun 2011 20:04:23 +0000 (UTC) Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p53K4KiE027604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Jun 2011 06:04:22 +1000 Date: Sat, 4 Jun 2011 06:04:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kevin Lo In-Reply-To: <1307106007.2865.8.camel@nsl> Message-ID: <20110604052946.Q3281@besplex.bde.org> References: <1307069726.2024.18.camel@nsl> <1307071973.2024.19.camel@nsl> <20110603173555.X994@besplex.bde.org> <20110603105904.GM48734@deviant.kiev.zoral.com.ua> <1307106007.2865.8.camel@nsl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, rmacklem@FreeBSD.org Subject: Re: [PATCH] Set the DE_UPDATE flag on the directory node on msdosfs 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, 03 Jun 2011 20:04:24 -0000 On Fri, 3 Jun 2011, Kevin Lo wrote: > Kostik Belousov wrote: >> On Fri, Jun 03, 2011 at 06:25:07PM +1000, Bruce Evans wrote: >>> On Fri, 3 Jun 2011, Kevin Lo wrote: >>> >>>> Kevin Lo wrote: >>>>> If you try to NFS export a fat32 formatted external usb devices, >>>>> you'll notice if a new file is created, you won't see that file >>>>> on the NFS client. The reason is msdosfs(5) doesn't change the >>>>> modify time of the directory when an entry is created. >>>>> >>>>> Attached is a patch against HEAD that sets DE_UPDATE on the >>>>> directory node in both createde() and removede(). >>>>> Please test it, thanks. >>> >>> It breaks compatibility with MSDOS and Windows. >>> >>> No correct fix is evident. ffs maintains the generation count va_filerev >>> which should help, but: >>> ... >> It seems that reporter forgot to mention this, but the problem was >> reported for the _linux_ NFS client mounting FAT share from the FreeBSD >> server. It's going to be hard to fix this portably. I looked at the FreeBSD server a bit more. It seems to pass va_filerev for v4 but not for v3 (or of course v2). > Thank kib@ for pointing that out. Yes, the NFS clients running on Linux. > I looked at the Darwin's msdosfs: > http://opensource.apple.com/source/msdosfs/msdosfs-48/msdosfs.kextproj/msdosfs.kmodproj/msdosfs_lookup.c > > It seems the DE_UPDATE flag is also set in createde() and removede(). These settings look like Apple bugs. The one in createde() is misindented, and in in removede(), the whole function is misindented. Otherwise, the formatting and contents doesn't seem to have been changed much since Apple obtained the file from FreeBSD in Y2K. Apple's msdosfs_denode.c still carefully avoids setting IN_UPDATE | IN_MODIFIED for directories in detrunc(). I will check what Linux (2.6.10) msdosfs does. BTW, how do you get unmangled source files from Apple? The one in the above URL is actually an html file so it is fully mangled when fetched. When viewed in a browser, it just has corrupt tabs and some leading and trailing garbage. All libm files that I have fetched from Apple have the same problems. In 1 case I wasn't able to recover a source file without too much editing, since printing the file from a browser gave mangled more than tabs. Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 20:06:52 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B80521065675 for ; Fri, 3 Jun 2011 20:06:52 +0000 (UTC) (envelope-from pvz@itassistans.se) Received: from zcs1.itassistans.net (zcs1.itassistans.net [212.112.191.37]) by mx1.freebsd.org (Postfix) with ESMTP id 56E0D8FC0C for ; Fri, 3 Jun 2011 20:06:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs1.itassistans.net (Postfix) with ESMTP id C0957C0234; Fri, 3 Jun 2011 22:06:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at zcs1.itassistans.net Received: from zcs1.itassistans.net ([127.0.0.1]) by localhost (zcs1.itassistans.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au2pUDP-w3wh; Fri, 3 Jun 2011 22:06:49 +0200 (CEST) Received: from [192.168.1.239] (c213-89-160-61.bredband.comhem.se [213.89.160.61]) by zcs1.itassistans.net (Postfix) with ESMTPSA id 41801C01FC; Fri, 3 Jun 2011 22:06:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) From: Per von Zweigbergk In-Reply-To: <20110604052946.Q3281@besplex.bde.org> Date: Fri, 3 Jun 2011 22:06:47 +0200 Message-Id: <9DD5A034-DA68-4D03-8B0D-F484AAE003CC@itassistans.se> References: <1307069726.2024.18.camel@nsl> <1307071973.2024.19.camel@nsl> <20110603173555.X994@besplex.bde.org> <20110603105904.GM48734@deviant.kiev.zoral.com.ua> <1307106007.2865.8.camel@nsl> <20110604052946.Q3281@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@FreeBSD.org, rmacklem@FreeBSD.org Subject: Re: [PATCH] Set the DE_UPDATE flag on the directory node on msdosfs 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, 03 Jun 2011 20:06:52 -0000 3 jun 2011 kl. 22.04 skrev Bruce Evans: > BTW, how do you get unmangled source files from Apple? The one in the > above URL is actually an html file so it is fully mangled when fetched. There's a "plain text" link at the top. From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 20:37: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 2A1D01065689 for ; Fri, 3 Jun 2011 20:37:10 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8EA098FC19 for ; Fri, 3 Jun 2011 20:37:09 +0000 (UTC) Received: from [IPv6:2001:470:28:140:6c98:8f17:eeb3:d87e] ([IPv6:2001:470:28:140:6c98:8f17:eeb3:d87e]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p53Kb4K9032887 for ; Fri, 3 Jun 2011 23:37:04 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4DE945DC.30201@ukr.net> Date: Fri, 03 Jun 2011 23:36:44 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4DDC0D13.3030401@ukr.net> <4DE91C38.8030602@ukr.net> In-Reply-To: <4DE91C38.8030602@ukr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-95.5 required=5.0 tests=FREEMAIL_FROM,FSL_RU_URL, RDNS_NONE, SPF_SOFTFAIL, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Fri, 03 Jun 2011 23:37:07 +0300 (EEST) Subject: Re: how to import raidz2, if only one disk is missing? 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, 03 Jun 2011 20:37:10 -0000 03.06.2011 20:39, Vladislav V. Prodan wrote: > I put a new HDD to 2 terabytes, but the pool does not see gpt/disk3 :( how to properly set the LABEL [0-4]? For example, a working HDD: # zdb -l /dev/ad16p1 | more -------------------------------------------- LABEL 0 -------------------------------------------- version=15 name='tank' state=0 txg=10280816 pool_guid=17628573572433446879 hostid=143250101 hostname='mary-teresa.otrada.od.ua' top_guid=17179795338638175685 guid=8664568011785700035 vdev_tree type='raidz' id=0 guid=17179795338638175685 nparity=2 metaslab_array=14 metaslab_shift=35 ashift=9 asize=4500909195264 is_log=0 children[0] type='disk' id=0 guid=1193943216826871140 path='/dev/gpt/disk0' whole_disk=0 DTL=22 children[1] type='disk' id=1 guid=15455958051005423086 path='/dev/gpt/disk1' whole_disk=0 DTL=20 children[2] type='disk' id=2 guid=8664568011785700035 path='/dev/gpt/disk2' whole_disk=0 DTL=163 children[3] type='disk' id=3 guid=8811702962298963660 path='/dev/gpt/disk3' whole_disk=0 DTL=161 children[4] type='disk' id=4 guid=6754554128830363882 path='/dev/gpt/disk4' whole_disk=0 DTL=164 children[5] type='disk' id=5 guid=16960671095707356147 path='/dev/ad18p1' whole_disk=0 DTL=160 -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 21:07: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 4379D1065674; Fri, 3 Jun 2011 21:07:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id D2AA18FC15; Fri, 3 Jun 2011 21:07:02 +0000 (UTC) Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p53L6u7t005989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Jun 2011 07:06:58 +1000 Date: Sat, 4 Jun 2011 07:06:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20110604052946.Q3281@besplex.bde.org> Message-ID: <20110604064215.D970@besplex.bde.org> References: <1307069726.2024.18.camel@nsl> <1307071973.2024.19.camel@nsl> <20110603173555.X994@besplex.bde.org> <20110603105904.GM48734@deviant.kiev.zoral.com.ua> <1307106007.2865.8.camel@nsl> <20110604052946.Q3281@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, rmacklem@FreeBSD.org Subject: Re: [PATCH] Set the DE_UPDATE flag on the directory node on msdosfs 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, 03 Jun 2011 21:07:03 -0000 On Sat, 4 Jun 2011, Bruce Evans wrote: > On Fri, 3 Jun 2011, Kevin Lo wrote: >> Thank kib@ for pointing that out. Yes, the NFS clients running on Linux. >> I looked at the Darwin's msdosfs: >> http://opensource.apple.com/source/msdosfs/msdosfs-48/msdosfs.kextproj/msdosfs.kmodproj/msdosfs_lookup.c >> >> It seems the DE_UPDATE flag is also set in createde() and removede(). > ... > I will check what Linux (2.6.10) msdosfs does. It is incompatible in the same way as Apple. It has the following other bugs for the root directory (note that the msdosfs root directory has no place to store any timestamps on disks, so any timestamps can only be transient): - the timestamps after mount were the Epoch. This is not a valid msdosfs timestamp - changes to the directory update the ctime and the mtime but not the atime In FreeBSD and WinXP, the timestamp for the root directory is invariant at 1 am 1 Jan 1980. BTW, I use the following related changes which allow managing msdosfs directory timestamps from FreeBSD. Even WinXP allows changing directory timestamps using WinXP's analogue of utimes() (I don't know what this is, but it must exist since Cygwin touch can set directory times). % Index: msdosfs_vnops.c % =================================================================== % RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v % retrieving revision 1.147 % diff -u -2 -r1.147 msdosfs_vnops.c % --- msdosfs_vnops.c 4 Feb 2004 21:52:53 -0000 1.147 % +++ msdosfs_vnops.c 12 Nov 2007 21:47:48 -0000 % @@ -457,5 +457,7 @@ % (error = VOP_ACCESS(ap->a_vp, VWRITE, cred, ap->a_td)))) % return (error); % +#if 0 % if (vp->v_type != VDIR) { % +#endif Hack to not treat directories specially here... % if ((pmp->pm_flags & MSDOSFSMNT_NOWIN95) == 0 && % vap->va_atime.tv_sec != VNOVAL) { % @@ -463,4 +465,7 @@ % unix2dostime(&vap->va_atime, &dep->de_ADate, % NULL, NULL); % + if (vp->v_type != VDIR) % + dep->de_Attributes |= ATTR_ARCHIVE; ...but still avoid setting ATTR_ARCHIVES for directories. % + dep->de_flag |= DE_MODIFIED; Don't set this unconditionally. Only set it it we actually set a time. I think this makes no difference in practice, since although in theory the caller might only ask to set a time that we don't set (the atime in some cases), all callers in practice always ask to set both times. This is missing the optimization of not setting DE_MODIFIED (and thus being forced to write out the denode) for null changes. msdosfs does this optimization for most settings of times in denode.h. ffs is also missing this optimization. Except in my version for both, I compare the in-core inode with the on-disk inode, and skip the write for null changes even if XX_MODIFIED says to write. This covers all attributes. % } % if (vap->va_mtime.tv_sec != VNOVAL) { % @@ -468,8 +473,11 @@ % unix2dostime(&vap->va_mtime, &dep->de_MDate, % &dep->de_MTime, NULL); % + if (vp->v_type != VDIR) % + dep->de_Attributes |= ATTR_ARCHIVE; % + dep->de_flag |= DE_MODIFIED; % } % - dep->de_Attributes |= ATTR_ARCHIVE; % - dep->de_flag |= DE_MODIFIED; % +#if 0 % } % +#endif % } % /* Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 21:13: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 DC8FA1065688; Fri, 3 Jun 2011 21:13:46 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 5D3918FC17; Fri, 3 Jun 2011 21:13:46 +0000 (UTC) Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p53LDi6f005306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Jun 2011 07:13:45 +1000 Date: Sat, 4 Jun 2011 07:13:44 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Per von Zweigbergk In-Reply-To: <9DD5A034-DA68-4D03-8B0D-F484AAE003CC@itassistans.se> Message-ID: <20110604070707.K970@besplex.bde.org> References: <1307069726.2024.18.camel@nsl> <1307071973.2024.19.camel@nsl> <20110603173555.X994@besplex.bde.org> <20110603105904.GM48734@deviant.kiev.zoral.com.ua> <1307106007.2865.8.camel@nsl> <20110604052946.Q3281@besplex.bde.org> <9DD5A034-DA68-4D03-8B0D-F484AAE003CC@itassistans.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, rmacklem@FreeBSD.org Subject: Re: [PATCH] Set the DE_UPDATE flag on the directory node on msdosfs 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, 03 Jun 2011 21:13:46 -0000 On Fri, 3 Jun 2011, Per von Zweigbergk wrote: > 3 jun 2011 kl. 22.04 skrev Bruce Evans: > >> BTW, how do you get unmangled source files from Apple? The one in the >> above URL is actually an html file so it is fully mangled when fetched. > > There's a "plain text" link at the top. This gives even worse results for me (with lynx): - selecting the link gives a directory listing; downloading file.c from this gives file.c.gz which is actually an html file gzipped - downloading on the link gives a poor recommended file name (?.txt) and a file which is actually an html file. I think the file is the same one as from downloading using fetch on the original url, but didn't check this. Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Jun 3 22:06: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 1F27F1065672 for ; Fri, 3 Jun 2011 22:06:27 +0000 (UTC) (envelope-from sortris@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id A167F8FC19 for ; Fri, 3 Jun 2011 22:06:26 +0000 (UTC) Received: by ewy1 with SMTP id 1so1075370ewy.13 for ; Fri, 03 Jun 2011 15:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=8alkTc6Clf1ssNFe/mdoslUpxMGbDvD40jxtiN/OQGk=; b=a3uWmBKHHcVpSGPa9q8xJrurI2564hZsGgPz6K8msYuEC7x0ITJoeP9Ba0przN3Rhw Zo+L7msk5Nv5A/HM/aBw01X75FMAB9csUqaKD84Sp3FrDhZpw54nNEmmlVn9UQsgEBft PtNRJFW0ZhoqZAa3leXKNsTkn2EB8nJO/h6K4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=ezGmJukn0QVm3ysU1Yy8RVuFZEw8GZAV39JjnPwVpyozgjihqe/yRbOJBHVFe5yM/W 6tM2KdME/rg7WENKim68FJJGwmjggz40ypEWqu8OOvgNrOz5sjF6vlVusdORkzK3flcm L+6eCpiSvwJ2FlZiSnqK5kwwo9TIQAlR4EhHM= MIME-Version: 1.0 Received: by 10.14.50.7 with SMTP id y7mr973209eeb.83.1307136890163; Fri, 03 Jun 2011 14:34:50 -0700 (PDT) Sender: sortris@gmail.com Received: by 10.14.28.136 with HTTP; Fri, 3 Jun 2011 14:34:50 -0700 (PDT) Date: Fri, 3 Jun 2011 23:34:50 +0200 X-Google-Sender-Auth: eqbMhRoilDGnGRcutaSmtE4ObE4 Message-ID: From: =?ISO-8859-2?Q?Tobiasz_Siemi=F1ski?= To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: NFSv4 at Diskless Station 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, 03 Jun 2011 22:06:27 -0000 Hello, I have a little problem with FreeBsd9 at the diskless station. I want to configure NFSv4 server on it, I have specific configuration and I dont know which kernel modules are necessary to work correctly. Could you say which modules are the most important and which order of loading them is ok. Could I load these modules by kldload after boot system? When I load nfs_common, nfsclient.ko, nfsserver.ko with kldload, then I configure nfsv4 server and when i am trying to mount nfsv4 client on other station it mounts nfsv3 client. Best regards, Tobiasz Siemi=F1ski. From owner-freebsd-fs@FreeBSD.ORG Sat Jun 4 00:21: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 810B81065670 for ; Sat, 4 Jun 2011 00:21:28 +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 3EC348FC0C for ; Sat, 4 Jun 2011 00:21:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAAl66U2DaFvO/2dsb2JhbABThEqidIhxsEWQWoErg2yBCgSQdI9V X-IronPort-AV: E=Sophos;i="4.65,317,1304308800"; d="scan'208";a="126829356" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 03 Jun 2011 20:21:26 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 07A11B3F8E; Fri, 3 Jun 2011 20:21:27 -0400 (EDT) Date: Fri, 3 Jun 2011 20:21:27 -0400 (EDT) From: Rick Macklem To: =?utf-8?Q?Tobiasz_Siemi=C5=84ski?= Message-ID: <1243226547.108967.1307146886997.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.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 at Diskless Station 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, 04 Jun 2011 00:21:28 -0000 > Tobiasz wrote: > Hello, > I have a little problem with FreeBsd9 at the diskless station. I want > to > configure NFSv4 server on it, I have specific configuration and I dont > know > which kernel modules are necessary to work correctly. Could you say > which > modules are the most important and which order of loading them is ok. > Could > I load these modules by kldload after boot system? >=20 > When I load nfs_common, nfsclient.ko, nfsserver.ko with kldload, then > I > configure nfsv4 server and when i am trying to mount nfsv4 client on > other > station it mounts nfsv3 client. > Best regards, Tobiasz Siemi=C5=84ski. > Those modules are the old server that doesn't support NFSv4. You can set the following in /etc/rc.conf: nfs_server_enable=3D"YES" nfsv4_server_enable=3D"YES" or if you want to load the module yourself, do a: # kldload nfsd.ko <-- it will load any others that are needed You'll also need a "V4:" line in your /etc/exports. Look at "man nfsv4" for more info, rick ps: The diskless root fs needs to use nfsv3, but other mounts can be NFSv4. From owner-freebsd-fs@FreeBSD.ORG Sat Jun 4 01:49:23 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7AD3106564A for ; Sat, 4 Jun 2011 01:49:22 +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 7D22E8FC0A for ; Sat, 4 Jun 2011 01:49:22 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QSfzM-0005QH-V5 for freebsd-fs@freebsd.org; Sat, 04 Jun 2011 03:49:20 +0200 Received: from dyn1245-230.vpn.ic.ac.uk ([129.31.245.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Jun 2011 03:49:20 +0200 Received: from jtotz by dyn1245-230.vpn.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Jun 2011 03:49:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Sat, 04 Jun 2011 02:49:06 +0100 Lines: 89 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: dyn1245-230.vpn.ic.ac.uk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Subject: Re: fusefs broken on 8-stable? 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, 04 Jun 2011 01:49:23 -0000 On 13/05/2011 13:56, Johannes Totz wrote: > Heya! > > Using encfs (built on top of fuse) gives me panics in combination with > rsync. Dump didn't succeed. The info below is transcribbled from a > photograph. This is repeatable. > Without dump this is probably not very helpful.... > > > # uname -a > FreeBSD XXX 8.2-STABLE FreeBSD 8.2-STABLE #1: Thu Mar 10 23:30:08 GMT > 2011 root@XXX:/usr/obj/usr/src/sys/GENERIC amd64 Managed to get a dump: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x40 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff81f2ba3c stack pointer = 0x28:0xffffff813aa2f570 frame pointer = 0x28:0xffffff813aa2f5a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1560 (rsync) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: #0 0xffffffff805cc226 at kdb_backtrace+0x5c #1 0xffffffff8059d000 at panic+0x1b4 #2 0xffffffff80875a75 at trap_fatal+0x394 #3 0xffffffff80875ce5 at trap_pfault+0x252 #4 0xffffffff808761b5 at trap+0x3f4 #5 0xffffffff8085f384 at calltrap+0x8 #6 0xffffffff81f2c170 at fdisp_make+0xe4 #7 0xffffffff81f3033d at fuse_lookup+0x1dc #8 0xffffffff808caac8 at VOP_LOOKUP_APV+0x4c #9 0xffffffff8061b0db at lookup+0x61e #10 0xffffffff8061bf1f at namei+0x592 #11 0xffffffff80629df4 at kern_statat_vnhook+0x87 #12 0xffffffff80629f98 at kern_statat+0x15 #13 0xffffffff80629fb6 at kern_lstat+0x1c #14 0xffffffff8062a03d at lstat+0x25 #15 0xffffffff805d7cf4 at syscallenter+0x2d9 #16 0xffffffff80875d45 at syscall+0x38 #17 0xffffffff8085f662 at Xfast_syscall+0xe2 #0 doadump () at pcpu.h:224 #1 0xffffffff8059cd12 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff8059d03b in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0xffffffff80875a75 in trap_fatal (frame=0xffffff813aa2f4c0, eva=64) at /usr/src/sys/amd64/amd64/trap.c:809 #4 0xffffffff80875ce5 in trap_pfault (frame=0xffffff813aa2f4c0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:725 #5 0xffffffff808761b5 in trap (frame=0xffffff813aa2f4c0) at /usr/src/sys/amd64/amd64/trap.c:475 #6 0xffffffff8085f384 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff81f2ba3c in fiov_adjust () from /usr/local/modules/fuse.ko #8 0xffffffff81f2c170 in fdisp_make () from /usr/local/modules/fuse.ko #9 0xffffffff81f3033d in fuse_lookup () from /usr/local/modules/fuse.ko #10 0xffffffff808caac8 in VOP_LOOKUP_APV (vop=0x0, a=0x30) at vnode_if.c:123 #11 0xffffffff8061b0db in lookup (ndp=0x618) at vnode_if.h:54 #12 0xffffffff8061bf1f in namei (ndp=0xffffff813aa2f8e0) at /usr/src/sys/kern/vfs_lookup.c:269 #13 0xffffffff80629df4 in kern_statat_vnhook (td=0xffffff00039f2460, flag=Variable "flag" is not available.) at /usr/src/sys/kern/vfs_syscalls.c:2346 #14 0xffffffff80629f98 in kern_statat (td=Variable "td" is not available.) at /usr/src/sys/kern/vfs_syscalls.c:2327 #15 0xffffffff80629fb6 in kern_lstat (td=Variable "td" is not available.) at /usr/src/sys/kern/vfs_syscalls.c:2400 #16 0xffffffff8062a03d in lstat (td=Variable "td" is not available.) at /usr/src/sys/kern/vfs_syscalls.c:2390 #17 0xffffffff805d7cf4 in syscallenter (td=0xffffff00039f2460, sa=0xffffff813aa2fbc0) at /usr/src/sys/kern/subr_trap.c:315 #18 0xffffffff80875d45 in syscall (frame=0xffffff813aa2fc50) at /usr/src/sys/amd64/amd64/trap.c:914 #19 0xffffffff8085f662 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:381 #20 0x000000080097a5dc in ?? () At #10 a=0x30 looks dodgy and fault address is 0x40, but I have no idea what that means... From owner-freebsd-fs@FreeBSD.ORG Sat Jun 4 10:15:20 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68E011065674 for ; Sat, 4 Jun 2011 10:15:20 +0000 (UTC) (envelope-from dave.evans55@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EF8778FC17 for ; Sat, 4 Jun 2011 10:15:19 +0000 (UTC) Received: by wyf23 with SMTP id 23so2607586wyf.13 for ; Sat, 04 Jun 2011 03:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; bh=OGX/5OGkB13Jj3vWHbaoXu5iAv9V4TRo1hDYM3jNt9A=; b=g/VvzWSAzKyl8KLbmJxGHNmTQAoMrmTLs61AYW1rWySr4n+Sq/0Hy5hwfCt33ESXo9 lkoOpKSiMqQx2PgRTTZLBjPqmIC0Ho9zORn0uJcARfgZPTYz4i1uG4YyaUjAen+UmEKO bXtRlIBZtgXNIvMr20GbYNnnEuWsaNEPEenHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=HwZnCk6lt5JYiHX5qTIHxqTGErj6U9/cvCssa4WCFfpHfuroDEaCZ3fmSVVooBw+1U pM1ihwAkelEoyPiVyxaaEETZ7aq8YTwoJfCzZPDdedtfQg6/Khq6IuT4aIKq3RyxsILp o3cdcQRqxcyfGxjGRHTDqnBREfWV912A+wCJ8= Received: by 10.227.195.13 with SMTP id ea13mr2888736wbb.0.1307181040125; Sat, 04 Jun 2011 02:50:40 -0700 (PDT) Received: from two.pearl (dsl-fixed-77-44-81-131.interdsl.co.uk [77.44.81.131]) by mx.google.com with ESMTPS id ex2sm1553535wbb.14.2011.06.04.02.50.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Jun 2011 02:50:39 -0700 (PDT) Message-ID: <4DE9FFEC.7070206@googlemail.com> Date: Sat, 04 Jun 2011 10:50:36 +0100 From: David Evans User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: fsck does not work on ZFS ZVOL formatted as UFS2 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, 04 Jun 2011 10:15:20 -0000 This does not work zroot2 is a ZFS pool zfs create -V 10g zroot2/volume newfs /dev/zvol/zroot2/volume fsck /dev/zvol/zroot2/volume returns error- fsck: Could not determine filesystem type dumpfs and tunefs work on the volume. Perhaps I am doing something wrong, otherwise I would submit this as a bug report. 9-CURRENT as of a few days ago, amd64 From owner-freebsd-fs@FreeBSD.ORG Sat Jun 4 10:24: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 4CCF5106564A for ; Sat, 4 Jun 2011 10:24:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BCEB88FC0C for ; Sat, 4 Jun 2011 10:24:06 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p54AO2Do079366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Jun 2011 13:24:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p54AO2CY029128; Sat, 4 Jun 2011 13:24:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p54AO2vb029127; Sat, 4 Jun 2011 13:24:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Jun 2011 13:24:02 +0300 From: Kostik Belousov To: David Evans Message-ID: <20110604102402.GN48734@deviant.kiev.zoral.com.ua> References: <4DE9FFEC.7070206@googlemail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hMqxZgAHHKe5m0zX" Content-Disposition: inline In-Reply-To: <4DE9FFEC.7070206@googlemail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: fsck does not work on ZFS ZVOL formatted as UFS2 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, 04 Jun 2011 10:24:07 -0000 --hMqxZgAHHKe5m0zX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 04, 2011 at 10:50:36AM +0100, David Evans wrote: > This does not work >=20 > zroot2 is a ZFS pool >=20 > zfs create -V 10g zroot2/volume > newfs /dev/zvol/zroot2/volume > fsck /dev/zvol/zroot2/volume >=20 > returns error- fsck: Could not determine filesystem type >=20 > dumpfs and tunefs work on the volume. >=20 > Perhaps I am doing something wrong, otherwise I > would submit this as a bug report. >=20 > 9-CURRENT as of a few days ago, amd64 fsck needs an entry in fstab to determine the filesystem type. Either add the line to fstab, or use -t ufs. This has nothing to do with zvols. --hMqxZgAHHKe5m0zX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3qB8EACgkQC3+MBN1Mb4ho3QCfT/w6gN2qBk+BZXcKj/xXieG5 V+kAoMt8ZmPcxBzFFSGXRb66cZqk/gIn =Ogze -----END PGP SIGNATURE----- --hMqxZgAHHKe5m0zX-- From owner-freebsd-fs@FreeBSD.ORG Sat Jun 4 11:57:56 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 CB9AB106566C; Sat, 4 Jun 2011 11:57:56 +0000 (UTC) (envelope-from pvz@itassistans.se) Received: from zcs1.itassistans.net (zcs1.itassistans.net [212.112.191.37]) by mx1.freebsd.org (Postfix) with ESMTP id 75B0D8FC14; Sat, 4 Jun 2011 11:57:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs1.itassistans.net (Postfix) with ESMTP id BD971C0234; Sat, 4 Jun 2011 13:57:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at zcs1.itassistans.net Received: from zcs1.itassistans.net ([127.0.0.1]) by localhost (zcs1.itassistans.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1T02dA4qOP2; Sat, 4 Jun 2011 13:57:54 +0200 (CEST) Received: from [192.168.1.239] (c213-89-160-61.bredband.comhem.se [213.89.160.61]) by zcs1.itassistans.net (Postfix) with ESMTPSA id E6275C01FC; Sat, 4 Jun 2011 13:57:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Per von Zweigbergk In-Reply-To: <20110604070707.K970@besplex.bde.org> Date: Sat, 4 Jun 2011 13:57:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1307069726.2024.18.camel@nsl> <1307071973.2024.19.camel@nsl> <20110603173555.X994@besplex.bde.org> <20110603105904.GM48734@deviant.kiev.zoral.com.ua> <1307106007.2865.8.camel@nsl> <20110604052946.Q3281@besplex.bde.org> <9DD5A034-DA68-4D03-8B0D-F484AAE003CC@itassistans.se> <20110604070707.K970@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@FreeBSD.org, rmacklem@FreeBSD.org Subject: Re: [PATCH] Set the DE_UPDATE flag on the directory node on msdosfs 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, 04 Jun 2011 11:57:56 -0000 3 jun 2011 kl. 23.13 skrev Bruce Evans: > On Fri, 3 Jun 2011, Per von Zweigbergk wrote: >=20 >> 3 jun 2011 kl. 22.04 skrev Bruce Evans: >>=20 >>> BTW, how do you get unmangled source files from Apple? The one in = the >>> above URL is actually an html file so it is fully mangled when = fetched. >>=20 >> There's a "plain text" link at the top. >=20 > This gives even worse results for me (with lynx): > - selecting the link gives a directory listing; downloading file.c = from > this gives file.c.gz which is actually an html file gzipped > - downloading on the link gives a poor recommended file name (?.txt) > and a file which is actually an html file. I think the file is the > same one as from downloading using fetch on the original url, but > didn't check this. >=20 > Bruce Odd, I just tested this on Lynx on a machine I have access to, and while = it's true that I got a bad recommended filename, I was able to download = the plain text of the source code just fine. We can continue off-list = though, since this discussion looks like it's going to be off-topic. :-)= From owner-freebsd-fs@FreeBSD.ORG Sat Jun 4 12:21:18 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 5999C106566C; Sat, 4 Jun 2011 12:21:18 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 810398FC12; Sat, 4 Jun 2011 12:21:17 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QSpql-000Gep-Uf; Sat, 04 Jun 2011 14:21:16 +0200 Message-ID: <4DEA232C.8000804@it4pro.pl> Date: Sat, 04 Jun 2011 14:21:00 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4DE7C122.2040004@it4pro.pl> <20110603121625.GD1862@garage.freebsd.pl> In-Reply-To: <20110603121625.GD1862@garage.freebsd.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.76 (build at 12-May-2011 10:41:54) X-Date: 2011-06-04 14:21:16 X-Connected-IP: 78.8.144.74:49425 X-Message-Linecount: 342 X-Body-Linecount: 328 X-Message-Size: 16291 X-Body-Size: 15635 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: freebsd-fs@freebsd.org Subject: Re: [ZFSv28] Loader hangs, import failes, zfs filesystem 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: Sat, 04 Jun 2011 12:21:18 -0000 W dniu 2011-06-03 14:16, Pawel Jakub Dawidek pisze: > On Thu, Jun 02, 2011 at 06:58:10PM +0200, Bartosz Stec wrote: >> Hi list, >> Today I needed to shut down my home server (FreeSBD9-CURRENT, 3 x >> 40GB ATA HDD in RADZ1, ZFS only, GPT, i386) for a moment. After >> power up, loader started to spin cursor indifinitely, and didn't >> load the kernel. No error messages, no hints, just spinning cursor. >> I tried booting from other HDDs in case that bootstrap area errors >> on single hdd but no luck. >> I wanted to play with latest current LiveFS snapshot (with ZFSv28 >> support), but apparently latest one is from february?? >> Finally I ended with mfsBSD from http://mfsbsd.vx.sk/ >> I've downloaded "8.2-RELEASE-i386 with ZFSv28 special edition >> " iso, burned >> it and booted machine. Here's what happened when i was trying to >> import zpool: >> >> mfsbsd# zpool status >> no pools available >> mfsbsd# zpool import >> pool: zroot >> id: 16074929158756467860 >> state: ONLINE >> status: The pool was last accessed by another system. >> action: The pool can be imported using its name or numeric >> identifier and >> the '-f' flag. >> see: http://www.sun.com/msg/ZFS-8000-EY >> config: >> >> zroot ONLINE >> raidz1-0 ONLINE >> gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE >> gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE >> gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE >> mfsbsd# zpool import -f zroot >> cannot import 'zroot': one or more devices is currently unavailable > Is there anything that may keep any of those vdevs open? > Try setting vfs.zfs.debug to 1 before import. > mfsbsd# zpool import -f zroot cannot import 'zroot': one or more devices is currently unavailable mfsbsd# dmesg vdev_geom_open_by_guid:352[1]: Searching by guid [2774520698453861827]. vdev_geom_read_guid:239[1]: Reading guid from acd0t01... vdev_geom_read_guid:239[1]: Reading guid from acd0... vdev_geom_read_guid:239[1]: Reading guid from gptid/87d467cc-bc3b-11df-8066-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/87d467cc-bc3b-11df-8066-0050dad823cd is 8179308819206918822 vdev_geom_read_guid:239[1]: Reading guid from gptid/f5ee2146-bc3a-11df-8066-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gpt/swap2... vdev_geom_read_guid:239[1]: Reading guid from gptid/c506cc78-bc3a-11df-8066-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gptid/5bc92016-6852-11df-a16c-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/5bc92016-6852-11df-a16c-0050dad823cd is 8243099701788087797 vdev_geom_read_guid:239[1]: Reading guid from gptid/303e329f-6852-11df-a16c-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gpt/swap1... vdev_geom_read_guid:239[1]: Reading guid from gptid/060c432a-6852-11df-a16c-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gptid/2ea57c66-bc69-11df-8955-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/2ea57c66-bc69-11df-8955-0050dad823cd is 2774520698453861827 vdev_geom_attach:95[1]: Attaching to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_attach:116[1]: Created geom and consumer for gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_open_by_guid:363[1]: Attach by guid [2774520698453861827] succeeded, provider /dev/gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_open_by_guid:352[1]: Searching by guid [8243099701788087797]. vdev_geom_read_guid:239[1]: Reading guid from acd0t01... vdev_geom_read_guid:239[1]: Reading guid from acd0... vdev_geom_read_guid:239[1]: Reading guid from gptid/87d467cc-bc3b-11df-8066-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/87d467cc-bc3b-11df-8066-0050dad823cd is 8179308819206918822 vdev_geom_read_guid:239[1]: Reading guid from gptid/f5ee2146-bc3a-11df-8066-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gpt/swap2... vdev_geom_read_guid:239[1]: Reading guid from gptid/c506cc78-bc3a-11df-8066-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gptid/5bc92016-6852-11df-a16c-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/5bc92016-6852-11df-a16c-0050dad823cd is 8243099701788087797 vdev_geom_attach:95[1]: Attaching to gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_attach:136[1]: Created consumer for gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_open_by_guid:363[1]: Attach by guid [8243099701788087797] succeeded, provider /dev/gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_open_by_guid:352[1]: Searching by guid [8179308819206918822]. vdev_geom_read_guid:239[1]: Reading guid from acd0t01... vdev_geom_read_guid:239[1]: Reading guid from acd0... vdev_geom_read_guid:239[1]: Reading guid from gptid/87d467cc-bc3b-11df-8066-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/87d467cc-bc3b-11df-8066-0050dad823cd is 8179308819206918822 vdev_geom_attach:95[1]: Attaching to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_attach:136[1]: Created consumer for gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_open_by_guid:363[1]: Attach by guid [8179308819206918822] succeeded, provider /dev/gptid/87d467cc-bc3b-11df-8066-0050dad823cd. log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented vdev_geom_detach:156[1]: Closing access to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_detach:160[1]: Destroyed consumer to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_detach:156[1]: Closing access to gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_detach:160[1]: Destroyed consumer to gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_detach:156[1]: Closing access to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_detach:160[1]: Destroyed consumer to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_detach:168[1]: Destroyed geom zfs::vdev. vdev_geom_open_by_guid:352[1]: Searching by guid [2774520698453861827]. vdev_geom_read_guid:239[1]: Reading guid from acd0t01... vdev_geom_read_guid:239[1]: Reading guid from acd0... vdev_geom_read_guid:239[1]: Reading guid from gptid/87d467cc-bc3b-11df-8066-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/87d467cc-bc3b-11df-8066-0050dad823cd is 8179308819206918822 vdev_geom_read_guid:239[1]: Reading guid from gptid/f5ee2146-bc3a-11df-8066-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gpt/swap2... vdev_geom_read_guid:239[1]: Reading guid from gptid/c506cc78-bc3a-11df-8066-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gptid/5bc92016-6852-11df-a16c-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/5bc92016-6852-11df-a16c-0050dad823cd is 8243099701788087797 vdev_geom_read_guid:239[1]: Reading guid from gptid/303e329f-6852-11df-a16c-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gpt/swap1... vdev_geom_read_guid:239[1]: Reading guid from gptid/060c432a-6852-11df-a16c-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gptid/2ea57c66-bc69-11df-8955-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/2ea57c66-bc69-11df-8955-0050dad823cd is 2774520698453861827 vdev_geom_attach:95[1]: Attaching to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_attach:116[1]: Created geom and consumer for gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_open_by_guid:363[1]: Attach by guid [2774520698453861827] succeeded, provider /dev/gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_open_by_guid:352[1]: Searching by guid [8243099701788087797]. vdev_geom_read_guid:239[1]: Reading guid from acd0t01... vdev_geom_read_guid:239[1]: Reading guid from acd0... vdev_geom_read_guid:239[1]: Reading guid from gptid/87d467cc-bc3b-11df-8066-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/87d467cc-bc3b-11df-8066-0050dad823cd is 8179308819206918822 vdev_geom_read_guid:239[1]: Reading guid from gptid/f5ee2146-bc3a-11df-8066-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gpt/swap2... vdev_geom_read_guid:239[1]: Reading guid from gptid/c506cc78-bc3a-11df-8066-0050dad823cd... vdev_geom_read_guid:239[1]: Reading guid from gptid/5bc92016-6852-11df-a16c-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/5bc92016-6852-11df-a16c-0050dad823cd is 8243099701788087797 vdev_geom_attach:95[1]: Attaching to gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_attach:136[1]: Created consumer for gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_open_by_guid:363[1]: Attach by guid [8243099701788087797] succeeded, provider /dev/gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_open_by_guid:352[1]: Searching by guid [8179308819206918822]. vdev_geom_read_guid:239[1]: Reading guid from acd0t01... vdev_geom_read_guid:239[1]: Reading guid from acd0... vdev_geom_read_guid:239[1]: Reading guid from gptid/87d467cc-bc3b-11df-8066-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/87d467cc-bc3b-11df-8066-0050dad823cd is 8179308819206918822 vdev_geom_attach:95[1]: Attaching to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_attach:136[1]: Created consumer for gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_open_by_guid:363[1]: Attach by guid [8179308819206918822] succeeded, provider /dev/gptid/87d467cc-bc3b-11df-8066-0050dad823cd. log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented vdev_geom_detach:156[1]: Closing access to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_detach:160[1]: Destroyed consumer to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_detach:156[1]: Closing access to gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_detach:160[1]: Destroyed consumer to gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_detach:156[1]: Closing access to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_detach:160[1]: Destroyed consumer to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_detach:168[1]: Destroyed geom zfs::vdev. vdev_geom_open_by_path:384[1]: Found provider by name /dev/gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_attach:95[1]: Attaching to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_attach:116[1]: Created geom and consumer for gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_read_guid:239[1]: Reading guid from gptid/2ea57c66-bc69-11df-8955-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/2ea57c66-bc69-11df-8955-0050dad823cd is 2774520698453861827 vdev_geom_open_by_path:399[1]: guid match for provider /dev/gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_open_by_path:384[1]: Found provider by name /dev/gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_attach:95[1]: Attaching to gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_attach:136[1]: Created consumer for gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_read_guid:239[1]: Reading guid from gptid/5bc92016-6852-11df-a16c-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/5bc92016-6852-11df-a16c-0050dad823cd is 8243099701788087797 vdev_geom_open_by_path:399[1]: guid match for provider /dev/gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_open_by_path:384[1]: Found provider by name /dev/gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_attach:95[1]: Attaching to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_attach:136[1]: Created consumer for gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_read_guid:239[1]: Reading guid from gptid/87d467cc-bc3b-11df-8066-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/87d467cc-bc3b-11df-8066-0050dad823cd is 8179308819206918822 vdev_geom_open_by_path:399[1]: guid match for provider /dev/gptid/87d467cc-bc3b-11df-8066-0050dad823cd. log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented log_sysevent: type 19 is not implemented vdev_geom_detach:156[1]: Closing access to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_detach:160[1]: Destroyed consumer to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_open_by_path:384[1]: Found provider by name /dev/gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_attach:95[1]: Attaching to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_attach:136[1]: Created consumer for gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_read_guid:239[1]: Reading guid from gptid/2ea57c66-bc69-11df-8955-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/2ea57c66-bc69-11df-8955-0050dad823cd is 2774520698453861827 vdev_geom_open_by_path:399[1]: guid match for provider /dev/gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_open_by_path:384[1]: Found provider by name /dev/gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_attach:95[1]: Attaching to gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_attach:121[1]: Found consumer for gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_attach:140[1]: Used existing consumer for gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_read_guid:239[1]: Reading guid from gptid/5bc92016-6852-11df-a16c-0050dad823cd... vdev_geom_detach:156[1]: Closing access to gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_detach:156[1]: Closing access to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_detach:160[1]: Destroyed consumer to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_read_guid:273[1]: guid for gptid/5bc92016-6852-11df-a16c-0050dad823cd is 8243099701788087797 vdev_geom_open_by_path:399[1]: guid match for provider /dev/gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_open_by_path:384[1]: Found provider by name /dev/gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_attach:95[1]: Attaching to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_attach:136[1]: Created consumer for gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_read_guid:239[1]: Reading guid from gptid/87d467cc-bc3b-11df-8066-0050dad823cd... vdev_geom_read_guid:273[1]: guid for gptid/87d467cc-bc3b-11df-8066-0050dad823cd is 8179308819206918822 vdev_geom_open_by_path:399[1]: guid match for provider /dev/gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_detach:156[1]: Closing access to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_detach:160[1]: Destroyed consumer to gptid/2ea57c66-bc69-11df-8955-0050dad823cd. vdev_geom_detach:156[1]: Closing access to gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_detach:160[1]: Destroyed consumer to gptid/5bc92016-6852-11df-a16c-0050dad823cd. vdev_geom_detach:156[1]: Closing access to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_detach:160[1]: Destroyed consumer to gptid/87d467cc-bc3b-11df-8066-0050dad823cd. vdev_geom_detach:168[1]: Destroyed geom zfs::vdev. -- Bartosz Stec From owner-freebsd-fs@FreeBSD.ORG Sat Jun 4 16:56: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 E4241106564A; Sat, 4 Jun 2011 16:56:06 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1368FC08; Sat, 4 Jun 2011 16:56:06 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QSu8i-000HIU-EH; Sat, 04 Jun 2011 18:56:05 +0200 Message-ID: <4DEA6394.5000602@it4pro.pl> Date: Sat, 04 Jun 2011 18:55:48 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4DE7C122.2040004@it4pro.pl> <20110603121625.GD1862@garage.freebsd.pl> <4DEA232C.8000804@it4pro.pl> In-Reply-To: <4DEA232C.8000804@it4pro.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.76 (build at 12-May-2011 10:41:54) X-Date: 2011-06-04 18:56:05 X-Connected-IP: 78.8.144.74:56550 X-Message-Linecount: 74 X-Body-Linecount: 60 X-Message-Size: 3393 X-Body-Size: 2721 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: Pawel Jakub Dawidek Subject: Re: [ZFSv28] Loader hangs, import failes, zfs filesystem 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: Sat, 04 Jun 2011 16:56:07 -0000 W dniu 2011-06-04 14:21, Bartosz Stec pisze: > W dniu 2011-06-03 14:16, Pawel Jakub Dawidek pisze: >> On Thu, Jun 02, 2011 at 06:58:10PM +0200, Bartosz Stec wrote: >>> Hi list, >>> Today I needed to shut down my home server (FreeSBD9-CURRENT, 3 x >>> 40GB ATA HDD in RADZ1, ZFS only, GPT, i386) for a moment. After >>> power up, loader started to spin cursor indifinitely, and didn't >>> load the kernel. No error messages, no hints, just spinning cursor. >>> I tried booting from other HDDs in case that bootstrap area errors >>> on single hdd but no luck. >>> I wanted to play with latest current LiveFS snapshot (with ZFSv28 >>> support), but apparently latest one is from february?? >>> Finally I ended with mfsBSD from http://mfsbsd.vx.sk/ >>> I've downloaded "8.2-RELEASE-i386 with ZFSv28 special edition >>> " iso, burned >>> it and booted machine. Here's what happened when i was trying to >>> import zpool: >>> >>> mfsbsd# zpool status >>> no pools available >>> mfsbsd# zpool import >>> pool: zroot >>> id: 16074929158756467860 >>> state: ONLINE >>> status: The pool was last accessed by another system. >>> action: The pool can be imported using its name or numeric >>> identifier and >>> the '-f' flag. >>> see: http://www.sun.com/msg/ZFS-8000-EY >>> config: >>> >>> zroot ONLINE >>> raidz1-0 ONLINE >>> gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE >>> gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE >>> gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE >>> mfsbsd# zpool import -f zroot >>> cannot import 'zroot': one or more devices is currently unavailable >> Is there anything that may keep any of those vdevs open? >> Try setting vfs.zfs.debug to 1 before import. >> > It seems that LiveFS is now included in bootonly ISO, so I made another attempt using FreeBSD-9.0-CURRENT-201105-i386-bootonly.iso image. I tried importing with debugging enabled, but dmesg output was the same as in my previous message. I had so much faith in raidz + snapshots, that I have absolutely no backups of this system :( I don't care about time which is needed to find a problem and possible fix, but I am really worried about my data now. What else could I do? And yes, I know that I shouldn't treat CURRENT as a stable and reliable system, and you never have too much backups. I just didn't realized how important data on this machine is until I realized that maybe I just lost it... Crap. -- Bartosz Stec From owner-freebsd-fs@FreeBSD.ORG Sat Jun 4 18:50: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 D5E121065670 for ; Sat, 4 Jun 2011 18:50:25 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE8A8FC12 for ; Sat, 4 Jun 2011 18:50:24 +0000 (UTC) Received: from [IPv6:2001:470:28:140:6c98:8f17:eeb3:d87e] ([IPv6:2001:470:28:140:6c98:8f17:eeb3:d87e]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p54IoGR3099586 for ; Sat, 4 Jun 2011 21:50:16 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4DEA7E50.3090507@ukr.net> Date: Sat, 04 Jun 2011 21:49:52 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4DE7C122.2040004@it4pro.pl> In-Reply-To: <4DE7C122.2040004@it4pro.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-95.5 required=5.0 tests=FREEMAIL_FROM,FSL_RU_URL, RDNS_NONE, SPF_SOFTFAIL, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Sat, 04 Jun 2011 21:50:23 +0300 (EEST) Subject: Re: [ZFSv28] Loader hangs, import failes, zfs filesystem 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: Sat, 04 Jun 2011 18:50:25 -0000 02.06.2011 19:58, Bartosz Stec wrote: > Hi list, > Today I needed to shut down my home server (FreeSBD9-CURRENT, 3 x 40GB > ATA HDD in RADZ1, ZFS only, GPT, i386) for a moment. After power up, > loader started to spin cursor indifinitely, and didn't load the kernel. > No error messages, no hints, just spinning cursor. > I tried booting from other HDDs in case that bootstrap area errors on > single hdd but no luck. > I wanted to play with latest current LiveFS snapshot (with ZFSv28 > support), but apparently latest one is from february?? > Finally I ended with mfsBSD from http://mfsbsd.vx.sk/ > I've downloaded "8.2-RELEASE-i386 with ZFSv28 special edition > " iso, burned it > and booted machine. Here's what happened when i was trying to import zpool: > > mfsbsd# zpool status > no pools available > mfsbsd# zpool import > pool: zroot > id: 16074929158756467860 > state: ONLINE > status: The pool was last accessed by another system. > action: The pool can be imported using its name or numeric > identifier and > the '-f' flag. > see: http://www.sun.com/msg/ZFS-8000-EY > config: > > zroot ONLINE > raidz1-0 ONLINE > gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE > gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE > gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE Please run and show the output of these commands: zpool status -x zdb -l /dev/ad0 zdb -l /dev/ad1 zdb -l /dev/ad2 zdb zroot -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Sat Jun 4 19:12: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 74FB5106566C for ; Sat, 4 Jun 2011 19:12:27 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id CB4068FC15 for ; Sat, 4 Jun 2011 19:12:26 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QSwGe-000Hba-QE; Sat, 04 Jun 2011 21:12:25 +0200 Message-ID: <4DEA838B.3060404@it4pro.pl> Date: Sat, 04 Jun 2011 21:12:11 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Vladislav V. Prodan" References: <4DE7C122.2040004@it4pro.pl> <4DEA7E50.3090507@ukr.net> In-Reply-To: <4DEA7E50.3090507@ukr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.2 X-Spam-Score-Int: -81 X-Exim-Version: 4.76 (build at 12-May-2011 10:41:54) X-Date: 2011-06-04 21:12:25 X-Connected-IP: 78.8.144.74:49418 X-Message-Linecount: 642 X-Body-Linecount: 628 X-Message-Size: 17937 X-Body-Size: 17306 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: freebsd-fs@freebsd.org Subject: Re: [ZFSv28] Loader hangs, import failes, zfs filesystem 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: Sat, 04 Jun 2011 19:12:27 -0000 W dniu 2011-06-04 20:49, Vladislav V. Prodan pisze: > 02.06.2011 19:58, Bartosz Stec wrote: >> Hi list, >> Today I needed to shut down my home server (FreeSBD9-CURRENT, 3 x 40GB >> ATA HDD in RADZ1, ZFS only, GPT, i386) for a moment. After power up, >> loader started to spin cursor indifinitely, and didn't load the kernel. >> No error messages, no hints, just spinning cursor. >> I tried booting from other HDDs in case that bootstrap area errors on >> single hdd but no luck. >> I wanted to play with latest current LiveFS snapshot (with ZFSv28 >> support), but apparently latest one is from february?? >> Finally I ended with mfsBSD from http://mfsbsd.vx.sk/ >> I've downloaded "8.2-RELEASE-i386 with ZFSv28 special edition >> " iso, burned it >> and booted machine. Here's what happened when i was trying to import >> zpool: >> >> mfsbsd# zpool status >> no pools available >> mfsbsd# zpool import >> pool: zroot >> id: 16074929158756467860 >> state: ONLINE >> status: The pool was last accessed by another system. >> action: The pool can be imported using its name or numeric >> identifier and >> the '-f' flag. >> see: http://www.sun.com/msg/ZFS-8000-EY >> config: >> >> zroot ONLINE >> raidz1-0 ONLINE >> gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE >> gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE >> gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE > > Please run and show the output of these commands: > zpool status -x > zdb -l /dev/ad0 > zdb -l /dev/ad1 > zdb -l /dev/ad2 > zdb zroot > 'Zpool status' and 'zdb root' won't work until pool is imported (I think), and I guess you wanted zdb output from ZFS partitions, not whole HDD's, so here you go: mfsbsd# zpool status -x no pools available mfsbsd# zdb zroot zdb: can't open 'zroot': No such file or directory mfsbsd# zdb -l /dev/ad0p3 -------------------------------------------- LABEL 0 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 2774520698453861827 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 -------------------------------------------- LABEL 1 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 2774520698453861827 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 -------------------------------------------- LABEL 2 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 2774520698453861827 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 -------------------------------------------- LABEL 3 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 2774520698453861827 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 mfsbsd# zdb -l /dev/ad1p3 -------------------------------------------- LABEL 0 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 8243099701788087797 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 -------------------------------------------- LABEL 1 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 8243099701788087797 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 -------------------------------------------- LABEL 2 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 8243099701788087797 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 -------------------------------------------- LABEL 3 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 8243099701788087797 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 mfsbsd# zdb -l /dev/ad1p3 -------------------------------------------- LABEL 0 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 8179308819206918822 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 -------------------------------------------- LABEL 1 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 8179308819206918822 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 -------------------------------------------- LABEL 2 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 8179308819206918822 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 -------------------------------------------- LABEL 3 -------------------------------------------- version: 28 name: 'zroot' state: 0 txg: 2686596 pool_guid: 16074929158756467860 hostid: 1256456247 hostname: 'serwer.obsysa.net' top_guid: 16978903338095502658 guid: 8179308819206918822 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 16978903338095502658 nparity: 1 metaslab_array: 23 metaslab_shift: 30 ashift: 9 asize: 116826046464 is_log: 0 children[0]: type: 'disk' id: 0 guid: 2774520698453861827 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 0 DTL: 264 children[1]: type: 'disk' id: 1 guid: 8243099701788087797 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 0 DTL: 779 children[2]: type: 'disk' id: 2 guid: 8179308819206918822 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 0 DTL: 263 -- Bartosz Stec From owner-freebsd-fs@FreeBSD.ORG Sat Jun 4 19:56:49 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86BDF106564A; Sat, 4 Jun 2011 19:56:49 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0BD8FC0C; Sat, 4 Jun 2011 19:56:48 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QSwxb-000Hjc-8q; Sat, 04 Jun 2011 21:56:46 +0200 Message-ID: <4DEA8DF1.4060302@it4pro.pl> Date: Sat, 04 Jun 2011 21:56:33 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4DE7C122.2040004@it4pro.pl> <20110603121625.GD1862@garage.freebsd.pl> <4DEA232C.8000804@it4pro.pl> <4DEA6394.5000602@it4pro.pl> In-Reply-To: <4DEA6394.5000602@it4pro.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.2 X-Spam-Score-Int: -81 X-Exim-Version: 4.76 (build at 12-May-2011 10:41:54) X-Date: 2011-06-04 21:56:46 X-Connected-IP: 78.8.144.74:50101 X-Message-Linecount: 97 X-Body-Linecount: 82 X-Message-Size: 4323 X-Body-Size: 3576 X-Received-Count: 1 X-Recipient-Count: 3 X-Local-Recipient-Count: 3 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: Pawel Jakub Dawidek Subject: Re: [ZFSv28] Loader hangs, import failes, zfs filesystem 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: Sat, 04 Jun 2011 19:56:49 -0000 W dniu 2011-06-04 18:55, Bartosz Stec pisze: > W dniu 2011-06-04 14:21, Bartosz Stec pisze: >> W dniu 2011-06-03 14:16, Pawel Jakub Dawidek pisze: >>> On Thu, Jun 02, 2011 at 06:58:10PM +0200, Bartosz Stec wrote: >>>> Hi list, >>>> Today I needed to shut down my home server (FreeSBD9-CURRENT, 3 x >>>> 40GB ATA HDD in RADZ1, ZFS only, GPT, i386) for a moment. After >>>> power up, loader started to spin cursor indifinitely, and didn't >>>> load the kernel. No error messages, no hints, just spinning cursor. >>>> I tried booting from other HDDs in case that bootstrap area errors >>>> on single hdd but no luck. >>>> I wanted to play with latest current LiveFS snapshot (with ZFSv28 >>>> support), but apparently latest one is from february?? >>>> Finally I ended with mfsBSD from http://mfsbsd.vx.sk/ >>>> I've downloaded "8.2-RELEASE-i386 with ZFSv28 special edition >>>> " iso, burned >>>> it and booted machine. Here's what happened when i was trying to >>>> import zpool: >>>> >>>> mfsbsd# zpool status >>>> no pools available >>>> mfsbsd# zpool import >>>> pool: zroot >>>> id: 16074929158756467860 >>>> state: ONLINE >>>> status: The pool was last accessed by another system. >>>> action: The pool can be imported using its name or numeric >>>> identifier and >>>> the '-f' flag. >>>> see: http://www.sun.com/msg/ZFS-8000-EY >>>> config: >>>> >>>> zroot ONLINE >>>> raidz1-0 ONLINE >>>> gptid/2ea57c66-bc69-11df-8955-0050dad823cd ONLINE >>>> gptid/5bc92016-6852-11df-a16c-0050dad823cd ONLINE >>>> gptid/87d467cc-bc3b-11df-8066-0050dad823cd ONLINE >>>> mfsbsd# zpool import -f zroot >>>> cannot import 'zroot': one or more devices is currently >>>> unavailable >>> Is there anything that may keep any of those vdevs open? >>> Try setting vfs.zfs.debug to 1 before import. >>> >> > It seems that LiveFS is now included in bootonly ISO, so I made > another attempt using FreeBSD-9.0-CURRENT-201105-i386-bootonly.iso > image. I tried importing with debugging enabled, but dmesg output was > the same as in my previous message. > > I had so much faith in raidz + snapshots, that I have absolutely no > backups of this system :( I don't care about time which is needed to > find a problem and possible fix, but I am really worried about my data > now. What else could I do? > And yes, I know that I shouldn't treat CURRENT as a stable and > reliable system, and you never have too much backups. I just didn't > realized how important data on this machine is until I realized that > maybe I just lost it... Crap. > Simplest solutions are always hardest to find: mfsbsd# zpool import -F zroot cannot import 'zroot': pool may be in use from other system, it was last accessed by serwer.obsysa.net (hostid: 0x4ae40037) on Thu Jun 2 14:40:59 2011 use '-f' to import anyway mfsbsd# zpool import -Ff zroot Pool zroot returned to its state as of Thu Jun 2 14:40:57 2011. Discarded approximately 2 seconds of transactions. mfsbsd# zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zroot 108G 41.6G 66.4G 38% 1.29x ONLINE - Although filesystem is alive again now, what we've seen here was probably some serious bug, because PC was shut down cleanly before it turned unusable. Thanks Pawel, Vladislav, for your effort :) -- Bartosz Stec