From owner-freebsd-fs@FreeBSD.ORG Sun Dec 2 23:27:11 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96FBBEC0 for ; Sun, 2 Dec 2012 23:27:11 +0000 (UTC) (envelope-from phil.stone@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id DB3538FC14 for ; Sun, 2 Dec 2012 23:27:10 +0000 (UTC) Received: (qmail 22558 invoked by uid 0); 2 Dec 2012 23:20:29 -0000 Received: from 82.122.18.30 by rms-eu006 with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 03 Dec 2012 00:20:28 +0100 From: "Phil Stone" Message-ID: <20121202232028.292620@gmx.com> MIME-Version: 1.0 Subject: Birthtime handling in ZFS To: freebsd-fs@freebsd.org X-Authenticated: #67349898 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: a4fJcCoTeSEqJuvOaHAh7RR+IGRvb4B7 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 23:27:11 -0000 I'm using 8.3-RELEASE-p5 It seems that st_birthtime returned by lstat(2) on a zfs file always equals ctime instead of birthtime. Looking at /base/stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c Function zfs_getattr() Line 2682 : SA_ADD_BULK_ATTR(bulk, count, SA_ZPL_CTIME(zfsvfs), NULL, &crtime, 16); Shouldn't it be : SA_ADD_BULK_ATTR(bulk, count, SA_ZPL_CRTIME(zfsvfs), NULL, &crtime, 16); instead ? Same in stable/9 and head. Thanks in advance for your help. Phil From owner-freebsd-fs@FreeBSD.ORG Sun Dec 2 23:56:35 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCCE4511; Sun, 2 Dec 2012 23:56:35 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3148FC12; Sun, 2 Dec 2012 23:56:35 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2790778oag.13 for ; Sun, 02 Dec 2012 15:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VYCuh6pdrkuLULCSTRx/wEW7bv8lW0xiUWq63zcs5ng=; b=ngjUK7z5x++NkDMtDLIRTiCXgc0n0hFhZWrlodWObuxcCZHIo4IYOtl0MVLAHo/ODL fU3VDQ/oiNdNssf/Alh+R4Ehn8vpYyiRhL3GV4oxlqiyW05CAyrIlEwxJEEln2A8jtKk pGXA/5vEvDlhNaBRL1IjMkmQAgdqcStIHPMlOeD9nPsWJtuqbxv5hbEadDVCa67S7xkE Mv3IQRKiZ3HSxDEZHGp01WHvYkTvPag9JdHsZtauXRFM93qIynVcY/fRyAANQPVU8roG 14fDBwq+MFKP2LvnSSuxncc5MBo8reHX9DbLbFXNPez2SKiuSMQV7sN1JGG6/WpRyV0n ahoA== MIME-Version: 1.0 Received: by 10.182.194.2 with SMTP id hs2mr2991903obc.97.1354492594732; Sun, 02 Dec 2012 15:56:34 -0800 (PST) Received: by 10.76.143.33 with HTTP; Sun, 2 Dec 2012 15:56:34 -0800 (PST) In-Reply-To: <20121202232028.292620@gmx.com> References: <20121202232028.292620@gmx.com> Date: Sun, 2 Dec 2012 15:56:34 -0800 Message-ID: Subject: Re: Birthtime handling in ZFS From: Garrett Cooper To: Phil Stone Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, Xin LI X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 23:56:36 -0000 On Sun, Dec 2, 2012 at 3:20 PM, Phil Stone wrote: > I'm using 8.3-RELEASE-p5 > It seems that st_birthtime returned by lstat(2) on a zfs file always equals ctime instead of birthtime. > > Looking at /base/stable/8/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > Function zfs_getattr() > Line 2682 : > SA_ADD_BULK_ATTR(bulk, count, SA_ZPL_CTIME(zfsvfs), NULL, &crtime, 16); > > Shouldn't it be : > SA_ADD_BULK_ATTR(bulk, count, SA_ZPL_CRTIME(zfsvfs), NULL, &crtime, 16); > instead ? > > Same in stable/9 and head. Yup, it's a regression introduced with the ZFS v28 import as I noted in the PR [1]. The patch attached ot the PR will apply to stable/9 and HEAD and should apply to stable/8. Thanks! -Garrett 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=174067 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 3 01:27:33 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DD8061A for ; Mon, 3 Dec 2012 01:27:33 +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 D026E8FC0C for ; Mon, 3 Dec 2012 01:27:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAJH/u1CDaFvO/2dsb2JhbABEFoYWuXNzgh4BAQMlVhsOCgICDRkCX4gjDKwmkVuBIosegy6BEwOIXo0jgRyPK4MQggM X-IronPort-AV: E=Sophos;i="4.84,202,1355115600"; d="scan'208";a="2792191" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 02 Dec 2012 20:27:25 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id ABFAEB3F47; Sun, 2 Dec 2012 20:27:25 -0500 (EST) Date: Sun, 2 Dec 2012 20:27:25 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <1751068041.1071962.1354498045662.JavaMail.root@erie.cs.uoguelph.ca> Subject: Re: RFC: moving NFSv4.1 client from projects to head MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 01:27:33 -0000 Konstantin Belousov wrote: >On Fri, Nov 16, 2012 at 09:15:49PM -0500, Rick Macklem wrote: >> Hi, >> >> I've been working on NFSv4.1 client support for FreeBSD >> for some time now and known issues from testing at a >> Bakeathon last June have been resolved. The patch is >> rather big, but I believe it should not affect the >> client unless the new mount options: >> minorversion=1,pnfs >> are used for an nfsv4 mount. >> >> Since I don't believe that the new NFS client will be >> affected unless these new mount options are used, I think >> it could go into head now. On the other hand, there are few >> NFSv4.1 servers currently available, so it might not yet >> be widely useful. (See below for slides w.r.t. server availability.) >> >> How do folks feel about doing this in early December? >> >> Since it doesn't change any KBIs, it could also be MFC'd >> to stable/9. Would MFC'ing it to stable/9 make sense? >> >> For those interested in testing and/or reviewing it, >> the code is currently in: >> base/projects/nfsv4.1-client >> (It is purely a kernel patch.) >> Also, the current state of NFSv4.1 servers is roughly: >> http://www.pnfs.com/docs/LISA-11-pNFS-BoF-final.pdf >> >> Thanks in advance for any comments, rick >IMO, the earlier the change that you feel mature enough, hits the HEAD in >the HEAD x.0 cycle, the better. That said, would you mind to put a diff >somewhere to ease the review and testing ? Well, there is now a patch at: http://people.freebsd.org/~rmacklem/nfsv4.1.patch It is just under 7,000lines, so you may not want to look at it, but whatever you can do with it would be appreciated, rick From owner-freebsd-fs@FreeBSD.ORG Mon Dec 3 04:49:54 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33A51E57; Mon, 3 Dec 2012 04:49:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id F20F68FC15; Mon, 3 Dec 2012 04:49:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qB34nrgT001649; Mon, 3 Dec 2012 04:49:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qB34nr3k001645; Mon, 3 Dec 2012 04:49:53 GMT (envelope-from linimon) Date: Mon, 3 Dec 2012 04:49:53 GMT Message-Id: <201212030449.qB34nr3k001645@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/173830: [zfs] Brain-dead simple change to ZFS error description link prefix X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 04:49:54 -0000 Old Synopsis: Brain-dead simple change to ZFS error description link prefix New Synopsis: [zfs] Brain-dead simple change to ZFS error description link prefix Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 3 04:48:26 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=173830 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 3 05:02:44 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C94A5AD; Mon, 3 Dec 2012 05:02:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4E28FC0C; Mon, 3 Dec 2012 05:02:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qB352iir002855; Mon, 3 Dec 2012 05:02:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qB352iAt002851; Mon, 3 Dec 2012 05:02:44 GMT (envelope-from linimon) Date: Mon, 3 Dec 2012 05:02:44 GMT Message-Id: <201212030502.qB352iAt002851@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174060: [ext2fs] Ext2FS system crashes (buffer overflow?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:02:44 -0000 Old Synopsis: Ext2FS system crashes (buffer overflow?) New Synopsis: [ext2fs] Ext2FS system crashes (buffer overflow?) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 3 05:01:53 UTC 2012 Responsible-Changed-Why: reclassify http://www.freebsd.org/cgi/query-pr.cgi?pr=174060 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 3 05:05:31 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0BDE8A8; Mon, 3 Dec 2012 05:05:31 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A9E8A8FC19; Mon, 3 Dec 2012 05:05:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qB355VSs003416; Mon, 3 Dec 2012 05:05:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qB355VdL003412; Mon, 3 Dec 2012 05:05:31 GMT (envelope-from linimon) Date: Mon, 3 Dec 2012 05:05:31 GMT Message-Id: <201212030505.qB355VdL003412@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/173718: [zfs] phantom directory in zraid2 pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:05:32 -0000 Old Synopsis: phantom directory in zraid2 pool New Synopsis: [zfs] phantom directory in zraid2 pool Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 3 05:05:14 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=173718 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 3 11:06:44 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C56F8F for ; Mon, 3 Dec 2012 11:06:44 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E44528FC0C for ; Mon, 3 Dec 2012 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qB3B6hh3027538 for ; Mon, 3 Dec 2012 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qB3B6hMb027536 for freebsd-fs@FreeBSD.org; Mon, 3 Dec 2012 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Dec 2012 11:06:43 GMT Message-Id: <201212031106.qB3B6hMb027536@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 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 11:06:44 -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/174060 fs [ext2fs] Ext2FS system crashes (buffer overflow?) o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool o kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173234 fs [zfs] [patch] Allow filtering of properties on zfs rec o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/172259 fs [zfs] [patch] ZFS fails to receive valid snapshots (pa o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o kern/170914 fs [zfs] [patch] Import patchs related with issues 3090 a o kern/170912 fs [zfs] [patch] unnecessarily setting DS_FLAG_INCONSISTE o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165923 fs [nfs] Writing to NFS-backed mmapped files fails if flu o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o conf/144213 fs [rc.d] [patch] Disappearing zvols on reboot o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 295 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Dec 3 11:19:48 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C1F5C8E; Mon, 3 Dec 2012 11:19:48 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 013068FC08; Mon, 3 Dec 2012 11:19:47 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so1826585qcs.13 for ; Mon, 03 Dec 2012 03:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JO4n9ONcMRVY3YyNacWn7c/2+K0tBuxnafqLnT34asw=; b=jlR/F0WFLBGmdv94CA7LhQKf9oPIDxLUUmPw2XRFjltiyi+6vMJiZrvMVrNEBZMMnr LeO8RPeSnSTykh8GiqR1KVKN/exSpwuzb/LyqZfC9yYln6sFRbRK1vr+nco8nDGsGgOY tMDs40ILHPzp89rsku2fxLK4pQllwpxFjdNPfnky107ht+ta1xiz0vHFdOigpwEuCrpO Z1tr5lOBNQZNZayUOgL3QZz9qPCBJ+URtdqn/Nt6KSPU60b0o6s+ecO8G4GIN4t4xLPZ RAGVBqekNSRQckww6TLtl4EgfX73StmRuRv2amK5mC3bFx9+hF6XAuXzBbKGzqn0Zb5J qBJQ== MIME-Version: 1.0 Received: by 10.224.45.6 with SMTP id c6mr16691789qaf.54.1354533587015; Mon, 03 Dec 2012 03:19:47 -0800 (PST) Received: by 10.229.113.102 with HTTP; Mon, 3 Dec 2012 03:19:46 -0800 (PST) In-Reply-To: <201211241313.qAODDwld048466@freefall.freebsd.org> References: <201211241313.qAODDwld048466@freefall.freebsd.org> Date: Mon, 3 Dec 2012 12:19:46 +0100 Message-ID: Subject: Re: kern/167066: [zfs] ZVOLs not appearing in /dev/zvol From: Andreas Nilsson To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 11:19:48 -0000 Hello again, I think that the nodes in /dev/zvol should be removed after a zfs destroy. Ie. if you do zfs create -V1g tank/vol ; zfs snapshot tank/vol@1 ; zfs snapshot tank/vol@2; zfs destroy tank/vol@2; zfs destroy tank/vol@1 I think that only /dev/zvol/tank/vol should still exist. Even after zfs destroy tank/vol /dev/zvol/tank/vol@1 and /dev/zvol/tank/vol@2 still exists. It gets a bit more exiting when creating partitions on the volume as well. Best regards Andreas On Sat, Nov 24, 2012 at 2:13 PM, wrote: > Synopsis: [zfs] ZVOLs not appearing in /dev/zvol > > Responsible-Changed-From-To: freebsd-fs->avg > Responsible-Changed-By: avg > Responsible-Changed-When: Sat Nov 24 13:13:49 UTC 2012 > Responsible-Changed-Why: > I am handling this. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=167066 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Mon Dec 3 15:25:35 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37CBC2E3 for ; Mon, 3 Dec 2012 15:25:35 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by mx1.freebsd.org (Postfix) with ESMTP id E38B28FC12 for ; Mon, 3 Dec 2012 15:25:34 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id 13so5186448iea.21 for ; Mon, 03 Dec 2012 07:25:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=CRovgCjE5m4aHQMlNN3MyQBxzqDRdrN2T8rpja4xApE=; b=QRf0tyTe3QJcmkVP6kjGUY+3hR4Ew6UjIqxtq5Zbh+94ApREXsGJ//jViX0kmDgdos zzA8pwzoseVJaNj4Mpv7siKCU20WYcv+J7h1qoI4h756SR8fDwJn0OQJkByKKYFYMRmb 5GKgjMdnzr0QN7zS1TRi1h6KnZW/AJyM/uEQYp17h0cW0w+uDOmi3wbi3oAeffcaJf80 bh5YFKPZhUtJcjPQqn4uc75wuhdCkHQJr5cMVjw+MNovoDalaTkLYMJxNHsxBu6x9PMZ PMt4G1uB7Tdn+TLkFCuBMQIzaN6f+dMpeh4BnHkZ8r0CCdASnbAXeH3XqUNtPxCIN7OB tHHg== Received: by 10.50.40.225 with SMTP id a1mr6455581igl.7.1354548333843; Mon, 03 Dec 2012 07:25:33 -0800 (PST) Received: from wawanesa.iciti.ca (CPE0080c8f208a5-CM001371173cf8.cpe.net.cable.rogers.com. [99.246.61.82]) by mx.google.com with ESMTPS id az6sm7209416igb.11.2012.12.03.07.25.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 07:25:32 -0800 (PST) Date: Mon, 3 Dec 2012 10:24:15 -0500 (EST) From: Graham Todd X-X-Sender: gtodd@wawanesa.iciti.ca To: nikitosiusis Subject: Re: "zpool add" safety checks are skipped if a pool was created with "-f" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQn/lYJ11GTAZ7D7XjfcqxeUrRNniTxjt2CcICECLCUrP1+8k1L9sIi8cQgG5zrwsCTCzibU Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 15:25:35 -0000 On Tue, 13 Nov 2012, nikitosiusis wrote: > Good day everyone. > I managed to add a single device to a raidz2 pool by a typo(actually I > wanted to add a cache device) without "-f" flag. This can be > reproduced with md devices. > # for a in {1..8}; do dd if=/dev/zero of=$a bs=1M count=96;done > # dd if=/dev/zero of=9 bs=1M count=128 > # ls -la > -rw-r--r-- 1 root wheel 100663296 Nov 12 21:04 1 > -rw-r--r-- 1 root wheel 100663296 Nov 12 21:04 2 > -rw-r--r-- 1 root wheel 100663296 Nov 12 21:04 3 > -rw-r--r-- 1 root wheel 100663296 Nov 12 21:04 4 > -rw-r--r-- 1 root wheel 100663296 Nov 12 21:04 5 > -rw-r--r-- 1 root wheel 100663296 Nov 12 21:04 6 > -rw-r--r-- 1 root wheel 100663296 Nov 12 21:04 7 > -rw-r--r-- 1 root wheel 100663296 Nov 12 21:04 8 > -rw-r--r-- 1 root wheel 134217728 Nov 12 21:04 9 > # for a in {1..9}; do mdconfig -f ~/tmp/$a; done > > Now we create a raidz pool with 8 identical drives. > > # zpool create testpool raidz2 md{1..8} > # zpool add testpool md9 > invalid vdev specification > use '-f' to override the following errors: > mismatched replication level: pool uses raidz and new vdev is disk > > It's ok. It doesn't allow to add a device. > Now we create a new pool, but with devices of different size(I don't > know what is the difference in size allowed, I used 32mb). > > # zpool create testpool raidz2 md{1..7} md9 > invalid vdev specification > use '-f' to override the following errors: > raidz contains devices of different sizes > # zpool create -f testpool raidz2 md{1..7} md9 > # zpool add testpool md8 > And we have no error here - single drive is added to the pool. Since > it is an undoable action - it can ruin your pool and should be > considered as a bug imho. Here is my result in production. > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > root 3.63T 1.06T 2.57T 29% 1.00x ONLINE - > raidz2 3.62T 1.06T 2.57T - > ada0 - - - - > ada1 - - - - > ada3 - - - - > ada4 - - - - > ada5 - - - - > ada6 - - - - > ada7 - - - - > ada8 - - - - > da0p1 3.75G 76.5K 3.75G - > > # uname -rv > 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2: Thu Nov 8 13:50:55 UTC 2012 > root@ex.a.nikitos.name:/usr/obj/usr/src/sys/GENERIC I haven't done it lately, but it was possible to make a similar error with a simple mirror vdev if you were trying to add a second pool or a second separate vdev in an existing pool and "added" instead of "attached", or mistyped the pool name (sometimes pools have similar names). I agree that if this risks creating an undoable mistake in a pool the lack of checks or verification should be considered a "bug". > # zpool get version testpool > NAME PROPERTY VALUE SOURCE > testpool version 28 default > # zfs get version testpool > NAME PROPERTY VALUE SOURCE > testpool version 5 - > > btw is there a chance to remove this device now? I'm not sure if some combination of split, detach, remove, destroy would have helped in the simpler case of a mirror - the split feature was not available when this happened. We had root/boot on a separate device, not much data and extra disks, so we could zfs send/recv things to a new pool and rebuild things that way. Better checks at creation time would have prevented any problems. Is there a PR for these sort of issues at freebsd.org or illumos or elsewhere? cheers From owner-freebsd-fs@FreeBSD.ORG Mon Dec 3 17:36:44 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E078D6D for ; Mon, 3 Dec 2012 17:36:44 +0000 (UTC) (envelope-from jusher71@yahoo.com) Received: from nm20-vm0.bullet.mail.ne1.yahoo.com (nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45]) by mx1.freebsd.org (Postfix) with ESMTP id 7F7F88FC08 for ; Mon, 3 Dec 2012 17:36:44 +0000 (UTC) Received: from [98.138.226.178] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 03 Dec 2012 17:33:45 -0000 Received: from [98.138.226.169] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 03 Dec 2012 17:33:45 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 03 Dec 2012 17:33:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 820290.3828.bm@omp1070.mail.ne1.yahoo.com Received: (qmail 23503 invoked by uid 60001); 3 Dec 2012 17:33:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354556025; bh=4FkAOVLoWGoEI4Z4H/Ukdvps8hCuBj5x2Xb1mWgTKbw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=fQbTatgr15DdPoaMC+b+pplk2dEaacFi4ny+oiGsd33ypcJUFuynruou6bf5QUYQiM9X/4AljweCOETug1CgRmY1b/VOQ7zUtMuO80dujypxUX1YJSiWocaJhh/Tm8/F0lUsTKjBgB+V1wFHvPa+FO9mI8QTRX+SZk3MQdw9m1c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=bc/6Gf0tS5OxAW4XqPmIZy+rAiAztrW8lVtGbmO13nSsZAQw54FNXwwEDGF5Gsqe3wLRuuKqRt1dP1dQayYW0SLkREbDsM+r8nTzHprsDi9ymeU/dyiI9f+929jNe7t1ZA+Otiz+H0Kg9Kj7zw0P/WFAi+XlW1FpdpX0IzxaNxU=; X-YMail-OSG: h7VEGGsVM1mpiikfGuT_2EbLMQ3qApXcwe83jT3iZqx5jda J8BYKzlZajUiolBmYT4MOkxtI_b2fNjOiirUPCq4XbY1VsMb8Sd2xI45pz2J rMaSU4Tegy4am_NG7XJ3XzoH5X6TK3hvAU_OahnwOgtfMnZkbS6UrxK8DPZh DWbBQhmmoYtYDblgGG3QFa_EzlwI6_CoIwXvpfUYkxzn.s8QH.ydXoCWPw1q kHBfBjYfvOmYEQP3OiHIyuGdTPdTRwZ3sH.8zdTEff9krmfD923yZKtJ8i0q 9nh1Hpk.wv6BfwzztV1syuuc.Q2VjoxpSvllW4gZnhCQHB6gpoHg58UdIBX0 sN4iKqiGnGCb8XzBagIg3b.Of4uUVCbXzzry55IJSoS4qG8Hx.Dll0WJmRQZ unciG.BPlUZnIDKv8nbF8iY0B350zHpr4D_PbzeQxcFyyDvyXRotjFD4- Received: from [173.164.238.34] by web120701.mail.ne1.yahoo.com via HTTP; Mon, 03 Dec 2012 09:33:45 PST X-Rocket-MIMEInfo: 001.001, SGVsbG8sCgpJIGhhdmUgYSBxdWVzdGlvbiBvciB0d28gYWJvdXQgZ3JhaWQgYW5kIGF0YXJhaWQgKHNwZWNpZmljYWxseSwgbWlncmF0aW5nIGEgYXRhcmFpZCBzeXN0ZW0gdG8gZ3JhaWQpIGFuZCBJIHdvbmRlciB3aGVyZSBJIHNob3VsZCBwb3N0IHRoYXQgPwoKSSd2ZSBwb3N0ZWQgdG8gYm90aCAtcXVlc3Rpb25zIGFuZCAtZnMgYnV0IGdvdHRlbiBubyByZXNwb25zZXMuCgpUaGFua3MuATABAQEB X-Mailer: YahooMailClassic/15.1.1 YahooMailWebService/0.8.128.478 Message-ID: <1354556025.18771.YahooMailClassic@web120701.mail.ne1.yahoo.com> Date: Mon, 3 Dec 2012 09:33:45 -0800 (PST) From: Jason Usher Subject: appropriate list for graid/ataraid questions ? To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 03 Dec 2012 17:44:59 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:36:45 -0000 Hello, I have a question or two about graid and ataraid (specifically, migrating a ataraid system to graid) and I wonder where I should post that ? I've posted to both -questions and -fs but gotten no responses. Thanks. From owner-freebsd-fs@FreeBSD.ORG Mon Dec 3 18:41:34 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C3A17B; Mon, 3 Dec 2012 18:41:34 +0000 (UTC) (envelope-from olivier777a7@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 64CC68FC18; Mon, 3 Dec 2012 18:41:34 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so2182036pbc.13 for ; Mon, 03 Dec 2012 10:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=F2irgfTg0TOHUAOL52kSmh+t9uR1Aulef3Y65iHenX8=; b=JWZmt5Wsg6U7BBYrnBaFe+VsXyLzm6MzuFzF2PKpnc8huNl0mIf5MZzJdxo6z7Tmop pFTnuQxe5le7g2iwYrg118fuFDcGZXHNkwVeRsA1XD4emi5b8fOe8dTf1paq4WEMcKsk ZvfRPx30iGjDywZvfZF7HOdw98+DoigGLwPywB1I4jMzoN4TToQfa8/5Nd5IDEHt5iCz o6kKSjxiwHBfRS6EYAWL5u33ZlJjj9ET55pJg85DZ0piYLnDu430r9zeVx+gTNTNv5hS Z0cqLH/uaHrX4vuVcKX514Vzy0AjUyMfYtuQ/Xe+pslPR7/V1uDSigLXA/PsEGVaOfAg GnQQ== MIME-Version: 1.0 Received: by 10.66.75.162 with SMTP id d2mr28097929paw.27.1354560093820; Mon, 03 Dec 2012 10:41:33 -0800 (PST) Received: by 10.66.148.136 with HTTP; Mon, 3 Dec 2012 10:41:33 -0800 (PST) Date: Mon, 3 Dec 2012 10:41:33 -0800 Message-ID: Subject: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE From: olivier olivier To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:41:34 -0000 Hi all After upgrading from 9.0-RELEASE to 9.1-PRERELEASE #0 r243679 I'm having severe problems with NFS sharing of a ZFS volume. nfsd appears to hang at random times (between once every couple hours to once every two days) while accessing a ZFS volume, and the only way I have found of resolving the problem is to reboot. The server console is sometimes still responsive during the nfsd hang, and I can read and write files to the same ZFS volume while nfsd is hung. I am pasting below the output of procstat -kk on nfsd, and details of my pool (nfsstat on the server gets hung when the problem has started occurring, and does not produce any output). The pool is v28 and was created from a bunch of volumes attached over Fibre Channel using the mpt driver. My system has a Supermicro board and 4 AMD Opteron 6274 CPUs. I did not experience any nfsd hangs with 9.0-RELEASE (same machine, essentially same configuration, same usage pattern). I would greatly appreciate any help to resolve this problem! Thank you Olivier PID TID COMM TDNAME KSTACK 1511 102751 nfsd nfsd: master mi_switch+0x186 sleepq_wait+0x42 __lockmgr_args+0x5ae vop_stdlock+0x39 VOP_LOCK1_APV+0x46 _vn_lock+0x47 zfs_fhtovp+0x338 nfsvno_fhtovp+0x87 nfsd_fhtovp+0x7a nfsrvd_dorpc+0x9cf nfssvc_program+0x447 svc_run_internal+0x687 svc_run+0x8f nfsrvd_nfsd+0x193 nfssvc_nfsd+0x9b sys_nfssvc+0x90 amd64_syscall+0x540 Xfast_syscall+0xf7 1511 102752 nfsd nfsd: service mi_switch+0x186 sleepq_wait+0x42 __lockmgr_args+0x5ae vop_stdlock+0x39 VOP_LOCK1_APV+0x46 _vn_lock+0x47 zfs_fhtovp+0x338 nfsvno_fhtovp+0x87 nfsd_fhtovp+0x7a nfsrvd_dorpc+0x9cf nfssvc_program+0x447 svc_run_internal+0x687 svc_thread_start+0xb fork_exit+0x11f fork_trampoline+0xe 1511 102753 nfsd nfsd: service mi_switch+0x186 sleepq_wait+0x42 _cv_wait+0x112 zio_wait+0x61 zil_commit+0x764 zfs_freebsd_write+0xba0 VOP_WRITE_APV+0xb2 nfsvno_write+0x14d nfsrvd_write+0x362 nfsrvd_dorpc+0x3c0 nfssvc_program+0x447 svc_run_internal+0x687 svc_thread_start+0xb fork_exit+0x11f fork_trampoline+0xe 1511 102754 nfsd nfsd: service mi_switch+0x186 sleepq_wait+0x42 _cv_wait+0x112 zio_wait+0x61 zil_commit+0x3cf zfs_freebsd_fsync+0xdc nfsvno_fsync+0x2f2 nfsrvd_commit+0xe7 nfsrvd_dorpc+0x3c0 nfssvc_program+0x447 svc_run_internal+0x687 svc_thread_start+0xb fork_exit+0x11f fork_trampoline+0xe 1511 102755 nfsd nfsd: service mi_switch+0x186 sleepq_wait+0x42 __lockmgr_args+0x5ae vop_stdlock+0x39 VOP_LOCK1_APV+0x46 _vn_lock+0x47 zfs_fhtovp+0x338 nfsvno_fhtovp+0x87 nfsd_fhtovp+0x7a nfsrvd_dorpc+0x9cf nfssvc_program+0x447 svc_run_internal+0x687 svc_thread_start+0xb fork_exit+0x11f fork_trampoline+0xe 1511 102756 nfsd nfsd: service mi_switch+0x186 sleepq_wait+0x42 _cv_wait+0x112 zil_commit+0x6d zfs_freebsd_write+0xba0 VOP_WRITE_APV+0xb2 nfsvno_write+0x14d nfsrvd_write+0x362 nfsrvd_dorpc+0x3c0 nfssvc_program+0x447 svc_run_internal+0x687 svc_thread_start+0xb fork_exit+0x11f fork_trampoline+0xe PID TID COMM TDNAME KSTACK 1507 102750 nfsd - mi_switch+0x186 sleepq_catch_signals+0x2e1 sleepq_wait_sig+0x16 _cv_wait_sig+0x12a seltdwait+0xf6 kern_select+0x6ef sys_select+0x5d amd64_syscall+0x540 Xfast_syscall+0xf7 pool: tank state: ONLINE status: The pool is formatted using a legacy on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on software that does not support feature flags. scan: scrub repaired 0 in 45h37m with 0 errors on Mon Dec 3 03:07:11 2012 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da19 ONLINE 0 0 0 da31 ONLINE 0 0 0 da32 ONLINE 0 0 0 da33 ONLINE 0 0 0 da34 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 da20 ONLINE 0 0 0 da36 ONLINE 0 0 0 da37 ONLINE 0 0 0 da38 ONLINE 0 0 0 da39 ONLINE 0 0 0 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 3 18:47:19 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FDE8509 for ; Mon, 3 Dec 2012 18:47:19 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2776D8FC16 for ; Mon, 3 Dec 2012 18:47:18 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id D557328427; Mon, 3 Dec 2012 19:47:11 +0100 (CET) Received: from [192.168.1.2] (unknown [89.177.49.69]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 186E128422; Mon, 3 Dec 2012 19:47:11 +0100 (CET) Message-ID: <50BCF3AE.30009@quip.cz> Date: Mon, 03 Dec 2012 19:47:10 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Jason Usher Subject: Re: appropriate list for graid/ataraid questions ? References: <1354556025.18771.YahooMailClassic@web120701.mail.ne1.yahoo.com> In-Reply-To: <1354556025.18771.YahooMailClassic@web120701.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:47:19 -0000 Jason Usher wrote: > Hello, > > I have a question or two about graid and ataraid (specifically, migrating a ataraid system to graid) and I wonder where I should post that ? > > I've posted to both -questions and -fs but gotten no responses. Maybe freebsd-geom would be better. I read your original question on the -fs. I don't have any experiences with graid and only few with ataraid. We used gmirror instead, because it is more universal (supporting migration of disks between different machines) Anyway - I think it can be possible to use graid with existing data, because both should use the same metadata format (depending on HW / BIOS manufacturer). You can try it with some FreeBSD 9 Live CD / USB booted system with a custom kernel (without ataraid support) and with graid loaded as a module. Then you will see if your existing array will be recognized or not. Miroslav Lachman PS: don't try it on a production system without proper backup of your valuable data. From owner-freebsd-fs@FreeBSD.ORG Mon Dec 3 22:41:37 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFF50E85; Mon, 3 Dec 2012 22:41:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2CCF88FC14; Mon, 3 Dec 2012 22:41:36 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qB3MfWXd084116; Tue, 4 Dec 2012 00:41:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qB3MfWXd084116 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qB3MfWmZ084115; Tue, 4 Dec 2012 00:41:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 Dec 2012 00:41:32 +0200 From: Konstantin Belousov To: sig6247 Subject: Re: clang compiled kernel panic when mounting zfs root on i386 Message-ID: <20121203224132.GJ3013@kib.kiev.ua> References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dOlf0zsnhJ4/ZPgF" Content-Disposition: inline In-Reply-To: <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, dim@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:41:37 -0000 --dOlf0zsnhJ4/ZPgF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 01, 2012 at 01:34:04AM -0800, sig6247 wrote: > On Fri, 30 Nov 2012 18:47:15 +0200, Konstantin Belousov wrote: >=20 > > Hm, this is not very useful. Although the panic is again caused by the = stack > > overflow, most likely (please also include the output of the "show thre= ad" > > from ddb), it is at different place, and probably at the leaf function. > > > > Can you try some more times, so that we could see 'big' backtrace ? >=20 > Sure. Thanks. >=20 > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from zfs:zroot []... >=20 > Fatal double fault: > eip =3D 0xc0add15d > esp =3D 0xc86bffc8 > ebp =3D 0xc86c003c > cpuid =3D 1; apic id =3D 01 > panic: double fault > cpuid =3D 1 > KDB: enter: panic > [ thread pid 1 tid 100002 ] > Stopped at kdb_enter+0x3d: movl $0,kdb_why > db> bt > Tracing pid 1 tid 100002 td 0xc89efbc0 > kdb_enter(c1065960,c1065960,c10b903b,c139f438,2243cdbd,...) at kdb_enter+= 0x3d/frame 0xc139f3f0 > panic(c10b903b,1,1,1,c86c003c,...) at panic+0x14b/frame 0xc139f42c > dblfault_handler() at dblfault_handler+0xab/frame 0xc139f42c > --- trap 0x17, eip =3D 0xc0add15d, esp =3D 0xc86bffc8, ebp =3D 0xc86c003c= --- > witness_checkorder(c1fd7508,9,c109ee8c,7fa,0,...) at witness_checkorder+0= x37d/frame 0xc86c003c > __mtx_lock_flags(c1fd7518,0,c109ee8c,7fa,c135e998,...) at __mtx_lock_flag= s+0x87/frame 0xc86c007 > 0 > uma_zalloc_arg(c1fd66c0,0,1,4d3,c86c0110,...) at uma_zalloc_arg+0x605/fra= me 0xc86c00c8 > vm_map_insert(c1fd508c,c13e0ca0,bd3a000,0,cbc39000,...) at vm_map_insert+= 0x499/frame 0xc86c0130 >=20 > kmem_back(c1fd508c,cbc39000,1000,3,c86c01d4,...) at kmem_back+0x76/frame = 0xc86c018c > kmem_malloc(c1fd508c,1000,3) at kmem_malloc+0x250/frame 0xc86c01c0 > page_alloc(c1fd1d80,1000,c86c020b,3,c1fd1d80,...) at page_alloc+0x27/fram= e 0xc86c01d4 > keg_alloc_slab(103,4,c109ee8c,870,cbb95f6c,...) at keg_alloc_slab+0xc3/fr= ame 0xc86c0218 > keg_fetch_slab(103,c1fd1d80,cbb95f6c,c1fc8230,c86c02c0,...) at keg_fetch_= slab+0xe2/frame 0xc86c > 0250 > zone_fetch_slab(c1fd1d80,c1fd0480,103,826,0,...) at zone_fetch_slab+0x43/= frame 0xc86c0268 > uma_zalloc_arg(c1fd1d80,0,102,3,2,...) at uma_zalloc_arg+0x3f2/frame 0xc8= 6c02c0 > malloc(4c,c1826100,102,c86c0388,c173909a,...) at malloc+0xe9/frame 0xc86c= 02e8 > zfs_kmem_alloc(4c,102,cb7d8820,c89efbc0,cb7d8820,...) at zfs_kmem_alloc+0= x20/frame 0xc86c02fc > vdev_mirror_io_start(cba232e0,10,cba232e0,1,0,...) at vdev_mirror_io_star= t+0x14a/frame 0xc86c03 > 88 > zio_vdev_io_start(cba232e0,c89efbc0,0,cba232e0,c86c0600,...) at zio_vdev_= io_start+0x228/frame 0 > xc86c03e4 > zio_execute(cba232e0,cb7d8000,cbbec640,cbbe2000,600,...) at zio_execute+0= x106/frame 0xc86c0418 > spa_load_verify_cb(cb7d8000,0,cbbec640,cba6bd20,c86c0600,...) at spa_load= _verify_cb+0x89/frame=20 > 0xc86c0458 > traverse_visitbp(cba6bd20,cbbec640,c86c0600,c86c0ba0,0,...) at traverse_v= isitbp+0x29f/frame 0xc > 86c05e0 > traverse_dnode(cba6bd20,0,0,23,0,...) at traverse_dnode+0x92/frame 0xc86c= 0638 > traverse_visitbp(cba6bd98,cbbf0080,c86c0890,cba6bdd4,c16ca7e0,...) at tra= verse_visitbp+0xe47/fr > ame 0xc86c07c0 > traverse_visitbp(cba6bdd4,cbbe2840,c86c0968,c86c0ba0,0,...) at traverse_v= isitbp+0xf32/frame 0xc > 86c0948 > traverse_dnode(cba6bdd4,0,0,0,0,...) at traverse_dnode+0x92/frame 0xc86c0= 9a0 > traverse_visitbp(0,cb7d8398,c86c0b50,2,cbbdc214,...) at traverse_visitbp+= 0x96d/frame 0xc86c0b28 >=20 > traverse_impl(0,0,cb7d8398,74,0,...) at traverse_impl+0x268/frame 0xc86c0= be0 > traverse_pool(cb7d8000,74,0,d,c1723830,...) at traverse_pool+0x79/frame 0= xc86c0c88 > spa_load(0,1,c86c0ec4,1e,0,...) at spa_load+0x1dde/frame 0xc86c0df0 > spa_load(0,0,c13d9d14,1,3,...) at spa_load+0x11a5/frame 0xc86c0f58 > spa_load_best(0,ffffffff,ffffffff,1,c0add175,...) at spa_load_best+0x71/f= rame 0xc86c0fb0 > spa_open_common(c17dce4e,0,0,c86c1190,c16f1a1c,...) at spa_open_common+0x= 11a/frame 0xc86c100c > spa_open(c86c1078,c86c1074,c17dce4e,c135e998,c1fd7798,...) at spa_open+0x= 27/frame 0xc86c1020 > dsl_dir_open_spa(0,c89770b0,c17dd1e1,c86c11f8,c86c11f4,...) at dsl_dir_op= en_spa+0x6c/frame 0xc8 > 6c1190 > dsl_dataset_hold(c89770b0,cb7d3800,c86c1240,cb7d3800,cb7d3800,...) at dsl= _dataset_hold+0x3a/fra > me 0xc86c120c > dsl_dataset_own(c89770b0,0,cb7d3800,c86c1240,c1824e30,...) at dsl_dataset= _own+0x21/frame 0xc86c > 1228 > dmu_objset_own(c89770b0,2,1,cb7d3800,c86c1290,...) at dmu_objset_own+0x2a= /frame 0xc86c1250 > zfsvfs_create(c89770b0,c86c13ac,c17ea09b,681,0,...) at zfsvfs_create+0x4c= /frame 0xc86c12a8 > zfs_mount(cb99b540,c17f0160,cb98b100,c89cae80,0,...) at zfs_mount+0x42c/f= rame 0xc86c14e0 > vfs_donmount(c89efbc0,4000,0,c86c1790,cb98b180,...) at vfs_donmount+0xc6d= /frame 0xc86c1778 > kernel_mount(c8977490,4000,0,0,1,...) at kernel_mount+0x6b/frame 0xc86c17= b8 > parse_mount(cb96e0e0,c1195498,0,1,0,...) at parse_mount+0x606/frame 0xc86= c19d8 > vfs_mountroot(c13da634,4,c105ceba,2bb,0,...) at vfs_mountroot+0x6cf/frame= 0xc86c1c60 > start_init(0,c86c1d08,c105f7c4,3db,0,...) at start_init+0x6a/frame 0xc86c= 1ccc > fork_exit(c0a429e0,0,c86c1d08) at fork_exit+0x7f/frame 0xc86c1cf4 > fork_trampoline() at fork_trampoline+0x8/frame 0xc86c1cf4 > --- trap 0, eip =3D 0, esp =3D 0xc86c1d40, ebp =3D 0 --- > db> show thread > Thread 100002 at 0xc89efbc0: > proc (pid 1): 0xc89edb40 > name: kernel > stack: 0xc86c0000-0xc86c1fff > flags: 0x4 pflags: 0x10000 > state: RUNNING (CPU 1) > priority: 84 > container lock: sched lock 1 (0xc1220000) > db> Please try the patch below. It might give an immediate relief, but still there are many offenders in the backtrace. diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c index 83948f2..147926e 100644 --- a/sys/kern/vfs_mountroot.c +++ b/sys/kern/vfs_mountroot.c @@ -672,10 +672,11 @@ parse_mount_dev_present(const char *dev) return (error !=3D 0) ? 0 : 1; } =20 +#define ERRMSGL 255 static int parse_mount(char **conf) { - char errmsg[255]; + char *errmsg; struct mntarg *ma; char *dev, *fs, *opts, *tok; int delay, error, timeout; @@ -707,7 +708,7 @@ parse_mount(char **conf) printf("Trying to mount root from %s:%s [%s]...\n", fs, dev, (opts !=3D NULL) ? opts : ""); =20 - bzero(errmsg, sizeof(errmsg)); + errmsg =3D malloc(ERRMSGL, M_TEMP, M_WAITOK | M_ZERO); =20 if (vfs_byname(fs) =3D=3D NULL) { strlcpy(errmsg, "unknown file system", sizeof(errmsg)); @@ -734,7 +735,7 @@ parse_mount(char **conf) ma =3D mount_arg(ma, "fstype", fs, -1); ma =3D mount_arg(ma, "fspath", "/", -1); ma =3D mount_arg(ma, "from", dev, -1); - ma =3D mount_arg(ma, "errmsg", errmsg, sizeof(errmsg)); + ma =3D mount_arg(ma, "errmsg", errmsg, ERRMSGL); ma =3D mount_arg(ma, "ro", NULL, 0); ma =3D parse_mountroot_options(ma, opts); error =3D kernel_mount(ma, MNT_ROOTFS); @@ -748,11 +749,13 @@ parse_mount(char **conf) printf(".\n"); } free(fs, M_TEMP); + free(errmsg, M_TEMP); if (opts !=3D NULL) free(opts, M_TEMP); /* kernel_mount can return -1 on error. */ return ((error < 0) ? EDOOFUS : error); } +#undef ERRMSGL =20 static int vfs_mountroot_parse(struct sbuf *sb, struct mount *mpdevfs) --dOlf0zsnhJ4/ZPgF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQvSqbAAoJEJDCuSvBvK1BReQP/RXbi0ki7FLFns4TAlqSmnKL 40xkEdhbtAAQpSsLyf0JX3tgZCPhmr7evS1klFdM0CAYd3OlFl8VA8n63EmBZDp1 zo2BxQjREBtaw6tSiCvA8SCFgX0PvDCjkcdY7/a77e4zMh8+8LYs62HquJsYwV4g Jd9qsS2/8thsAegP8OxcU3sgHkC1EzGPbbwTyz0bNx+XddDDHe6kSITPLt1VdQuK NHG9H3QaO6Wi/H0YxeBCgN+wKifwMq2YzBLBdInMCXVaWEERduLyChUVvFc7k73x 62VAjUj+mltD16HefhGGp6Dy2Tv2gTdUACN6w5XFh/TKazwGQzqyXQx2HuEAyArv yCf55AZuHw8DJ3tca1MF1CSiz6aKJ4ru8b288bBL0ztf+wgyLSnh2dKzyF7gOXEV MUu+ZzV0iyxSjtiHzaVMcmX8SznM0YQQUO0ghhoHQCl5jfCZn1f1vfjTaG0YJig9 xiXPyzpE5Xu1M9mKQIzTIkzoA38kj/E60jsYBEeWmDUwNo30vOmQXtwfS9CaaAXN g7gt2eN2b+q7I0Y3DCSOGKkZNlW6it9rmqfLKqfHPFAXUMNi5NGl2hp2fcPTCGci JESomTPNMMRpOaU0XWeiP6YtBYpEweSamzDST7wchMXeYSjEncOkW6grLR2AWzgN QBl/tmfaXYGODTdbR9cT =kQfc -----END PGP SIGNATURE----- --dOlf0zsnhJ4/ZPgF-- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 4 14:26:19 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 196AE91B; Tue, 4 Dec 2012 14:26:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B02C98FC0C; Tue, 4 Dec 2012 14:26:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAJ0HvlCDaFvO/2dsb2JhbABEhjO4EHOCHgEBAQMBAQEBICsgCxsYAgINGQIpAQkmBggHBAEcBIdpBgyuWYI/kE+BIosVARoNgwaBEwOIX4p2gi6BHI8rgxCBRwcXHg X-IronPort-AV: E=Sophos;i="4.84,215,1355115600"; d="scan'208";a="3254280" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 04 Dec 2012 09:26:10 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6EF50B3F15; Tue, 4 Dec 2012 09:26:10 -0500 (EST) Date: Tue, 4 Dec 2012 09:26:10 -0500 (EST) From: Rick Macklem To: olivier olivier Message-ID: <1769356561.1118634.1354631170432.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 14:26:19 -0000 Olivier wrote: > Hi all > After upgrading from 9.0-RELEASE to 9.1-PRERELEASE #0 r243679 I'm > having > severe problems with NFS sharing of a ZFS volume. nfsd appears to hang > at > random times (between once every couple hours to once every two days) > while > accessing a ZFS volume, and the only way I have found of resolving the > problem is to reboot. The server console is sometimes still responsive > during the nfsd hang, and I can read and write files to the same ZFS > volume > while nfsd is hung. I am pasting below the output of procstat -kk on > nfsd, > and details of my pool (nfsstat on the server gets hung when the > problem > has started occurring, and does not produce any output). The pool is > v28 > and was created from a bunch of volumes attached over Fibre Channel > using > the mpt driver. My system has a Supermicro board and 4 AMD Opteron > 6274 > CPUs. > > I did not experience any nfsd hangs with 9.0-RELEASE (same machine, > essentially same configuration, same usage pattern). > > I would greatly appreciate any help to resolve this problem! > Thank you > Olivier > > PID TID COMM TDNAME KSTACK > 1511 102751 nfsd nfsd: master > mi_switch+0x186 > sleepq_wait+0x42 > __lockmgr_args+0x5ae > vop_stdlock+0x39 > VOP_LOCK1_APV+0x46 > _vn_lock+0x47 > zfs_fhtovp+0x338 > nfsvno_fhtovp+0x87 > nfsd_fhtovp+0x7a > nfsrvd_dorpc+0x9cf > nfssvc_program+0x447 > svc_run_internal+0x687 > svc_run+0x8f > nfsrvd_nfsd+0x193 > nfssvc_nfsd+0x9b > sys_nfssvc+0x90 > amd64_syscall+0x540 > Xfast_syscall+0xf7 > 1511 102752 nfsd nfsd: service > mi_switch+0x186 > sleepq_wait+0x42 > __lockmgr_args+0x5ae > vop_stdlock+0x39 > VOP_LOCK1_APV+0x46 > _vn_lock+0x47 > zfs_fhtovp+0x338 > nfsvno_fhtovp+0x87 > nfsd_fhtovp+0x7a > nfsrvd_dorpc+0x9cf > nfssvc_program+0x447 > svc_run_internal+0x687 > svc_thread_start+0xb > fork_exit+0x11f > fork_trampoline+0xe > 1511 102753 nfsd nfsd: service > mi_switch+0x186 > sleepq_wait+0x42 > _cv_wait+0x112 > zio_wait+0x61 > zil_commit+0x764 > zfs_freebsd_write+0xba0 > VOP_WRITE_APV+0xb2 > nfsvno_write+0x14d > nfsrvd_write+0x362 > nfsrvd_dorpc+0x3c0 > nfssvc_program+0x447 > svc_run_internal+0x687 > svc_thread_start+0xb > fork_exit+0x11f > fork_trampoline+0xe > 1511 102754 nfsd nfsd: service > mi_switch+0x186 > sleepq_wait+0x42 > _cv_wait+0x112 > zio_wait+0x61 > zil_commit+0x3cf > zfs_freebsd_fsync+0xdc > nfsvno_fsync+0x2f2 > nfsrvd_commit+0xe7 > nfsrvd_dorpc+0x3c0 > nfssvc_program+0x447 > svc_run_internal+0x687 > svc_thread_start+0xb > fork_exit+0x11f > fork_trampoline+0xe > 1511 102755 nfsd nfsd: service > mi_switch+0x186 > sleepq_wait+0x42 > __lockmgr_args+0x5ae > vop_stdlock+0x39 > VOP_LOCK1_APV+0x46 > _vn_lock+0x47 > zfs_fhtovp+0x338 > nfsvno_fhtovp+0x87 > nfsd_fhtovp+0x7a > nfsrvd_dorpc+0x9cf > nfssvc_program+0x447 > svc_run_internal+0x687 > svc_thread_start+0xb > fork_exit+0x11f > fork_trampoline+0xe > 1511 102756 nfsd nfsd: service > mi_switch+0x186 > sleepq_wait+0x42 > _cv_wait+0x112 > zil_commit+0x6d > zfs_freebsd_write+0xba0 > VOP_WRITE_APV+0xb2 > nfsvno_write+0x14d > nfsrvd_write+0x362 > nfsrvd_dorpc+0x3c0 > nfssvc_program+0x447 > svc_run_internal+0x687 > svc_thread_start+0xb > fork_exit+0x11f > fork_trampoline+0xe > These threads are either waiting for a vnode lock or waiting inside zil_commit() { at 3 different locations in zil_commit() }. A guess would be that the ZIL hasn`t completed a write for some reason, so 3 threads are waiting for it when one of them is holding a lock on the vnode being written and the remaining threads are waiting for that vnode lock. I am not a ZFS guy, so I cannot help further, except to suggest that you try and determine what might cause a write to the ZIL to stall. (Different device, different device driver...) Good luck with it, rick > > PID TID COMM TDNAME KSTACK > 1507 102750 nfsd - > mi_switch+0x186 > sleepq_catch_signals+0x2e1 > sleepq_wait_sig+0x16 > _cv_wait_sig+0x12a > seltdwait+0xf6 > kern_select+0x6ef > sys_select+0x5d > amd64_syscall+0x540 > Xfast_syscall+0xf7 > > > pool: tank > state: ONLINE > status: The pool is formatted using a legacy on-disk format. The pool > can > still be used, but some features are unavailable. > action: Upgrade the pool using 'zpool upgrade'. Once this is done, the > pool will no longer be accessible on software that does not support > feature > flags. > scan: scrub repaired 0 in 45h37m with 0 errors on Mon Dec 3 03:07:11 > 2012 > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > da19 ONLINE 0 0 0 > da31 ONLINE 0 0 0 > da32 ONLINE 0 0 0 > da33 ONLINE 0 0 0 > da34 ONLINE 0 0 0 > raidz1-1 ONLINE 0 0 0 > da20 ONLINE 0 0 0 > da36 ONLINE 0 0 0 > da37 ONLINE 0 0 0 > da38 ONLINE 0 0 0 > da39 ONLINE 0 0 0 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Tue Dec 4 15:40:02 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DD66A53 for ; Tue, 4 Dec 2012 15:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 42C758FC15 for ; Tue, 4 Dec 2012 15:40:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qB4Fe1P1030742 for ; Tue, 4 Dec 2012 15:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qB4Fe16S030741; Tue, 4 Dec 2012 15:40:01 GMT (envelope-from gnats) Date: Tue, 4 Dec 2012 15:40:01 GMT Message-Id: <201212041540.qB4Fe16S030741@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: CeDeROM Subject: Re: misc/174060: Ext2FS system crashes (buffer overflow?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: CeDeROM List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 15:40:02 -0000 The following reply was made to PR kern/174060; it has been noted by GNATS. From: CeDeROM To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org Cc: Subject: Re: misc/174060: Ext2FS system crashes (buffer overflow?) Date: Tue, 4 Dec 2012 16:32:28 +0100 It got worse, now the system crash on single file save :-( Maybe this is not the reason but the address/location number is printed as negative value... Is there any way to see why this happens? Maybe some backtrace from kernel dump? I noticed some time ago that the filesystem was too big to handle so many files, some sort of inodes exhaustion, so I have removed lots of unnecessary files and it was fine for some time. Should I increase bytes-per-inode and/or number of inodes? Any hints are welcome :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-fs@FreeBSD.ORG Tue Dec 4 17:54:47 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA950B28 for ; Tue, 4 Dec 2012 17:54:47 +0000 (UTC) (envelope-from rcartwri@asu.edu) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 86EAF8FC13 for ; Tue, 4 Dec 2012 17:54:47 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so8009081iec.13 for ; Tue, 04 Dec 2012 09:54:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DTRrfAzfOMcXshAkFr6g9AlKnMV+y+l0hvheyPf7ofU=; b=Y2sLko0qsHsPpzM4A6wgyi1QHmUx+nCukFPPb90Mwk/7469kH3tpxgTWLVUqMiAy9Q kBJtU4lkEQyH1EktOUPk2c7wmHqg6Qda5pPsmYfZlWREl5hhwsKfvDYNDMjzXJ7fJY5o 0ux4JW1l0YbNZMICD13hddhb955xwE4LZeqoXTdEeQH1RcTEcoyvX6HASdh6JQcwt2an hBhneeC+vR8NvYiPz5epbjuCOI2wCK4BtE2tZlVjBtMm1zZY/r1j6yx2/a5+17XHojxg IScLvYPB0vSFLI/0EEfozDbuSVzQSauL2Aasoqmw/2UR8MClm5npsbvp376FDQJBm803 /97w== MIME-Version: 1.0 Received: by 10.50.173.103 with SMTP id bj7mr3617597igc.47.1354643686996; Tue, 04 Dec 2012 09:54:46 -0800 (PST) Received: by 10.64.64.39 with HTTP; Tue, 4 Dec 2012 09:54:46 -0800 (PST) In-Reply-To: <1769356561.1118634.1354631170432.JavaMail.root@erie.cs.uoguelph.ca> References: <1769356561.1118634.1354631170432.JavaMail.root@erie.cs.uoguelph.ca> Date: Tue, 4 Dec 2012 10:54:46 -0700 Message-ID: Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE From: "Reed A. Cartwright" To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkZ+KIvs1NsvbOZ5f5P1XgYyCyexFvIxWXoQeP+vCNo/SQQtbVqu61DhtHgfNMi//6d0WWp Cc: freebsd-fs@freebsd.org, "freebsd-stable@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 17:54:47 -0000 I'm having similar issues after upgrading to 9.1-RC2 and RC3. I'm not using either NFS or a ZIL. On Tue, Dec 4, 2012 at 7:26 AM, Rick Macklem wrote: > Olivier wrote: >> Hi all >> After upgrading from 9.0-RELEASE to 9.1-PRERELEASE #0 r243679 I'm >> having >> severe problems with NFS sharing of a ZFS volume. nfsd appears to hang >> at >> random times (between once every couple hours to once every two days) >> while >> accessing a ZFS volume, and the only way I have found of resolving the >> problem is to reboot. The server console is sometimes still responsive >> during the nfsd hang, and I can read and write files to the same ZFS >> volume >> while nfsd is hung. I am pasting below the output of procstat -kk on >> nfsd, >> and details of my pool (nfsstat on the server gets hung when the >> problem >> has started occurring, and does not produce any output). The pool is >> v28 >> and was created from a bunch of volumes attached over Fibre Channel >> using >> the mpt driver. My system has a Supermicro board and 4 AMD Opteron >> 6274 >> CPUs. >> >> I did not experience any nfsd hangs with 9.0-RELEASE (same machine, >> essentially same configuration, same usage pattern). >> >> I would greatly appreciate any help to resolve this problem! >> Thank you >> Olivier >> >> PID TID COMM TDNAME KSTACK >> 1511 102751 nfsd nfsd: master >> mi_switch+0x186 >> sleepq_wait+0x42 >> __lockmgr_args+0x5ae >> vop_stdlock+0x39 >> VOP_LOCK1_APV+0x46 >> _vn_lock+0x47 >> zfs_fhtovp+0x338 >> nfsvno_fhtovp+0x87 >> nfsd_fhtovp+0x7a >> nfsrvd_dorpc+0x9cf >> nfssvc_program+0x447 >> svc_run_internal+0x687 >> svc_run+0x8f >> nfsrvd_nfsd+0x193 >> nfssvc_nfsd+0x9b >> sys_nfssvc+0x90 >> amd64_syscall+0x540 >> Xfast_syscall+0xf7 >> 1511 102752 nfsd nfsd: service >> mi_switch+0x186 >> sleepq_wait+0x42 >> __lockmgr_args+0x5ae >> vop_stdlock+0x39 >> VOP_LOCK1_APV+0x46 >> _vn_lock+0x47 >> zfs_fhtovp+0x338 >> nfsvno_fhtovp+0x87 >> nfsd_fhtovp+0x7a >> nfsrvd_dorpc+0x9cf >> nfssvc_program+0x447 >> svc_run_internal+0x687 >> svc_thread_start+0xb >> fork_exit+0x11f >> fork_trampoline+0xe >> 1511 102753 nfsd nfsd: service >> mi_switch+0x186 >> sleepq_wait+0x42 >> _cv_wait+0x112 >> zio_wait+0x61 >> zil_commit+0x764 >> zfs_freebsd_write+0xba0 >> VOP_WRITE_APV+0xb2 >> nfsvno_write+0x14d >> nfsrvd_write+0x362 >> nfsrvd_dorpc+0x3c0 >> nfssvc_program+0x447 >> svc_run_internal+0x687 >> svc_thread_start+0xb >> fork_exit+0x11f >> fork_trampoline+0xe >> 1511 102754 nfsd nfsd: service >> mi_switch+0x186 >> sleepq_wait+0x42 >> _cv_wait+0x112 >> zio_wait+0x61 >> zil_commit+0x3cf >> zfs_freebsd_fsync+0xdc >> nfsvno_fsync+0x2f2 >> nfsrvd_commit+0xe7 >> nfsrvd_dorpc+0x3c0 >> nfssvc_program+0x447 >> svc_run_internal+0x687 >> svc_thread_start+0xb >> fork_exit+0x11f >> fork_trampoline+0xe >> 1511 102755 nfsd nfsd: service >> mi_switch+0x186 >> sleepq_wait+0x42 >> __lockmgr_args+0x5ae >> vop_stdlock+0x39 >> VOP_LOCK1_APV+0x46 >> _vn_lock+0x47 >> zfs_fhtovp+0x338 >> nfsvno_fhtovp+0x87 >> nfsd_fhtovp+0x7a >> nfsrvd_dorpc+0x9cf >> nfssvc_program+0x447 >> svc_run_internal+0x687 >> svc_thread_start+0xb >> fork_exit+0x11f >> fork_trampoline+0xe >> 1511 102756 nfsd nfsd: service >> mi_switch+0x186 >> sleepq_wait+0x42 >> _cv_wait+0x112 >> zil_commit+0x6d >> zfs_freebsd_write+0xba0 >> VOP_WRITE_APV+0xb2 >> nfsvno_write+0x14d >> nfsrvd_write+0x362 >> nfsrvd_dorpc+0x3c0 >> nfssvc_program+0x447 >> svc_run_internal+0x687 >> svc_thread_start+0xb >> fork_exit+0x11f >> fork_trampoline+0xe >> > These threads are either waiting for a vnode lock or waiting inside > zil_commit() { at 3 different locations in zil_commit() }. A guess > would be that the ZIL hasn`t completed a write for some reason, so > 3 threads are waiting for it when one of them is holding a lock on > the vnode being written and the remaining threads are waiting for > that vnode lock. > > I am not a ZFS guy, so I cannot help further, except to suggest > that you try and determine what might cause a write to the ZIL to > stall. (Different device, different device driver...) > > Good luck with it, rick > >> >> PID TID COMM TDNAME KSTACK >> 1507 102750 nfsd - >> mi_switch+0x186 >> sleepq_catch_signals+0x2e1 >> sleepq_wait_sig+0x16 >> _cv_wait_sig+0x12a >> seltdwait+0xf6 >> kern_select+0x6ef >> sys_select+0x5d >> amd64_syscall+0x540 >> Xfast_syscall+0xf7 >> >> >> pool: tank >> state: ONLINE >> status: The pool is formatted using a legacy on-disk format. The pool >> can >> still be used, but some features are unavailable. >> action: Upgrade the pool using 'zpool upgrade'. Once this is done, the >> pool will no longer be accessible on software that does not support >> feature >> flags. >> scan: scrub repaired 0 in 45h37m with 0 errors on Mon Dec 3 03:07:11 >> 2012 >> config: >> >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> raidz1-0 ONLINE 0 0 0 >> da19 ONLINE 0 0 0 >> da31 ONLINE 0 0 0 >> da32 ONLINE 0 0 0 >> da33 ONLINE 0 0 0 >> da34 ONLINE 0 0 0 >> raidz1-1 ONLINE 0 0 0 >> da20 ONLINE 0 0 0 >> da36 ONLINE 0 0 0 >> da37 ONLINE 0 0 0 >> da38 ONLINE 0 0 0 >> da39 ONLINE 0 0 0 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Reed A. Cartwright, PhD Assistant Professor of Genomics, Evolution, and Bioinformatics School of Life Sciences Center for Evolutionary Medicine and Informatics The Biodesign Institute Arizona State University From owner-freebsd-fs@FreeBSD.ORG Tue Dec 4 18:20:36 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2A0A98C; Tue, 4 Dec 2012 18:20:35 +0000 (UTC) (envelope-from sig6247@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id AF00A8FC15; Tue, 4 Dec 2012 18:20:35 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so2950213pad.13 for ; Tue, 04 Dec 2012 10:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:cc:subject:in-reply-to:references :mime-version:content-type; bh=kUCg9PMbH6MSUK0lOeM4T666OkIDE+Kf+6JkHfytbng=; b=WasI5ZJ9Zz2CAGhihawmMbbRsVdGUcZIJejA1K1SgZz2nGVHvWCNoDCXDa0vMMloii 1XjQS95h/laqMoGQtog95oNlJXoWVys6qXVKgjaijNPD1Axw+32hysHQP6uE/N+xQl8X ceAnjJX3VdJC8db0q7amabaQ7gnoKSRdT138vEIZ7iFboJXrZJOGB00eFGaCkkd5Ekd8 L7MxzJy/7jMQMP/c8OCksqAU7t6RT4fKuTvt0nAHypKljsfUxC/DcJ3oWWD00HT/nU7N Ocj7aQDC/xnsnxzyyeiILoT5TaNFnv3HB0dgZnADyZg2SE2TJ2s/9IFAyODn6Y3i8Hgb Z2eg== Received: by 10.68.231.97 with SMTP id tf1mr40505395pbc.149.1354645235259; Tue, 04 Dec 2012 10:20:35 -0800 (PST) Received: from localhost (exit-01a.noisetor.net. [173.254.216.66]) by mx.google.com with ESMTPS id n11sm1359353pby.67.2012.12.04.10.20.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Dec 2012 10:20:34 -0800 (PST) Message-ID: <50be3ef2.2b53440a.35c0.79d3@mx.google.com> Date: Tue, 04 Dec 2012 10:20:34 -0800 (PST) From: sig6247 To: Konstantin Belousov Subject: Re: clang compiled kernel panic when mounting zfs root on i386 In-Reply-To: <20121203224132.GJ3013@kib.kiev.ua> (Konstantin Belousov's message of "Tue, 4 Dec 2012 00:41:32 +0200") References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, dim@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 18:20:36 -0000 On Tue, 4 Dec 2012 00:41:32 +0200, Konstantin Belousov wrote: > Please try the patch below. It might give an immediate relief, but still > there are many offenders in the backtrace. Thanks for the patch, it works now. From owner-freebsd-fs@FreeBSD.ORG Wed Dec 5 09:54:25 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32A0FD08; Wed, 5 Dec 2012 09:54:25 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7F228FC13; Wed, 5 Dec 2012 09:54:24 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so6163723obc.13 for ; Wed, 05 Dec 2012 01:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4n88mFKnaNLQdudBx1w+UXeZhpWT/NJWn5OfZYo3jlg=; b=iJUeN1/IfyDUFIHKjucISZw1ekxVs0trFI7rKFfg2+qMqui1H9sh+LnPXUjuqdujtU JrWoVSbQBw+nfi9lBjNGTdeYQ2wgwhzu1s4Xo5keGBPg57yUodm648Cr3YsPaeZJs/9y aNsU+TmYhYVvVACa+E7kjoxgb9reNzpSFQspxKn2aSuaxqWxY3B/ByVqGPAQCsRQMz9e 3O5mvKZIy6bU0Nn4gi/rJDzIm8wrUCTISZKPbmODuFGzRmKGbhrpFpYMuq6RE1I4Odrn 7K4VcktulyS+4bbEssvlu/bn0o+g4UbkkdBEmgKLbU1jip7BkDxFnse0gaRtO131GgBA AMyQ== MIME-Version: 1.0 Received: by 10.182.240.45 with SMTP id vx13mr10277803obc.21.1354701258542; Wed, 05 Dec 2012 01:54:18 -0800 (PST) Received: by 10.76.143.199 with HTTP; Wed, 5 Dec 2012 01:54:18 -0800 (PST) Date: Wed, 5 Dec 2012 01:54:18 -0800 Message-ID: Subject: GELI on USB From: Ali Mashtizadeh To: FreeBSD Hackers , freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 09:54:25 -0000 I think I found a possible bug in 9.1 where I configured an encrypted root partition on a USB key and I have trouble entering the password from what seems like a race. 1. GELI first prints to ask for my password on the root, but immediately is interrupted with a message saying that the root failed to mount with error 19. As shown here: http://www.mashtizadeh.com/usbnotwaiting.jpg When I type the file system path some characters are missing. It appears that geli and the prompt for root are both reading the USB keyboard input. When setting kern.geom.eli.visible_passphrase=3D1 then all characters are printed on the screen, but the prompt seems to receive bad input. Is there a way to prevent the root mount failing immediately? I set the boot flag and it seems this works properly on some hardware. --=20 Ali Mashtizadeh =D8=B9=D9=84=DB=8C =D9=85=D8=B4=D8=AA=DB=8C =D8=B2=D8=A7=D8=AF=D9=87 From owner-freebsd-fs@FreeBSD.ORG Wed Dec 5 12:04:53 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A9663C4 for ; Wed, 5 Dec 2012 12:04:53 +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 CF6578FC19 for ; Wed, 5 Dec 2012 12:04:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA13329; Wed, 05 Dec 2012 14:04:45 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TgB8M-0009xS-MI; Wed, 05 Dec 2012 11:19:14 +0200 Message-ID: <50BF1191.8010007@FreeBSD.org> Date: Wed, 05 Dec 2012 11:19:13 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andreas Nilsson Subject: Re: kern/167066: [zfs] ZVOLs not appearing in /dev/zvol References: <201211241313.qAODDwld048466@freefall.freebsd.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 12:04:53 -0000 on 03/12/2012 13:19 Andreas Nilsson said the following: > Hello again, > > I think that the nodes in /dev/zvol should be removed after a zfs destroy. > > Ie. if you do > > zfs create -V1g tank/vol ; zfs snapshot tank/vol@1 ; zfs snapshot tank/vol@2 ; > zfs destroy tank/vol@2 ; zfs destroy tank/vol@1 > > I think that only /dev/zvol/tank/vol should still exist. Even after > > zfs destroy tank/vol > > /dev/zvol/tank/vol@1 and /dev/zvol/tank/vol@2 still exists. Telegraph style: kern/173442, r242862 > It gets a bit more exiting when creating partitions on the volume as well. > > Best regards > Andreas > > > On Sat, Nov 24, 2012 at 2:13 PM, > wrote: > > Synopsis: [zfs] ZVOLs not appearing in /dev/zvol > > Responsible-Changed-From-To: freebsd-fs->avg > Responsible-Changed-By: avg > Responsible-Changed-When: Sat Nov 24 13:13:49 UTC 2012 > Responsible-Changed-Why: > I am handling this. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=167066 > _______________________________________________ > 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 > " > > -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Dec 6 08:53:06 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BF61685; Thu, 6 Dec 2012 08:53:06 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3613F8FC17; Thu, 6 Dec 2012 08:53:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qB68r6mP032643; Thu, 6 Dec 2012 08:53:06 GMT (envelope-from mm@freefall.freebsd.org) Received: (from mm@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qB68r6M2032639; Thu, 6 Dec 2012 08:53:06 GMT (envelope-from mm) Date: Thu, 6 Dec 2012 08:53:06 GMT Message-Id: <201212060853.qB68r6M2032639@freefall.freebsd.org> To: araujo@FreeBSD.org, mm@FreeBSD.org, freebsd-fs@FreeBSD.org From: mm@FreeBSD.org Subject: Re: kern/170912: [zfs] [patch] unnecessarily setting DS_FLAG_INCONSISTENT on async destroyed datasets X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 08:53:06 -0000 Synopsis: [zfs] [patch] unnecessarily setting DS_FLAG_INCONSISTENT on async destroyed datasets State-Changed-From-To: open->closed State-Changed-By: mm State-Changed-When: Thu Dec 6 08:53:05 UTC 2012 State-Changed-Why: Resolved. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=170912 From owner-freebsd-fs@FreeBSD.ORG Thu Dec 6 08:53:22 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6439700; Thu, 6 Dec 2012 08:53:22 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 837B68FC17; Thu, 6 Dec 2012 08:53:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qB68rM3I032757; Thu, 6 Dec 2012 08:53:22 GMT (envelope-from mm@freefall.freebsd.org) Received: (from mm@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qB68rMMD032753; Thu, 6 Dec 2012 08:53:22 GMT (envelope-from mm) Date: Thu, 6 Dec 2012 08:53:22 GMT Message-Id: <201212060853.qB68rMMD032753@freefall.freebsd.org> To: araujo@FreeBSD.org, mm@FreeBSD.org, freebsd-fs@FreeBSD.org From: mm@FreeBSD.org Subject: Re: kern/170914: [zfs] [patch] Import patchs related with issues 3090 and 3102. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 08:53:22 -0000 Synopsis: [zfs] [patch] Import patchs related with issues 3090 and 3102. State-Changed-From-To: open->closed State-Changed-By: mm State-Changed-When: Thu Dec 6 08:53:22 UTC 2012 State-Changed-Why: Resolved. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=170914 From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 05:08:38 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AEAAB8C for ; Fri, 7 Dec 2012 05:08:38 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 473DC8FC08 for ; Fri, 7 Dec 2012 05:08:38 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TgqAv-0007PT-1n for freebsd-fs@freebsd.org; Fri, 07 Dec 2012 05:08:37 +0000 Date: Fri, 07 Dec 2012 14:08:36 +0900 Message-ID: From: Randy Bush To: FreeBSD FS Subject: moving to gpart mirroring, one drive at a time User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 05:08:38 -0000 i have an existing old-style glabel gmirror. a drive, ada0 failed. we inserted a new drive as ada0. as the old drive is a teensie 80g drive and the new is a 500g, we figured to create gm1, dump/restore to it, and then swap out the old working 80g for another 500 and mirror away. so i went to the handbook. 20.4.3 Creating a Mirror with an Existing Drive does not seem appropriate as it assumes no source mirror and equal sized drives. so i figured to do the dance of 20.4.2 Creating a Mirror with Two New Disks, but with one disk and then mirror back. but ... # gmirror label -v gm1 /dev/ada0 Metadata value stored on /dev/ada0. Done. # gpart create -s MBR mirror/gm1 mirror/gm1 created # gpart show mirror/gm1 => 63 976773104 mirror/gm1 MBR (465G) 63 976773104 - free - (465G) # gpart create -s BSD mirror/gm1s1 gpart: arg0 'mirror/gm1s1': Invalid argument whoopsie. clue? randy From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 05:15:56 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54197D27 for ; Fri, 7 Dec 2012 05:15:56 +0000 (UTC) (envelope-from edho@myconan.net) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D212B8FC0C for ; Fri, 7 Dec 2012 05:15:55 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so52636wey.13 for ; Thu, 06 Dec 2012 21:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myconan.net; s=myconan; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RL2KIlv+L7I5QCIwgWIt9EcjgpErsBjht5njVVka8oU=; b=DwRSt1IO40MWXl19XPLLTN0zI+wYPBX9Jv5ng4iAEjARm0eOigf/oYIzToQ8hduCtv r1GSNpOinEXA0CqaNypvJdG4cUwiYjzTR5Ub5/zKAtwBfkdSAZkLY3VcRtFzBpS2gt7Z FGzw3f6I2PMnlTcUioMvNH5o2aCqmlC4aQAKM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=RL2KIlv+L7I5QCIwgWIt9EcjgpErsBjht5njVVka8oU=; b=lQIyz3nxOLVFSdw1X1a5nxjzZSuthq6BTEwmZIgS474EFU8DdFOPR2aM8Cr0FTvfJh Y20AqnNXFRVX3TxgBx2HbmOYLNLIavh/zBb3yLpNPvL2faYWhJ7TjWBOQsZTrtygv0M6 ybRofubNTo5Rdvrlvd9dvVGNXv5CqRysE0Zp0gx0BHIyYTGb76oG/txJ9quolVxs6AS3 uvQfKEsn+hOpTJfnIsSnn/1YLTl2BLJC+74SusoP8bwbFiiaeGDzALJfgWtdTGC2d5V2 v4koSnC5msVr+WXzuDiUdHBcyoU1pkFM//dvSbryTptWDlvhDZSbaD/l2B4geQYaK+6I V6mw== Received: by 10.180.88.71 with SMTP id be7mr6293198wib.17.1354857353795; Thu, 06 Dec 2012 21:15:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.84.69 with HTTP; Thu, 6 Dec 2012 21:15:23 -0800 (PST) In-Reply-To: References: From: Edho Arief Date: Fri, 7 Dec 2012 12:15:23 +0700 Message-ID: Subject: Re: moving to gpart mirroring, one drive at a time To: Randy Bush Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkP21QkOk1/zY3Lr7dhn8gvadVI1hSXCKsAmp+E+Gexb2xSle3RIv4VPeVw9NeZA4sCsvNf Cc: FreeBSD FS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 05:15:56 -0000 On Fri, Dec 7, 2012 at 12:08 PM, Randy Bush wrote: > i have an existing old-style glabel gmirror. a drive, ada0 failed. we > inserted a new drive as ada0. as the old drive is a teensie 80g drive > and the new is a 500g, we figured to create gm1, dump/restore to it, and > then swap out the old working 80g for another 500 and mirror away. > > so i went to the handbook. 20.4.3 Creating a Mirror with an Existing > Drive does not seem appropriate as it assumes no source mirror and equal > sized drives. > > so i figured to do the dance of 20.4.2 Creating a Mirror with Two New > Disks, but with one disk and then mirror back. but ... > > # gmirror label -v gm1 /dev/ada0 > Metadata value stored on /dev/ada0. > Done. > > # gpart create -s MBR mirror/gm1 > mirror/gm1 created > > # gpart show mirror/gm1 > => 63 976773104 mirror/gm1 MBR (465G) > 63 976773104 - free - (465G) > > # gpart create -s BSD mirror/gm1s1 > gpart: arg0 'mirror/gm1s1': Invalid argument > > whoopsie. > > clue? > ...create the partition first? gpart add -t freebsd mirror/gm1 From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 05:17:42 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34AC3DA9 for ; Fri, 7 Dec 2012 05:17:42 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 0F83B8FC08 for ; Fri, 7 Dec 2012 05:17:42 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TgqJh-0007di-9u; Fri, 07 Dec 2012 05:17:41 +0000 Date: Fri, 07 Dec 2012 14:17:40 +0900 Message-ID: From: Randy Bush To: Edho Arief Subject: Re: moving to gpart mirroring, one drive at a time In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD FS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 05:17:42 -0000 > gpart add -t freebsd mirror/gm1 thank you randy From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 11:00:20 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C79C4D12 for ; Fri, 7 Dec 2012 11:00:20 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [93.95.13.41]) by mx1.freebsd.org (Postfix) with SMTP id 0764F8FC08 for ; Fri, 7 Dec 2012 11:00:19 +0000 (UTC) Received: (qmail 25251 invoked from network); 7 Dec 2012 10:55:51 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 7 Dec 2012 10:55:51 -0000 Received: (qmail 25242 invoked by uid 599); 7 Dec 2012 10:55:50 -0000 Received: from unknown (HELO PDC002.icritical.int) (212.57.254.146) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Fri, 07 Dec 2012 10:55:50 +0000 Message-ID: <50C1CB34.3000308@icritical.com> Date: Fri, 7 Dec 2012 10:55:48 +0000 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120906 Thunderbird/15.0 MIME-Version: 1.0 To: Subject: ZFS hang Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-TLS-Incoming: YES X-Virus-Scanned: by iCritical at mail1.icritical.com X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 11:00:20 -0000 Hi. I've just experienced a filesystem hang on 9.1-PRE from Sept 17th while hitting the disks hard (io-bound database workload). The disks are: 16 Spinning SAS disks (ZFS vdevs), hung off a pair of Areca 1320 HBAs 4 SATA SSDs (L2ARC), hung off onboard ICH (SATA3) and onboard C600 2 SATA SSDs (gmirror swap, zfs root fs (mirrored), main array ZIL) connected the same as the other SSDs Symptoms are any filesystem activity (login, starting gstat, tab completion) is hanging, with processes either in state 'zfs' or 'zio->io_cv)'. CPUs are idle. 'zpool status -v' doesn't hang. All disks online, no errors. In the debugger, I got the following: 118 0 0 0 DL ipmireq 0xfffffe0038bfcbb8 [ipmi0: kcs] 108 0 0 0 DL crypto_r 0xffffffff81a31900 [crypto returns] 107 0 0 0 DL crypto_w 0xffffffff81a318c0 [crypto] 19 0 0 0 DL m:w1 0xfffffe0038a79400 [g_mirror swap] 18 0 0 0 DL sdflush 0xffffffff81337c58 [softdepflush] 17 0 0 0 DL zio->io_ 0xfffffe07d9633d70 [syncer] 16 0 0 0 DL vlruwt 0xfffffe00389d1000 [vnlru] 9 0 0 0 DL psleep 0xffffffff8132bf48 [bufdaemon] 8 0 0 0 DL pgzero 0xffffffff81341c9c [pagezero] 7 0 0 0 DL psleep 0xffffffff81340e68 [vmdaemon] 6 0 0 0 DL psleep 0xffffffff81340e2c [pagedaemon] 5 0 0 0 DL ccb_scan 0xffffffff812988e0 [xpt_thrd] 4 0 0 0 DL waiting_ 0xffffffff81331f60 [sctp_iterator] 3 0 0 0 DL (threaded) [zfskern] 100740 D zio->io_ 0xfffffe1f3e786a00 [txg_thread_enter] 100739 D tx->tx_q 0xfffffe0038cd0230 [txg_thread_enter] 100409 D zio->io_ 0xfffffe1f40f02a00 [txg_thread_enter] 100408 D tx->tx_q 0xfffffe0038d43e30 [txg_thread_enter] 100097 D zio->io_ 0xfffffe1e6412da00 [l2arc_feed_thread] 100096 D arc_recl 0xffffffff817d4ca0 [arc_reclaim_thread] 15 0 0 0 DL (threaded) [usb] 100083 D - 0xffffff8001f5de18 [usbus1] 100082 D - 0xffffff8001f5ddc0 [usbus1] 100081 D - 0xffffff8001f5dd68 [usbus1] 100080 D - 0xffffff8001f5dd10 [usbus1] 100078 D - 0xffffff8001f54e18 [usbus0] 100077 D - 0xffffff8001f54dc0 [usbus0] 100076 D - 0xffffff8001f54d68 [usbus0] 100075 D - 0xffffff8001f54d10 [usbus0] 2 0 0 0 DL ctl_work 0xffffff8000a6a000 [ctl_thrd] 14 0 0 0 DL - 0xffffffff812dd7c4 [yarrow] 13 0 0 0 DL (threaded) [geom] 100023 D - 0xffffffff812d6b90 [g_down] 100022 D - 0xffffffff812d6b88 [g_up] 100021 D - 0xffffffff812d6b78 [g_event] 12 0 0 0 WL (threaded) [intr] Everything else looked 'normal' (piles of stuck cron/sendmail processes, etc) 66608 66605 66608 0 DVs zfs 0xfffffe005922c638 cron db> bt 66608 Tracing pid 66608 tid 108987 td 0xfffffe164ac67000 sched_switch() at sched_switch+0x13d mi_switch() at mi_switch+0x196 sleepq_wait() at sleepq_wait+0x42 __lockmgr_args() at __lockmgr_args+0x610 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x52 _vn_lock() at _vn_lock+0x47 vget() at vget+0x70 cache_lookup_times() at cache_lookup_times+0x5f5 vfs_cache_lookup() at vfs_cache_lookup+0xc8 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x4c lookup() at lookup+0x424 namei() at namei+0x535 vn_open_cred() at vn_open_cred+0x3cb kern_openat() at kern_openat+0x1f9 amd64_syscall() at amd64_syscall+0x5ea Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x800d3b0ac, rsp = --- 0x7fffffffc878, rbp = 0x7fffffffc9c0 --- (gstat, attempted to run after hang) 66578 11191 66578 0 D+ zio->io_ 0xfffffe1f3a16ad70 gstat Tracing pid 66578 tid 109053 td 0xfffffe07e012e000 sched_switch() at sched_switch+0x13d mi_switch() at mi_switch+0x196 sleepq_wait() at sleepq_wait+0x42 _cv_wait() at _cv_wait+0x121 zio_wait() at zio_wait+0x61 dbuf_read() at dbuf_read+0x5e5 dbuf_findbp() at dbuf_findbp+0x107 dbuf_hold_impl() at dbuf_hold_impl+0xc2 dbuf_hold() at dbuf_hold+0x1b dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x147 dmu_buf_hold_array() at dmu_buf_hold_array+0x67 dmu_read_uio() at dmu_read_uio+0x3f zfs_freebsd_read() at zfs_freebsd_read+0x3e3 VOP_READ_APV() at VOP_READ_APV+0x44 vn_read() at vn_read+0x316 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x6c sys_read() at sys_read+0x64 amd64_syscall() at amd64_syscall+0x5ea Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (3, FreeBSD ELF64, sys_read), rip = 0x8017d1b4c, rsp = --- 0x7fffffffc488, rbp = 0x7fffffffc5d0 --- 17 0 0 0 DL zio->io_ 0xfffffe07d9633d70 [syncer] Tracing pid 17 tid 100105 td 0xfffffe00389ba000 sched_switch() at sched_switch+0x13d mi_switch() at mi_switch+0x196 sleepq_wait() at sleepq_wait+0x42 _cv_wait() at _cv_wait+0x121 zio_wait() at zio_wait+0x61 dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x22b dmu_read() at dmu_read+0x89 space_map_load() at space_map_load+0x108 metaslab_activate() at metaslab_activate+0xdc metaslab_alloc() at metaslab_alloc+0x7b2 zio_alloc_zil() at zio_alloc_zil+0x61 zil_lwb_write_start() at zil_lwb_write_start+0x1ad zil_commit() at zil_commit+0x24a zfs_sync() at zfs_sync+0xb3 sync_fsync() at sync_fsync+0x19d VOP_FSYNC_APV() at VOP_FSYNC_APV+0x4a sync_vnode() at sync_vnode+0x15e sched_sync() at sched_sync+0x1c5 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffa3008acbb0, rbp = 0 --- 3 0 0 0 DL (threaded) [zfskern] Tracing pid 3 tid 100740 td 0xfffffe0038c858e0 sched_switch() at sched_switch+0x13d mi_switch() at mi_switch+0x196 sleepq_wait() at sleepq_wait+0x42 _cv_wait() at _cv_wait+0x121 zio_wait() at zio_wait+0x61 dsl_pool_sync() at dsl_pool_sync+0xe0 spa_sync() at spa_sync+0x336 txg_sync_thread() at txg_sync_thread+0x139 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffa303242bb0, rbp = 0 --- 100740 D zio->io_ 0xfffffe1f3e786a00 [txg_thread_enter] Tracing pid 3 tid 100740 td 0xfffffe0038c858e0 sched_switch() at sched_switch+0x13d mi_switch() at mi_switch+0x196 sleepq_wait() at sleepq_wait+0x42 _cv_wait() at _cv_wait+0x121 zio_wait() at zio_wait+0x61 dsl_pool_sync() at dsl_pool_sync+0xe0 spa_sync() at spa_sync+0x336 txg_sync_thread() at txg_sync_thread+0x139 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffa303242bb0, rbp = 0 --- 100739 D tx->tx_q 0xfffffe0038cd0230 [txg_thread_enter] Tracing pid 3 tid 100739 td 0xfffffe0038c86000 sched_switch() at sched_switch+0x13d mi_switch() at mi_switch+0x196 sleepq_wait() at sleepq_wait+0x42 _cv_wait() at _cv_wait+0x121 txg_thread_wait() at txg_thread_wait+0x79 txg_quiesce_thread() at txg_quiesce_thread+0xb5 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffa303239bb0, rbp = 0 --- 100409 D zio->io_ 0xfffffe1f40f02a00 [txg_thread_enter] db> bt 100409 Tracing pid 3 tid 100409 td 0xfffffe00389b9000 sched_switch() at sched_switch+0x13d mi_switch() at mi_switch+0x196 sleepq_wait() at sleepq_wait+0x42 _cv_wait() at _cv_wait+0x121 zio_wait() at zio_wait+0x61 dsl_pool_sync() at dsl_pool_sync+0xe0 spa_sync() at spa_sync+0x336 txg_sync_thread() at txg_sync_thread+0x139 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffa302eb5bb0, rbp = 0 --- 100408 D tx->tx_q 0xfffffe0038d43e30 [txg_thread_enter] Tracing pid 3 tid 100408 td 0xfffffe0038c778e0 sched_switch() at sched_switch+0x13d mi_switch() at mi_switch+0x196 sleepq_wait() at sleepq_wait+0x42 _cv_wait() at _cv_wait+0x121 txg_thread_wait() at txg_thread_wait+0x79 txg_quiesce_thread() at txg_quiesce_thread+0xb5 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffa302eacbb0, rbp = 0 --- 100097 D zio->io_ 0xfffffe1e6412da00 [l2arc_feed_thread] Tracing pid 3 tid 100097 td 0xfffffe0036c4d000 sched_switch() at sched_switch+0x13d mi_switch() at mi_switch+0x196 sleepq_wait() at sleepq_wait+0x42 _cv_wait() at _cv_wait+0x121 zio_wait() at zio_wait+0x61 l2arc_feed_thread() at l2arc_feed_thread+0x981 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffa30075fbb0, rbp = 0 --- 100096 D arc_recl 0xffffffff817d4ca0 [arc_reclaim_thread] Tracing pid 3 tid 100096 td 0xfffffe0036c4d470 sched_switch() at sched_switch+0x13d mi_switch() at mi_switch+0x196 sleepq_timedwait() at sleepq_timedwait+0x42 _cv_timedwait() at _cv_timedwait+0x13c arc_reclaim_thread() at arc_reclaim_thread+0x29d fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffa30075abb0, rbp = 0 --- Does anyone either recognise what's going on (hopefully be able to say this was fixed in r....), or could someone give me an indication of how better to diagnose this if it happens again? I can set a dumpdev, but this machine's got 128G RAM and precious little free memory (DB server), so I doubt anyone would want to touch it! Thanks -- Sorry for the below... The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 12:22:22 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39E5BF6 for ; Fri, 7 Dec 2012 12:22:22 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail2.icritical.com (mail2.icritical.com [212.57.248.50]) by mx1.freebsd.org (Postfix) with SMTP id 7D0D78FC14 for ; Fri, 7 Dec 2012 12:22:21 +0000 (UTC) Received: (qmail 18775 invoked from network); 7 Dec 2012 12:15:46 -0000 Received: from localhost (127.0.0.1) by mail2.icritical.com with SMTP; 7 Dec 2012 12:15:46 -0000 Received: (qmail 18764 invoked by uid 599); 7 Dec 2012 12:15:45 -0000 Received: from unknown (HELO PDC002.icritical.int) (212.57.254.146) by mail2.icritical.com (qpsmtpd/0.28) with ESMTP; Fri, 07 Dec 2012 12:15:45 +0000 Message-ID: <50C1DDE8.9030503@icritical.com> Date: Fri, 7 Dec 2012 12:15:36 +0000 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120906 Thunderbird/15.0 MIME-Version: 1.0 To: Subject: Re: ZFS hang References: <50C1CB34.3000308@icritical.com> In-Reply-To: <50C1CB34.3000308@icritical.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-TLS-Incoming: YES X-Virus-Scanned: by iCritical at mail2.icritical.com X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 12:22:22 -0000 After rebooting the box, I've just seen this on the console (after 'Setting hostid'): (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 53 8 0 1 0 0 (da8:isci0:0:0:0): CAM status: SCSI Status Error (da8:isci0:0:0:0): SCSI status: Check Condition (da8:isci0:0:0:0): SCSI sense: MEDIUM ERROR asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) (da8:isci0:0:0:0): Info: 0x4215378 (da8:isci0:0:0:0): Retrying command (per sense data) (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 53 8 0 1 0 0 (da8:isci0:0:0:0): CAM status: SCSI Status Error (da8:isci0:0:0:0): SCSI status: Check Condition (da8:isci0:0:0:0): SCSI sense: MEDIUM ERROR asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) (da8:isci0:0:0:0): Info: 0x4215378 (da8:isci0:0:0:0): Retrying command (per sense data) (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 53 8 0 1 0 0 (da8:isci0:0:0:0): CAM status: SCSI Status Error (da8:isci0:0:0:0): SCSI status: Check Condition (da8:isci0:0:0:0): SCSI sense: MEDIUM ERROR asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) (da8:isci0:0:0:0): Info: 0x4215378 (da8:isci0:0:0:0): Retrying command (per sense data) (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 53 8 0 1 0 0 (da8:isci0:0:0:0): CAM status: SCSI Status Error (da8:isci0:0:0:0): SCSI status: Check Condition (da8:isci0:0:0:0): SCSI sense: MEDIUM ERROR asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) (da8:isci0:0:0:0): Info: 0x4215378 (da8:isci0:0:0:0): Retrying command (per sense data) (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 53 8 0 1 0 0 (da8:isci0:0:0:0): CAM status: SCSI Status Error (da8:isci0:0:0:0): SCSI status: Check Condition (da8:isci0:0:0:0): SCSI sense: MEDIUM ERROR asc:ffffffff,ffffffff (Reserved ASC/ASCQ pair) (da8:isci0:0:0:0): Info: 0x4215378 (da8:isci0:0:0:0): Error 5, Retries exhausted and then again for the following: (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 65 8 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 75 8 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 76 8 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 82 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 83 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 84 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 94 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 95 58 0 1 0 0 (only 2 retries) (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 9b 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 a4 58 0 1 0 0 (only 1 retry) (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 a5 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 a6 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 b4 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 b5 58 0 1 0 0 (2 retries) (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 b6 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 bc 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 c7 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 d7 58 0 1 0 0 (1 retry) (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 d8 58 0 1 0 0 (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 e8 58 0 1 0 0 Obviously, the cause of my problems would seem to be a hosed disk. However the kernel msgbuf shows no complaints from the drive before reboot. da8 is a 60GB OCZ Agility 3 SSD (purchased prior to realising just how unreliable they are). According to the SMART data, it's had just 146GB of reads and 278GB writes over 3 power cycles with only 3 months power on time, similar to the others that have failed (~60% failure rate for ours) I can understand the drive failing, I just can't understand how it hung the system. I have had a similar thing happen on one of these machines before (with GENERIC and no dumpdev, so no debugging) with one of these disks on an Areca HBA. I've also had these drives fail on the onboard SATA controller, along with SAS drives on the SAS controllers, with no undesirable effects (other than having to swap it out). Could there be a problem with ATA devices on SCSI controllers which is causing failures to be silently dropped? Is ZFS lacking a timeout on IO calls? I'm going to move all these SSDs onto the SATA controller, and see if I can replicate the problem, but I'm not holding my breath over a conclusive result. -- Sorry for the below... The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 13:07:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A44A7FC9 for ; Fri, 7 Dec 2012 13:07:10 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 250598FC0C for ; Fri, 7 Dec 2012 13:07:09 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so254053bkc.13 for ; Fri, 07 Dec 2012 05:07:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SmDolnwes3XpeSOe2UGrxznguST9Wj3eLWCeBAiPPsQ=; b=WnEVK7GgTEX5PaRhtCN38g7EqNTcW5QEudmXW27CEEqQbHwWnwolSxhtjteXwZIlp1 FA33rctS1AFvBdivVvbSXuAbNlP4iMHJ/5XUoEwmdXReR5mQavnPQNZiK+jSf3pgc86P hzAG0chFxrlznP5ZyvXekh7ZrY/M2pPeZsLnb/oWkLNWjAJkNnaRS7KslvkKqLT0HDId QSjaeTUtxqypoWRaK7vaqysD60EkkgLWCXGRnU3iMutTPLqfml2gKqKWlCYc+nAW5gjA n32jiI2r1w1ex/Gsicyav8bsojLhUOzb2R9h4jQefqSmbDOxvoQjFsfb3kt9INZqPTe/ zByA== Received: by 10.204.133.219 with SMTP id g27mr1869207bkt.65.1354885629127; Fri, 07 Dec 2012 05:07:09 -0800 (PST) Received: from [192.168.50.105] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id o9sm9075407bko.15.2012.12.07.05.07.07 (version=SSLv3 cipher=OTHER); Fri, 07 Dec 2012 05:07:08 -0800 (PST) Message-ID: <50C1E9FB.4020108@gmail.com> Date: Fri, 07 Dec 2012 14:07:07 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: ZFS hang References: <50C1CB34.3000308@icritical.com> <50C1DDE8.9030503@icritical.com> In-Reply-To: <50C1DDE8.9030503@icritical.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 13:07:10 -0000 Matt Burke schreef: > After rebooting the box, I've just seen this on the console (after 'Setting > hostid'): > > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 53 8 0 1 0 0 > (da8:isci0:0:0:0): CAM status: SCSI Status Error > (da8:isci0:0:0:0): SCSI status: Check Condition > (da8:isci0:0:0:0): SCSI sense: MEDIUM ERROR asc:ffffffff,ffffffff (Reserved > ASC/ASCQ pair) > (da8:isci0:0:0:0): Info: 0x4215378 > (da8:isci0:0:0:0): Retrying command (per sense data) > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 53 8 0 1 0 0 > (da8:isci0:0:0:0): CAM status: SCSI Status Error > (da8:isci0:0:0:0): SCSI status: Check Condition > (da8:isci0:0:0:0): SCSI sense: MEDIUM ERROR asc:ffffffff,ffffffff (Reserved > ASC/ASCQ pair) > (da8:isci0:0:0:0): Info: 0x4215378 > (da8:isci0:0:0:0): Retrying command (per sense data) > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 53 8 0 1 0 0 > (da8:isci0:0:0:0): CAM status: SCSI Status Error > (da8:isci0:0:0:0): SCSI status: Check Condition > (da8:isci0:0:0:0): SCSI sense: MEDIUM ERROR asc:ffffffff,ffffffff (Reserved > ASC/ASCQ pair) > (da8:isci0:0:0:0): Info: 0x4215378 > (da8:isci0:0:0:0): Retrying command (per sense data) > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 53 8 0 1 0 0 > (da8:isci0:0:0:0): CAM status: SCSI Status Error > (da8:isci0:0:0:0): SCSI status: Check Condition > (da8:isci0:0:0:0): SCSI sense: MEDIUM ERROR asc:ffffffff,ffffffff (Reserved > ASC/ASCQ pair) > (da8:isci0:0:0:0): Info: 0x4215378 > (da8:isci0:0:0:0): Retrying command (per sense data) > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 53 8 0 1 0 0 > (da8:isci0:0:0:0): CAM status: SCSI Status Error > (da8:isci0:0:0:0): SCSI status: Check Condition > (da8:isci0:0:0:0): SCSI sense: MEDIUM ERROR asc:ffffffff,ffffffff (Reserved > ASC/ASCQ pair) > (da8:isci0:0:0:0): Info: 0x4215378 > (da8:isci0:0:0:0): Error 5, Retries exhausted > > and then again for the following: > > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 65 8 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 75 8 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 76 8 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 82 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 83 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 84 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 94 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 95 58 0 1 0 0 (only 2 retries) > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 9b 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 a4 58 0 1 0 0 (only 1 retry) > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 a5 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 a6 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 b4 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 b5 58 0 1 0 0 (2 retries) > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 b6 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 bc 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 c7 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 d7 58 0 1 0 0 (1 retry) > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 d8 58 0 1 0 0 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 1 e8 58 0 1 0 0 > > Obviously, the cause of my problems would seem to be a hosed disk. However > the kernel msgbuf shows no complaints from the drive before reboot. > > da8 is a 60GB OCZ Agility 3 SSD (purchased prior to realising just how > unreliable they are). According to the SMART data, it's had just 146GB of > reads and 278GB writes over 3 power cycles with only 3 months power on > time, similar to the others that have failed (~60% failure rate for ours) > > I can understand the drive failing, I just can't understand how it hung the > system. I have had a similar thing happen on one of these machines before > (with GENERIC and no dumpdev, so no debugging) with one of these disks on > an Areca HBA. > > I've also had these drives fail on the onboard SATA controller, along with > SAS drives on the SAS controllers, with no undesirable effects (other than > having to swap it out). > > Could there be a problem with ATA devices on SCSI controllers which is > causing failures to be silently dropped? Is ZFS lacking a timeout on IO calls? > > I'm going to move all these SSDs onto the SATA controller, and see if I can > replicate the problem, but I'm not holding my breath over a conclusive result. > > > I had somthing simular. This was on 9.0 with a LSI 9211-8i controller and a supermicro backplane. One disk was failing, with simular kernel messages. It was a seagate 300 GB SAS disk But zfs got stuck on it. It totally hangs the system. Which was no fun at all because we use ZFS as the storage for our VMware hypervisors. After replacing that drive all was fine again. But it looks like ZFS or something else can not handle it properly. I also had a disk that was known to have bad sectors, this disk was ejected from the pool like it should with a message that too many errors occured on the disk. Gr Johan From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 15:40:32 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1F15AE5 for ; Fri, 7 Dec 2012 15:40:32 +0000 (UTC) (envelope-from universite@ukr.net) Received: from ffe17.ukr.net (ffe17.ukr.net [195.214.192.83]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2A88FC12 for ; Fri, 7 Dec 2012 15:40:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=g9Yc2r2dKP8sljKEKtYfJDZwO2jYGEnvQ7AU+R4S4zE=; b=UimXbGB4g8hm7PEuPp6EwYNWbPvI2WYY6o35xcRKuzrpSxanDLvek7LRoYLI1zvcREGgg7vRrWP/yyZGK1hJisGpYSi6uqjIoAXO9VHiUqgK7+xtBuDaMlhQAt6HcwdmGPJ4eEcVbXe7R30EH2KmKZl+oD61kOLHpBlHbbU3Npk=; Received: from mail by ffe17.ukr.net with local ID 1Tgzne-000JqG-SU for freebsd-fs@freebsd.org; Fri, 07 Dec 2012 17:25:14 +0200 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: Freebsd fsck cannot find superblock To: freebsd-fs@freebsd.org From: "Vladislav Prodan" X-Mailer: freemail.ukr.net 4.0 Message-Id: <75249.1354893914.10573459057769119744@ffe17.ukr.net> X-Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0 Date: Fri, 07 Dec 2012 17:25:14 +0200 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:40:32 -0000 There is an ancient system of FreeBSD 7.4. And departed this life one partition (data). Screenshot is attached. http://s017.radikal.ru/i412/1212/bd/e9a9bfd0a644.jpg What will be thought how to save the slice? -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 15:56:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 744E7FF4 for ; Fri, 7 Dec 2012 15:56:28 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id F14028FC14 for ; Fri, 7 Dec 2012 15:56:27 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id a14so280759eaa.13 for ; Fri, 07 Dec 2012 07:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WnXOi9h/1rouqqfTnQZadoKdE9YLSrTHLKXx5GAJnxc=; b=z1RUiu4Y2XbZNXfHCdfTBbh8Q1gYA+zONdGKJdmXyV+ptC9TyGQXPwGaeyYGi8vM1L HwmCj6WGhXW2mwP/LEvdHjrL88zaPZbwcUgCRJB5aamInRfMbtuVkKHvckpaTSlTcezf x/GTHXSqteOpRYxT9eQ1isc3JisQgBesZPPa62l8UsCqfgAJpVlXUzxehlviRGOuzt8I 19LfGDfJkE8mnTE/oRlmzDFbHuusoKo5D8P62Y1tjwEBzsqH5SFZTA1zfye1lifsWT8L p9MHYImNp0IqUMhA5JiHOxgr+2uhddHrJr24Qih5IlUydIxg7rLkbm+p2DxN+IM5wfdS qF9w== Received: by 10.14.174.198 with SMTP id x46mr18113254eel.23.1354895783821; Fri, 07 Dec 2012 07:56:23 -0800 (PST) Received: from [192.168.1.104] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPS id f6sm1591111eeo.7.2012.12.07.07.56.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Dec 2012 07:56:23 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: ZFS hang Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <50C1DDE8.9030503@icritical.com> Date: Fri, 7 Dec 2012 16:56:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <44B9F706-687A-4EB5-88FF-2688350E44D5@FreeBSD.org> References: <50C1CB34.3000308@icritical.com> <50C1DDE8.9030503@icritical.com> To: Matt Burke X-Mailer: Apple Mail (2.1283) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:56:28 -0000 Wiadomo=B6=E6 napisana przez Matt Burke w dniu 7 gru 2012, o godz. = 13:15: > After rebooting the box, I've just seen this on the console (after = 'Setting > hostid'): >=20 > (da8:isci0:0:0:0): READ(10). CDB: 28 0 4 21 53 8 0 1 0 0 > (da8:isci0:0:0:0): CAM status: SCSI Status Error > (da8:isci0:0:0:0): SCSI status: Check Condition > (da8:isci0:0:0:0): SCSI sense: MEDIUM ERROR asc:ffffffff,ffffffff = (Reserved > ASC/ASCQ pair) [..] > I can understand the drive failing, I just can't understand how it = hung the > system. I have had a similar thing happen on one of these machines = before > (with GENERIC and no dumpdev, so no debugging) with one of these disks = on > an Areca HBA. Could you try to change the "failmode" zpool property (zpool set = failmode=3Dcontinue") and see if it helps? I seem to remember the default behaviour for ZFS = is to wait for a miracle to happen instead of returning Input/Output Error to the = application. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 16:22:48 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99063FD3 for ; Fri, 7 Dec 2012 16:22:48 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD488FC12 for ; Fri, 7 Dec 2012 16:22:47 +0000 (UTC) Received: from [87.79.199.75] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Th0hF-0005dA-1g; Fri, 07 Dec 2012 17:22:41 +0100 Date: Fri, 7 Dec 2012 17:22:40 +0100 From: Fabian Keil To: Matt Burke Subject: Re: ZFS hang Message-ID: <20121207172240.037306e1@fabiankeil.de> In-Reply-To: <50C1DDE8.9030503@icritical.com> References: <50C1CB34.3000308@icritical.com> <50C1DDE8.9030503@icritical.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/=RU/Fpp7.cOidyj8KH41+zQ"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 16:22:48 -0000 --Sig_/=RU/Fpp7.cOidyj8KH41+zQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Matt Burke wrote: > Obviously, the cause of my problems would seem to be a hosed disk. However > the kernel msgbuf shows no complaints from the drive before reboot. >=20 > da8 is a 60GB OCZ Agility 3 SSD (purchased prior to realising just how > unreliable they are). According to the SMART data, it's had just 146GB of > reads and 278GB writes over 3 power cycles with only 3 months power on > time, similar to the others that have failed (~60% failure rate for ours) >=20 > I can understand the drive failing, I just can't understand how it hung t= he > system. I have had a similar thing happen on one of these machines before > (with GENERIC and no dumpdev, so no debugging) with one of these disks on > an Areca HBA. In CURRENT, parts of the cam layer can silently hang under certain circumstances and this can negatively affect various other subsystems including ZFS: http://lists.freebsd.org/pipermail/freebsd-current/2012-October/037413.html I suppose this regression is old enough to have trickled down to the stable branches by now. I'm not saying that this is definitively the problem you are seeing, but I think it would explain the symptoms. > Could there be a problem with ATA devices on SCSI controllers which is > causing failures to be silently dropped? Is ZFS lacking a timeout on IO c= alls? I believe ZFS is designed with the expectation that timeouts are handled by the layers below it, so technically it doesn't "lack" the timeouts for IO calls ... Fabian --Sig_/=RU/Fpp7.cOidyj8KH41+zQ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDCF9UACgkQBYqIVf93VJ0orQCfcmsNJbxWyacbww51lJTjO0aH c5wAn0l/fOn7P6yLYvr3Vp6+A4CvzQCB =fGcL -----END PGP SIGNATURE----- --Sig_/=RU/Fpp7.cOidyj8KH41+zQ-- From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 16:41:15 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9EB0502 for ; Fri, 7 Dec 2012 16:41:15 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A1B888FC0C for ; Fri, 7 Dec 2012 16:41:14 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so500687pbc.13 for ; Fri, 07 Dec 2012 08:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BSdMbncgC9Dmv1AETP+a2AvhQfho2C94+9T1O9dDdSY=; b=IHN2PHtwbreS511MFzJVFShLxJGc6cLsXzVRCacXIpgcFQ5B3PYkuBjPVa7XOo/k8Z FMH/LQzKPhFTNjwxSizipmZDCQSjQ/H0bmkNPQJ/cBtl+hkD/8YdoAf63vy3Kk+6MenP h02e/O2C5q0RImnXTS+p2VQWTeMVq/6Q4T04rWN6SGceuRcfXDAoCP4SzgRY7klG3BwS 8uAwkV5T9zBVhXSmkZfHBW+3AUxvBQ8HGeR1ygqZs96XIlI1uGx1Iwww3/ZfCbwA+4Nv ZO9mR5DYqTGBW69HGMmzb7gdLB70IXkOiVya9bXMzFwXiXsAt/TiKC8gD4RPw/x/0vBQ YAuA== Received: by 10.68.230.105 with SMTP id sx9mr17344504pbc.44.1354898474225; Fri, 07 Dec 2012 08:41:14 -0800 (PST) Received: from [192.168.1.129] ([91.196.229.122]) by mx.google.com with ESMTPS id c2sm6836988pax.28.2012.12.07.08.41.11 (version=SSLv3 cipher=OTHER); Fri, 07 Dec 2012 08:41:13 -0800 (PST) Message-ID: <50C21C25.9060604@gmail.com> Date: Fri, 07 Dec 2012 18:41:09 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: Vladislav Prodan Subject: Re: Freebsd fsck cannot find superblock References: <75249.1354893914.10573459057769119744@ffe17.ukr.net> In-Reply-To: <75249.1354893914.10573459057769119744@ffe17.ukr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 16:41:16 -0000 07.12.2012 17:25, Vladislav Prodan: > > There is an ancient system of FreeBSD 7.4. > And departed this life one partition (data). > > Screenshot is attached. > http://s017.radikal.ru/i412/1212/bd/e9a9bfd0a644.jpg > What will be thought how to save the slice? Have you tried Sleuth kit? It's available in the ports. I used it once on NTFS and was happy about it. -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 18:21:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C69D648D for ; Fri, 7 Dec 2012 18:21:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8FF7B8FC14 for ; Fri, 7 Dec 2012 18:21:05 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so562847pbc.13 for ; Fri, 07 Dec 2012 10:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=Q2iEN0/v663AP3BCIlHmsE94qkpU2vJBR2oN3ihSHEA=; b=BN9ku0y+0GAwTtcFEldA7BzjgY/Wja8pI+NTweEAf5NmDLJmUspabf/xaHHZFvVotU TSlwvg6+Tt/P0kuEf5DqtIAEhUNDqixHW2aMxPoz7xO8rO6e6ZJpqt0IknectFHQlRcF hfmYPTg9YYcbHjOIhvhGb9f6sSrL1LGT3JZOw9AlKQ7QS+Qe/DCRexp1xG33nBk75X0D If1hac4VayjHAdOzax1D204Jrw5GMPKhxmsKvnrpWeqmbLTXvwHhNXWC4N0+uuW3xs6q cUQ6/fMbfbfN5Al37GhG3VMstJ2btJ0M01fEtIrsV8koqByRySZJsYrdv06ilLx9ZUpC rhtw== Received: by 10.68.204.103 with SMTP id kx7mr18203083pbc.33.1354904465101; Fri, 07 Dec 2012 10:21:05 -0800 (PST) Received: from [192.168.20.12] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id zv10sm7051614pbc.76.2012.12.07.10.21.02 (version=SSLv3 cipher=OTHER); Fri, 07 Dec 2012 10:21:03 -0800 (PST) References: <50C1CB34.3000308@icritical.com> <50C1DDE8.9030503@icritical.com> <20121207172240.037306e1@fabiankeil.de> Mime-Version: 1.0 (1.0) In-Reply-To: <20121207172240.037306e1@fabiankeil.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <79E03100-A019-4579-8762-50FBB82DD356@gmail.com> X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: ZFS hang Date: Fri, 7 Dec 2012 10:21:01 -0800 To: Fabian Keil Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 18:21:05 -0000 On Dec 7, 2012, at 8:22 AM, Fabian Keil wrote= : > Matt Burke wrote: >=20 >> Obviously, the cause of my problems would seem to be a hosed disk. Howeve= r >> the kernel msgbuf shows no complaints from the drive before reboot. >>=20 >> da8 is a 60GB OCZ Agility 3 SSD (purchased prior to realising just how >> unreliable they are). According to the SMART data, it's had just 146GB of= >> reads and 278GB writes over 3 power cycles with only 3 months power on >> time, similar to the others that have failed (~60% failure rate for ours)= >>=20 >> I can understand the drive failing, I just can't understand how it hung t= he >> system. I have had a similar thing happen on one of these machines before= >> (with GENERIC and no dumpdev, so no debugging) with one of these disks on= >> an Areca HBA. >=20 > In CURRENT, parts of the cam layer can silently hang under certain > circumstances and this can negatively affect various other subsystems > including ZFS: > http://lists.freebsd.org/pipermail/freebsd-current/2012-October/037413.htm= l >=20 > I suppose this regression is old enough to have trickled down > to the stable branches by now. >=20 > I'm not saying that this is definitively the problem you are > seeing, but I think it would explain the symptoms. >=20 >> Could there be a problem with ATA devices on SCSI controllers which is >> causing failures to be silently dropped? Is ZFS lacking a timeout on IO c= alls? >=20 > I believe ZFS is designed with the expectation that timeouts are > handled by the layers below it, so technically it doesn't "lack" > the timeouts for IO calls ... I've noticed hangs on reboot as well recently (in the last 2-3 months) with m= y ata single disk pools and my mfi pool. All storage disks seem healthy... T= he pools were running v28 with the zfs features upgrade. Thanks, -Garrett= From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 18:47:00 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B74C3A9A for ; Fri, 7 Dec 2012 18:47:00 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 838E98FC08 for ; Fri, 7 Dec 2012 18:47:00 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so576971pbc.13 for ; Fri, 07 Dec 2012 10:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:date:message-id:subject:from:to:content-type; bh=f86nfrlfXhq+i8KK4Tyadj4INkoumb+iG1lEMNXqI80=; b=ZIzZEwuwsDrjvCCxbjgxzbZZG4fGIFJAff2Fhuc7NpTxFy3QgzVvifGuLwhxpnx1qO WTHELw554ueA+WvAUWGOnvz0onze4PZ+ylka9eADci+vDv+1KEaXKR0veVqcOwx5T+BR fr7kOiZQ52F8jDaEBhd7E0oK/qeHoApjImuDE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=f86nfrlfXhq+i8KK4Tyadj4INkoumb+iG1lEMNXqI80=; b=e8M2PZpAQOjpQAMhYi/F546AobnnFKFVxzAjZ4R591KXScJupClDqWJpKmmaYtHzom Yc66DoqjHU71fbgHMPfJJa9WghlGk575f+1MkUicLwP4CqVrXv9jnVh9uEuZsATPKdMA 7DYANE/I5/+7DwwxfrtCom4H/hMqziFbI1THwugCnD5SK9uXHXwab00LAXxE2rlez00E vuQFVOhKIm/GMlrf/KhUmC3sfflT83WABCVFxOfKSiHv2sroNWFOCwlKYH9/2MbrE7jM pbR45PEQS8qH3Js+TwYwkm62EcVRKkVl3u47IoEhGQ2vCba9+W+BBmucMacOGVYEgAXY /bjQ== MIME-Version: 1.0 Received: by 10.66.80.68 with SMTP id p4mr15759368pax.35.1354906019986; Fri, 07 Dec 2012 10:46:59 -0800 (PST) Received: by 10.68.200.99 with HTTP; Fri, 7 Dec 2012 10:46:59 -0800 (PST) Date: Fri, 7 Dec 2012 10:46:59 -0800 Message-ID: Subject: zfs list slow From: Tim Gustafson To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmGwBUmtDRmZQMgRaEYFF+H/GdYB+UNsabT5l2WsWezEQEgxOImENc6jNRinIhwSpqgFkN2 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 18:47:00 -0000 We're running zpool version 28, and zfs version 5, on a FreeBSD 9.0-RELEASE-p4 box. I'm trying to get a list of all snapshots in my zpool, like this: /sbin/zfs list -H -r -t snapshot -o name -s name tank We have about 2,000 file systems, and each of those has perhaps a dozen snapshots. This command currently takes about 5 minutes to run the first time. If you run it again immediately, it goes much quicker - perhaps a few seconds. But if you change any of the zpool configuration (like creating a new snapshot, or a new file system), the command takes about 5 minutes to run again. Is there any way to speed up the listing of all local snapshots? -- Tim Gustafson tjg@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 19:41:32 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A921DD0B for ; Fri, 7 Dec 2012 19:41:32 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2781A8FC13 for ; Fri, 7 Dec 2012 19:41:31 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so801204lah.13 for ; Fri, 07 Dec 2012 11:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZnycsuBYhNQaiKzCNhnKrjpSrV/QIArvXxbP4sdRrHU=; b=qvqUZHJRev5CJmE3DgZKivpxQjZokwp4ifqTHu4o+7FQsFUxi/qYczrc2+i+ccTlpz 3E0CQq//ckjlZAOra8LxHI4q0+AsNt1UE7xxId7F9zl4b2Tr3WfMUm9bfMyrb4x6FjYd boT0ML+zYwgwdN1yjupEr6UZ2zz98TNwr8KDcEBBkCiFpSw7qakzQzRhMV5x6o1ZvG3k CaiCxDH63OZk1AblM7r3vP+36qu2Szf+nNmU5rcO9lEDogjqamsKUwK2AnO6cQYsKib+ TRnTENkLLTE1yiDjyTvQFpM4izshpZfKkTHrW84B/mlTy2qsC92rvXba5l3pYs/MkjJ6 krpA== MIME-Version: 1.0 Received: by 10.112.49.65 with SMTP id s1mr2941667lbn.123.1354909290245; Fri, 07 Dec 2012 11:41:30 -0800 (PST) Received: by 10.114.81.40 with HTTP; Fri, 7 Dec 2012 11:41:30 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Dec 2012 11:41:30 -0800 Message-ID: Subject: Re: zfs list slow From: Freddie Cash To: Tim Gustafson Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:41:32 -0000 Pawel committed a fix for snapshot listing that greatly sped up the listing when using "-o name". I believe it was in 9-STABLE after 9.0 was released, so you would need to upgrade to 9.1 to get the fix. There should be an announcement/CFT for it in the freebsd-fs archives. On Fri, Dec 7, 2012 at 10:46 AM, Tim Gustafson wrote: > We're running zpool version 28, and zfs version 5, on a FreeBSD > 9.0-RELEASE-p4 box. > > I'm trying to get a list of all snapshots in my zpool, like this: > > /sbin/zfs list -H -r -t snapshot -o name -s name tank > > We have about 2,000 file systems, and each of those has perhaps a > dozen snapshots. This command currently takes about 5 minutes to run > the first time. If you run it again immediately, it goes much quicker > - perhaps a few seconds. But if you change any of the zpool > configuration (like creating a new snapshot, or a new file system), > the command takes about 5 minutes to run again. > > Is there any way to speed up the listing of all local snapshots? > > -- > > Tim Gustafson > tjg@soe.ucsc.edu > 831-459-5354 > Baskin Engineering, Room 313A > _______________________________________________ > 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" > -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 19:58:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08064F49 for ; Fri, 7 Dec 2012 19:58:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD098FC08 for ; Fri, 7 Dec 2012 19:58:03 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so814562lah.13 for ; Fri, 07 Dec 2012 11:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BHhQnRUqN70ZXa3SZWlxPS9+0S3I8/Qkgq+pjJXE7qQ=; b=f35CWyRCHa5V4J8Se3swTrVSxXE5ORWIvGHfoFURkjvVgoVyehG8umedlmhpJNcvem MWB4yCDrHe5Y7zOJ28N/YcQbAy3+lLA03+h00q1UHmxGfzpxKAj1l62rrTMZmefQE8t7 Hs1+gJ/bTEGQtIDVnq49hiCLqyBr8+/iKVYsoAtgamtzWJJISE9BEzpiWz/rFOkuAzXz wna80lpRjKFEPpfNTT0yD0oygm0PNrtCAMeJUW5RY0ivOOxaQMMWECATBo+rSzhHcI9K X4pJOx3mTBrS6/0BXNp5cD0zcXUCFu5hvrSuHiVaIn1gS2XBmujbIX7mSjlzbBJ12XK3 fe1A== MIME-Version: 1.0 Received: by 10.112.29.104 with SMTP id j8mr3044891lbh.0.1354910283105; Fri, 07 Dec 2012 11:58:03 -0800 (PST) Received: by 10.112.99.70 with HTTP; Fri, 7 Dec 2012 11:58:02 -0800 (PST) In-Reply-To: <201211091540.qA9Fe1Dc063613@freefall.freebsd.org> References: <201211091540.qA9Fe1Dc063613@freefall.freebsd.org> Date: Fri, 7 Dec 2012 11:58:02 -0800 Message-ID: Subject: Re: kern/150503: [zfs] ZFS disks are UNAVAIL and corrupted after reboot From: Garrett Cooper To: Guido Falsi Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:58:05 -0000 On Fri, Nov 9, 2012 at 7:40 AM, Guido Falsi wrote: ... > Uhm I don't know how to generate a new zpool.cache from a newly update > system, since I can't export/import the root and don't have a newer > system on a USB key. I'll have to produce one perhaps. Glen Barber's snapshots are really helpful when doing this: https://snapshots.glenbarber.us/Latest/ . It got me from a completely unusable state to a limping state (booted off the LiveCD, zpool imported and working from there) with the latest ZFS code commits (which seem to have broken pool importing on my system). Thanks, -Garrett From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 20:06:40 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E182D189 for ; Fri, 7 Dec 2012 20:06:40 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id 91C4B8FC13 for ; Fri, 7 Dec 2012 20:06:40 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3YJ4St0sJqzFW9F; Fri, 7 Dec 2012 21:06:38 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl0Dg-a6N-IW; Fri, 7 Dec 2012 21:06:36 +0100 (CET) Received: from tommy.madpilot.net (host115-31-dynamic.180-80-r.retail.telecomitalia.it [80.180.31.115]) by winston.madpilot.net (Postfix) with ESMTPSA; Fri, 7 Dec 2012 21:06:36 +0100 (CET) Message-ID: <50C24C4C.3030003@madpilot.net> Date: Fri, 07 Dec 2012 21:06:36 +0100 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: kern/150503: [zfs] ZFS disks are UNAVAIL and corrupted after reboot References: <201211091540.qA9Fe1Dc063613@freefall.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 20:06:40 -0000 On 12/07/12 20:58, Garrett Cooper wrote: > On Fri, Nov 9, 2012 at 7:40 AM, Guido Falsi wrote: > > ... > >> Uhm I don't know how to generate a new zpool.cache from a newly update >> system, since I can't export/import the root and don't have a newer >> system on a USB key. I'll have to produce one perhaps. > > Glen Barber's snapshots are really helpful when doing this: > https://snapshots.glenbarber.us/Latest/ . It got me from a completely > unusable state to a limping state (booted off the LiveCD, zpool > imported and working from there) with the latest ZFS code commits > (which seem to have broken pool importing on my system). I did solve this using make release another system and making a memstick with the result. The system with problems was just a test machine so I was in no hurry to fix it. Anyway your suggestion will be useful in the future! Thanks! -- Guido Falsi From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 23:02:15 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C63F2C43 for ; Fri, 7 Dec 2012 23:02:15 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) by mx1.freebsd.org (Postfix) with ESMTP id 42CB58FC0C for ; Fri, 7 Dec 2012 23:02:14 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBDD8A.dip.t-dialin.net [93.203.221.138]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id qB7KXZTa063470; Fri, 7 Dec 2012 21:33:35 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id qB7KXWRr060983; Fri, 7 Dec 2012 21:33:32 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id qB7KXJJC082366; Fri, 7 Dec 2012 21:33:26 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201212072033.qB7KXJJC082366@fire.js.berklix.net> To: "Vladislav Prodan" Subject: Re: Freebsd fsck cannot find superblock From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Fri, 07 Dec 2012 17:25:14 +0200." <75249.1354893914.10573459057769119744@ffe17.ukr.net> Date: Fri, 07 Dec 2012 21:33:19 +0100 Sender: jhs@berklix.com Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:02:15 -0000 Hi, Reference: > From: "Vladislav Prodan" > Date: Fri, 07 Dec 2012 17:25:14 +0200 > Message-id: <75249.1354893914.10573459057769119744@ffe17.ukr.net> "Vladislav Prodan" wrote: > > There is an ancient system of FreeBSD 7.4. > And departed this life one partition (data). > > Screenshot is attached. > http://s017.radikal.ru/i412/1212/bd/e9a9bfd0a644.jpg > What will be thought how to save the slice? Hi, sorry, No time to look at jpg but... If your superblocks are shot (as mine were last week - half dead disk) here my notes of how I recovered all data: ------- cd /usr/ports/*/dd_rescue ; make install mount -t ufs /dev/da0s1 /mnt ; cd /mnt dd_rescue -l log -o bbfile -A -v /dev/ad0s1f image cat bbfile # 130 160 9785408 9785409 71591611 71784469 mdconfig -a -t vnode -f image (cd /usr/ports/sysutils/ffs2recov; make install) ffs2recov -s /dev/md0 superblock: 81920(byte), 160(block) superblock: 6160384(byte), 12032(block) superblock: 73351168(byte), 143264(block) superblock: 192774144(byte), 376512(block), \ cg: 192790528(byte), 376544(block), 1(nth), \ fs begin: 0(block), primary sb at: 128(block) superblock: 385466368(byte), 752864(block), \ cg: 385482752(byte), 752896(block), 2(nth), \ fs begin: 0(block), primary sb at: 128(block) superblock: 578158592(byte), 1129216(block), \ cg: 578174976(byte), 1129248(block), 3(nth), \ fs begin: 0(block), primary sb at: 128(block) superblock: 770850816(byte), 1505568(block), \ cg: 770867200(byte), 1505600(block), 4(nth), \ fs begin: 0(block), primary sb at: 128(block) superblock: 963543040(byte), 1881920(block), \ cg: 963559424(byte), 1881952(block), 5(nth), \ fs begin: 0(block), primary sb at: 128(block) superblock: 1156235264(byte), 2258272(block), \ cg: 1156251648(byte), 2258304(block), 6(nth), \ fs begin: 0(block), primary sb at: 128(block) superblock: 1348927488(byte), 2634624(block), \ cg: 1348943872(byte), 2634656(block), 7(nth), \ fs begin: 0(block), primary sb at: 128(block) ffs2recov -o 160 /dev/md0 # Failed, presumably cos of data corruption. echo The first few superblocks dont work, so I used first one showing cg: fsck_ffs -y -b 376512 /dev/md0 # Succeeded mdconfig -d -u 0 -------- Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. Not: HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-fs@FreeBSD.ORG Fri Dec 7 23:22:12 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A8A0214 for ; Fri, 7 Dec 2012 23:22:12 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 019DE8FC14 for ; Fri, 7 Dec 2012 23:22:11 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so821196pad.13 for ; Fri, 07 Dec 2012 15:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O2PWxq6WbYfGKUsY7B2eQPqTGdQPKDzbvYMJ7jrShno=; b=GKAFDXZAL0r6UL+kHnVIXH35SjpXXJy5eYjTNRJf6icKjbxbzJhJjes26UiN/+8UXL 5XIMQEQAqaJuIjwYiwDLKtMGIwVTBkGkCaOX5/Xt11Y5g7mTMha1HohzYLgTm+3IShKB s/kANNnQQJC4SkgS5JSjQxytXPUqjrcfQtX/8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=O2PWxq6WbYfGKUsY7B2eQPqTGdQPKDzbvYMJ7jrShno=; b=RXDPu3YbUteKyYWrOEDsunQXrfFFClbJySq6iMruVWgCU8/XVkj+Uqo2zAyeomMjns uYMOamHHPtBXNn/n3MUcPyap3YR5remhOnvw7BKLYU1f41Dc9exI3pDMUy5PhzQzofDp 05m0rM9dHht5CGR6CmQ9xhOLkSFnbtqahQ5Yyjx2JYfGZe4MC0NI5/Eew1TCxfWgh/uJ 9bn3rmlgVk93iRZsm+fscQusD9JOfslCO80NXevSMG/d1W/kmrQsDxKWG26SBvUK9ijU 9R4qPIoLCLVBznSw4o1+M5+TIMLQAFjF6Iv07QGZ4oJOCYtyn3CbCs7ThtR1aOdVqBpW GW3g== MIME-Version: 1.0 Received: by 10.68.252.228 with SMTP id zv4mr19927853pbc.134.1354922531206; Fri, 07 Dec 2012 15:22:11 -0800 (PST) Received: by 10.68.200.99 with HTTP; Fri, 7 Dec 2012 15:22:11 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Dec 2012 15:22:11 -0800 Message-ID: Subject: Re: zfs list slow From: Tim Gustafson To: Freddie Cash Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnUK9l+PfhneEPCf21vIfO/UsQj4nRlTV05FRSHGsvJWGkfmxbf2bhHoSc5ZLovqqNV10h7 Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:22:12 -0000 > Pawel committed a fix for snapshot listing that greatly sped up the listing > when using "-o name". I believe it was in 9-STABLE after 9.0 was released, > so you would need to upgrade to 9.1 to get the fix. > > There should be an announcement/CFT for it in the freebsd-fs archives. Thanks; I'll check into upgrading. I appreciate the help. -- Tim Gustafson tjg@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From owner-freebsd-fs@FreeBSD.ORG Sat Dec 8 01:01:14 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 615225F3; Sat, 8 Dec 2012 01:01:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id BF6288FC15; Sat, 8 Dec 2012 01:01:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qB811AOV087925; Sat, 8 Dec 2012 03:01:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qB811AOV087925 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qB8119AG087924; Sat, 8 Dec 2012 03:01:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 8 Dec 2012 03:01:09 +0200 From: Konstantin Belousov To: fs@freebsd.org Subject: nullfs changes MFC Message-ID: <20121208010109.GH3013@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rYG72ePx0AS+3phQ" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: stable@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 01:01:14 -0000 --rYG72ePx0AS+3phQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I am going to merge latest batch of the nullfs improvements into stable/9. This will bring up significant performance enchancements due to use of the shared locks for lookups if the lower layer supports it, much better caching on the nullfs layer, and proper handling of the text segments on the nullfs. Also, it should improve the error recovery and some corner cases with locking. Unfortunately, the merge would break KBI for VFS, since it needs 5 new VOP slots, and only three spares are left. We already are very liberal with the VFS KBI, so I do not feel that the merge is not acceptable, due to the benefits it brings to the nullfs. The merge is available at=20 http://people.freebsd.org/~kib/misc/nullfs_9.1.patch --rYG72ePx0AS+3phQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQwpFVAAoJEJDCuSvBvK1BoH0P/iRe4AYokmwWxnYIZqHUyigi 7j/q46ZPx5LU6e5c3rM/RRQED3enIyBcCndiIcvTLqpCSSLjlL/Zw0RmsbWuRF7Z 9WbVosx00Oh8+7MVI2oFuaJqKuhUDS4Q6W8uOD/ZUYRZ/wzg4Av/jwW/3hIbfA+v 1rrA1moUcXAhtwQiP+VKCw8V9+15EVNfhBPIAgl2sPBZpbGLqlTjPUS1FRGGBN4t iriSi0bb4XfOiNIJTbyk4HSCxh1P/gPewXRLYBmn2J1uq28ckeOIOiE7+hr37LD1 QFiItMc1SWdvUOcQwB6ZL0bJomeoQYsVfnRBfYVgO/7AZTVJbGtfwv7qT5SsBwev bOTA4IRawSTwe0bM0FQubDgLRARrOLFpY2l3d+6vRwZ2cCRyOmvA1AwXiZZlwjQ8 J3NxH5XkwJYtkiUmKVkq6Eanv1Kh1Z4Koe7sVsM66/MVJJwXKjWtsLKkZkMQGzg8 z/kt7vrGoaLRg7UmQ8SYrkPrM5qNZfzbkTZHoDfZmqrEv0bvzWUcn4VbH6WJZ3kw G5pXUf0QhVXcYUS1ONfMxsyoL+axDJ7GuzWfPEIfVqdQP3qD7ioA3I2g4Lr+L0HU Zp6mZgWnwnhyVGej4uakmwoWeksKMrJsHzm40IZi+UmnOcK11Q+xKkxZrAfQqaBP pmL+rD9hEistjnrkRFAB =Rj7D -----END PGP SIGNATURE----- --rYG72ePx0AS+3phQ-- From owner-freebsd-fs@FreeBSD.ORG Sat Dec 8 02:58:21 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BBD9265; Sat, 8 Dec 2012 02:58:21 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5205F8FC0C; Sat, 8 Dec 2012 02:58:19 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so755991eek.13 for ; Fri, 07 Dec 2012 18:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=aC4BkGCLPaFWIB33Gg/8dDynUV6JPf7bk5xHXV1sWgs=; b=lUe/Rwj2ux0lUwXFSfeMvgvO/9wuVD7f6XYHl1Nto/DKjgJZ3x1h+sEgaVPvDFm/Rd PCgRXrpFleBQSWsz+zYy3/v0xP7HYYzwx8iHyXhpFuWi66xIE83G7HfMa0cYxTGO/zZF l/edvS53OgUDz+c4rbX7AxC8wTA7Yy4FYqj+CTem3B84VeChNQbL2Bqdvw0/XZObxFaz AhdaOy9XTWFzg4CKd3TuaQKh1Qa5Bjk7q8C2B3TpumDejVEUENpEOAmx6qbGUyGwNCGv 9iaLKLBps2hIlR3Iz6gSqHTwH8nSllC8Oxhpcv/g9er+ZvwtCfHA2CxtVGaDWV1V+5uP RBfw== Received: by 10.14.203.2 with SMTP id e2mr23834473eeo.20.1354935499143; Fri, 07 Dec 2012 18:58:19 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id r1sm26577245eeo.2.2012.12.07.18.58.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Dec 2012 18:58:18 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 8 Dec 2012 03:58:16 +0100 From: Baptiste Daroussin To: Konstantin Belousov Subject: Re: nullfs changes MFC Message-ID: <20121208025816.GC88230@ithaqua.etoilebsd.net> References: <20121208010109.GH3013@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6zdv2QT/q3FMhpsV" Content-Disposition: inline In-Reply-To: <20121208010109.GH3013@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 02:58:21 -0000 --6zdv2QT/q3FMhpsV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 08, 2012 at 03:01:09AM +0200, Konstantin Belousov wrote: > Hi, > I am going to merge latest batch of the nullfs improvements into > stable/9. This will bring up significant performance enchancements due > to use of the shared locks for lookups if the lower layer supports it, > much better caching on the nullfs layer, and proper handling of the text > segments on the nullfs. Also, it should improve the error recovery and > some corner cases with locking. >=20 > Unfortunately, the merge would break KBI for VFS, since it needs 5 new > VOP slots, and only three spares are left. We already are very liberal > with the VFS KBI, so I do not feel that the merge is not acceptable, due > to the benefits it brings to the nullfs. >=20 > The merge is available at=20 > http://people.freebsd.org/~kib/misc/nullfs_9.1.patch Sorry I haven't checked the latest zfs related MFC, but for some time there= was an issue with nullfs improvements and zfs, will this mfc be synchronize wit= h the mfc of the related zfs fixes? regards, Bapt --6zdv2QT/q3FMhpsV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDCrMgACgkQ8kTtMUmk6EydgQCfRQIxqYF/JPfz2yO9KyQX282K 40UAoKLAfTk0SfRqKLdkaBSg7/Wz0YYW =E7wz -----END PGP SIGNATURE----- --6zdv2QT/q3FMhpsV-- From owner-freebsd-fs@FreeBSD.ORG Sat Dec 8 03:06:21 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E58D633; Sat, 8 Dec 2012 03:06:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 877518FC08; Sat, 8 Dec 2012 03:06:20 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qB836GkU003097; Sat, 8 Dec 2012 05:06:16 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qB836GkU003097 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qB836GCc003096; Sat, 8 Dec 2012 05:06:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 8 Dec 2012 05:06:16 +0200 From: Konstantin Belousov To: Baptiste Daroussin Subject: Re: nullfs changes MFC Message-ID: <20121208030616.GI3013@kib.kiev.ua> References: <20121208010109.GH3013@kib.kiev.ua> <20121208025816.GC88230@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K7aE7P/AKa2gsrZH" Content-Disposition: inline In-Reply-To: <20121208025816.GC88230@ithaqua.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: stable@freebsd.org, avg@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 03:06:21 -0000 --K7aE7P/AKa2gsrZH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 08, 2012 at 03:58:16AM +0100, Baptiste Daroussin wrote: > On Sat, Dec 08, 2012 at 03:01:09AM +0200, Konstantin Belousov wrote: =2E.. > > The merge is available at=20 > > http://people.freebsd.org/~kib/misc/nullfs_9.1.patch >=20 >=20 > Sorry I haven't checked the latest zfs related MFC, but for some time > there was an issue with nullfs improvements and zfs, will this mfc be > synchronize with the mfc of the related zfs fixes? Corresponding zfs fixes were already merged to stable/9, as I was told. Cc:ed Andrey to confirm it once more. --K7aE7P/AKa2gsrZH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQwq6nAAoJEJDCuSvBvK1BV3kQAKXDSmilNHMB4NLxhmmRDKMo raHSILsJXXJGqZc/CORWMnI1buEM9N1CHeRoLlpgbi08Mi6NyTF4zTPQGKlVihdr W/a9Z05xZjv5SF0TCHi5WZn6PvQGBSrwtfywVhMlI3Q9gsTWnsIRvbFENKRyzkro Y1EPLm712DW8AHXDiyxy0zucYptL+Ct3foBR0/stcgj/h5zGnwudQk9tM+Wl6jkN 0fk52FpIXoHlyc9+j2r5Xijx1kGMu4oZ6wed0wag2l91A2m8aw/cBkrNNnblNc5L BDmHLi5wT3kCNd0NBN06hN+XXNMurVDZUVjXL//7wr9JrG/tWgAfrOHA2/9TObHi AZAbFfqi+EflM55KT1yVMLRp9soR47wKKsYcGNumIaW+i4Y2qZL69dXu/83mGJXw Yc44L5or36gSzEAXh6IWFt+RyZucHpe6IRjt4u1HfiufoC7eAbDnZdLMLRFhDyyc I4aoLVxvKnpal4TiXIrFzChVXErIn81OtX3ACVCUZKO4h3H8+q53dTIDtiWXcByV G7JN+aIhFWvfpy0Oo2BeJ9ThGrKYd3p4ehJn3Okf8aWQrxdz72Pe/0BYzn9VWW97 vO3Et6fgdMd2pd6EM/VpIc+r3frg1T372E0LJE6pXTiJjN1fFQYkQF7BliCR/pmV ExNcm2VQwil1ljAPXx76 =aYn1 -----END PGP SIGNATURE----- --K7aE7P/AKa2gsrZH-- From owner-freebsd-fs@FreeBSD.ORG Sat Dec 8 10:35:56 2012 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 795EBA1D; Sat, 8 Dec 2012 10:35:56 +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 62AA48FC0C; Sat, 8 Dec 2012 10:35:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA21337; Sat, 08 Dec 2012 12:35:44 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ThHl2-000Fe2-6w; Sat, 08 Dec 2012 12:35:44 +0200 Message-ID: <50C317FE.8090609@FreeBSD.org> Date: Sat, 08 Dec 2012 12:35:42 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: nullfs changes MFC References: <20121208010109.GH3013@kib.kiev.ua> <20121208025816.GC88230@ithaqua.etoilebsd.net> <20121208030616.GI3013@kib.kiev.ua> In-Reply-To: <20121208030616.GI3013@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 10:35:56 -0000 on 08/12/2012 05:06 Konstantin Belousov said the following: > On Sat, Dec 08, 2012 at 03:58:16AM +0100, Baptiste Daroussin wrote: >> On Sat, Dec 08, 2012 at 03:01:09AM +0200, Konstantin Belousov wrote: > ... >>> The merge is available at >>> http://people.freebsd.org/~kib/misc/nullfs_9.1.patch >> >> >> Sorry I haven't checked the latest zfs related MFC, but for some time >> there was an issue with nullfs improvements and zfs, will this mfc be >> synchronize with the mfc of the related zfs fixes? > > Corresponding zfs fixes were already merged to stable/9, as I was told. > Cc:ed Andrey to confirm it once more. Yes, a while ago. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Dec 8 13:17:35 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D13965E8; Sat, 8 Dec 2012 13:17:35 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5F88FC0C; Sat, 8 Dec 2012 13:17:34 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id a14so619556eaa.13 for ; Sat, 08 Dec 2012 05:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=yWOijk5OYR/ZQx46T8PMNrGx5BjTvn8niGBeFuUDB40=; b=0JTaNckWjtkrT1X3VHTrh7sGDzDt4dpeKPiNrm3jrR3TbFJCM8DxkIydD6EWTMYMTW 6qwqCnqwt5kcjqyYMnsKpojz5Eh7bDsEbxs+nqx4FX17d92eJQdO69G02T7KBQKfIhFW 1UNpgYxKLNFbXMy3xwHuzpKyZs6iPOu5RPKuMyBGNZe39K1UlA9cDkKhra3TE2+2c4S8 Z++92aGeQdG9oPBCwyzcpcC7WTzQKK4S2BDSKRa2G7K5ABcitcQbs/7Pghj0HCWqLK8K shNRlvo4QBwOvemY0d7IiD1sx/9Y891IzP6rAwbrGrtuiNPKFCVQVdrCPLhv0GpcYonI zFbg== Received: by 10.14.0.133 with SMTP id 5mr28280955eeb.29.1354972648205; Sat, 08 Dec 2012 05:17:28 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id w3sm29533918eel.17.2012.12.08.05.17.27 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 08 Dec 2012 05:17:27 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 8 Dec 2012 14:17:25 +0100 From: Baptiste Daroussin To: Andriy Gapon Subject: Re: nullfs changes MFC Message-ID: <20121208131725.GE88230@ithaqua.etoilebsd.net> References: <20121208010109.GH3013@kib.kiev.ua> <20121208025816.GC88230@ithaqua.etoilebsd.net> <20121208030616.GI3013@kib.kiev.ua> <50C317FE.8090609@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JBi0ZxuS5uaEhkUZ" Content-Disposition: inline In-Reply-To: <50C317FE.8090609@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org, fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 13:17:35 -0000 --JBi0ZxuS5uaEhkUZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 08, 2012 at 12:35:42PM +0200, Andriy Gapon wrote: > on 08/12/2012 05:06 Konstantin Belousov said the following: > > On Sat, Dec 08, 2012 at 03:58:16AM +0100, Baptiste Daroussin wrote: > >> On Sat, Dec 08, 2012 at 03:01:09AM +0200, Konstantin Belousov wrote: > > ... > >>> The merge is available at=20 > >>> http://people.freebsd.org/~kib/misc/nullfs_9.1.patch > >> > >> > >> Sorry I haven't checked the latest zfs related MFC, but for some time > >> there was an issue with nullfs improvements and zfs, will this mfc be > >> synchronize with the mfc of the related zfs fixes? > >=20 > > Corresponding zfs fixes were already merged to stable/9, as I was told. > > Cc:ed Andrey to confirm it once more. >=20 > Yes, a while ago. >=20 Perfect thank you both! And sorry for noise :) regards, Bapt --JBi0ZxuS5uaEhkUZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDDPeUACgkQ8kTtMUmk6EwnwwCgoOfUI2S5nfyIHOa2OrHPiL85 nwYAnAtam3YwXXGFC3AyTxVXlWweK08z =2bf6 -----END PGP SIGNATURE----- --JBi0ZxuS5uaEhkUZ-- From owner-freebsd-fs@FreeBSD.ORG Sat Dec 8 15:27:51 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91BD9BB3; Sat, 8 Dec 2012 15:27:51 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1418FC13; Sat, 8 Dec 2012 15:27:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qB8FRp4c018334; Sat, 8 Dec 2012 15:27:51 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qB8FRpTk018330; Sat, 8 Dec 2012 15:27:51 GMT (envelope-from eadler) Date: Sat, 8 Dec 2012 15:27:51 GMT Message-Id: <201212081527.qB8FRpTk018330@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: eadler@FreeBSD.org Subject: Re: kern/174279: [ufs] UFS2-SU+J journal and filesystem corruption X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 15:27:51 -0000 Old Synopsis: UFS2-SU+J journal and filesystem corruption New Synopsis: [ufs] UFS2-SU+J journal and filesystem corruption Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: eadler Responsible-Changed-When: Sat Dec 8 15:27:29 UTC 2012 Responsible-Changed-Why: fix synopsis and assign http://www.freebsd.org/cgi/query-pr.cgi?pr=174279 From owner-freebsd-fs@FreeBSD.ORG Sat Dec 8 21:12:32 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0D93F44; Sat, 8 Dec 2012 21:12:32 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 824BF8FC13; Sat, 8 Dec 2012 21:12:32 +0000 (UTC) Received: from [10.236.164.166] (160.sub-174-234-0.myvzw.com [174.234.0.160]) by elvis.mu.org (Postfix) with ESMTPSA id DFF081A3C36; Sat, 8 Dec 2012 13:12:25 -0800 (PST) References: <20121208010109.GH3013@kib.kiev.ua> Mime-Version: 1.0 (1.0) In-Reply-To: <20121208010109.GH3013@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A523) From: Alfred Perlstein Subject: Re: nullfs changes MFC Date: Sat, 8 Dec 2012 13:12:19 -0800 To: Konstantin Belousov Cc: "stable@freebsd.org" , "fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 21:12:32 -0000 By combining vop_settext/unset/get into a single call with parameters "op" a= nd &out (for gettext) you can reduce 3 new vops into a single vop.=20 The same can be done for write count vops.=20 This will allow you to preserve kbi by reducing the vop additions to 2.=20 Sent from my iPhone On Dec 7, 2012, at 5:01 PM, Konstantin Belousov wrote:= > Hi, > I am going to merge latest batch of the nullfs improvements into > stable/9. This will bring up significant performance enchancements due > to use of the shared locks for lookups if the lower layer supports it, > much better caching on the nullfs layer, and proper handling of the text > segments on the nullfs. Also, it should improve the error recovery and > some corner cases with locking. >=20 > Unfortunately, the merge would break KBI for VFS, since it needs 5 new > VOP slots, and only three spares are left. We already are very liberal > with the VFS KBI, so I do not feel that the merge is not acceptable, due > to the benefits it brings to the nullfs. >=20 > The merge is available at=20 > http://people.freebsd.org/~kib/misc/nullfs_9.1.patch