From owner-freebsd-fs@FreeBSD.ORG Sun Jun 3 04:19:41 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 AF8BD106566B for ; Sun, 3 Jun 2012 04:19:41 +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 9269E8FC16 for ; Sun, 3 Jun 2012 04:19:41 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sb2Hz-0001Jv-JD; Sun, 03 Jun 2012 04:19:39 +0000 Date: Sat, 02 Jun 2012 21:19:38 -0700 Message-ID: From: Randy Bush To: kpneal@pobox.com In-Reply-To: <20120601033945.GA37797@neutralgood.org> References: <20120601033945.GA37797@neutralgood.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD FS Subject: Re: hptrr disk labeling X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 04:19:41 -0000 >> i have an hptrr controller with 12-16 2tb satas on it. a picture >> before i started cleaning up some disk failures. >> >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> mirror ONLINE 0 0 0 >> label/m00-d01 ONLINE 0 0 0 >> label/m00-d00 ONLINE 0 0 0 >> mirror ONLINE 0 0 0 >> label/m01-d00 ONLINE 0 0 0 >> label/m01-d01 ONLINE 0 0 0 >> >> the reason i used glabels was because when the system boots or the >> controller rescans, it assigns da0 to the first drive it finds alive on >> the controller, da1 to the second, etc. >> >> this means that drive addition or removal changes the daX numbering. >> >> so the labels are so that zfs can find its ass when assembling the >> array. > > Can you use GPT for partitioning? Put a single partition on each disk and > set the GPT label (which is not the glabel). See gpart's add and modify > subcommands. > > NAME STATE READ WRITE CKSUM > gs1p ONLINE 0 0 0 > mirror ONLINE 0 0 0 > gpt/CONST_2-9XE02KPK-zfs ONLINE 0 0 0 > gpt/SAVVIO-6XQ10F80-zfs ONLINE 0 0 0 > gpt/SAVVIO-6XQ103C7-zfs ONLINE 0 0 0 ok. sure i could do that. but what's the win? randy From owner-freebsd-fs@FreeBSD.ORG Sun Jun 3 06:40:21 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24662106566C for ; Sun, 3 Jun 2012 06:40:21 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EA0CA8FC15 for ; Sun, 3 Jun 2012 06:40:20 +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 q536eKsj004226 for ; Sun, 3 Jun 2012 06:40:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q536eKqE004225; Sun, 3 Jun 2012 06:40:20 GMT (envelope-from gnats) Date: Sun, 3 Jun 2012 06:40:20 GMT Message-Id: <201206030640.q536eKqE004225@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Jukka A. Ukkonen" Cc: Subject: Re: kern/167612: [portalfs] The portal file system gets stuck inside portal_open(). ("1 extra fds") X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Jukka A. Ukkonen" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 06:40:21 -0000 The following reply was made to PR kern/167612; it has been noted by GNATS. From: "Jukka A. Ukkonen" To: bug-followup@FreeBSD.org, jau@iki.fi Cc: Subject: Re: kern/167612: [portalfs] The portal file system gets stuck inside portal_open(). ("1 extra fds") Date: Sun, 03 Jun 2012 09:25:40 +0300 Now the patch has been tested to work on... - AMD64 - Sparc64 From owner-freebsd-fs@FreeBSD.ORG Sun Jun 3 12:16:26 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CA251065672 for ; Sun, 3 Jun 2012 12:16:26 +0000 (UTC) (envelope-from jjuanino@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 D9B898FC1A for ; Sun, 3 Jun 2012 12:16:25 +0000 (UTC) Received: by bkvi18 with SMTP id i18so3797970bkv.13 for ; Sun, 03 Jun 2012 05:16:24 -0700 (PDT) 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=NhurmuukDvStw+YYJsYJWX32HzlnfG6wfEhUH+OCSBc=; b=v92ERYgNGsIprCiulnMJHJyaBCGyIeYfg+i/rTVDqW/l9EAyhADi6Q6xGTx3a1Htm3 GOaeoJ+b5v9OutCXmCMQnPcjxlypt33lf8DPES3BqZU48GAFDlBR8ViGztKQ0StoGH4M h8bJR8Vf2HTgXcUOnTU9WUjdfACd7o1oMFzAZBEIQinkmTg1i35FMxzO1c8k6FVSqNKv OtNy055UVlLoVMTdpfiTJfRtSgv6ejJLX9GYtoH+OtMijjOyLFxduicgGmPEVw5ot9el HqsG1S/mPfYTRNIVVfoMqjfp9Lpua5+vqH52A8YV/QHJ502PiRf6TZoDI6hswdwszdV4 d3bg== MIME-Version: 1.0 Received: by 10.204.156.150 with SMTP id x22mr4595020bkw.55.1338725784767; Sun, 03 Jun 2012 05:16:24 -0700 (PDT) Received: by 10.205.114.140 with HTTP; Sun, 3 Jun 2012 05:16:24 -0700 (PDT) Date: Sun, 3 Jun 2012 14:16:24 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Garc=EDa_Juanino?= To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: "panic: snapblkfree: inconsistent block type" on FreeBSD 9.0 RELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 12:16:26 -0000 Hi, I am getting a lot of "snapblkfree: inconsistent block type" panics on my FreeBSD 9.0-RELEASE. My file systems have not any inconsistencies, I am checked them with fsck. But I have some snapshots with softupdate inconsistencies (fsck_ffs /path/to/snapshot), and I suspect that may be the cause of the panics. I have several questions: 1- Snapshots with fsck inconsistencies might be the cause of my panics? 2- Should I remove any of such "corrupt" snapshots? If someone is interested, I can provide a full backtrace. Kernel is GENERIC, with no tweaks. File system are been created with normal "newfs -U". No special setting is using. Any advice is wellcome Best regards From owner-freebsd-fs@FreeBSD.ORG Sun Jun 3 13:36:12 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05C0D106566C for ; Sun, 3 Jun 2012 13:36:12 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79BEB8FC08 for ; Sun, 3 Jun 2012 13:36:11 +0000 (UTC) Received: by lbon10 with SMTP id n10so3288246lbo.13 for ; Sun, 03 Jun 2012 06:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=wrAw++9S2fK/l4PXzee3bwJzzNE9zjTOy0fHOPi1Jps=; b=rksS/4OXO8jIPm4l9g4SaWkPYOK6fY2KvnjUq62dz2UHqE+5flUX09digAhtwKPqkN NehtInIKsTT0TQo0wC4WnVmwTCi+wftDRptHULqEJeCH+5LcLqi8+3JObymEawoqLQ8k xL3al29oyC0Rv9lUJCFKXGF6TyiiLR2cR3GRCMN7WuMvy7dLFSuqYVCsZ/sPDi0vLbZ3 7C52w9ATWH30etNF6e27H6lOoMiu+pubMJ76B9kSA7CIPTcORQymMUsrDoaCfDHtjIQm IxLkKYG4ST868ewjTSsg45nNPqC0aRu9sZfCcMh8RUzKnjDps9SKq4z3AI8f0jaiBeRt bgVw== Received: by 10.112.40.33 with SMTP id u1mr4634660lbk.28.1338730570130; Sun, 03 Jun 2012 06:36:10 -0700 (PDT) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id h6sm4805143lbl.13.2012.06.03.06.36.08 (version=SSLv3 cipher=OTHER); Sun, 03 Jun 2012 06:36:08 -0700 (PDT) Date: Sun, 3 Jun 2012 16:36:04 +0300 From: Gleb Kurtsou To: Allen Landsidel Message-ID: <20120603133604.GB1225@reks> References: <201205311940.q4VJe2nl085865@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201205311940.q4VJe2nl085865@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/160790: [fusefs] [panic] VPUTX: negative ref count with FUSE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 13:36:12 -0000 On (31/05/2012 19:40), Allen Landsidel wrote: > The following reply was made to PR kern/160790; it has been noted by GNATS. > > From: Allen Landsidel > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/160790: [fusefs] [panic] VPUTX: negative ref count with > FUSE > Date: Thu, 31 May 2012 15:30:47 -0400 > > This bug continues to occur on a new system, different 'hardware'. The > system is running MooseFS and was migrated some time ago to an VMWare > ESX 5 VM, 64bit. There is an "improved" FUSE version produced during GSoC last year. You may be lucky with it. gnn@ continued working on it afterwards. https://github.com/glk/fuse-freebsd https://github.com/glk/fuse-freebsd-ports From owner-freebsd-fs@FreeBSD.ORG Sun Jun 3 18:08:09 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 66DEF1065670 for ; Sun, 3 Jun 2012 18:08:09 +0000 (UTC) (envelope-from jjuanino@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 E742D8FC0A for ; Sun, 3 Jun 2012 18:08:08 +0000 (UTC) Received: by bkvi18 with SMTP id i18so3949645bkv.13 for ; Sun, 03 Jun 2012 11:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=KxTtLsWR/B1m2cgeyxrBPVD1tJHUgbymXc6Sv4F9tDg=; b=n+Ho6pA9CD+aZU3ZqDJT+QqRewiUkixt/D+Nq2m12+JT8SeAs911/T61OTV/aoLiUF wKdqXNuYThUiP9eBPRpLOTIiIYeKAmLZPi6DAbj8QXLr9iZtkaFD0WtTxFVi8/x/+8Xu MSEm0bpMJ4vbVuxEySDEO4j32dH9HeCM5OdrkMRRegysoeFmfzZiZpaC78ldElDK+ZnR 1wppIMOpnr23SB7wEtH1eTsy+8rQbdCmOpmc7qHEfu6eaDlb3vw/Dqkianmo/irSG2Gd k/F/kd8aOdxDsfXnPDXG/CyQtt1P3ZvYv/sdCWbxwpW8GuPm+TUJ72RzNE1bGpn5+2h5 iY3w== MIME-Version: 1.0 Received: by 10.204.154.138 with SMTP id o10mr4927384bkw.34.1338746887637; Sun, 03 Jun 2012 11:08:07 -0700 (PDT) Received: by 10.205.114.140 with HTTP; Sun, 3 Jun 2012 11:08:07 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Jun 2012 20:08:07 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Garc=EDa_Juanino?= To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: "panic: snapblkfree: inconsistent block type" on FreeBSD 9.0 RELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 18:08:09 -0000 On 3 June 2012 14:16, Jos=E9 Garc=EDa Juanino wrote: > Hi, > > I am getting a lot of "snapblkfree: inconsistent block type" panics on > my FreeBSD 9.0-RELEASE. My file systems have not any inconsistencies, > I am checked them with fsck. But I have some snapshots with softupdate > inconsistencies =A0(fsck_ffs /path/to/snapshot), and I suspect that may > be the cause of the panics. I have several questions: > > 1- Snapshots with fsck inconsistencies might be the cause of my panics? > 2- Should I remove any of such "corrupt" snapshots? > > If someone is interested, I can provide a full backtrace. Kernel is > GENERIC, with no tweaks. File system are been created with normal > "newfs -U". No special setting is using. I have three full core dumps: http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.1 http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.2 http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.3 The relevant code is, in the three examples: #3 0xffffffff80a40124 in ffs_snapblkfree (fs=3D0xfffffe0002deb000, devvp=3DVariable "devvp" is not available. ) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1799 Regards From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 09:33:13 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C1EF106566B; Mon, 4 Jun 2012 09:33:13 +0000 (UTC) (envelope-from joh.hendriks@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 D4AB18FC12; Mon, 4 Jun 2012 09:33:12 +0000 (UTC) Received: by eeke49 with SMTP id e49so1578940eek.13 for ; Mon, 04 Jun 2012 02:33:11 -0700 (PDT) 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=rgrowigx0yd60vW5NegN9MG6BIAWUegl5n3aiwJwIkE=; b=TDV7kdBG4pUzbWuJdVU+tCu1lPjo+B/lfUYvvwO4sa8kqUsMDf4r5LlAAItH+cU3BB wVODv7KIiZNHxN/Nxb+pNy3HZPVYWClCpDCvAzuZ08UWy/0TFGATR3Dm6VAYDy1b44TW +fr4H2YHubkWjl7Dg7I9forfYelyAnWo5xRiB+vrKAxz6EEns35vB8ZA+ro+Rv+t9ShX nrsLbcrA/iOG5RTZo1F+DTtcni0dGawGYT2aDQc605VkUVeVbJt0QAh2mQMlrJ3BXOPN /5sPFe+pOZEMFvsxiUpcrHd0p2OI3LEA0Pac1gUen2ODir+n2yii/WRzz5o60GNRCvvH +XjQ== Received: by 10.14.99.206 with SMTP id x54mr5005480eef.94.1338802391643; Mon, 04 Jun 2012 02:33:11 -0700 (PDT) Received: from [192.168.50.111] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id t3sm35113474eeb.15.2012.06.04.02.33.08 (version=SSLv3 cipher=OTHER); Mon, 04 Jun 2012 02:33:09 -0700 (PDT) Message-ID: <4FCC80D3.8000605@gmail.com> Date: Mon, 04 Jun 2012 11:33:07 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Martin Matuska References: <4FC366D0.6030206@FreeBSD.org> In-Reply-To: <4FC366D0.6030206@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: [CFT][PREVIEW] ZFS new SPA X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 09:33:13 -0000 Martin Matuska schreef: > Hello all, > > I have ported the ZFS features support (SPA version 5000) from Illumos > to FreeBSD-current. > What is still missing is boot support - needs to be implemented. > > Patch against CURRENT: > http://www.vx.sk/download/patches/freebsd/zfs/head-zfs-features.patch > > Amd64 ISO images for testing (bootable, work well in VirtualBox): > Basic: http://www.vx.sk/download/ISO-images/mfsbsd/head-zfs-features.iso > (86MB) > With full installworld: > http://www.vx.sk/download/ISO-images/mfsbsd/head-se-zfs-features.iso (239MB) > > TODO: boot support (check feature availability from ZFS boot code) > > References: > https://hg.openindiana.org/upstream/illumos/illumos-gate/rev/2889e2596bd6 > https://hg.openindiana.org/upstream/illumos/illumos-gate/rev/1949b688d5fb > hello. I saw this announcement, and decided to try the patch. I just did a csup today and patched the tree. # cd /usr/src # patch < /root/patch/head-zfs-features.patch then after doing a make cleanworld i get the following. # make cleanworld "/usr/src/Makefile", line 242: warning: duplicate script for target "clean" ignored "/usr/src/Makefile", line 242: warning: duplicate script for target "cleandepend" ignored "/usr/src/Makefile", line 242: warning: duplicate script for target "distribute" ignored "/usr/src/Makefile", line 242: warning: duplicate script for target "lint" ignored "/usr/src/Makefile", line 242: warning: duplicate script for target "obj" ignored "/usr/src/Makefile", line 242: warning: duplicate script for target "objlink" ignored "/usr/src/Makefile", line 242: warning: duplicate script for target "tags" ignored "/usr/src/Makefile", line 242: warning: duplicate script for target "files" ignored "/usr/src/Makefile", line 242: warning: duplicate script for target "includes" ignored rm -rf /usr/obj/usr/src/* chflags -R 0 /usr/obj/usr/src rm -rf /usr/obj/usr/src/* # make buildworld starts the with the same messages, but fails. ===> cddl/usr.sbin/lockstat (cleandir) rm -f lockstat lockstat.o sym.o rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> cddl/usr.sbin/zdb (cleandir) rm -f zdb zdb.o zdb_il.o zdb.8.gz zdb.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> cddl/usr.sbin/zhack (cleandir) cd: /usr/src/cddl/usr.sbin/zhack: No such file or directory *** [cleandir] Error code 2 Stop in /usr/src/cddl/usr.sbin. *** [cleandir] Error code 1 Stop in /usr/src/cddl. *** [cddl.cleandir__D] Error code 1 Stop in /usr/src. *** [_cleanobj] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. Here is my make.conf CPUTYPE?=nocona #CLANG CC=clang CXX=clang++ CPP=clang-cpp KERNCONF=KRNL BATCH_DELETE_OLD_FILES= yes CUPS_OVERWRITE_BASE=yes WITHOUT_X11=yes WITHOUT_GUI=yes #### END MAKE.CONF FILE ### regards. Johan Hendriks From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 09:41:06 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 97A7A1065670; Mon, 4 Jun 2012 09:41:06 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3A5608FC12; Mon, 4 Jun 2012 09:41:06 +0000 (UTC) Received: by yhgm50 with SMTP id m50so3217626yhg.13 for ; Mon, 04 Jun 2012 02:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FISo3AGwFxj1+0ZriuSUD9BjWB21hHxep5XWGE86f+c=; b=Z1AohZlsqM4Y3Paf3N7MT6Dp/k8orMKYW2mET8VSI28qszFqBtYritSFToSn4lQAIE qhw8/DrIq4g0s33jJ3S+uzaUr/MJLrJTloERnAolujyW932LZRNK999TOiAiXVcZLSxC 0qFNsTQY3ZWXGFlEUDgo/V9PhzQRF7Ak6hQzQ/Z0v5QTXJb1mYxJmTjQs0R6WquW7Yjh ymUJK9FF71gSkjxtaIVFIo5LFzSlZ1Vj3vrgQKOn0ZJBnC2S5ptKftpCPZ93rUbCHt+h oKI1rbDevbkSH7u4Dc2UbLUPtay9cludTi30np9hqIiDItEDxlE3Z695i26YBM7TLLGj FosA== MIME-Version: 1.0 Received: by 10.50.161.234 with SMTP id xv10mr718997igb.66.1338802865517; Mon, 04 Jun 2012 02:41:05 -0700 (PDT) Received: by 10.231.244.8 with HTTP; Mon, 4 Jun 2012 02:41:05 -0700 (PDT) In-Reply-To: <4FCC80D3.8000605@gmail.com> References: <4FC366D0.6030206@FreeBSD.org> <4FCC80D3.8000605@gmail.com> Date: Mon, 4 Jun 2012 17:41:05 +0800 Message-ID: From: Marcelo Araujo To: Johan Hendriks Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: [CFT][PREVIEW] ZFS new SPA X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 09:41:06 -0000 Dear Johan, As you don't have the zhack directory, you must create it before to apply the patch. *cd: /usr/src/cddl/usr.sbin/zhack: No such file or directory* I'm using the latest version of FreeBSD with the patch, and it works pretty well. Best Regards, - Araujo 2012/6/4 Johan Hendriks > Martin Matuska schreef: > > Hello all, >> >> I have ported the ZFS features support (SPA version 5000) from Illumos >> to FreeBSD-current. >> What is still missing is boot support - needs to be implemented. >> >> Patch against CURRENT: >> http://www.vx.sk/download/**patches/freebsd/zfs/head-zfs-**features.patch >> >> Amd64 ISO images for testing (bootable, work well in VirtualBox): >> Basic: http://www.vx.sk/download/ISO-**images/mfsbsd/head-zfs-** >> features.iso >> (86MB) >> With full installworld: >> http://www.vx.sk/download/ISO-**images/mfsbsd/head-se-zfs-**features.iso(239MB) >> >> TODO: boot support (check feature availability from ZFS boot code) >> >> References: >> https://hg.openindiana.org/**upstream/illumos/illumos-gate/** >> rev/2889e2596bd6 >> https://hg.openindiana.org/**upstream/illumos/illumos-gate/** >> rev/1949b688d5fb >> >> hello. > > I saw this announcement, and decided to try the patch. > I just did a csup today and patched the tree. > > # cd /usr/src > # patch < /root/patch/head-zfs-features.**patch > > then after doing a make cleanworld i get the following. > > # make cleanworld > "/usr/src/Makefile", line 242: warning: duplicate script for target > "clean" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for target > "cleandepend" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for target > "distribute" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for target "lint" > ignored > "/usr/src/Makefile", line 242: warning: duplicate script for target "obj" > ignored > "/usr/src/Makefile", line 242: warning: duplicate script for target > "objlink" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for target "tags" > ignored > "/usr/src/Makefile", line 242: warning: duplicate script for target > "files" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for target > "includes" ignored > rm -rf /usr/obj/usr/src/* > chflags -R 0 /usr/obj/usr/src > rm -rf /usr/obj/usr/src/* > > # make buildworld starts the with the same messages, but fails. > > ===> cddl/usr.sbin/lockstat (cleandir) > rm -f lockstat lockstat.o sym.o > rm -f .depend GPATH GRTAGS GSYMS GTAGS > ===> cddl/usr.sbin/zdb (cleandir) > rm -f zdb zdb.o zdb_il.o zdb.8.gz zdb.8.cat.gz > rm -f .depend GPATH GRTAGS GSYMS GTAGS > ===> cddl/usr.sbin/zhack (cleandir) > cd: /usr/src/cddl/usr.sbin/zhack: No such file or directory > *** [cleandir] Error code 2 > > Stop in /usr/src/cddl/usr.sbin. > *** [cleandir] Error code 1 > > Stop in /usr/src/cddl. > *** [cddl.cleandir__D] Error code 1 > > Stop in /usr/src. > *** [_cleanobj] Error code 1 > > Stop in /usr/src. > *** [buildworld] Error code 1 > > Stop in /usr/src. > > Here is my make.conf > > CPUTYPE?=nocona > > #CLANG > CC=clang > CXX=clang++ > CPP=clang-cpp > > KERNCONF=KRNL > > BATCH_DELETE_OLD_FILES= yes > CUPS_OVERWRITE_BASE=yes > > WITHOUT_X11=yes > WITHOUT_GUI=yes > > #### END MAKE.CONF FILE ### > > regards. > Johan Hendriks > > ______________________________**_________________ > 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 > " > -- Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 11:07:36 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 818AD10656A5 for ; Mon, 4 Jun 2012 11:07:36 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6A3088FC1F for ; Mon, 4 Jun 2012 11:07:36 +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 q54B7amM017408 for ; Mon, 4 Jun 2012 11:07:36 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q54B7ZOD017406 for freebsd-fs@FreeBSD.org; Mon, 4 Jun 2012 11:07:35 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Jun 2012 11:07:35 GMT Message-Id: <201206041107.q54B7ZOD017406@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 11:07:36 -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/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/167905 fs [zfs] zfs set canmount=on UNMOUNTS dataset o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167066 fs [zfs] ZVOLs not appearing in /dev/zvol o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166566 fs [zfs] zfs split renders 2 disk (MBR based) mirror unbo 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/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 276 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 11:11:46 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E1081065676; Mon, 4 Jun 2012 11:11:46 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id D10A68FC0A; Mon, 4 Jun 2012 11:11:45 +0000 (UTC) Received: by eaac13 with SMTP id c13so865669eaa.13 for ; Mon, 04 Jun 2012 04:11:44 -0700 (PDT) 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; bh=Ts+O4fKUCg1sOpaDoEAx+rnDSBr0WmKV4/0UanIoFJY=; b=08sIr+tuuLNYyUizhXyDkSQB9WSOmo6X9srL6qU/N06/jU8j/ml+K98b1RzmmwG5qX 8bDIV4H2UKjrD79vZlnQX4FflrDWzwOCcMLB65eY5bqz3g+Ks8wSm8nLBuZajISqbvy8 4H0/vCPyRBvkhuxr0sbMWgb8wspfMj/HbJIgKAd0Ln62MnVFWs3zJd8EdUW+nnzbklvU OGYEjiR7k4yvgnIGMa8qVSXcwo6oQmAQ8CmhvhKpgR15Pdo+Oafj+oCK/sxr2ixj41M1 1flByuplLCdImmR01W+J9EDY1LtwCMh4VzdoW9JUvRuqYEOKB1bYCigjqPYRsb/Z9XhE KBmw== Received: by 10.14.185.144 with SMTP id u16mr5075833eem.232.1338808304644; Mon, 04 Jun 2012 04:11:44 -0700 (PDT) Received: from [192.168.50.111] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id a16sm36108908eeg.0.2012.06.04.04.11.42 (version=SSLv3 cipher=OTHER); Mon, 04 Jun 2012 04:11:43 -0700 (PDT) Message-ID: <4FCC97ED.1010807@gmail.com> Date: Mon, 04 Jun 2012 13:11:41 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: araujo@FreeBSD.org References: <4FC366D0.6030206@FreeBSD.org> <4FCC80D3.8000605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: [CFT][PREVIEW] ZFS new SPA X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 11:11:46 -0000 Marcelo Araujo schreef: > Dear Johan, > > As you don't have the zhack directory, you must create it before to > apply the patch. > > *cd: /usr/src/cddl/usr.sbin/zhack: No such file or directory* > > I'm using the latest version of FreeBSD with the patch, and it works > pretty well. > > > > Best Regards, > - Araujo > > > 2012/6/4 Johan Hendriks > > > Martin Matuska schreef: > > Hello all, > > I have ported the ZFS features support (SPA version 5000) from > Illumos > to FreeBSD-current. > What is still missing is boot support - needs to be implemented. > > Patch against CURRENT: > http://www.vx.sk/download/patches/freebsd/zfs/head-zfs-features.patch > > Amd64 ISO images for testing (bootable, work well in VirtualBox): > Basic: > http://www.vx.sk/download/ISO-images/mfsbsd/head-zfs-features.iso > (86MB) > With full installworld: > http://www.vx.sk/download/ISO-images/mfsbsd/head-se-zfs-features.iso > (239MB) > > TODO: boot support (check feature availability from ZFS boot code) > > References: > https://hg.openindiana.org/upstream/illumos/illumos-gate/rev/2889e2596bd6 > https://hg.openindiana.org/upstream/illumos/illumos-gate/rev/1949b688d5fb > > hello. > > I saw this announcement, and decided to try the patch. > I just did a csup today and patched the tree. > > # cd /usr/src > # patch < /root/patch/head-zfs-features.patch > > then after doing a make cleanworld i get the following. > > # make cleanworld > "/usr/src/Makefile", line 242: warning: duplicate script for > target "clean" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for > target "cleandepend" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for > target "distribute" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for > target "lint" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for > target "obj" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for > target "objlink" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for > target "tags" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for > target "files" ignored > "/usr/src/Makefile", line 242: warning: duplicate script for > target "includes" ignored > rm -rf /usr/obj/usr/src/* > chflags -R 0 /usr/obj/usr/src > rm -rf /usr/obj/usr/src/* > > # make buildworld starts the with the same messages, but fails. > > ===> cddl/usr.sbin/lockstat (cleandir) > rm -f lockstat lockstat.o sym.o > rm -f .depend GPATH GRTAGS GSYMS GTAGS > ===> cddl/usr.sbin/zdb (cleandir) > rm -f zdb zdb.o zdb_il.o zdb.8.gz zdb.8.cat.gz > rm -f .depend GPATH GRTAGS GSYMS GTAGS > ===> cddl/usr.sbin/zhack (cleandir) > cd: /usr/src/cddl/usr.sbin/zhack: No such file or directory > *** [cleandir] Error code 2 > > Stop in /usr/src/cddl/usr.sbin. > *** [cleandir] Error code 1 > > Stop in /usr/src/cddl. > *** [cddl.cleandir__D] Error code 1 > > Stop in /usr/src. > *** [_cleanobj] Error code 1 > > Stop in /usr/src. > *** [buildworld] Error code 1 > > Stop in /usr/src. > > Here is my make.conf > > CPUTYPE?=nocona > > #CLANG > CC=clang > CXX=clang++ > CPP=clang-cpp > > KERNCONF=KRNL > > BATCH_DELETE_OLD_FILES= yes > CUPS_OVERWRITE_BASE=yes > > WITHOUT_X11=yes > WITHOUT_GUI=yes > > #### END MAKE.CONF FILE ### > > regards. > Johan Hendriks > > _______________________________________________ > 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 > " > > > > > -- > Marcelo Araujo > araujo@FreeBSD.org Well i did not get the duplicte script errors anymore, but the build world did not succeed the error is /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:550:1: error: redefinition of 'fnvlist_alloc' fnvlist_alloc(void) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:52:1: note: previous definition is here fnvlist_alloc(void) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:558:1: error: redefinition of 'fnvlist_free' fnvlist_free(nvlist_t *nvl) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:60:1: note: previous definition is here fnvlist_free(nvlist_t *nvl) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:564:1: error: redefinition of 'fnvlist_size' fnvlist_size(nvlist_t *nvl) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:66:1: note: previous definition is here fnvlist_size(nvlist_t *nvl) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:576:1: error: redefinition of 'fnvlist_pack' fnvlist_pack(nvlist_t *nvl, size_t *sizep) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:78:1: note: previous definition is here fnvlist_pack(nvlist_t *nvl, size_t *sizep) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:586:1: error: redefinition of 'fnvlist_pack_free' fnvlist_pack_free(char *pack, size_t size) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:88:1: note: previous definition is here fnvlist_pack_free(char *pack, size_t size) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:596:1: error: redefinition of 'fnvlist_unpack' fnvlist_unpack(char *buf, size_t buflen) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:98:1: note: previous definition is here fnvlist_unpack(char *buf, size_t buflen) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:604:1: error: redefinition of 'fnvlist_dup' fnvlist_dup(nvlist_t *nvl) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:106:1: note: previous definition is here fnvlist_dup(nvlist_t *nvl) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:612:1: error: redefinition of 'fnvlist_merge' fnvlist_merge(nvlist_t *dst, nvlist_t *src) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:114:1: note: previous definition is here fnvlist_merge(nvlist_t *dst, nvlist_t *src) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:618:1: error: redefinition of 'fnvlist_add_boolean' fnvlist_add_boolean(nvlist_t *nvl, const char *name) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:120:1: note: previous definition is here fnvlist_add_boolean(nvlist_t *nvl, const char *name) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:624:1: error: redefinition of 'fnvlist_add_boolean_value' fnvlist_add_boolean_value(nvlist_t *nvl, const char *name, boolean_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:126:1: note: previous definition is here fnvlist_add_boolean_value(nvlist_t *nvl, const char *name, boolean_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:630:1: error: redefinition of 'fnvlist_add_byte' fnvlist_add_byte(nvlist_t *nvl, const char *name, uchar_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:132:1: note: previous definition is here fnvlist_add_byte(nvlist_t *nvl, const char *name, uchar_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:636:1: error: redefinition of 'fnvlist_add_int8' fnvlist_add_int8(nvlist_t *nvl, const char *name, int8_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:138:1: note: previous definition is here fnvlist_add_int8(nvlist_t *nvl, const char *name, int8_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:642:1: error: redefinition of 'fnvlist_add_uint8' fnvlist_add_uint8(nvlist_t *nvl, const char *name, uint8_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:144:1: note: previous definition is here fnvlist_add_uint8(nvlist_t *nvl, const char *name, uint8_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:648:1: error: redefinition of 'fnvlist_add_int16' fnvlist_add_int16(nvlist_t *nvl, const char *name, int16_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:150:1: note: previous definition is here fnvlist_add_int16(nvlist_t *nvl, const char *name, int16_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:654:1: error: redefinition of 'fnvlist_add_uint16' fnvlist_add_uint16(nvlist_t *nvl, const char *name, uint16_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:156:1: note: previous definition is here fnvlist_add_uint16(nvlist_t *nvl, const char *name, uint16_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:660:1: error: redefinition of 'fnvlist_add_int32' fnvlist_add_int32(nvlist_t *nvl, const char *name, int32_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:162:1: note: previous definition is here fnvlist_add_int32(nvlist_t *nvl, const char *name, int32_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:666:1: error: redefinition of 'fnvlist_add_uint32' fnvlist_add_uint32(nvlist_t *nvl, const char *name, uint32_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:168:1: note: previous definition is here fnvlist_add_uint32(nvlist_t *nvl, const char *name, uint32_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:672:1: error: redefinition of 'fnvlist_add_int64' fnvlist_add_int64(nvlist_t *nvl, const char *name, int64_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:174:1: note: previous definition is here fnvlist_add_int64(nvlist_t *nvl, const char *name, int64_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:678:1: error: redefinition of 'fnvlist_add_uint64' fnvlist_add_uint64(nvlist_t *nvl, const char *name, uint64_t val) ^ /usr/src/cddl/lib/libnvpair/../../../sys/cddl/contrib/opensolaris/common/nvpair/fnvpair.c:180:1: note: previous definition is here fnvlist_add_uint64(nvlist_t *nvl, const char *name, uint64_t val) ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** [fnvpair.o] Error code 1 Stop in /usr/src/cddl/lib/libnvpair. *** [all] Error code 1 Stop in /usr/src/cddl/lib. *** [cddl/lib__L] Error code 1 Stop in /usr/src. *** [libraries] Error code 1 Stop in /usr/src. *** [_libraries] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. BTW i am using clang, maybe that is the culprit? regards Johan Hendriks From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 11:33: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 CD9D51065670 for ; Mon, 4 Jun 2012 11:33:20 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8428C8FC0A for ; Mon, 4 Jun 2012 11:33:19 +0000 (UTC) Received: by yenl8 with SMTP id l8so3425076yen.13 for ; Mon, 04 Jun 2012 04:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MhuAgx31Ir6F7pvuit3bqq8F08Fh0GwIsEU5ioI2zsU=; b=CVzsedmbTKVo+zIFc79kbrOaOfWQC5ABWEWqnRaSuWpsv39gW4t0RVC6RmudeDxUJu syMTpboLTnBYhm+7t4Onq2K+Rl00EUKkvXERSbolK/4+4sLa2ezBKnuSv8wMwYqLcUPy wruOy+/OdgVSpupTASWBUI+jrHFXP3w8QgtIXntHA0ps/hAlOT6MFk7T/lYc0WXE1PJy CLgB/5DhAEeC1sEIRZmfsZ6E1ViBpBB2e9TZQmModueJDXgFjNPJTJk9ZGsugcx/AHz6 OvPRv5GnFGr+1TBnfK9AN/kZ+on0j+FQxXXfiFNJ08op7MYfixG8ZIOYXBNcMv+Wz4Vm 0Hlw== MIME-Version: 1.0 Received: by 10.50.161.234 with SMTP id xv10mr984889igb.66.1338809598955; Mon, 04 Jun 2012 04:33:18 -0700 (PDT) Received: by 10.231.244.8 with HTTP; Mon, 4 Jun 2012 04:33:18 -0700 (PDT) In-Reply-To: <4FCC97ED.1010807@gmail.com> References: <4FC366D0.6030206@FreeBSD.org> <4FCC80D3.8000605@gmail.com> <4FCC97ED.1010807@gmail.com> Date: Mon, 4 Jun 2012 19:33:18 +0800 Message-ID: From: Marcelo Araujo To: Johan Hendriks Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: [CFT][PREVIEW] ZFS new SPA X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 11:33:20 -0000 Hey Johan, 2012/6/4 Johan Hendriks > Marcelo Araujo schreef: > > BTW i am using clang, maybe that is the culprit? > Yeap, could be. I didn't build with CLANG. Best Regards, -- Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 12:08:02 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 6B858106566B for ; Mon, 4 Jun 2012 12:08:02 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id E44878FC1C for ; Mon, 4 Jun 2012 12:08:01 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SbW4l-0003lQ-VP for freebsd-fs@freebsd.org; Mon, 04 Jun 2012 14:08:00 +0200 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SbW4l-00055u-Sr for freebsd-fs@freebsd.org; Mon, 04 Jun 2012 14:07:59 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: Date: Mon, 04 Jun 2012 14:07:58 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.64 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.0 X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=disabled version=3.2.5 X-Scan-Signature: 76f3589a93270604ea078d468a2051b3 Subject: Re: "panic: snapblkfree: inconsistent block type" on FreeBSD 9.0 RELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 12:08:02 -0000 On Sun, 03 Jun 2012 20:08:07 +0200, José García Juanino wrote: > On 3 June 2012 14:16, José García Juanino wrote: >> Hi, >> >> I am getting a lot of "snapblkfree: inconsistent block type" panics on >> my FreeBSD 9.0-RELEASE. My file systems have not any inconsistencies, >> I am checked them with fsck. But I have some snapshots with softupdate >> inconsistencies (fsck_ffs /path/to/snapshot), and I suspect that may >> be the cause of the panics. I have several questions: >> >> 1- Snapshots with fsck inconsistencies might be the cause of my panics? >> 2- Should I remove any of such "corrupt" snapshots? >> >> If someone is interested, I can provide a full backtrace. Kernel is >> GENERIC, with no tweaks. File system are been created with normal >> "newfs -U". No special setting is using. > > I have three full core dumps: > > http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.1 > http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.2 > http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.3 > > The relevant code is, in the three examples: > > #3 0xffffffff80a40124 in ffs_snapblkfree (fs=0xfffffe0002deb000, > devvp=Variable "devvp" is not available. > ) > at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1799 > > Regards I don't know about the internals of FFS, but I know there were some fixes to FFS + snapshots ( + journal (SUJ) ??) after 9.0-RELEASE. So maybe you can test updating to and running with 9-STABLE. Ronald. From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 12: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 59EB1106566B for ; Mon, 4 Jun 2012 12:08:38 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 0E91F8FC16 for ; Mon, 4 Jun 2012 12:08:38 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SbVxR-0003Wt-IO for freebsd-fs@freebsd.org; Mon, 04 Jun 2012 14:00:26 +0200 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SbVxR-0004wq-VC for freebsd-fs@freebsd.org; Mon, 04 Jun 2012 14:00:25 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: <20120601033945.GA37797@neutralgood.org> Date: Mon, 04 Jun 2012 14:00:24 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.64 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.0 X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=disabled version=3.2.5 X-Scan-Signature: 788438cbfdc4dc137ce560360a3a99c7 Subject: Re: hptrr disk labeling X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 12:08:38 -0000 On Sun, 03 Jun 2012 06:19:38 +0200, Randy Bush wrote: >>> i have an hptrr controller with 12-16 2tb satas on it. a picture >>> before i started cleaning up some disk failures. >>> >>> NAME STATE READ WRITE CKSUM >>> tank ONLINE 0 0 0 >>> mirror ONLINE 0 0 0 >>> label/m00-d01 ONLINE 0 0 0 >>> label/m00-d00 ONLINE 0 0 0 >>> mirror ONLINE 0 0 0 >>> label/m01-d00 ONLINE 0 0 0 >>> label/m01-d01 ONLINE 0 0 0 >>> >>> the reason i used glabels was because when the system boots or the >>> controller rescans, it assigns da0 to the first drive it finds alive on >>> the controller, da1 to the second, etc. >>> >>> this means that drive addition or removal changes the daX numbering. >>> >>> so the labels are so that zfs can find its ass when assembling the >>> array. >> >> Can you use GPT for partitioning? Put a single partition on each disk >> and >> set the GPT label (which is not the glabel). See gpart's add and modify >> subcommands. >> >> NAME STATE READ WRITE CKSUM >> gs1p ONLINE 0 0 0 >> mirror ONLINE 0 0 0 >> gpt/CONST_2-9XE02KPK-zfs ONLINE 0 0 0 >> gpt/SAVVIO-6XQ10F80-zfs ONLINE 0 0 0 >> gpt/SAVVIO-6XQ103C7-zfs ONLINE 0 0 0 > > ok. sure i could do that. but what's the win? > > randy Glabel is FreeBSD only. GPT is standardized. So if you import your pool in Solaris it will work with GPT, but not with glabel. But in your original question I don't really understand your problem with glabel (glabel solves the problem of changing da* numbering), so what do you want to win? Ronald. From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 20: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 85F0D106564A for ; Mon, 4 Jun 2012 20:00:20 +0000 (UTC) (envelope-from kayasaman@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 000E88FC18 for ; Mon, 4 Jun 2012 20:00:19 +0000 (UTC) Received: by eeke49 with SMTP id e49so1825241eek.13 for ; Mon, 04 Jun 2012 13:00:19 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=59K7Hjv3T+Lddhb9VCHmvVNKoSI4XgKsYFb7wU+DwsY=; b=j79sLGmz5eeDdqtTg2NpwzracuBPh+IeFejhkXuOPpG3RxbbgbTiILG/cDTefzJzpY 7vIPbrt9ZOvmzJ/P4ATsXjlhEsVGzwBQbXEyYbV8lgTPZNhKYYGq/v8ZeW7JF774yXw/ DF0DjUPJ3Yde3cATEfmrs1qIuy3ZTKOZ/No9JYWlH2jpZDO+IJPPocZdJsGMx34FQ/mo jctYwQdNrKlMcq3q56odApTMfu6IJvWR+aBKRvyB4c+MVQg6c/udvVmpwAxk5ec+A6Ys RQ/uVDPV5hsg4EAbxwXo17ixFxsEho998eCvCJ9gLRyjcn4A2ehFVOItYJr16TT6qlB0 0P3g== Received: by 10.14.96.70 with SMTP id q46mr5709914eef.231.1338840018888; Mon, 04 Jun 2012 13:00:18 -0700 (PDT) Received: from X220.optiplex-networks.com (81-178-2-118.dsl.pipex.com. [81.178.2.118]) by mx.google.com with ESMTPS id u7sm40805224eeb.7.2012.06.04.13.00.16 (version=SSLv3 cipher=OTHER); Mon, 04 Jun 2012 13:00:17 -0700 (PDT) Message-ID: <4FCD13CF.3010406@gmail.com> Date: Mon, 04 Jun 2012 21:00:15 +0100 From: Kaya Saman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Using ZFS as RAID0 - disk offline question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:00:20 -0000 Hi, in ZFS when using a simple RAID 0 style array is there a way to recover a pool after a disk has gone down? Or remove a disk from the pool to shrink it? To be more specific this is what I'm simulating at the moment: zpool create ZPOOL_1 /mnt/disk1 /mnt/disk2 zpool status shows disk1 and disk2 as being part of ZPOOL_1 and ZPOOL_1 is ONLINE. However, if I should ever want to remove disk2 from the pool or if disk2 has gone down how would one go about getting the ZPOOL_1 back online? I am hoping that there is a solution to just running the pool with 1 disk. Or if the disk name changes ie. simulating a disk number to change after moving it to a different controller or so internally. I am just trying to see what would happen as RAIDZ or RAID1 is very good however what about RAID0 in the situation above. I guess one could call this as disaster recovery for the unprepared :-) In actual fact I have done this physically on a Mini-ITX NAS system (of course I have backups of everything) however, my point is to try to see if one disk goes down if the ZPOOL will still be able to function without the additional disk! - as commands such as remove and detach are unavailable in this mode...... Regards, Kaya From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 20:15:04 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 4D8B4106566C for ; Mon, 4 Jun 2012 20:15:04 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id F33E08FC08 for ; Mon, 4 Jun 2012 20:15:03 +0000 (UTC) Received: (qmail 99581 invoked by uid 110); 4 Jun 2012 20:15:03 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 4 Jun 2012 20:15:03 -0000 From: "Simon" To: "freebsd-fs@freebsd.org" , "Kaya Saman" Date: Mon, 04 Jun 2012 16:14:47 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: <4FCD13CF.3010406@gmail.com> MIME-Version: 1.0 Message-Id: <20120604201504.4D8B4106566C@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Using ZFS as RAID0 - disk offline question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:15:04 -0000 This isn't really ZFS related, rather just RAID The answer would apply to any standard implementation of RAID0 which is nothing more than striping across multiple disks. Should you sustain a disk failure in RAID0, you will lose all your data. Check out http://en.wikipedia.org/wiki/Standard_RAID_levels -Simon On Mon, 04 Jun 2012 21:00:15 +0100, Kaya Saman wrote: >Hi, >in ZFS when using a simple RAID 0 style array is there a way to recover >a pool after a disk has gone down? >Or remove a disk from the pool to shrink it? >To be more specific this is what I'm simulating at the moment: >zpool create ZPOOL_1 /mnt/disk1 /mnt/disk2 >zpool status shows disk1 and disk2 as being part of ZPOOL_1 and ZPOOL_1 >is ONLINE. >However, if I should ever want to remove disk2 from the pool or if disk2 >has gone down how would one go about getting the ZPOOL_1 back online? >I am hoping that there is a solution to just running the pool with 1 disk. >Or if the disk name changes ie. simulating a disk number to change after >moving it to a different controller or so internally. >I am just trying to see what would happen as RAIDZ or RAID1 is very good >however what about RAID0 in the situation above. >I guess one could call this as disaster recovery for the unprepared :-) >In actual fact I have done this physically on a Mini-ITX NAS system (of >course I have backups of everything) however, my point is to try to see >if one disk goes down if the ZPOOL will still be able to function >without the additional disk! - as commands such as remove and detach are >unavailable in this mode...... >Regards, >Kaya >_______________________________________________ >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 Jun 4 20:17: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 0E8D8106566B for ; Mon, 4 Jun 2012 20:17:22 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 6ECFF8FC15 for ; Mon, 4 Jun 2012 20:17:21 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q54KHH64078989 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 21:17:17 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q54KHH64078989 Authentication-Results: smtp.infracaninophile.co.uk/q54KHH64078989; dkim=none (no signature); dkim-adsp=none Message-ID: <4FCD17C6.5020503@FreeBSD.org> Date: Mon, 04 Jun 2012 21:17:10 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Kaya Saman References: <4FCD13CF.3010406@gmail.com> In-Reply-To: <4FCD13CF.3010406@gmail.com> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig329BAD6B4A8FAFCE0CDA0462" X-Virus-Scanned: clamav-milter 0.97.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-fs@FreeBSD.org Subject: Re: Using ZFS as RAID0 - disk offline question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:17:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig329BAD6B4A8FAFCE0CDA0462 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/06/2012 21:00, Kaya Saman wrote: > in ZFS when using a simple RAID 0 style array is there a way to recover= > a pool after a disk has gone down? No. RAID0 has no resilience to disk failure. That's why things like RAID1, RAID10, RAIDz, RAIDz2 exist: so that your data will survive failure of some number of the drives it is stored on. Make sure you have good backups, basically. Cheers Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig329BAD6B4A8FAFCE0CDA0462 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/NF80ACgkQ8Mjk52CukIwGoQCfbgBjnROEfNDlh4po8ksYOzwQ 0ycAnR61tiTSfdk5uW2baws//nSTkuaB =OQiH -----END PGP SIGNATURE----- --------------enig329BAD6B4A8FAFCE0CDA0462-- From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 20:26:24 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FB221065680; Mon, 4 Jun 2012 20:26:24 +0000 (UTC) (envelope-from kayasaman@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9CBF78FC16; Mon, 4 Jun 2012 20:26:23 +0000 (UTC) Received: by eaac13 with SMTP id c13so1078344eaa.13 for ; Mon, 04 Jun 2012 13:26:17 -0700 (PDT) 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=AMundgGb84eEMSTGRgbjIdsfTOc3ohgZfGLABaw0hVQ=; b=ZlWGsL6A9slwBxlOOR07RlxOBhn5fUwEbIDn2+ZrydtX6J6a77LDTKelK2E9ddgJqH csIjrb4lTZzhJfxS16H5a0/FDEfBID4HK9javPv7fmHUDkmMA66ztUPVG01IPeVPRwGv fHv8YfKkOgRKlkAeRMDHSPYQjyRhYIVxr34i6KLF/Dej7vytyLGhHOA4L5bTbsmTpmH4 zFyZSfkQSc1tYzvEOfYQMjgr8j7ESiAcxZfMuHUtqXHUFuWkdBKecG9sZQpQnulO1/S+ m6oHEaxunnA9yp5ZbEO+ega6JZew3k/BSJQ9z2pUZLYjDM3fUfavNRwE0Lwhn0qHxMu9 5tFQ== Received: by 10.14.96.70 with SMTP id q46mr5748820eef.231.1338841577545; Mon, 04 Jun 2012 13:26:17 -0700 (PDT) Received: from X220.optiplex-networks.com (81-178-2-118.dsl.pipex.com. [81.178.2.118]) by mx.google.com with ESMTPS id u7sm41001322eeb.7.2012.06.04.13.26.15 (version=SSLv3 cipher=OTHER); Mon, 04 Jun 2012 13:26:16 -0700 (PDT) Message-ID: <4FCD19E6.1010802@gmail.com> Date: Mon, 04 Jun 2012 21:26:14 +0100 From: Kaya Saman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Matthew Seaman References: <4FCD13CF.3010406@gmail.com> <4FCD17C6.5020503@FreeBSD.org> In-Reply-To: <4FCD17C6.5020503@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Using ZFS as RAID0 - disk offline question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:26:24 -0000 On 06/04/2012 09:17 PM, Matthew Seaman wrote: > On 04/06/2012 21:00, Kaya Saman wrote: >> in ZFS when using a simple RAID 0 style array is there a way to recover >> a pool after a disk has gone down? > No. RAID0 has no resilience to disk failure. That's why things like > RAID1, RAID10, RAIDz, RAIDz2 exist: so that your data will survive > failure of some number of the drives it is stored on. > > Make sure you have good backups, basically. > > Cheers > > Matthew > Thanks for the responses! I wasn't actually meaning recovering data on the 'downed' disk but on the disk that was still online...... You see if say a system board fails and both devices are named /dev/ad4 and /dev/ad5 then a new system board gets put in and the device names changed to /dev/ad12 and /dev/ad13 my question is will the ZPOOL still exist? Will ZFS be intelligent enough to pick up the new device names via the disk ID's? Additionally if /dev/ad5 goes down, is it possible to keep using /dev/ad4 which is part of the 'downed' pool...?? Or would one need to replace the disk ad5 then the pool comes up again with only the information on ad4?? This is what I was trying to get at and sorry if I didn't understand 100% the direction of the responses! As in if you meant that the information of on /dev/ad5 will be lost - I do understand this :-) Regards, Kaya From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 20:38:50 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA6691065672 for ; Mon, 4 Jun 2012 20:38:49 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 749858FC1B for ; Mon, 4 Jun 2012 20:38:49 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q54Kcj1q079453 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 21:38:45 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q54Kcj1q079453 Authentication-Results: smtp.infracaninophile.co.uk/q54Kcj1q079453; dkim=none (no signature); dkim-adsp=none Message-ID: <4FCD1CD4.5080406@FreeBSD.org> Date: Mon, 04 Jun 2012 21:38:44 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Kaya Saman References: <4FCD13CF.3010406@gmail.com> <4FCD17C6.5020503@FreeBSD.org> <4FCD19E6.1010802@gmail.com> In-Reply-To: <4FCD19E6.1010802@gmail.com> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C07C9F536A679043898022C" X-Virus-Scanned: clamav-milter 0.97.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-fs@FreeBSD.org Subject: Re: Using ZFS as RAID0 - disk offline question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:38:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C07C9F536A679043898022C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/06/2012 21:26, Kaya Saman wrote: > You see if say a system board fails and both devices are named /dev/ad4= > and /dev/ad5 then a new system board gets put in and the device names > changed to /dev/ad12 and /dev/ad13 my question is will the ZPOOL still > exist? Will ZFS be intelligent enough to pick up the new device names > via the disk ID's? Yes, this should work just fine. ZFS labels each disk with its own UUID value, so you can pretty much shuffle the disks in any order across all available disk slots, and ZFS will be able to put the zpool back together= =2E > Additionally if /dev/ad5 goes down, is it possible to keep using > /dev/ad4 which is part of the 'downed' pool...?? Or would one need to > replace the disk ad5 then the pool comes up again with only the > information on ad4?? No. A RAID0 zpool will be marked offline if any of the drives within it fails. You might be able to recover some data from remaining drives, but not easily. The surest way of getting anything back would be to go to a specialist disaster recovery company, but expect to pay $$$ for it. Considering the price of hard drives nowadays, this would be a dumb choice: you could easily convert your RAID0 to a RAID10 for much less than it would cost you to try and recover from a broken RAID0. Even if you do install a replacement disk, ZFS won't be able to rebuild from your original drive. You'ld have to wipe and rebuild from scratch. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig7C07C9F536A679043898022C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/NHNUACgkQ8Mjk52CukIyQRwCdF2OY+RQiQTiY4NTeAp+bPD47 Pb8An0q1PigP/Ncx6co2c4Oj+bO8+pVN =IiSz -----END PGP SIGNATURE----- --------------enig7C07C9F536A679043898022C-- From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 20:41:21 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EA911065689; Mon, 4 Jun 2012 20:41:21 +0000 (UTC) (envelope-from kayasaman@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 73EF88FC0C; Mon, 4 Jun 2012 20:41:20 +0000 (UTC) Received: by eeke49 with SMTP id e49so1836568eek.13 for ; Mon, 04 Jun 2012 13:41:19 -0700 (PDT) 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=VRSOx86GSn/PyPy+qWgEhKoxH0vg4nemAqorbK0m5+c=; b=LLBY4e9naCCsE+kQf0c6m4s5vF2qUaCcL8WLWw2fgAesZ/ykWlsml6Eb48G5q9EXc4 8CikQW955sfBV7D0E5beXUPQ5/3SeYuIyNGQjRidfzkYrcaIhdnP4xn4X5UD5eSeVfcD Bq+JvzWcML97Lx3lqbBfCNI4FSsfIFmzk7u+etLWQORd4sIdjBpUoPMNcLd+VBrLyZiK khLIMBjPjqa++vKWSG1PQjx7eytgbU4HybHZM74P8+K3H5CAy1qsI4MLyl0elTiDJOdX qM1gbcJAZ/tr5yipmyRv1mX/Br2dkpWA9BHDaCJ/ac9C/82UCdnTV7z9EUFKsY87FyPm gqsw== Received: by 10.14.186.14 with SMTP id v14mr5935671eem.49.1338842479326; Mon, 04 Jun 2012 13:41:19 -0700 (PDT) Received: from X220.optiplex-networks.com (81-178-2-118.dsl.pipex.com. [81.178.2.118]) by mx.google.com with ESMTPS id g51sm41085209eea.14.2012.06.04.13.41.17 (version=SSLv3 cipher=OTHER); Mon, 04 Jun 2012 13:41:18 -0700 (PDT) Message-ID: <4FCD1D6B.9030901@gmail.com> Date: Mon, 04 Jun 2012 21:41:15 +0100 From: Kaya Saman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Matthew Seaman References: <4FCD13CF.3010406@gmail.com> <4FCD17C6.5020503@FreeBSD.org> <4FCD19E6.1010802@gmail.com> <4FCD1CD4.5080406@FreeBSD.org> In-Reply-To: <4FCD1CD4.5080406@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Using ZFS as RAID0 - disk offline question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:41:21 -0000 On 06/04/2012 09:38 PM, Matthew Seaman wrote: > On 04/06/2012 21:26, Kaya Saman wrote: >> You see if say a system board fails and both devices are named /dev/ad4 >> and /dev/ad5 then a new system board gets put in and the device names >> changed to /dev/ad12 and /dev/ad13 my question is will the ZPOOL still >> exist? Will ZFS be intelligent enough to pick up the new device names >> via the disk ID's? > Yes, this should work just fine. ZFS labels each disk with its own UUID > value, so you can pretty much shuffle the disks in any order across all > available disk slots, and ZFS will be able to put the zpool back together. > >> Additionally if /dev/ad5 goes down, is it possible to keep using >> /dev/ad4 which is part of the 'downed' pool...?? Or would one need to >> replace the disk ad5 then the pool comes up again with only the >> information on ad4?? > No. A RAID0 zpool will be marked offline if any of the drives within it > fails. You might be able to recover some data from remaining drives, > but not easily. The surest way of getting anything back would be to go > to a specialist disaster recovery company, but expect to pay $$$ for it. > Considering the price of hard drives nowadays, this would be a dumb > choice: you could easily convert your RAID0 to a RAID10 for much less > than it would cost you to try and recover from a broken RAID0. > > Even if you do install a replacement disk, ZFS won't be able to rebuild > from your original drive. You'ld have to wipe and rebuild from scratch. > > Cheers, > > Matthew > Many thanks! They were exactly the answers I was looking for :-) Apologies for my inexperience in this matter! Regards, Kaya From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 20:48: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 8E1FB106567D for ; Mon, 4 Jun 2012 20:48:05 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4EF8FC15 for ; Mon, 4 Jun 2012 20:48:04 +0000 (UTC) Received: by eaac13 with SMTP id c13so1083941eaa.13 for ; Mon, 04 Jun 2012 13:48:04 -0700 (PDT) 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=w8AAAysMxMKMCrPflrBBRZ/OMqImaTTcQ+un5s7CvkY=; b=D5cbGOpXuVeDuc4+N5nDz7mcHifEGzwdACWKvPh/z1iBzrBZmkzMJrKXYgRXkQIZnw h8GIvIedJu4npzRBT0q0J7JiDB1Rx9s+2aijm2NwWwBl7aYWuhyBDxAWjaZJo6VqOiSU cIFT2pGXeauKnXwJC8gaKF3XKh8qlXbz8wUMCl7goTNhY66LAiupPqi9Z6oSWScb3kbQ +te+onAGf4Ev7UyKI+Hge2a6Fr3D9PjvFIk0D3Zk0Nw0w+MYWf2ACSMvmJKG3KQc9N83 ING3LutxoTP0MQMxCfWMWo2ZML3qQDVLMXLee9aemX2flCLqxohooBAfJE8M/aj+nI0m wxIA== Received: by 10.14.119.196 with SMTP id n44mr6725099eeh.29.1338842884117; Mon, 04 Jun 2012 13:48:04 -0700 (PDT) Received: from [192.168.1.14] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPS id c51sm41141480eei.12.2012.06.04.13.48.02 (version=SSLv3 cipher=OTHER); Mon, 04 Jun 2012 13:48:02 -0700 (PDT) Message-ID: <4FCD1F00.5080805@gmail.com> Date: Mon, 04 Jun 2012 22:48:00 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Kaya Saman References: <4FCD13CF.3010406@gmail.com> <4FCD17C6.5020503@FreeBSD.org> <4FCD19E6.1010802@gmail.com> In-Reply-To: <4FCD19E6.1010802@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Using ZFS as RAID0 - disk offline question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:48:05 -0000 Kaya Saman schreef: > On 06/04/2012 09:17 PM, Matthew Seaman wrote: >> On 04/06/2012 21:00, Kaya Saman wrote: >>> in ZFS when using a simple RAID 0 style array is there a way to recover >>> a pool after a disk has gone down? >> No. RAID0 has no resilience to disk failure. That's why things like >> RAID1, RAID10, RAIDz, RAIDz2 exist: so that your data will survive >> failure of some number of the drives it is stored on. >> >> Make sure you have good backups, basically. >> >> Cheers >> >> Matthew >> > > Thanks for the responses! > > > I wasn't actually meaning recovering data on the 'downed' disk but on > the disk that was still online...... > > > You see if say a system board fails and both devices are named > /dev/ad4 and /dev/ad5 then a new system board gets put in and the > device names changed to /dev/ad12 and /dev/ad13 my question is will > the ZPOOL still exist? Will ZFS be intelligent enough to pick up the > new device names via the disk ID's? > > > Additionally if /dev/ad5 goes down, is it possible to keep using > /dev/ad4 which is part of the 'downed' pool...?? Or would one need to > replace the disk ad5 then the pool comes up again with only the > information on ad4?? > > > This is what I was trying to get at and sorry if I didn't understand > 100% the direction of the responses! > > As in if you meant that the information of on /dev/ad5 will be lost - > I do understand this :-) > > > Regards, > > Kaya > _______________________________________________ > 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" you can not loose a disk from a raid0 period. To put it simple, your files are split in half, one part is copied to disk 1 and the other part on disk2 . So without the two copies no files, no data. If device names changes because of a hardware change, the pool schould be importable. But both disks need to be there. Raid0 should be avoided if possible, better add one disk extra and create a raidz. regards Johan Hendriks From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 20:53:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4BA2106566B for ; Mon, 4 Jun 2012 20:53:05 +0000 (UTC) (envelope-from kayasaman@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 4E7E08FC19 for ; Mon, 4 Jun 2012 20:53:04 +0000 (UTC) Received: by eeke49 with SMTP id e49so1839418eek.13 for ; Mon, 04 Jun 2012 13:53:04 -0700 (PDT) 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=Sq9ixjh2NP6fAahixVbG29Utu5VFvnsMFxlJaJcgvzU=; b=j+SBfenxxfDqr4TR6PCt9gjBDQ2pKRIrVILbKlQMqGBHfZYm0Ug/15cK2LxtOL7Eqc ZWr7tWfWt7vfBO3u/tqmhKftV88qs+j98w+TJ9X/yWA5TwbkHupeldWq+IOMg1qLz3bp uUGCTNWGea0u5I8gXWodbY1nB+vdoy+keYA9n6/w2glBA19AGwdum/bgjGTmQddZAygn WBrzhFd8wSXRa97ehbIm+4q1FF+qdM5eWmva1ZF29AFuvaZFNiS/UzW0v4QtKhjbMGxV Fa2xXENZKUeiT/z7lw6N/ZlylUYx3g0SdOpX9ZqoMmVu7QP18pcuM/ueSlSQNYfcsSgc cCGw== Received: by 10.14.22.16 with SMTP id s16mr3208281ees.183.1338843184278; Mon, 04 Jun 2012 13:53:04 -0700 (PDT) Received: from X220.optiplex-networks.com (81-178-2-118.dsl.pipex.com. [81.178.2.118]) by mx.google.com with ESMTPS id e45sm41210300eeb.6.2012.06.04.13.53.02 (version=SSLv3 cipher=OTHER); Mon, 04 Jun 2012 13:53:03 -0700 (PDT) Message-ID: <4FCD202D.2060601@gmail.com> Date: Mon, 04 Jun 2012 21:53:01 +0100 From: Kaya Saman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Johan Hendriks References: <4FCD13CF.3010406@gmail.com> <4FCD17C6.5020503@FreeBSD.org> <4FCD19E6.1010802@gmail.com> <4FCD1F00.5080805@gmail.com> In-Reply-To: <4FCD1F00.5080805@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Using ZFS as RAID0 - disk offline question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:53:05 -0000 On 06/04/2012 09:48 PM, Johan Hendriks wrote: > Kaya Saman schreef: >> On 06/04/2012 09:17 PM, Matthew Seaman wrote: >>> On 04/06/2012 21:00, Kaya Saman wrote: >>>> in ZFS when using a simple RAID 0 style array is there a way to >>>> recover >>>> a pool after a disk has gone down? >>> No. RAID0 has no resilience to disk failure. That's why things like >>> RAID1, RAID10, RAIDz, RAIDz2 exist: so that your data will survive >>> failure of some number of the drives it is stored on. >>> >>> Make sure you have good backups, basically. >>> >>> Cheers >>> >>> Matthew >>> >> >> Thanks for the responses! >> >> >> I wasn't actually meaning recovering data on the 'downed' disk but on >> the disk that was still online...... >> >> >> You see if say a system board fails and both devices are named >> /dev/ad4 and /dev/ad5 then a new system board gets put in and the >> device names changed to /dev/ad12 and /dev/ad13 my question is will >> the ZPOOL still exist? Will ZFS be intelligent enough to pick up the >> new device names via the disk ID's? >> >> >> Additionally if /dev/ad5 goes down, is it possible to keep using >> /dev/ad4 which is part of the 'downed' pool...?? Or would one need to >> replace the disk ad5 then the pool comes up again with only the >> information on ad4?? >> >> >> This is what I was trying to get at and sorry if I didn't understand >> 100% the direction of the responses! >> >> As in if you meant that the information of on /dev/ad5 will be lost - >> I do understand this :-) >> >> >> Regards, >> >> Kaya >> _______________________________________________ >> 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" > you can not loose a disk from a raid0 period. > To put it simple, your files are split in half, one part is copied to > disk 1 and the other part on disk2 . > So without the two copies no files, no data. > > If device names changes because of a hardware change, the pool schould > be importable. > But both disks need to be there. > Raid0 should be avoided if possible, better add one disk extra and > create a raidz. > > regards > Johan Hendriks > Yeah, I'm starting to see this now! Of course I don't think it's possible to upgrade from RADI0 to RAIDZ.... Easier to go to RAID1 which gives most protection. Though is not the most efficient method of doing things. Regards, Kaya From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 21:10:17 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90D4F1065670 for ; Mon, 4 Jun 2012 21:10:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 629F28FC0A for ; Mon, 4 Jun 2012 21:10:17 +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 q54LAGdh080967 for ; Mon, 4 Jun 2012 21:10:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q54LAGYo080966; Mon, 4 Jun 2012 21:10:16 GMT (envelope-from gnats) Date: Mon, 4 Jun 2012 21:10:16 GMT Message-Id: <201206042110.q54LAGYo080966@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Patrick Proniewski Cc: Subject: Re: kern/156781: [zfs] zfs is losing the snapshot directory, X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Patrick Proniewski List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 21:10:17 -0000 The following reply was made to PR kern/156781; it has been noted by GNATS. From: Patrick Proniewski To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/156781: [zfs] zfs is losing the snapshot directory, Date: Mon, 4 Jun 2012 23:04:07 +0200 Well, this bug is really really annoying. I would reclassify it as = critical: my server is hosted in a data center, and when I want/need to = reboot it, it just crashes and stays frozen. I've to ask my hosting = provider to hard reboot the server. I wonder if I need to use `reboot -qn` until the bug is corrected, or = should I ditch ZFS?= From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 22:59: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 A8B051065794 for ; Mon, 4 Jun 2012 22:59:40 +0000 (UTC) (envelope-from dustinwenz@ebureau.com) Received: from internet02.ebureau.com (internet02.tru-signal.biz [65.127.24.21]) by mx1.freebsd.org (Postfix) with ESMTP id D79038FC19 for ; Mon, 4 Jun 2012 22:59:39 +0000 (UTC) Received: from service02.office.ebureau.com (service02.office.ebureau.com [192.168.20.15]) by internet02.ebureau.com (Postfix) with ESMTP id B6556C921E5 for ; Mon, 4 Jun 2012 17:54:04 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by service02.office.ebureau.com (Postfix) with ESMTP id 611129D7A931 for ; Mon, 4 Jun 2012 17:54:04 -0500 (CDT) X-Virus-Scanned: amavisd-new at ebureau.com Received: from service02.office.ebureau.com ([127.0.0.1]) by localhost (service02.office.iscompanies.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54Lr1lAwuQ33 for ; Mon, 4 Jun 2012 17:54:03 -0500 (CDT) Received: from square.office.ebureau.com (square.office.ebureau.com [10.10.20.22]) by service02.office.ebureau.com (Postfix) with ESMTPSA id 6CB469D7A922 for ; Mon, 4 Jun 2012 17:54:03 -0500 (CDT) From: Dustin Wenz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jun 2012 17:54:03 -0500 Message-Id: <5532CFFB-F943-4D9E-9722-7FB9C8A9F82A@ebureau.com> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: Can mps drop a failing device from bus? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 22:59:40 -0000 I asked this question back in April on the stable list with no response = ( = http://lists.freebsd.org/pipermail/freebsd-stable/2012-April/067305.html = ). I've now been seeing the same behavior on 9.0-release, and I thought = it would be good to ask again here. There is a failure mode for SATA disks (Seagate Barracuda ST3000DM001 = disks, in this case) that the mps driver doesn't handle very well. If a = disk is slow to respond, or is unresponsive altogether, I'd like it to = be removed from the bus and degrade the zpool that it's a part of. The way things are now, mps will just report a lot of "SCSI command = timeout on device" messages. Any I/O on the affected zpools will hang = for an excessive amount of time (sometimes forever). We typically = configure our storage volumes as a pool of mirrors, with the expectation = that availability will be maintained if any redundant disk(s) should = fail. Unfortunately, availability is actually made *worse* on = highly-redundant mirrors when mps won't give up on an unresponsive = device. It's possible that I'm overlooking an obvious solution, or some relevant = configuration options for the driver. Can anyone offer some insight on = this? Thanks, - .Dustin From owner-freebsd-fs@FreeBSD.ORG Mon Jun 4 23:15:03 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 01228106566C for ; Mon, 4 Jun 2012 23:15:02 +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 CF1F58FC14 for ; Mon, 4 Jun 2012 23:15:02 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SbgUH-0006IJ-JQ; Mon, 04 Jun 2012 23:15:01 +0000 Date: Mon, 04 Jun 2012 16:15:01 -0700 Message-ID: From: Randy Bush To: "Ronald Klop" In-Reply-To: References: <20120601033945.GA37797@neutralgood.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD FS Subject: Re: hptrr disk labeling X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 23:15:03 -0000 >>>> i have an hptrr controller with 12-16 2tb satas on it. a picture >>>> before i started cleaning up some disk failures. >>>> >>>> NAME STATE READ WRITE CKSUM >>>> tank ONLINE 0 0 0 >>>> mirror ONLINE 0 0 0 >>>> label/m00-d01 ONLINE 0 0 0 >>>> label/m00-d00 ONLINE 0 0 0 >>>> mirror ONLINE 0 0 0 >>>> label/m01-d00 ONLINE 0 0 0 >>>> label/m01-d01 ONLINE 0 0 0 >>>> >>>> the reason i used glabels was because when the system boots or the >>>> controller rescans, it assigns da0 to the first drive it finds alive on >>>> the controller, da1 to the second, etc. >>>> >>>> this means that drive addition or removal changes the daX numbering. >>>> >>>> so the labels are so that zfs can find its ass when assembling the >>>> array. >>> >>> Can you use GPT for partitioning? Put a single partition on each disk >>> and >>> set the GPT label (which is not the glabel). See gpart's add and modify >>> subcommands. >>> >>> NAME STATE READ WRITE CKSUM >>> gs1p ONLINE 0 0 0 >>> mirror ONLINE 0 0 0 >>> gpt/CONST_2-9XE02KPK-zfs ONLINE 0 0 0 >>> gpt/SAVVIO-6XQ10F80-zfs ONLINE 0 0 0 >>> gpt/SAVVIO-6XQ103C7-zfs ONLINE 0 0 0 >> >> ok. sure i could do that. but what's the win? > > Glabel is FreeBSD only. GPT is standardized. So if you import your pool in > Solaris it will work with GPT, but not with glabel. p == 0.0 > But in your original question I don't really understand your problem with > glabel (glabel solves the problem of changing da* numbering), so what do > you want to win? for the archive, this won (thanks to private email) t# grep hint /boot/loader.conf.local hint.scbus.0.at="hptrr0" hint.da.0.at="scbus0" hint.da.1.at="scbus0" hint.da.2.at="scbus0" hint.da.3.at="scbus0" hint.da.4.at="scbus0" hint.da.5.at="scbus0" hint.da.6.at="scbus0" hint.da.7.at="scbus0" hint.da.8.at="scbus0" hint.da.9.at="scbus0" hint.da.10.at="scbus0" hint.da.11.at="scbus0" hint.da.12.at="scbus0" hint.da.13.at="scbus0" hint.da.14.at="scbus0" hint.da.15.at="scbus0" hint.da.0.target="0" hint.da.1.target="1" hint.da.2.target="2" hint.da.3.target="3" hint.da.4.target="4" hint.da.5.target="5" hint.da.6.target="6" hint.da.7.target="7" hint.da.8.target="8" hint.da.9.target="9" hint.da.10.target="10" hint.da.11.target="11" hint.da.12.target="12" hint.da.13.target="13" hint.da.14.target="14" hint.da.15.target="15" randy From owner-freebsd-fs@FreeBSD.ORG Tue Jun 5 11:37: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 0480E106564A for ; Tue, 5 Jun 2012 11:37:10 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id ACB2C8FC19 for ; Tue, 5 Jun 2012 11:37:09 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Sbs4N-0005ot-VM for freebsd-fs@freebsd.org; Tue, 05 Jun 2012 13:37:03 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Jun 2012 13:37:03 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Jun 2012 13:37:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Tue, 05 Jun 2012 13:36:52 +0200 Lines: 53 Message-ID: References: <4FCD13CF.3010406@gmail.com> <4FCD17C6.5020503@FreeBSD.org> <4FCD19E6.1010802@gmail.com> <4FCD1CD4.5080406@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4B13512928EBEB3E469E163C" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: <4FCD1CD4.5080406@FreeBSD.org> X-Enigmail-Version: 1.3.5 Subject: Re: Using ZFS as RAID0 - disk offline question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 11:37:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B13512928EBEB3E469E163C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/06/2012 22:38, Matthew Seaman wrote: > No. A RAID0 zpool will be marked offline if any of the drives within i= t > fails. You might be able to recover some data from remaining drives, > but not easily. The surest way of getting anything back would be to go= > to a specialist disaster recovery company, but expect to pay $$$ for it= =2E > Considering the price of hard drives nowadays, this would be a dumb > choice: you could easily convert your RAID0 to a RAID10 for much less > than it would cost you to try and recover from a broken RAID0. >=20 > Even if you do install a replacement disk, ZFS won't be able to rebuild= > from your original drive. You'ld have to wipe and rebuild from scratch= =2E This requires a more thorough answer from someone who's working on ZFS or has done extensive testing, but there is a particular circumstance in which (in theory), ZFS could recover from RAID0 failure: if the "ditto blocks" feature is turned on. E.g.: https://blogs.oracle.com/relling/entry/zfs_copies_and_data_protect= ion I think this would only work if the second drive isn't disconnected but continues to respond with IO errors while reading. If the drive is disconnected, the whole array will probably fail. Ditto blocks sort-of-but-not-quite turn ZFS RAID0 into RAID-10. --------------enig4B13512928EBEB3E469E163C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/N71QACgkQ/QjVBj3/HSyZ3wCgpPqcGvbzi0D4+mubZ56WbymC X2kAnjjin7a+OsKb5rBgJkQq/80BTGh7 =D3l1 -----END PGP SIGNATURE----- --------------enig4B13512928EBEB3E469E163C-- From owner-freebsd-fs@FreeBSD.ORG Tue Jun 5 12:19: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 22C4C106564A; Tue, 5 Jun 2012 12:19:34 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog134.obsmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) by mx1.freebsd.org (Postfix) with ESMTP id 263348FC1A; Tue, 5 Jun 2012 12:19:33 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKT835QUQW9Xh3uHPdEALNOXfDPjq3GQfs@postini.com; Tue, 05 Jun 2012 05:19:33 PDT Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 5 Jun 2012 08:25:13 -0400 Received: from inbexch02.lsi.com (135.36.98.40) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 5 Jun 2012 08:19:10 -0400 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Tue, 5 Jun 2012 17:49:07 +0530 From: "Desai, Kashyap" To: Konstantin Belousov , "Kenneth D. Merry" Date: Tue, 5 Jun 2012 17:49:05 +0530 Thread-Topic: Kernel panic in FreeBSD-8.3 from UFS Thread-Index: Ac0/9kNdhRScgfZLQl6YJCXP03aRdADFdYIg Message-ID: References: <20120601124338.GU2358@deviant.kiev.zoral.com.ua> <20120601125824.GV2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120601125824.GV2358@deviant.kiev.zoral.com.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_B2FD678A64EAAD45B089B123FDFC3ED72B9F6C21A7inbmail01lsic_" MIME-Version: 1.0 Cc: "freebsd-fs@freebsd.org" , "freebsd-scsi@freebsd.org" , "McConnell, Stephen" , "Reddy, Sreekanth" Subject: RE: Kernel panic in FreeBSD-8.3 from UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 12:19:34 -0000 --_002_B2FD678A64EAAD45B089B123FDFC3ED72B9F6C21A7inbmail01lsic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, We found some potential area of memory leak in CAM layer.=20 CAM XPT Memory leak is due to following function in scsi/scsi_all.c int scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb) = =20 In above function, CAM layer allocate memory for ccb device as below if ((cgd =3D (struct ccb_getdev*)xpt_alloc_ccb_nowait()) =3D=3D NULL) _But_, unfortunately we never free the allocated memory and we see memory l= eak of 2K every time when someone is calling=20 Scsi_command_string from kernel mode. Attached is a proposed patch for this issue. ` Kashyap > -----Original Message----- > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > Sent: Friday, June 01, 2012 6:28 PM > To: Desai, Kashyap > Cc: freebsd-scsi@freebsd.org; freebsd-fs@freebsd.org; McConnell, Stephen > Subject: Re: Kernel panic in FreeBSD-8.3 from UFS >=20 > On Fri, Jun 01, 2012 at 06:19:56PM +0530, Desai, Kashyap wrote: > > > > Thanks for the information. *YES* to me also looks like memory leaks > only.. but it is CAM XPT who is using "366195K " memory.. > > > Yes, it seems that cam should be investigated next. >=20 > It is indeed most likely not related to UFS at all, and just happens to > trace through the UFS code since you might have run fs-intensive test > and filesystem just called allocator most often. >=20 > > See below output of "vmstat -m" > > > > vmstat -m > > > > Type InUse MemUse HighUse Requests Size(s) > > feeder 7 1K - 7 16 > > acpiintr 1 1K - 1 32 > > isadev 9 1K - 9 64 > > acpica 3179 172K - 73127 > 16,32,64,128,256,512,1024,2048 > > cdev 7 1K - 7 128 > > acpitask 1 1K - 1 1024 > > sigio 1 1K - 1 32 > > filedesc 50 14K - 2926 16,256,512,1024 > > kenv 121 9K - 130 16,32,64,128,4096 > > kqueue 0 0K - 266 128,1024 > > CAM dev queue 8 1K - 8 128 > > proc-args 26 2K - 4746 16,32,64,128 > > hhook 2 1K - 2 128 > > ithread 128 11K - 128 16,64,128 > > CAM queue 43 9K - 595257 > 16,32,64,128,256,512,1024,2048,4096 > > KTRACE 100 13K - 100 128 > > acpisem 21 3K - 21 64,128 > > linker 157 6K - 166 16,32,256 > > lockf 1751 61K - 2311 32,64,128,256,512,1024 > > loginclass 2 1K - 96 64 > > ip6ndp 12 1K - 13 64,128 > > ip6opt 0 0K - 3 32 > > temp 56 233K - 11165 > 16,32,64,128,256,512,1024,2048,4096 > > devbuf 5248 4507K - 5360 > 16,32,64,128,256,512,1024,2048,4096 > > module 493 31K - 493 64,128 > > mtx_pool 2 8K - 2 4096 > > CAM SIM 8 1K - 8 128 > > subproc 216 219K - 3091 256,4096 > > proc 2 8K - 2 4096 > > session 18 2K - 109 64 > > pgrp 25 2K - 129 64 > > cred 62 6K - 13960 64,128 > > uidinfo 3 2K - 88 64,1024 > > plimit 18 5K - 1389 256 > > scsi_cd 0 0K - 4 16 > > CAM periph 22 3K - 84532 16,32,64,128 > > CAM XPT 183208 366195K - 722021 16,32,64,256,1024,2048 > > sysctltmp 0 0K - 453 16,32,64,128,4096 > > sysctloid 5010 158K - 5286 16,32,64,128 > > sysctl 0 0K - 763 16,32,64 > > tidhash 1 8K - 1 > > callout 7 1792K - 7 > > umtx 750 71K - 750 64,128 > > p1003.1b 1 1K - 1 16 > > SWAP 2 4373K - 2 64 > > bus-sc 97 417K - 6298 > 16,32,64,128,256,512,1024,2048,4096 > > bus 1382 64K - 9711 16,32,64,128,256,1024 > > devstat 16 33K - 16 16,4096 > > eventhandler 73 4K - 73 32,64,128 > > UART 6 3K - 6 16,256,1024 > > kobj 358 716K - 634 2048 > > Per-cpu 1 1K - 1 16 > > ata_pci 2 1K - 2 32 > > rman 226 13K - 424 16,32,64 > > sbuf 0 0K - 1636 > 16,32,64,128,256,512,1024,2048,4096 > > scsi_da 0 0K - 186 16 > > stack 0 0K - 2 128 > > taskqueue 15 1K - 15 16,64 > > Unitno 14 1K - 5912 16,64 > > iov 0 0K - 1847877 16,64,128,256 > > select 9 1K - 9 64 > > ioctlops 0 0K - 5848 > 16,32,64,128,256,512,1024,2048 > > msg 4 25K - 4 1024,4096 > > sem 4 101K - 4 1024,4096 > > shm 1 12K - 1 > > tty 21 11K - 23 512,2048 > > mbuf_tag 0 0K - 549 32,64 > > shmfd 1 4K - 1 4096 > > pcb 18 79K - 567 > 16,32,64,512,1024,2048,4096 > > soname 3 1K - 16885 16,32,128 > > vfscache 1 512K - 1 > > cl_savebuf 0 0K - 48 32 > > vfs_hash 1 256K - 1 > > acpidev 50 2K - 50 32 > > vnodes 2 1K - 2 128 > > vnodemarker 0 0K - 6497 512 > > mount 94 4K - 197 16,32,64,128,256 > > BPF 10 1K - 10 64 > > ether_multi 21 1K - 24 16,32,64 > > ifaddr 90 17K - 90 16,32,64,128,256,512,2048 > > ifnet 11 11K - 11 64,1024 > > USBdev 35 9K - 35 32,128,1024 > > clone 6 24K - 6 4096 > > arpcom 2 1K - 2 16 > > lltable 23 6K - 23 256 > > USB 66 40K - 69 > 16,32,64,128,256,1024,4096 > > routetbl 29 4K - 245 16,64,128,256 > > igmp 10 2K - 10 128 > > in_multi 1 1K - 1 128 > > sctp_iter 0 0K - 3 256 > > sctp_ifn 2 1K - 2 128 > > sctp_ifa 4 1K - 4 128 > > sctp_vrf 1 1K - 1 64 > > sctp_a_it 0 0K - 3 16 > > hostcache 1 16K - 1 > > syncache 1 72K - 1 > > entropy 1024 64K - 1024 64 > > in6_multi 15 2K - 15 16,256 > > pci_link 16 2K - 16 64,128 > > mld 10 2K - 10 128 > > rpc 2 1K - 2 128 > > audit_evclass 179 3K - 218 16 > > jblocks 2 1K - 2 128 > > savedino 0 0K - 121 256 > > sbdep 0 0K - 464 32 > > jsegdep 1 1K - 6778 32 > > jseg 1 1K - 4558 128 > > jfreefrag 0 0K - 179 64 > > jnewblk 0 0K - 5965 64 > > jremref 0 0K - 317 64 > > jaddref 0 0K - 317 64 > > freedep 0 0K - 9 32 > > freework 1 1K - 268 32,128 > > newdirblk 0 0K - 6 32 > > dirrem 0 0K - 305 64 > > mkdir 0 0K - 12 64 > > diradd 0 0K - 305 64 > > freefile 0 0K - 72 32 > > freeblks 0 0K - 157 128 > > freefrag 0 0K - 179 64 > > indirdep 1 1K - 4235 64 > > newblk 2 65K - 5966 128 > > bmsafemap 2 5K - 4389 128,4096 > > inodedep 2 257K - 4997 256 > > pagedep 1 64K - 51 128 > > ufs_dirhash 8 4K - 24 16,32,64,512 > > ufs_mount 21 390K - 21 256,4096 > > vm_pgdata 2 65K - 2 64 > > UMAHash 1 1K - 1 256 > > acpi_perf 2 1K - 2 256 > > DEVFS1 127 32K - 187 256 > > atkbddev 2 1K - 2 32 > > DEVFS3 141 18K - 223 128,256 > > DEVFS 24 1K - 25 16,64 > > memdesc 1 4K - 1 4096 > > apmdev 1 1K - 1 64 > > io_apic 2 2K - 2 1024 > > pfs_nodes 21 3K - 21 128 > > msi 3 1K - 3 64 > > nexusdev 5 1K - 5 16 > > GEOM 117 19K - 2291 > 16,32,64,128,256,512,1024,2048 > > SCSI SES 2 4K - 2 2048 > > kbdmux 7 18K - 7 16,256,1024,2048 > > mps 22 280K - 24141 > 16,32,64,128,256,512,2048,4096 > > mps_user 0 0K - 662 32,64 > > > > > > ` Kashyap > > > > > -----Original Message----- > > > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > > > Sent: Friday, June 01, 2012 6:14 PM > > > To: Desai, Kashyap > > > Cc: freebsd-scsi@freebsd.org; freebsd-fs@freebsd.org; McConnell, > > > Stephen > > > Subject: Re: Kernel panic in FreeBSD-8.3 from UFS > > > > > > On Fri, Jun 01, 2012 at 05:30:39PM +0530, Desai, Kashyap wrote: > > > > Hi, > > > > > > > > We have seen kernel panic while doing IO along with HBA reset. > > > > This looks to be very rare but not sure if someone can help me to > > > > understand what is a issue here. To me it does not look any issue > > > > with underline Device Driver > > > > > > > > See below back trace. > > > You did not specified the panic message. Was it 'kmem_map too small' > ? > > > > > > Unless HBA driver causes memory leak, this is probably indeed > unrelated. > > > > > > > > > > > > #0 doadump (textdump=3D1) at pcpu.h:244 > > > > 244 pcpu.h: No such file or directory. > > > > in pcpu.h > > > > (kgdb) #0 doadump (textdump=3D1) at pcpu.h:244 > > > > #1 0xc0a1845a in kern_reboot (howto=3D260) > > > > at /usr/src/sys/kern/kern_shutdown.c:442 > > > > #2 0xc0a186f1 in panic (fmt=3DVariable "fmt" is not available. > > > > ) at /usr/src/sys/kern/kern_shutdown.c:607 > > > > #3 0xc0c7ceda in kmem_malloc (map=3D0xc15c808c, size=3D32768, > flags=3D2) > > > > at /usr/src/sys/vm/vm_kern.c:334 > > > > #4 0xc0c708e7 in page_alloc (zone=3D0x0, bytes=3D32768, > > > > pflag=3D0xf19839bf > > > "\002", > > > > wait=3D2) at /usr/src/sys/vm/uma_core.c:994 > > > > #5 0xc0c72fe0 in uma_large_malloc (size=3D32768, wait=3D2) > > > > at /usr/src/sys/vm/uma_core.c:3067 > > > > #6 0xc0a04fac in malloc (size=3D32768, mtp=3D0xc102b808, flags=3D2= ) > > > > at /usr/src/sys/kern/kern_malloc.c:492 > > > > #7 0xc0c42e89 in softdep_disk_io_initiation (bp=3D0xdef881fc) > > > > at /usr/src/sys/ufs/ffs/ffs_softdep.c:10126 > > > > #8 0xc0c5208f in ffs_geom_strategy (bo=3D0xc5fc30ac, bp=3D0xdef881= fc) > > > > at buf.h:411 > > > > #9 0xc0c65a43 in ufs_strategy (ap=3D0xf1983b00) > > > > at /usr/src/sys/ufs/ufs/ufs_vnops.c:2317 > > > > #10 0xc0d6a6dd in VOP_STRATEGY_APV (vop=3D0xc102e4a0, a=3D0xf1983b0= 0) > > > > at vnode_if.c:2171 > > > > #11 0xc0a8d19e in bufstrategy (bo=3D0xc6b901bc, bp=3D0xdef881fc) at > > > > vnode_if.h:940 > > > > #12 0xc0a9352e in bufwrite (bp=3D0xdef881fc) at buf.h:404 > > > > #13 0xc0a8db5c in vfs_bio_awrite (bp=3D0xdef881fc) at buf.h:392 > > > > #14 0xc0c584c5 in ffs_syncvnode (vp=3D0xc6b90110, waitfor=3D1) > > > > at /usr/src/sys/ufs/ffs/ffs_vnops.c:288 > > > > #15 0xc0c58739 in ffs_fsync (ap=3D0xf1983c4c) > > > > at /usr/src/sys/ufs/ffs/ffs_vnops.c:187 > > > > #16 0xc0d69712 in VOP_FSYNC_APV (vop=3D0xc102dfc0, a=3D0xf1983c4c) > > > > at vnode_if.c:1267 > > > > #17 0xc0ab5d49 in sys_fsync (td=3D0xc64ea8a0, uap=3D0xf1983cec) at > > > > vnode_if.h:549 > > > > #18 0xc0d49315 in syscall (frame=3D0xf1983d28) at subr_syscall.c:13= 1 > > > > #19 0xc0d32af1 in Xint0x80_syscall () > > > > at /usr/src/sys/i386/i386/exception.s:266 > > > > #20 0x00000033 in ?? ( > > > > > > > > > > > > To me it looks like UFS is doing something to crash the kernel. > > > > > > You might try to use vmstat -z and vmstat -m on core to see what has > > > used KVA. --_002_B2FD678A64EAAD45B089B123FDFC3ED72B9F6C21A7inbmail01lsic_ Content-Type: application/octet-stream; name="xpt_free_ccb.patch" Content-Description: xpt_free_ccb.patch Content-Disposition: attachment; filename="xpt_free_ccb.patch"; size=372; creation-date="Tue, 05 Jun 2012 12:17:56 GMT"; modification-date="Tue, 05 Jun 2012 17:12:59 GMT" Content-Transfer-Encoding: base64 LS0tIHNjc2kvc2NzaV9hbGwuYwkyMDEyLTAxLTI1IDA2OjQ2OjE3LjAwMDAwMDAwMCArMDUzMAor Kysgc2NzaS9zY3NpX2FsbF9uZXcuYwkyMDEyLTA2LTA2IDAxOjM2OjE2LjAwMDAwMDAwMCArMDUz MApAQCAtMzA1Niw3ICszMDU2LDkgQEAgc2NzaV9jb21tYW5kX3N0cmluZyhzdHJ1Y3QgY2FtX2Rl dmljZSAqZAogCQkJICAgIHNjc2lfY2RiX3N0cmluZyhjc2lvLT5jZGJfaW8uY2RiX2J5dGVzLCBj ZGJfc3RyLAogCQkJCQkgICAgc2l6ZW9mKGNkYl9zdHIpKSk7CiAJfQotCisjaWZkZWYgX0tFUk5F TAorICAgIHhwdF9mcmVlX2NjYigodW5pb24gY2NiKiljZ2QpOworI2VuZGlmIC8qIF9LRVJORUwv IV9LRVJORUwgKi8KIAlyZXR1cm4oMCk7CiB9CiAK --_002_B2FD678A64EAAD45B089B123FDFC3ED72B9F6C21A7inbmail01lsic_-- From owner-freebsd-fs@FreeBSD.ORG Tue Jun 5 20:37:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EEC91065672 for ; Tue, 5 Jun 2012 20:37:28 +0000 (UTC) (envelope-from jjuanino@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E29538FC17 for ; Tue, 5 Jun 2012 20:37:27 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so5509106wgb.31 for ; Tue, 05 Jun 2012 13:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-operating-system :user-agent; bh=2dr/94Ncoz3NIUcIZhRyYiHnBV93+q/r9qMs+MX8ONQ=; b=sVInUClsqpgko8kVK4xQMSMNtlQwpESQEvx4/mt3MVqqKBVu1jP3xaDeS+aAUfZ9pe bOR26Jn3aHkW2HnEnF9vjKTJFEipog7/REbIgf5Dw6E9XWIUNrZgLf47PxrhuNdvalFN j7rK9mqXNKi68Hki+3vYQ4inuIBnUSUMtNn9ZStJaRNFVa5RrdpyzqTp6T5/mMaTMWRh +xVzyZRyCP3g7dHYe1NSlpQ/ms826azQSfyErpfl0r8CYcfFK7ZxPv84gx0zKrLk5ZQi wjzSofl+Ex1SYkHCVwvp7F6YcWtRCsvRPpN/+oj5HgpNlzj4saRGzzRiQvVATn0Q9hIv ogOQ== Received: by 10.216.141.164 with SMTP id g36mr3243646wej.119.1338928646271; Tue, 05 Jun 2012 13:37:26 -0700 (PDT) Received: from banach (128.red-80-26-197.adsl.dynamic.ccgg.telefonica.net. [80.26.197.128]) by mx.google.com with ESMTPS id k8sm9443044wia.6.2012.06.05.13.37.25 (version=SSLv3 cipher=OTHER); Tue, 05 Jun 2012 13:37:25 -0700 (PDT) Date: Tue, 5 Jun 2012 22:37:21 +0200 From: Jose Garcia Juanino To: Ronald Klop Message-ID: <20120605203718.GA2630@banach> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: "panic: snapblkfree: inconsistent block type" on FreeBSD 9.0 RELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 20:37:28 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El lunes 04 de junio a las 14:07:58 CEST, Ronald Klop escribi=F3: > On Sun, 03 Jun 2012 20:08:07 +0200, Jos=E9 Garc=EDa Juanino =20 > wrote: >=20 > > On 3 June 2012 14:16, Jos=E9 Garc=EDa Juanino wrot= e: > >> Hi, > >> > >> I am getting a lot of "snapblkfree: inconsistent block type" panics on > >> my FreeBSD 9.0-RELEASE. My file systems have not any inconsistencies, > >> I am checked them with fsck. But I have some snapshots with softupdate > >> inconsistencies (fsck_ffs /path/to/snapshot), and I suspect that may > >> be the cause of the panics. I have several questions: > >> > >> 1- Snapshots with fsck inconsistencies might be the cause of my panics? > >> 2- Should I remove any of such "corrupt" snapshots? > >> > >> If someone is interested, I can provide a full backtrace. Kernel is > >> GENERIC, with no tweaks. File system are been created with normal > >> "newfs -U". No special setting is using. > > > > I have three full core dumps: > > > > http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.1 > > http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.2 > > http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.3 > > > > The relevant code is, in the three examples: > > > > #3 0xffffffff80a40124 in ffs_snapblkfree (fs=3D0xfffffe0002deb000, > > devvp=3DVariable "devvp" is not available. > > ) > > at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1799 > > > > Regards >=20 > I don't know about the internals of FFS, but I know there were some fixes= =20 > to FFS + snapshots ( + journal (SUJ) ??) after 9.0-RELEASE. So maybe you = =20 > can test updating to and running with 9-STABLE. Thanks for your reply. I cannot upgrade to 9-STABLE; it is a production environment and only can run -RELEASE. In the other hand, I removed the unclean snapshots (checked with fsck_ffs), but unfortunately did not help and I got a new "snapblkfree: inconsistent block type" panic a few hours later. At this moment, the overall of filesystems and snapshots were clean (checked again with fsck). When the system started up again, I decided remove all the snapshots, but while I am doing this work, the computer again raised a new panic: "ffs_blkfree_cg: freeing free block". Related this panic, I found this post on freebsd-current: http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028860.html I am almost sure I have not hardware failures. Indeed, after that panic, I definitively removed all the remaining snapshots, and did a new fsck on the filesystems. The system now goes smoothly, and the computer does not panic anymore. My advices, after this experiences: never keep snapshots (clean or unclean) if your filesystem was not clean at some previous stage. The overall of panics I have suffered are related with a previous dirty mounted filesystem and several taken snapshots IMHO. Regards, and excuse me if my english is not clear enough. --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/Obf4ACgkQFOo0zaS9RnJoiwCeL8VLMhsjlhIoVFOX7esnLm6H b8oAnjGAAtvb7lRaxOi87Yyd7/hck1dU =A58G -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 06:24:20 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBFE9106564A for ; Wed, 6 Jun 2012 06:24:20 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 5E2878FC12 for ; Wed, 6 Jun 2012 06:24:20 +0000 (UTC) Received: from happy.home.yamagi.org (hmbg-5f767d17.pool.mediaWays.net [95.118.125.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTPSA id E23F21666334; Wed, 6 Jun 2012 08:24:18 +0200 (CEST) Date: Wed, 6 Jun 2012 08:24:12 +0200 From: Yamagi Burmeister To: jjuanino@gmail.com Message-Id: <20120606082412.bd21757e.lists@yamagi.org> In-Reply-To: <20120605203718.GA2630@banach> References: <20120605203718.GA2630@banach> X-Mailer: Sylpheed 3.1.4 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__6_Jun_2012_08_24_12_+0200_2Uf/RJ5bsCQxVA3+" Cc: freebsd-fs@freebsd.org, ronald-freebsd8@klop.yi.org Subject: Re: "panic: snapblkfree: inconsistent block type" on FreeBSD 9.0 RELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 06:24:21 -0000 --Signature=_Wed__6_Jun_2012_08_24_12_+0200_2Uf/RJ5bsCQxVA3+ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello :) On Tue, 5 Jun 2012 22:37:21 +0200 Jose Garcia Juanino wrote: > > > I have three full core dumps: > > > > > > http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.1 > > > http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.2 > > > http://www.mipaginapersonal.movistar.es/web3/jjuanino/core.txt.3 > > > > > > The relevant code is, in the three examples: > > > > > > #3 0xffffffff80a40124 in ffs_snapblkfree (fs=3D0xfffffe0002deb000, > > > devvp=3DVariable "devvp" is not available. > > > ) > > > at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1799 > > > > > > Regards > >=20 > > I don't know about the internals of FFS, but I know there were some fix= es =20 > > to FFS + snapshots ( + journal (SUJ) ??) after 9.0-RELEASE. So maybe yo= u =20 > > can test updating to and running with 9-STABLE. >=20 > Thanks for your reply. I cannot upgrade to 9-STABLE; it is a production > environment and only can run -RELEASE. In the other hand, I removed the > unclean snapshots (checked with fsck_ffs), but unfortunately did not > help and I got a new "snapblkfree: inconsistent block type" panic a few > hours later. At this moment, the overall of filesystems and snapshots > were clean (checked again with fsck). > > When the system started up again, I decided remove all the snapshots, > but while I am doing this work, the computer again raised a new panic: > "ffs_blkfree_cg: freeing free block". Related this panic, I found this > post on freebsd-current: >=20 > http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028860.ht= ml >=20 > I am almost sure I have not hardware failures. Indeed, after that panic, > I definitively removed all the remaining snapshots, and did a new fsck on > the filesystems. The system now goes smoothly, and the computer does not > panic anymore. If you're using SU+J this is a known problem. In 9.0-RELEASE creating and removing snapshots on filesystems with SU+J has a high chance to lead to panics, filesystem corruption and several more not so nice things. While there were some commits in 9-STABLE in that area, snapshots are still not working with SU+J. They are disabled and an error messages is printed when you try to create one. --=20 Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Signature=_Wed__6_Jun_2012_08_24_12_+0200_2Uf/RJ5bsCQxVA3+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/O95EACgkQWTjlg++8y8vMggCggO8vZlIzYD1v9tSoNUVmYa01 DhYAoLWMiRUVp2StlMc5D+buySNq+RSP =rEVV -----END PGP SIGNATURE----- --Signature=_Wed__6_Jun_2012_08_24_12_+0200_2Uf/RJ5bsCQxVA3+-- From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 07:49:37 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F311C1065689 for ; Wed, 6 Jun 2012 07:49:37 +0000 (UTC) (envelope-from jjuanino@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 790B18FC12 for ; Wed, 6 Jun 2012 07:49:37 +0000 (UTC) Received: by bkvi18 with SMTP id i18so6873382bkv.13 for ; Wed, 06 Jun 2012 00:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=fo4EZjLZhliCddXsCNL+OOr7Tcp+4QnJ2qyiJBN8rVk=; b=vRXGNLBpiCzg0qLb+f9M/Q/Hz8bgQfcDqODcPV8Rr4l7rcY9RJTOau7Ab0DqTO+lNW 0dTb6A5OCbI4JFzlhJR9sG92xL8PUg+Fr0b6eT7qCJlMP7iRAChHoC0ogu/YdVau8zBK Azpeoe6r7eBz/kaYAO8JhWBKnleZgw6nZR9+udgQvAlfzJZJlsAGiNr/7X/a0oNL6k+T x/CcPRDUoyzX8zpXqJwcF/MnnzGCs8nSQZqj3kKfKEroF/sUHVWYPAPIFHoDA2sQX6Mf 9Szjs9dEQH67oLJC1M5OFWNOFlCuN7TiwrPFGKyJ4nd1wosBSzQA4xemsyCH2uWYQQ1q GL9Q== MIME-Version: 1.0 Received: by 10.204.154.138 with SMTP id o10mr11095068bkw.34.1338968976450; Wed, 06 Jun 2012 00:49:36 -0700 (PDT) Received: by 10.205.114.140 with HTTP; Wed, 6 Jun 2012 00:49:36 -0700 (PDT) In-Reply-To: <20120606082412.bd21757e.lists@yamagi.org> References: <20120605203718.GA2630@banach> <20120606082412.bd21757e.lists@yamagi.org> Date: Wed, 6 Jun 2012 09:49:36 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Garc=EDa_Juanino?= To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: "panic: snapblkfree: inconsistent block type" on FreeBSD 9.0 RELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 07:49:38 -0000 On 6 June 2012 08:24, Yamagi Burmeister wrote: > On Tue, 5 Jun 2012 22:37:21 +0200 Jose Garcia Juanino wrote: > >> I am almost sure I have not hardware failures. Indeed, after that panic, >> I definitively removed all the remaining snapshots, and did a new fsck on >> the filesystems. The system now goes smoothly, and the computer does not >> panic anymore. > > If you're using SU+J this is a known problem. In 9.0-RELEASE creating > and removing snapshots on filesystems with SU+J has a high chance to > lead to panics, filesystem corruption and several more not so nice > things. While there were some commits in 9-STABLE in that area, > snapshots are still not working with SU+J. They are disabled and > an error messages is printed when you try to create one. Thanks for your reply. No, I have not journaling activated, are filesystems with soft updates, but no journal. I am watching the syslog, and after a crash (4 weeks ago) I see that a filesystem was not fully cleaned at startup: : UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. The system stopped, and a single user shell opened. But the system administrator at this moment simply ignored that issue, and hit "exit" in the shell. I believe that error was the start of my headaches: never an unclean filesystem must be mounted. Regards From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 10:01: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 E0243106564A for ; Wed, 6 Jun 2012 10:01:11 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 73B7C8FC08 for ; Wed, 6 Jun 2012 10:01:11 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3416:7ba8:97b:e894]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id CBAF34AC1C; Wed, 6 Jun 2012 14:01:09 +0400 (MSK) Date: Wed, 6 Jun 2012 14:01:05 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1842465203.20120606140105@serebryakov.spb.ru> To: =?iso-8859-1?Q?Jos=E9_Garc=EDa_Juanino?= In-Reply-To: References: <20120605203718.GA2630@banach> <20120606082412.bd21757e.lists@yamagi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: "panic: snapblkfree: inconsistent block type" on FreeBSD 9.0 RELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 10:01:12 -0000 Hello, Jos=C3=A9. You wrote 6 =D0=B8=D1=8E=D0=BD=D1=8F 2012 =D0=B3., 11:49:36: JGJ> Thanks for your reply. No, I have not journaling activated, are JGJ> filesystems with soft updates, but no journal. I am watching the JGJ> syslog, and after a crash (4 weeks ago) I see that a filesystem was JGJ> not fully cleaned at startup: JGJ> : UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. JGJ> The system stopped, and a single user shell opened. But the system JGJ> administrator at this moment simply ignored that issue, and hit "exit" JGJ> in the shell. I believe that error was the start of my headaches: JGJ> never an unclean filesystem must be mounted. It is what I'm ranting about for more than year, but only answers are "Your hardware is broken, on good hardware there should not be those errors" and "Use ZFS" :( Last time I've raised this question (about month ago) everybody told me how good ZFS is, and it's all :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 10:38:25 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C9B11065670 for ; Wed, 6 Jun 2012 10:38:25 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 08A728FC0A for ; Wed, 6 Jun 2012 10:38:25 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1ScDd8-0008Tn-W2; Wed, 06 Jun 2012 13:38:23 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 0A85F1CC21; Wed, 6 Jun 2012 13:38:23 +0300 (EEST) Date: Wed, 6 Jun 2012 13:38:22 +0300 From: Andrey Simonenko To: Rick Macklem Message-ID: <20120606103822.GA53529@pm513-1.comsys.ntu-kpi.kiev.ua> References: <20120511122020.GA13906@pm513-1.comsys.ntu-kpi.kiev.ua> <1493074817.296570.1336787111152.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1493074817.296570.1336787111152.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-06-06 13:38:23 X-Connected-IP: 10.18.52.101:61411 X-Message-Linecount: 96 X-Body-Linecount: 80 X-Message-Size: 4907 X-Body-Size: 4180 Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 10:38:25 -0000 On Fri, May 11, 2012 at 09:45:11PM -0400, Rick Macklem wrote: > Andrey Simonenko wrote: > > > NetBSD already has -noresvmnt and -noresvport options in their > > exports(5). > > > I'll let others comment w.r.t. whether they have a need for this. To me, > unless others are saying "we need this", I don't see any reason to change > what is already there, except maybe optionally require a reserved port# > for NFSv4 mounts via a sysctl. I comment on this further down. According to exports(5) manual page for Linux, similar option named "secure" also exists in Linux NFS server implementation. [1] > > If a client machine is trusted, then reserved ports can guaranty that > > requests come from privileged processes and not from user space where > > client can fill any credentials in AUTH_SYS. If client machine is not > > trusted, then this will not work of course. BTW mountd requires > > reserved > > port and NFS server does not required reserved port by default. > Well, I agree that, if you have a client machine where "root" is secure > (no root kit vunerabilities, etc) but non-root users on this machine > would potentially run their own bogus userland NFS client, then requiring > a reserved port# does subvert the use of such a bogus NFS client. > (My concern is that some people will think that requiring a reserved port# > makes NFS secure for other cases, like users with their own laptops/desktops.) Current implementation allows to export subdirectories to NFSv2/3 clients. A NFSv2/3 client can guess a filehandle and access any part of exported file system. This is more insecure by design, than option that allows to specify whether reserved port is required for NFS RPC requests. Similar logic is given in RFC2623. > Personally, I think the above case is rare and that having another sysctl > vfs.nfsd.nfsv4_privport (similar to vfs.nfsd.nfs_privport) is sufficient, > but I'll let others comment on this, since it is not my decision. Since nobody commented these ideas, I want to give description of my implementation. If somebody wants to do something similar for mountd, then this description will give some information for thinking at least. Command option for MOUNT protocol settings: -m mntset Specifies whether ... should service MOUNT protocol requests and what it should support from this protocol. The argument is a colon separated list of values: no disables the protocol support, v1 supports version 1 of the protocol (used in NFSv2), v3 sup- ports version 3 of the protocol (used in NFSv3), udp, tcp, udp6 and tcp6 specify which netconfig should be supported for the pro- tocol. Disabling MOUNT protocol or some its version does not disable NFSv2/3 in the NFS server, the same logic is applied for disabled netconfigs. Configuration options: -mnt_mount=arg1[:arg2...] Specify settings for MOUNT protocol's procedures MNT, UMNT and UMNTALL. Available arguments are: default (set default set- tings), regfile (allow MNT requests for regular files), resvport (allow requests from reserved IP ports numbers only). By default MNT requests are allowed for directories only, all requests are allowed from any IP port number. -resvport=value Specify whether NFS and NLM RPC requests should be received from sender's reserved IP port numbers (less than 1024). Available arguments are: default (set default settings), always (reserved sender's IP port number is always required), weakauth (reserved sender's IP port number is required if the AUTH_SYS security fla- vor is used). By default reserved sender's IP port numbers are not required. Well, -resvport option does not work well for NLM RPC requests if non-AUTH_SYS security flavor is used and user credentials on a client differ with user credentials on a server. But NLM does not work in such configuration even without this options, details here [2]. [1] http://www.linuxmanpages.com/man5/exports.5.php [2] http://lists.freebsd.org/pipermail/freebsd-fs/2012-May/014444.html From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 13:23:09 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 749EE106564A for ; Wed, 6 Jun 2012 13:23:09 +0000 (UTC) (envelope-from prvs=150441fdbd=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0A3B78FC15 for ; Wed, 6 Jun 2012 13:23:05 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Wed, 06 Jun 2012 14:22:24 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50020121778.msg for ; Wed, 06 Jun 2012 14:22:23 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=150441fdbd=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@FreeBSD.ORG Message-ID: <7F2BB05E358942F6835E22033840B36A@multiplay.co.uk> From: "Steven Hartland" To: Date: Wed, 6 Jun 2012 14:22:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Subject: zfs receive -o support in FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 13:23:09 -0000 According to Oracle's docs Solaris ZFS supports changing zfs properties on the fly during a zfs receive:- http://docs.oracle.com/cd/E19963-01/html/821-1448/gbchx.html Seems it was added to support:- http://arc.opensolaris.org/caselog/PSARC/2010/193/20100525_thomas.erickson This doesn't seem to be present in the version of ZFS for FreeBSD? Is this something that's coming as its a very handy feature? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 14:05:43 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5950F1065679; Wed, 6 Jun 2012 14:05:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2D5A98FC1D; Wed, 6 Jun 2012 14:05:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7D3F1B97B; Wed, 6 Jun 2012 10:05:42 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Wed, 6 Jun 2012 08:17:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <201203071318.08241.jhb@freebsd.org> <201203091059.29342.jhb@freebsd.org> <201203161406.27549.jhb@freebsd.org> In-Reply-To: <201203161406.27549.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201206060817.54684.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 06 Jun 2012 10:05:42 -0400 (EDT) Cc: pho@freebsd.org, Konstantin Belousov Subject: Re: close() of an flock'd file is not atomic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 14:05:43 -0000 On Friday, March 16, 2012 2:06:27 pm John Baldwin wrote: > On Friday, March 09, 2012 10:59:29 am John Baldwin wrote: > > On Thursday, March 08, 2012 5:39:19 pm Konstantin Belousov wrote: > > > On Thu, Mar 08, 2012 at 03:39:07PM -0500, John Baldwin wrote: > > > > On Wednesday, March 07, 2012 1:18:07 pm John Baldwin wrote: > > > > > So I ran into this problem at work. Suppose you have a process that opens a > > > > > read-write file descriptor with O_EXLOCK (so it has an flock()). It then > > > > > writes out a binary into that file. Another process wants to execve() the > > > > > file when it is ready, so it opens the file with O_EXLOCK (or O_SHLOCK), and > > > > > will call execve() once it has locked the file. In theory, what should happen > > > > > is that the second process should wait until the first process has finished > > > > > and called close(). In practice what happens is that I occasionally see the > > > > > second process fail with ETXTBUSY. > > > > > > > > > > The bug is that the vn_closefile() does the VOP_ADVLOCK() to unlock the file > > > > > separately from the call to vn_close() which drops the writecount. Thus, the > > > > > second process can do an open() and flock() of the file and subsequently call > > > > > execve() after the first process has done the VOP_ADVLOCK(), but before it > > > > > calls into vn_close(). In fact, since vn_close() requires a write lock on the > > > > > vnode, this turns out to not be too hard to reproduce at all. Below is a > > > > > simple test program that reproduces this constantly. To use, copy /bin/test > > > > > to some other file (e.g. /tmp/foo) and make it writable (chmod a+w), then run > > > > > ./flock_close_race /tmp/foo. > > > > > > > > > > The "fix" I came up with is to defer calling VOP_ADVLOCK() to release the lock > > > > > until after vn_close() executes. However, even with that fix applied, my test > > > > > case still fails. Now it is because open() with a given lock flag is > > > > > non-atomic in that the open(O_RDWR) will call vn_open() and bump v_writecount > > > > > before it blocks on the lock due to O_EXLOCK, so even though the 'exec_child' > > > > > process has the fd locked, the writecount can still be bumped. One gross hack > > > > > would be to defer the bump of the writecount to the caller of vn_open() if the > > > > > caller passes in O_EXLOCK or O_SHLOCK, but that's a really gross kludge, plus > > > > > it doesn't actually work. I ended up moving acquiring the lock into > > > > > vn_open_cred(). The current patch I'm testing has both of these approaches, > > > > > but the first one is #if 0'd out, and the second is #if 1'd. > > > > > > > > > > http://www.freebsd.org/~jhb/patches/flock_open_close.patch > > > > > > > > Based on some feedback from Konstantin, I've fixed some issues in the failure > > > > path handling for VOP_ADVLOCK(). I've also removed the #if 0'd code mentioned > > > > above, so the patch is now the actual change that I'm testing. So far it > > > > handles both my workload at work and my test program without any issues. > > > > > > I think a comment is needed for a reason to call vn_writechk() second time. > > > > Fixed. > > > > > Could you, please, point me, where the FHASLOCK is set for O_EXLOCK | O_SHLOCK > > > case in the patched kernel ? > > > > It wasn't. :( I wonder how this was even working since close shouldn't have > > been unlocking. I'll need to do some more testing. BTW, I ran into fhopen() > > and found that I would need to put all this same logic into that, so I've split > > the common code from fhopen() and vn_open_cred() into a new vn_open_vnode(). > > I think in general it improves both sets of code. > > > > I'll upate the patch once I've done some more testing. Based on feedback from Konstantin, I have split the vn_open_vnode() changes out into a separate patch. Once that patch is in the tree I will revisit this and update the actual bug-fix patch. The vn_open_vnode() patch is at http://www.freebsd.org/~jhb/patches/vn_open_vnode.patch I tested it by doing a buildworld -j 32 in a loop while NFS exporting the /usr/obj tree to another machine that did a continual find | xargs md5 loop over the /usr/obj tree. This survived overnight. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 14:05:44 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FD88106566B; Wed, 6 Jun 2012 14:05:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D4AE88FC1F; Wed, 6 Jun 2012 14:05:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 43309B98D; Wed, 6 Jun 2012 10:05:43 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Wed, 6 Jun 2012 08:19:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <20120601125824.GV2358@deviant.kiev.zoral.com.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201206060819.05864.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 06 Jun 2012 10:05:43 -0400 (EDT) Cc: "Desai, Kashyap" , "Kenneth D. Merry" , "Reddy, Sreekanth" , "freebsd-scsi@freebsd.org" , "McConnell, Stephen" Subject: Re: Kernel panic in FreeBSD-8.3 from UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 14:05:44 -0000 On Tuesday, June 05, 2012 8:19:05 am Desai, Kashyap wrote: > Hi All, > > We found some potential area of memory leak in CAM layer. > CAM XPT Memory leak is due to following function in scsi/scsi_all.c > > int > scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb) > > > In above function, CAM layer allocate memory for ccb device as below > if ((cgd = (struct ccb_getdev*)xpt_alloc_ccb_nowait()) == NULL) > > > _But_, unfortunately we never free the allocated memory and we see memory leak of 2K every time when someone is calling > Scsi_command_string from kernel mode. > > > Attached is a proposed patch for this issue. The patch looks correct to me. Can one of the CAM folks (Ken?) review it and commit it? -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 14:33: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 EFA921065672 for ; Wed, 6 Jun 2012 14:33:32 +0000 (UTC) (envelope-from rafaelhfaria@cenadigital.com.br) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by mx1.freebsd.org (Postfix) with ESMTP id A3F048FC1B for ; Wed, 6 Jun 2012 14:33:32 +0000 (UTC) Received: by qabj40 with SMTP id j40so3550145qab.15 for ; Wed, 06 Jun 2012 07:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cenadigital.com.br; s=mail; h=mime-version:from:date:message-id:subject:to:content-type; bh=AXhCDC2SYeudxxDyLLLByZY3anMcB2ST2SsHJV6Zs5s=; b=QdFWlY3Q2ti7JFj5IVDaXs3mcZ1nSoGws0DmNXj6x5Qpr8aNY3Tsf4lCDhp0hlZwsR upXCcVtkOkjIXrtohLfPcZsmrIbR98mbI0Wm2xzps9QoCyGFFN34rxqTmJ4csxuWJkvo YwKv2R2/z6QzEMmKzkBQRO6qXmeJBjZjgV9Vw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=AXhCDC2SYeudxxDyLLLByZY3anMcB2ST2SsHJV6Zs5s=; b=MHfaFuG1uOThRyE99EcLM/ilaTWrdjHS1WhQEpBxy6/sASPssidBNaD3b10T7cPlAq K5e7EfuhijctxSSxVVsguPQGHsoeUgdtaIvZCcL9Pcb3VhLrxxjN9VugjErnx/OCAcGR lyhvg+/7VHE2XZ7hPSb4/jprtHxXnWt3V+TnK2nEaUsFq0TfwRhSvJW+ZUvyveWad7nf LsecWiLGdBN9JeAbRWDjtEKAmO+Bi/5KBzB9oqynX9WRcJK/iVX5cXepqeL4fEZuj706 vQD3bb0ezhJVhHLnaZi/xAOERLvaYz7xsjHSpyBLhsVHpbQPZ7x8xg1Q0Z8sexlOdx2C 9FrA== Received: by 10.229.137.14 with SMTP id u14mr720850qct.87.1338993211769; Wed, 06 Jun 2012 07:33:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.149 with HTTP; Wed, 6 Jun 2012 07:32:50 -0700 (PDT) From: Rafael Henrique Faria Date: Wed, 6 Jun 2012 11:32:50 -0300 Message-ID: To: freebsd-fs@freebsd.org X-Gm-Message-State: ALoCoQklT98jdiPPaWVF/g569Qjc9f/jLrIlPm/NdGZjO0/8iLPAioJ/eWiej4o9ByGuVQwoIWIM Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: UFS2 space usage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 14:33:33 -0000 Hi. I'm transferring a disk from my MacBook to my FreeBSD server, it's a 500GB 3,5" disk in an USB enclosure. As I was using it in MacOS, it was formated with HFS+. So I transfered all data from it to an second disk. Then I reformatted the disk inside the FreeBSD 9.0, using GPT, and using all disk (with HFS+ there was a EFI partition, plus a free space in the beginning and in the end of the disk). I used this options for newfs: "-U2 -o space". The 500GB disk in HFS+, was with 2GB free, so 498GB in use. (Apple, uses 1 K as 1000 Bytes, and 1 M as 1000 K, so you really see 500GB of free space and occupied). After trying to move the data back to the 500GB disk formated in UFS2, 44GB couldn't be transferred. There is no free space for all the data. In FreeBSD it says that the disk have 458GB, and is using 415GB, and have 6.2GB free. But I still have 48GB of data to transfer to it. Is HFS+ more optimized to store files then UFS2? There is something that I can do to get more space for data? Thanks in advance. -- Rafael Henrique da Silva Faria From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 14:54: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 CD87A1065675 for ; Wed, 6 Jun 2012 14:54:10 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id 6FA0C8FC14 for ; Wed, 6 Jun 2012 14:54:10 +0000 (UTC) Received: (qmail 94312 invoked by uid 110); 6 Jun 2012 14:54:03 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 6 Jun 2012 14:54:03 -0000 From: "Simon" To: "freebsd-fs@freebsd.org" , "Rafael Henrique Faria" Date: Wed, 06 Jun 2012 10:54:01 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: MIME-Version: 1.0 Message-Id: <20120606145410.CD87A1065675@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: UFS2 space usage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 14:54:10 -0000 Take a look at man tunefs and the option -m Your issue is likely related to this. Besides that, UFS possibly uses more space to store metadata, etc... Haven't looked into this in long time, your inode size probably also affects total space available. When you were copying your data, were you doing it as root as normal user? Normal user won't be able to go beyond the reserved 8% (default), but root can, although this is bad a idea long-term. -Simon On Wed, 6 Jun 2012 11:32:50 -0300, Rafael Henrique Faria wrote: >Hi. >I'm transferring a disk from my MacBook to my FreeBSD server, it's a 500GB >3,5" disk in an USB enclosure. >As I was using it in MacOS, it was formated with HFS+. So I transfered all >data from it to an second disk. >Then I reformatted the disk inside the FreeBSD 9.0, using GPT, and using >all disk (with HFS+ there was a EFI partition, plus a free space in the >beginning and in the end of the disk). >I used this options for newfs: "-U2 -o space". >The 500GB disk in HFS+, was with 2GB free, so 498GB in use. (Apple, uses 1 >K as 1000 Bytes, and 1 M as 1000 K, so you really see 500GB of free space >and occupied). >After trying to move the data back to the 500GB disk formated in UFS2, 44GB >couldn't be transferred. There is no free space for all the data. >In FreeBSD it says that the disk have 458GB, and is using 415GB, and have >6.2GB free. But I still have 48GB of data to transfer to it. >Is HFS+ more optimized to store files then UFS2? There is something that I >can do to get more space for data? >Thanks in advance. >-- >Rafael Henrique da Silva Faria >_______________________________________________ >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 Wed Jun 6 15:49:55 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD721106564A for ; Wed, 6 Jun 2012 15:49:55 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 26A198FC17 for ; Wed, 6 Jun 2012 15:49:54 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBF89A.dip.t-dialin.net [93.203.248.154]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id q56FnlKd034696; Wed, 6 Jun 2012 15:49:48 GMT (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 q56FndZ0006725; Wed, 6 Jun 2012 17:49:39 +0200 (CEST) (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 q56FnLmk093064; Wed, 6 Jun 2012 17:49:27 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201206061549.q56FnLmk093064@fire.js.berklix.net> To: "Simon" 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 "Wed, 06 Jun 2012 10:54:01 EDT." <20120606145410.CD87A1065675@hub.freebsd.org> Date: Wed, 06 Jun 2012 17:49:21 +0200 Sender: jhs@berklix.com Cc: "freebsd-fs@freebsd.org" Subject: Re: UFS2 space usage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:49:55 -0000 "Simon" wrote: > > Take a look at man tunefs and the option -m Your issue is likely related to this. > Besides that, UFS possibly uses more space to store metadata, etc... Haven't > looked into this in long time, your inode size probably also affects total space > available. Apart from how many spare inodes you have, & the spare (root only accesible), mainly think block sizes (eg fsize bsize as shown by disklabel - though I see mine are now zero) efficiency depends on data type, a directory full of news & mail needs lots of little files, so use small blocks, films=movies are more efficient with large blocks. man tunefs # -b man newfs > > When you were copying your data, were you doing it as root as normal user? > Normal user won't be able to go beyond the reserved 8% (default), but root > can, although this is bad a idea long-term. > > -Simon > > On Wed, 6 Jun 2012 11:32:50 -0300, Rafael Henrique Faria wrote: > > >Hi. > > >I'm transferring a disk from my MacBook to my FreeBSD server, it's a 500GB > >3,5" disk in an USB enclosure. > >As I was using it in MacOS, it was formated with HFS+. So I transfered all > >data from it to an second disk. > >Then I reformatted the disk inside the FreeBSD 9.0, using GPT, and using > >all disk (with HFS+ there was a EFI partition, plus a free space in the > >beginning and in the end of the disk). > >I used this options for newfs: "-U2 -o space". > > >The 500GB disk in HFS+, was with 2GB free, so 498GB in use. (Apple, uses 1 > >K as 1000 Bytes, and 1 M as 1000 K, so you really see 500GB of free space > >and occupied). > > >After trying to move the data back to the 500GB disk formated in UFS2, 44GB > >couldn't be transferred. There is no free space for all the data. > > >In FreeBSD it says that the disk have 458GB, and is using 415GB, and have > >6.2GB free. But I still have 48GB of data to transfer to it. > > >Is HFS+ more optimized to store files then UFS2? There is something that I > >can do to get more space for data? > > >Thanks in advance. > > >-- > >Rafael Henrique da Silva Faria Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, & indent with "> ". Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 17:06:42 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 168471065672; Wed, 6 Jun 2012 17:06:42 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id CC4A28FC18; Wed, 6 Jun 2012 17:06:41 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q56H6fXr098454; Wed, 6 Jun 2012 11:06:41 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q56H6f3O098453; Wed, 6 Jun 2012 11:06:41 -0600 (MDT) (envelope-from ken) Date: Wed, 6 Jun 2012 11:06:41 -0600 From: "Kenneth D. Merry" To: "Desai, Kashyap" Message-ID: <20120606170640.GA98428@nargothrond.kdm.org> References: <20120601124338.GU2358@deviant.kiev.zoral.com.ua> <20120601125824.GV2358@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: "freebsd-scsi@freebsd.org" , "freebsd-fs@freebsd.org" , "McConnell, Stephen" , "Reddy, Sreekanth" Subject: Re: Kernel panic in FreeBSD-8.3 from UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 17:06:42 -0000 On Tue, Jun 05, 2012 at 17:49:05 +0530, Desai, Kashyap wrote: > Hi All, > > We found some potential area of memory leak in CAM layer. > CAM XPT Memory leak is due to following function in scsi/scsi_all.c > > int > scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb) > > > In above function, CAM layer allocate memory for ccb device as below > if ((cgd = (struct ccb_getdev*)xpt_alloc_ccb_nowait()) == NULL) > > > _But_, unfortunately we never free the allocated memory and we see memory leak of 2K every time when someone is calling > Scsi_command_string from kernel mode. > > > Attached is a proposed patch for this issue. The patch looks good, I just committed it. Thanks! Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 18:39:58 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 09A7E1065676; Wed, 6 Jun 2012 18:39:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5F39F8FC08; Wed, 6 Jun 2012 18:39:57 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q56IdoaO057089; Wed, 6 Jun 2012 21:39:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q56Idng5022856; Wed, 6 Jun 2012 21:39:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q56Idn4E022855; Wed, 6 Jun 2012 21:39:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 6 Jun 2012 21:39:49 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120606183949.GR85127@deviant.kiev.zoral.com.ua> References: <201203071318.08241.jhb@freebsd.org> <201203091059.29342.jhb@freebsd.org> <201203161406.27549.jhb@freebsd.org> <201206060817.54684.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="im83/wVv0jiGQj4J" Content-Disposition: inline In-Reply-To: <201206060817.54684.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, pho@freebsd.org Subject: Re: close() of an flock'd file is not atomic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 18:39:58 -0000 --im83/wVv0jiGQj4J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 06, 2012 at 08:17:54AM -0400, John Baldwin wrote: > Based on feedback from Konstantin, I have split the vn_open_vnode() chang= es > out into a separate patch. Once that patch is in the tree I will revisit > this and update the actual bug-fix patch. >=20 > The vn_open_vnode() patch is at > http://www.freebsd.org/~jhb/patches/vn_open_vnode.patch >=20 > I tested it by doing a buildworld -j 32 in a loop while NFS exporting the > /usr/obj tree to another machine that did a continual find | xargs md5 lo= op > over the /usr/obj tree. This survived overnight. There is #if 0 left in fhopen() which translates ERESTART into EINTR. Is it needed ? Otherwise it looks fine (but still quite hard to read). --im83/wVv0jiGQj4J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/Po/UACgkQC3+MBN1Mb4iWTgCdFuHxkGYMpxn4NuorK/BUAotw hX4An1rW4uWY9b4v1e8Jex037CeeZ8XY =dcfI -----END PGP SIGNATURE----- --im83/wVv0jiGQj4J-- From owner-freebsd-fs@FreeBSD.ORG Wed Jun 6 20:34: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 AFD99106564A; Wed, 6 Jun 2012 20:34:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 29CFA8FC1B; Wed, 6 Jun 2012 20:34:33 +0000 (UTC) Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q56KYNUa013150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jun 2012 06:34:24 +1000 Date: Thu, 7 Jun 2012 06:34:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120606183949.GR85127@deviant.kiev.zoral.com.ua> Message-ID: <20120607062703.P955@besplex.bde.org> References: <201203071318.08241.jhb@freebsd.org> <201203091059.29342.jhb@freebsd.org> <201203161406.27549.jhb@freebsd.org> <201206060817.54684.jhb@freebsd.org> <20120606183949.GR85127@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, pho@FreeBSD.org, John Baldwin Subject: Re: close() of an flock'd file is not atomic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 20:34:34 -0000 On Wed, 6 Jun 2012, Konstantin Belousov wrote: > On Wed, Jun 06, 2012 at 08:17:54AM -0400, John Baldwin wrote: >>... >> The vn_open_vnode() patch is at >> http://www.freebsd.org/~jhb/patches/vn_open_vnode.patch >> >> I tested it by doing a buildworld -j 32 in a loop while NFS exporting the >> /usr/obj tree to another machine that did a continual find | xargs md5 loop >> over the /usr/obj tree. This survived overnight. > > There is #if 0 left in fhopen() which translates ERESTART into EINTR. Is > it needed ? > > Otherwise it looks fine (but still quite hard to read). This translation in the old code causes the following bogus behaviour: - some device drivers try to restart open() after revoke(). They return ERESTART for this. But open never restarts, due to this translation. Never restarting may be correct, but EINTR is a bogus errno unless the open was actually interrupted by a signal, in which case the driver should have returned EINTR. ENXIO is closest to describing "killed by revoke". What case is the translation supposed to fix? Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Jun 7 12:37:52 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 B3B67106566B; Thu, 7 Jun 2012 12:37:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 872468FC1A; Thu, 7 Jun 2012 12:37:52 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E4A6CB96F; Thu, 7 Jun 2012 08:37:51 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Thu, 7 Jun 2012 08:17:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <201203071318.08241.jhb@freebsd.org> <20120606183949.GR85127@deviant.kiev.zoral.com.ua> <20120607062703.P955@besplex.bde.org> In-Reply-To: <20120607062703.P955@besplex.bde.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206070817.26342.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 07 Jun 2012 08:37:52 -0400 (EDT) Cc: pho@freebsd.org Subject: Re: close() of an flock'd file is not atomic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 12:37:52 -0000 On Wednesday, June 06, 2012 4:34:23 pm Bruce Evans wrote: > On Wed, 6 Jun 2012, Konstantin Belousov wrote: > > > On Wed, Jun 06, 2012 at 08:17:54AM -0400, John Baldwin wrote: > >>... > >> The vn_open_vnode() patch is at > >> http://www.freebsd.org/~jhb/patches/vn_open_vnode.patch > >> > >> I tested it by doing a buildworld -j 32 in a loop while NFS exporting the > >> /usr/obj tree to another machine that did a continual find | xargs md5 loop > >> over the /usr/obj tree. This survived overnight. > > > > There is #if 0 left in fhopen() which translates ERESTART into EINTR. Is > > it needed ? > > > > Otherwise it looks fine (but still quite hard to read). > > This translation in the old code causes the following bogus behaviour: > - some device drivers try to restart open() after revoke(). They return > ERESTART for this. But open never restarts, due to this translation. > Never restarting may be correct, but EINTR is a bogus errno unless the > open was actually interrupted by a signal, in which case the driver > should have returned EINTR. ENXIO is closest to describing "killed > by revoke". > > What case is the translation supposed to fix? I have no idea. :( I will take it out of fhopen() however since presumably fhopen() will not be used on devices (devfs doesn't have VOPs for filehandles and is not exportable). -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Thu Jun 7 12:55:33 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E719E106566B; Thu, 7 Jun 2012 12:55:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id BB0A28FC16; Thu, 7 Jun 2012 12:55:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3C949B977; Thu, 7 Jun 2012 08:55:33 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Date: Thu, 7 Jun 2012 08:41:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <201203071318.08241.jhb@freebsd.org> <201206060817.54684.jhb@freebsd.org> <20120606183949.GR85127@deviant.kiev.zoral.com.ua> In-Reply-To: <20120606183949.GR85127@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201206070841.00656.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 07 Jun 2012 08:55:33 -0400 (EDT) Cc: freebsd-fs@freebsd.org, pho@freebsd.org Subject: Re: close() of an flock'd file is not atomic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 12:55:34 -0000 On Wednesday, June 06, 2012 2:39:49 pm Konstantin Belousov wrote: > On Wed, Jun 06, 2012 at 08:17:54AM -0400, John Baldwin wrote: > > Based on feedback from Konstantin, I have split the vn_open_vnode() changes > > out into a separate patch. Once that patch is in the tree I will revisit > > this and update the actual bug-fix patch. > > > > The vn_open_vnode() patch is at > > http://www.freebsd.org/~jhb/patches/vn_open_vnode.patch > > > > I tested it by doing a buildworld -j 32 in a loop while NFS exporting the > > /usr/obj tree to another machine that did a continual find | xargs md5 loop > > over the /usr/obj tree. This survived overnight. > > There is #if 0 left in fhopen() which translates ERESTART into EINTR. Is > it needed ? Bruce's reply makes me think it is not, so I will remove it. > Otherwise it looks fine (but still quite hard to read). I agree the diff is hard to parse. Hopefully the patched code itself is easier to read than the previous version. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Thu Jun 7 14:26:53 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A046C1065678 for ; Thu, 7 Jun 2012 14:26:53 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 4CE258FC0C for ; Thu, 7 Jun 2012 14:26:52 +0000 (UTC) Received: (qmail 75722 invoked from network); 7 Jun 2012 14:20:12 -0000 Received: from 87.58.146.107 (HELO x2.osted.lan) (87.58.146.107) by relay02.pair.com with SMTP; 7 Jun 2012 14:20:12 -0000 X-pair-Authenticated: 87.58.146.107 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id q57EKALe083676; Thu, 7 Jun 2012 16:20:10 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id q57EKAav083675; Thu, 7 Jun 2012 16:20:10 +0200 (CEST) (envelope-from pho) Date: Thu, 7 Jun 2012 16:20:10 +0200 From: Peter Holm To: John Baldwin Message-ID: <20120607142010.GA83575@x2.osted.lan> References: <201203071318.08241.jhb@freebsd.org> <201203091059.29342.jhb@freebsd.org> <201203161406.27549.jhb@freebsd.org> <201206060817.54684.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201206060817.54684.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org, Konstantin Belousov Subject: Re: close() of an flock'd file is not atomic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:26:53 -0000 On Wed, Jun 06, 2012 at 08:17:54AM -0400, John Baldwin wrote: > On Friday, March 16, 2012 2:06:27 pm John Baldwin wrote: > > On Friday, March 09, 2012 10:59:29 am John Baldwin wrote: > > > On Thursday, March 08, 2012 5:39:19 pm Konstantin Belousov wrote: > > > > On Thu, Mar 08, 2012 at 03:39:07PM -0500, John Baldwin wrote: > > > > > On Wednesday, March 07, 2012 1:18:07 pm John Baldwin wrote: > > > > > > So I ran into this problem at work. Suppose you have a process that opens a > > > > > > read-write file descriptor with O_EXLOCK (so it has an flock()). It then > > > > > > writes out a binary into that file. Another process wants to execve() the > > > > > > file when it is ready, so it opens the file with O_EXLOCK (or O_SHLOCK), and > > > > > > will call execve() once it has locked the file. In theory, what should happen > > > > > > is that the second process should wait until the first process has finished > > > > > > and called close(). In practice what happens is that I occasionally see the > > > > > > second process fail with ETXTBUSY. > > > > > > > > > > > > The bug is that the vn_closefile() does the VOP_ADVLOCK() to unlock the file > > > > > > separately from the call to vn_close() which drops the writecount. Thus, the > > > > > > second process can do an open() and flock() of the file and subsequently call > > > > > > execve() after the first process has done the VOP_ADVLOCK(), but before it > > > > > > calls into vn_close(). In fact, since vn_close() requires a write lock on the > > > > > > vnode, this turns out to not be too hard to reproduce at all. Below is a > > > > > > simple test program that reproduces this constantly. To use, copy /bin/test > > > > > > to some other file (e.g. /tmp/foo) and make it writable (chmod a+w), then run > > > > > > ./flock_close_race /tmp/foo. > > > > > > > > > > > > The "fix" I came up with is to defer calling VOP_ADVLOCK() to release the lock > > > > > > until after vn_close() executes. However, even with that fix applied, my test > > > > > > case still fails. Now it is because open() with a given lock flag is > > > > > > non-atomic in that the open(O_RDWR) will call vn_open() and bump v_writecount > > > > > > before it blocks on the lock due to O_EXLOCK, so even though the 'exec_child' > > > > > > process has the fd locked, the writecount can still be bumped. One gross hack > > > > > > would be to defer the bump of the writecount to the caller of vn_open() if the > > > > > > caller passes in O_EXLOCK or O_SHLOCK, but that's a really gross kludge, plus > > > > > > it doesn't actually work. I ended up moving acquiring the lock into > > > > > > vn_open_cred(). The current patch I'm testing has both of these approaches, > > > > > > but the first one is #if 0'd out, and the second is #if 1'd. > > > > > > > > > > > > http://www.freebsd.org/~jhb/patches/flock_open_close.patch > > > > > > > > > > Based on some feedback from Konstantin, I've fixed some issues in the failure > > > > > path handling for VOP_ADVLOCK(). I've also removed the #if 0'd code mentioned > > > > > above, so the patch is now the actual change that I'm testing. So far it > > > > > handles both my workload at work and my test program without any issues. > > > > > > > > I think a comment is needed for a reason to call vn_writechk() second time. > > > > > > Fixed. > > > > > > > Could you, please, point me, where the FHASLOCK is set for O_EXLOCK | O_SHLOCK > > > > case in the patched kernel ? > > > > > > It wasn't. :( I wonder how this was even working since close shouldn't have > > > been unlocking. I'll need to do some more testing. BTW, I ran into fhopen() > > > and found that I would need to put all this same logic into that, so I've split > > > the common code from fhopen() and vn_open_cred() into a new vn_open_vnode(). > > > I think in general it improves both sets of code. > > > > > > I'll upate the patch once I've done some more testing. > > Based on feedback from Konstantin, I have split the vn_open_vnode() changes > out into a separate patch. Once that patch is in the tree I will revisit > this and update the actual bug-fix patch. > > The vn_open_vnode() patch is at > http://www.freebsd.org/~jhb/patches/vn_open_vnode.patch > > I tested it by doing a buildworld -j 32 in a loop while NFS exporting the > /usr/obj tree to another machine that did a continual find | xargs md5 loop > over the /usr/obj tree. This survived overnight. > I've tested this patch for 22 hours without finding any problems. - Peter From owner-freebsd-fs@FreeBSD.ORG Thu Jun 7 17:24:09 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DE91106564A for ; Thu, 7 Jun 2012 17:24:09 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [176.9.45.25]) by mx1.freebsd.org (Postfix) with ESMTP id 277618FC0A for ; Thu, 7 Jun 2012 17:24:09 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 4F58B1CEE6; Thu, 7 Jun 2012 19:24:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id IgHyKvm1jhXv; Thu, 7 Jun 2012 19:24:06 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-15.dynamic.chello.sk [188.167.78.15]) by mail.vx.sk (Postfix) with ESMTPSA id 5B5811CEC7; Thu, 7 Jun 2012 19:24:06 +0200 (CEST) Message-ID: <4FD0E3B5.9030204@FreeBSD.org> Date: Thu, 07 Jun 2012 19:24:05 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Steven Hartland References: <7F2BB05E358942F6835E22033840B36A@multiplay.co.uk> In-Reply-To: <7F2BB05E358942F6835E22033840B36A@multiplay.co.uk> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.ORG Subject: Re: zfs receive -o support in FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 17:24:09 -0000 Our new ZFS vendor is Illumos and they don't support this flag (yet). Web: http://www.illumos.org Source code: https://hg.openindiana.org/upstream/illumos/illumos-gate hg clone ssh://anonhg@hg.illumos.org/illumos-gate On 6.6.2012 15:22, Steven Hartland wrote: > According to Oracle's docs Solaris ZFS supports changing zfs properties > on the fly during a zfs receive:- > http://docs.oracle.com/cd/E19963-01/html/821-1448/gbchx.html > > Seems it was added to support:- > http://arc.opensolaris.org/caselog/PSARC/2010/193/20100525_thomas.erickson > > > This doesn't seem to be present in the version of ZFS for FreeBSD? > > Is this something that's coming as its a very handy feature? > > Regards > Steve > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > 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" -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Fri Jun 8 15:06:41 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 6B0391065673 for ; Fri, 8 Jun 2012 15:06:41 +0000 (UTC) (envelope-from c.kworr@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 DF79D8FC16 for ; Fri, 8 Jun 2012 15:06:40 +0000 (UTC) Received: by bkvi18 with SMTP id i18so2359025bkv.13 for ; Fri, 08 Jun 2012 08:06:39 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=+fM7VZ25fcrrveUgi5luVQYQ7kiaYxQy/1Qp91OBd1o=; b=cDTbJ8yJcp3HLjZnrt/OxP+YKQZC0o+kn6qRW3xyg/U9c8+iGvFJNLpan7hWJcjrmh m5qw9Gg8INbigjHKjOtq4CAumH+IB0mMjbcf/TwbNuASosL6B+devmUtgpx1MasGBtIZ bI90J4ETcGPfsbO6OuED9jNDIFj4lTL6Cw5rR2MzcZJHf8bM+K+ET76jCIEcfjdR5S20 1heucv0akHwgPHXxA626Gr+f/kT5hvEph2IzrJY5hYAP1MG52g6UPT//hnO3QJZuhH0e xzMD3+B0Jb8gURcjdRBW0/ScawTE+B+tgQ4Fdi8HS+h2ZAlozJF/GhpQUTWU91SMyjll FVLA== Received: by 10.204.143.138 with SMTP id v10mr6513113bku.40.1339167999589; Fri, 08 Jun 2012 08:06:39 -0700 (PDT) Received: from green.tandem.local (utwig.xim.bz. [91.216.237.46]) by mx.google.com with ESMTPS id fw10sm7969805bkc.11.2012.06.08.08.06.37 (version=SSLv3 cipher=OTHER); Fri, 08 Jun 2012 08:06:38 -0700 (PDT) Message-ID: <4FD214FB.3080507@gmail.com> Date: Fri, 08 Jun 2012 18:06:35 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120605 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.ORG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: zfs and swap working? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 15:06:41 -0000 Hi all. Didn't I miss anything? Someone has fixed swap to zfs vdevs? arcade@green\~> uname -a FreeBSD green.tandem.local 9.0-STABLE FreeBSD 9.0-STABLE #0 r236557: Mon Jun 4 rc/sys/MINIMAL amd64 arcade@green\~> swapinfo Device 1K-blocks Used Avail Capacity /dev/zvol/green/swap 10485760 2238996 8246764 21% arcade@green\~> zfs get all green/swap NAME PROPERTY VALUE SOURCE green/swap type volume - green/swap creation Thu Jun 7 23:01 2012 - green/swap used 915M - green/swap available 21,4G - green/swap referenced 915M - green/swap compressratio 2.72x - green/swap reservation none default green/swap volsize 10G local green/swap volblocksize 8K - green/swap checksum on default green/swap compression on local green/swap readonly off default green/swap copies 1 default green/swap refreservation none default green/swap primarycache metadata local green/swap secondarycache all default green/swap usedbysnapshots 0 - green/swap usedbydataset 915M - green/swap usedbychildren 0 - green/swap usedbyrefreservation 0 - green/swap logbias throughput local green/swap dedup off default green/swap mlslabel - green/swap sync disabled local green/swap refcompressratio 2.72x - green/swap written 915M This is just after surviving one night trying to rebuild lang/pypy without enough memory. Everything works fine, swap data is also compressed and cached on cache device. -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Fri Jun 8 16:50:54 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 2D3E11065673 for ; Fri, 8 Jun 2012 16:50:54 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id B55DB8FC1C for ; Fri, 8 Jun 2012 16:50:53 +0000 (UTC) Received: (qmail 18082 invoked by uid 110); 8 Jun 2012 16:50:47 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 8 Jun 2012 16:50:47 -0000 From: "Simon" To: "freebsd-fs@FreeBSD.ORG" , "Volodymyr Kostyrko" Date: Fri, 08 Jun 2012 12:50:42 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: <4FD214FB.3080507@gmail.com> MIME-Version: 1.0 Message-Id: <20120608165054.2D3E11065673@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: zfs and swap working? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 16:50:54 -0000 You can swap to ZFS, you just can't *kernel dump* to ZFS swap. -Simon On Fri, 08 Jun 2012 18:06:35 +0300, Volodymyr Kostyrko wrote: >Hi all. >Didn't I miss anything? Someone has fixed swap to zfs vdevs? >arcade@green\~> uname -a >FreeBSD green.tandem.local 9.0-STABLE FreeBSD 9.0-STABLE #0 r236557: Mon >Jun 4 >rc/sys/MINIMAL amd64 >arcade@green\~> swapinfo >Device 1K-blocks Used Avail Capacity >/dev/zvol/green/swap 10485760 2238996 8246764 21% >arcade@green\~> zfs get all green/swap >NAME PROPERTY VALUE SOURCE >green/swap type volume - >green/swap creation Thu Jun 7 23:01 2012 - >green/swap used 915M - >green/swap available 21,4G - >green/swap referenced 915M - >green/swap compressratio 2.72x - >green/swap reservation none default >green/swap volsize 10G local >green/swap volblocksize 8K - >green/swap checksum on default >green/swap compression on local >green/swap readonly off default >green/swap copies 1 default >green/swap refreservation none default >green/swap primarycache metadata local >green/swap secondarycache all default >green/swap usedbysnapshots 0 - >green/swap usedbydataset 915M - >green/swap usedbychildren 0 - >green/swap usedbyrefreservation 0 - >green/swap logbias throughput local >green/swap dedup off default >green/swap mlslabel - >green/swap sync disabled local >green/swap refcompressratio 2.72x - >green/swap written 915M >This is just after surviving one night trying to rebuild lang/pypy >without enough memory. Everything works fine, swap data is also >compressed and cached on cache device. >-- >Sphinx of black quartz judge my vow. >_______________________________________________ >freebsd-fs@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-fs >To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Jun 8 17:08: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 0C1201065677 for ; Fri, 8 Jun 2012 17:08:44 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9272C8FC14 for ; Fri, 8 Jun 2012 17:08:43 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so1491280wgb.1 for ; Fri, 08 Jun 2012 10:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sxZbgX4d5UbKv29JsVqs/4xxIHjuySwtJlMZWbwC6pQ=; b=JhRhWKMSfLAmqZ7PLJhVY3hNX8dLVX0v/ppnyRPMs9dS92RTmDP7zO+c185amyskee 9fKaBqAdb8u1BGIiySxQhvXfs6I74QeenkmLgpAG4WVjMjh7lao3FOWX3ZbOpGCFQlig oMFkZZdikThY+Zm3DhQuyQajFQ70xhYgcnD9IkF1clSGu+r19Em0uXU4ULp65TATp8xZ mCr+IlEHd+RWc4DPP4h/K8G8qdIvicfeHGrbj1YobVvmB3mpih62OlwNd/Udx0MK9Dxt J2cTcCwAGLfhsd/pGu1BcF3fdgnnns+w1k8tD724UNHnk7zHePOg+UtPuQUsAdQr4G0S JcpA== MIME-Version: 1.0 Received: by 10.216.213.219 with SMTP id a69mr1725610wep.16.1339175316665; Fri, 08 Jun 2012 10:08:36 -0700 (PDT) Received: by 10.223.88.155 with HTTP; Fri, 8 Jun 2012 10:08:36 -0700 (PDT) In-Reply-To: <4FD214FB.3080507@gmail.com> References: <4FD214FB.3080507@gmail.com> Date: Fri, 8 Jun 2012 12:08:36 -0500 Message-ID: From: Adam Vande More To: Volodymyr Kostyrko Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: zfs and swap working? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 17:08:44 -0000 On Fri, Jun 8, 2012 at 10:06 AM, Volodymyr Kostyrko wrote: > > Didn't I miss anything? Someone has fixed swap to zfs vdevs? > It has worked for quite some time on light loads. It at least used to hang on heavy. http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013545.html -- Adam Vande More From owner-freebsd-fs@FreeBSD.ORG Sat Jun 9 08:39:18 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 D9F69106566C; Sat, 9 Jun 2012 08:39:18 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [176.9.45.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8EE5D8FC1E; Sat, 9 Jun 2012 08:39:18 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 4965A1F737; Sat, 9 Jun 2012 10:39:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id 3O2CnXOFhfVi; Sat, 9 Jun 2012 10:39:10 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-15.dynamic.chello.sk [188.167.78.15]) by mail.vx.sk (Postfix) with ESMTPSA id 898EC1F72F; Sat, 9 Jun 2012 10:39:10 +0200 (CEST) Message-ID: <4FD30BAE.40702@FreeBSD.org> Date: Sat, 09 Jun 2012 10:39:10 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: araujo@FreeBSD.org References: <4FC366D0.6030206@FreeBSD.org> <4FCC80D3.8000605@gmail.com> <4FCC97ED.1010807@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Araujo , freebsd-fs@freebsd.org Subject: Re: [CFT][PREVIEW] ZFS new SPA X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 08:39:18 -0000 On 4.6.2012 13:33, Marcelo Araujo wrote: > Hey Johan, > > > 2012/6/4 Johan Hendriks > >> Marcelo Araujo schreef: >> >> BTW i am using clang, maybe that is the culprit? >> > > Yeap, could be. I didn't build with CLANG. > > > Best Regards, No, this looks much more like wrongly patched file (you have the file 2 times inside). Maybe you can try the latest patch with boot support: http://people.freebsd.org/~mm/patches/zfs/features/head-zfs-features.patch Try to apply it with "svn patch /path/to/head-zfs-features.patch" if you are using a svn checkout. This will properly add new directories and files. Cheers, mm -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Sat Jun 9 11:45:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB84E106566B for ; Sat, 9 Jun 2012 11:45:28 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm12.bullet.mail.ird.yahoo.com (nm12.bullet.mail.ird.yahoo.com [77.238.189.65]) by mx1.freebsd.org (Postfix) with SMTP id EEF288FC08 for ; Sat, 9 Jun 2012 11:45:27 +0000 (UTC) Received: from [77.238.189.48] by nm12.bullet.mail.ird.yahoo.com with NNFMP; 09 Jun 2012 11:45:26 -0000 Received: from [217.146.189.108] by tm1.bullet.mail.ird.yahoo.com with NNFMP; 09 Jun 2012 11:45:26 -0000 Received: from [127.0.0.1] by smtp124.mail.ird.yahoo.com with NNFMP; 09 Jun 2012 11:45:26 -0000 X-Yahoo-Newman-Id: 713434.37796.bm@smtp124.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: l5OunHIVM1lcsdXSPHCoZmVkjy1IAtp6B5khM17T.u17HzS b1aeb2MwCFNZTHptvmfIGmyvf.HBBLgJT0ywOg5jgz31p32giAU0TiBgJ8oO a1Lwit0GrQjWzICik3UzXn4y9IF30DakiRbva.ACtBiWCraNcHneQbwhI0Ze 1bnaCUur2aI52kbLY7sBhTscZLw5AAiHqDjfhBPmTCA4sPjs177V_NiQ7hgo nVhLVJTFHDukQoX3UJNeqs1L_MVOY44PJ9Z3P2Y520bhzW1qcE4XVAq2YjHc whqi8ys08jPDY1lgwcp0gAoQefcdSpz4DkHPx27CjtK4Ta7yFfsA.DRt8t0Q yW0zeYEoi9UwWGDoLWjdlgcJWV9tAaJbs4WkMPPfifZ5ykoL2X2hTzUBzicD E X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.11] (se@81.173.147.13 with plain) by smtp124.mail.ird.yahoo.com with SMTP; 09 Jun 2012 04:45:26 -0700 PDT Message-ID: <4FD33754.9080905@freebsd.org> Date: Sat, 09 Jun 2012 13:45:24 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: Rafael Henrique Faria References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: UFS2 space usage X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 11:45:28 -0000 Am 06.06.2012 16:32, schrieb Rafael Henrique Faria: > Hi. > > I'm transferring a disk from my MacBook to my FreeBSD server, it's a 500GB > 3,5" disk in an USB enclosure. > As I was using it in MacOS, it was formated with HFS+. So I transfered all > data from it to an second disk. > Then I reformatted the disk inside the FreeBSD 9.0, using GPT, and using > all disk (with HFS+ there was a EFI partition, plus a free space in the > beginning and in the end of the disk). > I used this options for newfs: "-U2 -o space". > > The 500GB disk in HFS+, was with 2GB free, so 498GB in use. (Apple, uses 1 > K as 1000 Bytes, and 1 M as 1000 K, so you really see 500GB of free space > and occupied). > > After trying to move the data back to the 500GB disk formated in UFS2, 44GB > couldn't be transferred. There is no free space for all the data. > > In FreeBSD it says that the disk have 458GB, and is using 415GB, and have > 6.2GB free. But I still have 48GB of data to transfer to it. > > Is HFS+ more optimized to store files then UFS2? There is something that I > can do to get more space for data? 1. What is the average file size? With small files, you should adjust the block size (possibly down to 4096/512) and may want to use UFS1 (smaller inode). With large files, you should specify the average file size in bytes as newfs option (-i). The block and fragment size is set with the -b and -f options of newfs and the fragment size must be a power of 2 larger than the sector size, while the block size is 8 times the fragment size for best results. 2. You probably do not want to use "-o space". Optimizing for Space hardly any effect for large files, since it only affects the allocation of fragments (and those are only relevant for files with less than 13 blocks). Since the file system switches from "-o time" to "-o space" when it fills, you probably do not want to override this setting. 3. You may want to reduce the reserved space down from 8%. Depending on your planned use of this disk, a lower reservation may or may not be acceptable. The higher the amount of free blocks, the better the allocation of blocks for a newly written file. If you do not plan to write many large files when the disk is nearly full, then you may adjust this value down without adverse effects. Regards, STefan From owner-freebsd-fs@FreeBSD.ORG Sat Jun 9 14:31:20 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8A271065672 for ; Sat, 9 Jun 2012 14:31:20 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 381238FC15 for ; Sat, 9 Jun 2012 14:31:20 +0000 (UTC) Received: from peterlaptop.site (hmbg-4d06e8be.pool.mediaWays.net [77.6.232.190]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0Luaps-1RvTJ109eC-0102JF; Sat, 09 Jun 2012 16:31:19 +0200 Message-ID: <4FD35E14.2040408@brockmann-consult.de> Date: Sat, 09 Jun 2012 16:30:44 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120421 Thunderbird/12.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <5532CFFB-F943-4D9E-9722-7FB9C8A9F82A@ebureau.com> In-Reply-To: <5532CFFB-F943-4D9E-9722-7FB9C8A9F82A@ebureau.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:61gjGRFVJU/jN5XuWbV3zSAtavAEi7IzQQOJ/H2QcAP vekEqS8ZLLr+FGbQuesJVjASU/ZekuC6MrOIt6/8kiIq5ZjdZv ZUhHPchNOmFrwKlz2x9txK+Kvk2Sr/+w8Odtp17WGT619Szz1I t7LEOJMqrh7b2D+RJYsEug8t0P3Ntg7qSktreeZGl6AnwjQTOU 9oQnW/vEQ1pFbormHbfajaBgDxx1Hpb+SwV6PF7KgM21vUW0or XlM+/EICgCkRGn1eP7Es8dk8+sO9AYLdmZ2c3GCX+ZL+Bf1kTo izuNlCofNC17XEVXaToSAfU6aWJy3PGvMvHElSQh/hApGzG56B mFp7nJfD1ODzNdOKoerK+OxtvAIzXTHxSQ9r5Z+tDOf9xStpjd zXUVWVhNAVFGw== X-Mailman-Approved-At: Sat, 09 Jun 2012 15:11:22 +0000 Subject: Re: Can mps drop a failing device from bus? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 14:31:20 -0000 I think I've had the same issues, but resolved it by avoiding certain disks and firmware (for disks that aren't really failed... don't know if a failing disk will cause such problems in the future). Here is a related message list thread about it: http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013477.html On 06/05/2012 12:54 AM, Dustin Wenz wrote: > I asked this question back in April on the stable list with no response ( http://lists.freebsd.org/pipermail/freebsd-stable/2012-April/067305.html ). I've now been seeing the same behavior on 9.0-release, and I thought it would be good to ask again here. > > There is a failure mode for SATA disks (Seagate Barracuda ST3000DM001 disks, in this case) that the mps driver doesn't handle very well. If a disk is slow to respond, or is unresponsive altogether, I'd like it to be removed from the bus and degrade the zpool that it's a part of. > > The way things are now, mps will just report a lot of "SCSI command timeout on device" messages. Any I/O on the affected zpools will hang for an excessive amount of time (sometimes forever). We typically configure our storage volumes as a pool of mirrors, with the expectation that availability will be maintained if any redundant disk(s) should fail. Unfortunately, availability is actually made *worse* on highly-redundant mirrors when mps won't give up on an unresponsive device. > > It's possible that I'm overlooking an obvious solution, or some relevant configuration options for the driver. Can anyone offer some insight on this? > > Thanks, > > - .Dustin > > _______________________________________________ > 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"