From owner-freebsd-fs@FreeBSD.ORG Sun Aug 19 07:02:29 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 29FB6106564A; Sun, 19 Aug 2012 07:02:29 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EF81F8FC08; Sun, 19 Aug 2012 07:02:28 +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 q7J72SYU082853; Sun, 19 Aug 2012 07:02:28 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7J72SKt082849; Sun, 19 Aug 2012 07:02:28 GMT (envelope-from araujo) Date: Sun, 19 Aug 2012 07:02:28 GMT Message-Id: <201208190702.q7J72SKt082849@freefall.freebsd.org> To: hirobo@tonteki.org, araujo@FreeBSD.org, araujo@FreeBSD.org, freebsd-fs@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: bin/153142: [zfs] ls -l outputs `ls: ./.zfs: Operation not supported' 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, 19 Aug 2012 07:02:29 -0000 Synopsis: [zfs] ls -l outputs `ls: ./.zfs: Operation not supported' State-Changed-From-To: feedback->open State-Changed-By: araujo State-Changed-When: Sun Aug 19 07:02:03 UTC 2012 State-Changed-Why: - Put it back to the freebsd-fs pool. Responsible-Changed-From-To: araujo->freebsd-fs Responsible-Changed-By: araujo Responsible-Changed-When: Sun Aug 19 07:02:03 UTC 2012 Responsible-Changed-Why: - Put it back to the freebsd-fs pool. http://www.freebsd.org/cgi/query-pr.cgi?pr=153142 From owner-freebsd-fs@FreeBSD.ORG Sun Aug 19 16:41:08 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 1F1AB106566B for ; Sun, 19 Aug 2012 16:41:08 +0000 (UTC) (envelope-from etnapierala@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 9C3348FC12 for ; Sun, 19 Aug 2012 16:41:07 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so4660382wgb.31 for ; Sun, 19 Aug 2012 09:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WXI+hlKi6kDLCETSwoNJYZnJjtQetTynGizWqeUwA6Q=; b=bbZM1jZwc3g+hxoFa0hoQC8evkYp5x8EZRNlIW5dXzfoLSeDNGmJ7JgL/7L/iQcNVV 7zojA0245L3KaOQzCCLE2SOQ/HRYZ0WkJzLlRZ6g+srG+wedxP/XOqILWE0ylHqD40sn YZMHhHav1hhFAuEyeHGisB0g6SVNBn5uSowtTqS/3IourbIIQ15momspQ2qpvpcaQ+ri TirEPkDW7kTXm8qTh+guryF8PO9zYNiWGzJCkWSuvskLMm0wAKS30EGqQWO6y0o2QDle H7umGAXlOHGSh2pMIp0CmycrtZnsJcO52pIODTBB6y0pAFk/ge46PoGm5r3E8sG+nbMD KXFw== Received: by 10.180.7.200 with SMTP id l8mr21783042wia.9.1345394466352; Sun, 19 Aug 2012 09:41:06 -0700 (PDT) Received: from [192.168.1.110] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPS id ck9sm34220033wib.2.2012.08.19.09.41.05 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Aug 2012 09:41:05 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <502FD583.9070105@hte.vl.net.ua> Date: Sun, 19 Aug 2012 18:40:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <06453437-D034-41C2-8B7F-15B228AD2532@FreeBSD.org> References: <502FD583.9070105@hte.vl.net.ua> To: Pavel Bychykhin X-Mailer: Apple Mail (2.1278) Cc: freebsd-fs@freebsd.org Subject: Re: Some of ZFS ACLs doesn't work as expected 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, 19 Aug 2012 16:41:08 -0000 Wiadomo=B6=E6 napisana przez Pavel Bychykhin w dniu 18 sie 2012, o godz. = 19:48: > Dear community! >=20 > After my experiments with ZFS, I concluded, that permissions = "delete_child" and "delete" are ignored. > For the create/update/delete operation a list of "rwxp" = (read_data/write_data/execute/append_data) is fully sufficient. They are not ignored, but yes, write access on a directory is enough to = delete a file. > No need to specify the "delete_child" and "delete" permissions at all, = or I don't understand something? Unless you need them - no, you don't. That's why these bits are not set = in a default case (so called 'trivial ACL', i.e. no ACL set on a file). --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-fs@FreeBSD.ORG Sun Aug 19 17:56: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 B6CAD106566C; Sun, 19 Aug 2012 17:56:21 +0000 (UTC) (envelope-from pavel.priv@hte.vl.net.ua) Received: from relay.hte.vl.net.ua (relay.hte.vl.net.ua [81.17.132.178]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2708FC1C; Sun, 19 Aug 2012 17:56:21 +0000 (UTC) Received: from filter (localhost [127.0.0.1]) by relay.hte.vl.net.ua (Postfix) with ESMTP id 6EAAC1713521; Sun, 19 Aug 2012 20:56:14 +0300 (EEST) X-Virus-Scanned: amavisd-new at hte.vl.net.ua Received: from relay.hte.vl.net.ua ([127.0.0.1]) by filter (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUhtuBZfpgKk; Sun, 19 Aug 2012 20:56:13 +0300 (EEST) Received: from [192.168.4.254] (unknown [192.168.4.254]) by relay.hte.vl.net.ua (Postfix) with ESMTPA id 16EBA1713528; Sun, 19 Aug 2012 20:56:12 +0300 (EEST) Message-ID: <503128BB.6040801@hte.vl.net.ua> Date: Sun, 19 Aug 2012 20:56:11 +0300 From: Pavel Bychykhin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: =?UTF-8?B?RWR3YXJkIFRvbWFzeiBOYXBpZXJhxYJh?= References: <502FD583.9070105@hte.vl.net.ua> <06453437-D034-41C2-8B7F-15B228AD2532@FreeBSD.org> In-Reply-To: <06453437-D034-41C2-8B7F-15B228AD2532@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org Subject: Re: Some of ZFS ACLs doesn't work as expected 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, 19 Aug 2012 17:56:21 -0000 19.08.2012 19:40, Edward Tomasz Napierała пишет: > Wiadomość napisana przez Pavel Bychykhin w dniu 18 sie 2012, o godz. 19:48: >> Dear community! >> >> After my experiments with ZFS, I concluded, that permissions "delete_child" and "delete" are ignored. >> For the create/update/delete operation a list of "rwxp" (read_data/write_data/execute/append_data) is fully sufficient. > > They are not ignored, but yes, write access on a directory is enough to delete a file. > >> No need to specify the "delete_child" and "delete" permissions at all, or I don't understand something? > > Unless you need them - no, you don't. That's why these bits are not set in a default > case (so called 'trivial ACL', i.e. no ACL set on a file). > Could you please provide an example of at least one practical situation, where the "delete_child" and "delete" permissions would be useful? -- Best regards, Pavel From owner-freebsd-fs@FreeBSD.ORG Mon Aug 20 10:16:38 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 8DA7C10656AA; Mon, 20 Aug 2012 10:16:38 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 61F668FC15; Mon, 20 Aug 2012 10:16:38 +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 q7KAGcjg023400; Mon, 20 Aug 2012 10:16:38 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7KAGcE1023396; Mon, 20 Aug 2012 10:16:38 GMT (envelope-from linimon) Date: Mon, 20 Aug 2012 10:16:38 GMT Message-Id: <201208201016.q7KAGcE1023396@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/170778: [zfs] [panic] FreeBSD panics randomly 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, 20 Aug 2012 10:16:38 -0000 Old Synopsis: [zfs] FreeBSD panics randomly New Synopsis: [zfs] [panic] FreeBSD panics randomly Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 20 10:16:22 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=170778 From owner-freebsd-fs@FreeBSD.ORG Mon Aug 20 10:44:22 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 4DBCE1065670 for ; Mon, 20 Aug 2012 10:44:22 +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 048F98FC14 for ; Mon, 20 Aug 2012 10:44:21 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T3PT3-0003LD-Bx for freebsd-fs@freebsd.org; Mon, 20 Aug 2012 12:44:21 +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 ; Mon, 20 Aug 2012 12:44:21 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Aug 2012 12:44:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Mon, 20 Aug 2012 12:44:11 +0200 Lines: 61 Message-ID: References: <5023D9B7.20001@digsys.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5CC6457B180713D1070139C7" X-Complaints-To: usenet@ger.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: <5023D9B7.20001@digsys.bg> X-Enigmail-Version: 1.3.5 Subject: Re: ZFS scrub CPU bound? 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, 20 Aug 2012 10:44:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5CC6457B180713D1070139C7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/08/2012 17:39, Daniel Kalchev wrote: > CPU: 0.4% user, 0.0% nice, 51.4% system, 0.8% interrupt, 47.3% idle > Mem: 2171M Active, 1541M Inact, 5407M Wired, 25M Cache, 416K Buf, 22G F= ree > Swap: 8192M Total, 8192M Free >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMM= AND > 11 root 32 155 ki31 0K 512K CPU31 31 190.2H 1818.46% id= le > 0 root 268 -8 0 0K 4288K - 0 141:25 1261.33% ke= rnel > 4 root 4 -8 - 0K 80K CPU30 30 9:13 95.17% zfsk= ern > 13 root 3 -8 - 0K 48K - 4 5:37 42.97% geom= > 12 root 66 -84 - 0K 1056K WAIT 0 6:19 30.86% intr= > [...] > It seems that zfskern will top to 100%. This is an 32 core system, and > as you see scrub, at 600MB/sec is able to eat 16 cores (from 2x 2.2 GHz= If you hit "H", top will show threads separately, so you will see which threads exactly do the work (you might need to reduce your font so that all of them fit on the screen :) ). > Opteron 6274). There is high load on geom as well... but geom does go > over 100% CPU, so I suppose it scales. Actually, GEOM itself is a bottleneck with SSDs and not really scalable in its current version. If you hit H, you could see that e.g. the g_down thread is sometimes pinned to 100% CPU or something similar. If all GEOM threads in your case are individually below 100%, then you didn't hit the GEOM bottleneck yet. --------------enig5CC6457B180713D1070139C7 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.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAyFPsACgkQ/QjVBj3/HSwYzgCfft3+Az6FgEYLk/qfIZVth9Xm EMkAoIIz2CqFG1AcaT7LeHs9wloTdJwj =p58/ -----END PGP SIGNATURE----- --------------enig5CC6457B180713D1070139C7-- From owner-freebsd-fs@FreeBSD.ORG Mon Aug 20 11:07: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 D69CE1065695 for ; Mon, 20 Aug 2012 11:07:43 +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 B0A678FC1A for ; Mon, 20 Aug 2012 11:07:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7KB7hS0047567 for ; Mon, 20 Aug 2012 11:07:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7KB7go9047486 for freebsd-fs@FreeBSD.org; Mon, 20 Aug 2012 11:07:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Aug 2012 11:07:42 GMT Message-Id: <201208201107.q7KB7go9047486@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, 20 Aug 2012 11:07:44 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/170238 fs [zfs] [panic] Panic when deleting data o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/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/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 p 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 bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/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 " p 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 286 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Aug 20 11:53:56 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0CAD106566B for ; Mon, 20 Aug 2012 11:53:56 +0000 (UTC) (envelope-from etnapierala@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 2D9D78FC0C for ; Mon, 20 Aug 2012 11:53:55 +0000 (UTC) Received: by eeke52 with SMTP id e52so1841846eek.13 for ; Mon, 20 Aug 2012 04:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5iM9LGaLbfg26S/vSrvpDhEleC1ORm1hdQUtxYT4YEg=; b=eaVOP/BrR5VHkpDsCl1ptuBBJyijjRPWzxtmCaHqQrsFXbrE+rts/3gYY43rqTpD6A DqdqmQFHB1Stl9MCHKtmJP9phgeokOoDjWKtC7FfFrmymBmMu+VDnvdIgIouvJr9fBw8 TV3bIaeiQCYBPi5OYHHuhIj3/UTysRsYc6bcVZoV3y2tC5SRQFw+M/Y7PGLGqwnGpxwj tOj3LR+L0+oOnUem+B4H6fFc1vvyV939jHEAplwk4y8m1U3IxJXv3uTvYoc/cCAtLZv/ KmdL1nX77iVQKfr/+HvCaPL5kEjojEcOec4FHenoQpOwLADdniXrWZMjPbg/zP7BdMAI Tmbw== Received: by 10.14.182.69 with SMTP id n45mr8366461eem.28.1345463634087; Mon, 20 Aug 2012 04:53:54 -0700 (PDT) Received: from [192.168.1.110] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPS id v3sm15340747eep.10.2012.08.20.04.53.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 04:53:53 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <503128BB.6040801@hte.vl.net.ua> Date: Mon, 20 Aug 2012 13:53:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <788B90E6-B36B-40D3-8C89-BD1A2902D4D5@FreeBSD.org> References: <502FD583.9070105@hte.vl.net.ua> <06453437-D034-41C2-8B7F-15B228AD2532@FreeBSD.org> <503128BB.6040801@hte.vl.net.ua> To: Pavel Bychykhin X-Mailer: Apple Mail (2.1278) Cc: freebsd-fs@freebsd.org Subject: Re: Some of ZFS ACLs doesn't work as expected 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, 20 Aug 2012 11:53:56 -0000 Wiadomo=C5=9B=C4=87 napisana przez Pavel Bychykhin w dniu 19 sie 2012, o = godz. 19:56: > 19.08.2012 19:40, Edward Tomasz Napiera=C5=82a =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: >> Wiadomo=C5=9B=C4=87 napisana przez Pavel Bychykhin w dniu 18 sie = 2012, o godz. 19:48: >>> Dear community! >>>=20 >>> After my experiments with ZFS, I concluded, that permissions = "delete_child" and "delete" are ignored. >>> For the create/update/delete operation a list of "rwxp" = (read_data/write_data/execute/append_data) is fully sufficient. >>=20 >> They are not ignored, but yes, write access on a directory is enough = to delete a file. >>=20 >>> No need to specify the "delete_child" and "delete" permissions at = all, or I don't understand something? >>=20 >> Unless you need them - no, you don't. That's why these bits are not = set in a default >> case (so called 'trivial ACL', i.e. no ACL set on a file). >>=20 >=20 > Could you please provide an example of at least one practical = situation, where the "delete_child" and "delete" permissions would be = useful? You could allow for file creation, but deny file removal. Still, as = someone already mentioned, main reason for these to exist is compatibility with = Windows and NFSv4 spec. It's just that they are not _completely_ ignored, like = SYNCHRONIZE or READ_XATTR/WRITE_XATTR are. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-fs@FreeBSD.ORG Mon Aug 20 12:07: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 CD9DA106568A for ; Mon, 20 Aug 2012 12:07:54 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 2ED9A8FC12 for ; Mon, 20 Aug 2012 12:07:53 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id q7KBo5lv013983 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 20 Aug 2012 14:50:06 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <5032246D.5060903@digsys.bg> Date: Mon, 20 Aug 2012 14:50:05 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.6esrpre) Gecko/20120728 Thunderbird/10.0.6 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <5023D9B7.20001@digsys.bg> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS scrub CPU bound? 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, 20 Aug 2012 12:07:54 -0000 On 20.08.12 13:44, Ivan Voras wrote: > On 09/08/2012 17:39, Daniel Kalchev wrote: > >> CPU: 0.4% user, 0.0% nice, 51.4% system, 0.8% interrupt, 47.3% idle >> Mem: 2171M Active, 1541M Inact, 5407M Wired, 25M Cache, 416K Buf, 22G Free >> Swap: 8192M Total, 8192M Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 11 root 32 155 ki31 0K 512K CPU31 31 190.2H 1818.46% idle >> 0 root 268 -8 0 0K 4288K - 0 141:25 1261.33% kernel >> 4 root 4 -8 - 0K 80K CPU30 30 9:13 95.17% zfskern >> 13 root 3 -8 - 0K 48K - 4 5:37 42.97% geom >> 12 root 66 -84 - 0K 1056K WAIT 0 6:19 30.86% intr >> [...] >> It seems that zfskern will top to 100%. This is an 32 core system, and >> as you see scrub, at 600MB/sec is able to eat 16 cores (from 2x 2.2 GHz > If you hit "H", top will show threads separately, so you will see which > threads exactly do the work (you might need to reduce your font so that > all of them fit on the screen :) ). I have large screen(s) :) Here is the top of top: last pid: 4779; load averages: 11.98, 4.15, 1.70 up 0+01:46:30 14:40:49 898 processes: 49 running, 785 sleeping, 64 waiting CPU: 1.2% user, 0.0% nice, 52.1% system, 0.6% interrupt, 46.1% idle Mem: 1942M Active, 1140M Inact, 3257M Wired, 4240K Cache, 400K Buf, 25G Free Swap: 8192M Total, 8192M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 4 root -8 - 0K 80K CPU4 4 1:35 100.00% zfskern{txg_thread_enter} 11 root 155 ki31 0K 512K RUN 13 104:57 57.08% idle{idle: cpu13} 11 root 155 ki31 0K 512K RUN 14 104:54 55.76% idle{idle: cpu14} 11 root 155 ki31 0K 512K CPU8 8 104:55 54.59% idle{idle: cpu8} 11 root 155 ki31 0K 512K RUN 9 105:01 54.20% idle{idle: cpu9} 11 root 155 ki31 0K 512K CPU30 30 104:46 53.66% idle{idle: cpu30} 11 root 155 ki31 0K 512K RUN 19 104:52 53.27% idle{idle: cpu19} 11 root 155 ki31 0K 512K CPU15 15 104:45 52.98% idle{idle: cpu15} 11 root 155 ki31 0K 512K CPU17 17 104:52 52.69% idle{idle: cpu17} 11 root 155 ki31 0K 512K RUN 20 104:51 52.69% idle{idle: cpu20} 11 root 155 ki31 0K 512K CPU12 12 104:54 52.29% idle{idle: cpu12} 11 root 155 ki31 0K 512K CPU25 25 104:48 52.29% idle{idle: cpu25} 11 root 155 ki31 0K 512K CPU24 24 104:51 52.10% idle{idle: cpu24} 11 root 155 ki31 0K 512K CPU26 26 104:46 50.98% idle{idle: cpu26} 11 root 155 ki31 0K 512K CPU11 11 104:53 50.68% idle{idle: cpu11} 11 root 155 ki31 0K 512K RUN 31 104:48 50.49% idle{idle: cpu31} 11 root 155 ki31 0K 512K CPU10 10 104:57 50.10% idle{idle: cpu10} 11 root 155 ki31 0K 512K CPU1 1 104:53 50.00% idle{idle: cpu1} 11 root 155 ki31 0K 512K RUN 29 104:48 49.76% idle{idle: cpu29} 0 root -16 0 0K 4288K - 11 0:42 49.66% kernel{zio_read_intr_20} 11 root 155 ki31 0K 512K CPU3 3 104:57 49.56% idle{idle: cpu3} 0 root -16 0 0K 4288K - 6 0:42 49.56% kernel{zio_read_intr_15} 0 root -16 0 0K 4288K - 21 0:42 49.27% kernel{zio_read_intr_3} 11 root 155 ki31 0K 512K CPU28 28 104:24 49.17% idle{idle: cpu28} 0 root -16 0 0K 4288K - 24 0:42 49.17% kernel{zio_read_intr_29} 0 root -16 0 0K 4288K CPU17 17 0:42 49.07% kernel{zio_read_intr_1} 11 root 155 ki31 0K 512K RUN 27 104:46 48.97% idle{idle: cpu27} 0 root -16 0 0K 4288K CPU12 12 0:42 48.97% kernel{zio_read_intr_2} 0 root -16 0 0K 4288K - 25 0:42 48.78% kernel{zio_read_intr_7} 0 root -16 0 0K 4288K CPU14 14 0:42 48.78% kernel{zio_read_intr_11} 0 root -16 0 0K 4288K CPU19 19 0:42 48.78% kernel{zio_read_intr_28} 0 root -16 0 0K 4288K - 12 0:42 48.78% kernel{zio_read_intr_6} 0 root -16 0 0K 4288K - 29 0:42 48.78% kernel{zio_read_intr_18} 11 root 155 ki31 0K 512K RUN 0 105:10 48.68% idle{idle: cpu0} 11 root 155 ki31 0K 512K RUN 6 104:51 48.58% idle{idle: cpu6} 0 root -16 0 0K 4288K - 16 0:42 48.58% kernel{zio_read_intr_19} 0 root -16 0 0K 4288K CPU21 10 0:42 48.58% kernel{zio_read_intr_0} 0 root -16 0 0K 4288K CPU20 20 0:42 48.58% kernel{zio_read_intr_8} 0 root -16 0 0K 4288K CPU13 13 0:41 48.49% kernel{zio_read_intr_12} 0 root -16 0 0K 4288K - 5 0:42 48.39% kernel{zio_read_intr_5} 0 root -16 0 0K 4288K - 22 0:42 48.39% kernel{zio_read_intr_17} 0 root -16 0 0K 4288K CPU31 31 0:42 48.29% kernel{zio_read_intr_16} 0 root -16 0 0K 4288K - 17 0:42 48.29% kernel{zio_read_intr_4} 0 root -16 0 0K 4288K CPU0 0 0:42 48.29% kernel{zio_read_intr_13} 11 root 155 ki31 0K 512K CPU22 22 104:41 48.19% idle{idle: cpu22} 0 root -16 0 0K 4288K - 25 0:42 48.19% kernel{zio_read_intr_31} 0 root -16 0 0K 4288K - 26 0:42 48.19% kernel{zio_read_intr_25} 0 root -16 0 0K 4288K CPU15 29 0:42 48.19% kernel{zio_read_intr_22} 0 root -16 0 0K 4288K - 10 0:42 48.10% kernel{zio_read_intr_14} 0 root -16 0 0K 4288K - 8 0:42 48.10% kernel{zio_read_intr_21} 0 root -16 0 0K 4288K - 15 0:42 48.10% kernel{zio_read_intr_26} 0 root -16 0 0K 4288K - 16 0:42 48.00% kernel{zio_read_intr_9} 0 root -16 0 0K 4288K - 18 0:42 48.00% kernel{zio_read_intr_30} 0 root -16 0 0K 4288K CPU9 9 0:41 48.00% kernel{zio_read_intr_27} 11 root 155 ki31 0K 512K RUN 21 104:48 47.66% idle{idle: cpu21} 0 root -16 0 0K 4288K - 29 0:42 47.66% kernel{zio_read_intr_23} 0 root -16 0 0K 4288K - 29 0:42 47.66% kernel{zio_read_intr_10} 0 root -16 0 0K 4288K CPU23 23 0:42 47.56% kernel{zio_read_intr_24} 11 root 155 ki31 0K 512K CPU18 18 104:52 47.36% idle{idle: cpu18} 11 root 155 ki31 0K 512K CPU5 5 104:53 47.27% idle{idle: cpu5} 11 root 155 ki31 0K 512K CPU16 16 104:50 47.17% idle{idle: cpu16} 11 root 155 ki31 0K 512K RUN 23 104:44 47.17% idle{idle: cpu23} 11 root 155 ki31 0K 512K CPU7 7 104:56 45.46% idle{idle: cpu7} 11 root 155 ki31 0K 512K RUN 4 104:50 45.36% idle{idle: cpu4} 11 root 155 ki31 0K 512K CPU2 2 104:55 42.29% idle{idle: cpu2} 13 root -8 - 0K 48K - 7 0:42 18.65% geom{g_down} 12 root -68 - 0K 1056K CPU30 30 0:32 16.26% intr{swi2: cambio} 13 root -8 - 0K 48K CPU28 28 0:32 14.99% geom{g_up} 12 root -88 - 0K 1056K CPU12 12 0:21 9.28% intr{irq256: mps0} Is it possible the large number of IOPS to be causing this bottleneck? Too many zfskern state changes or something like that? gstat says dT: 1.002s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0| cd0 6 9030 9024 149343 0.5 3 128 0.1 90.4| da0 5 8740 8734 148807 0.5 3 128 0.1 89.9| da1 5 8935 8929 149328 0.5 3 128 0.1 90.3| da2 6 8649 8643 148753 0.5 3 128 0.1 90.1| da3 0 0 0 0 0.0 0 0 0.0 0.0| da0p1 0 0 0 0 0.0 0 0 0.0 0.0| da0p2 6 9030 9024 149343 0.5 3 128 0.2 91.0| da0p3 0 0 0 0 0.0 0 0 0.0 0.0| da1p1 0 0 0 0 0.0 0 0 0.0 0.0| da1p2 7 8739 8733 148803 0.5 3 128 0.2 90.5| da1p3 0 0 0 0 0.0 0 0 0.0 0.0| da2p1 0 0 0 0 0.0 0 0 0.0 0.0| da2p2 7 8935 8929 149328 0.5 3 128 0.2 90.8| da2p3 0 0 0 0 0.0 0 0 0.0 0.0| da3p1 0 0 0 0 0.0 0 0 0.0 0.0| da3p2 6 8649 8643 148753 0.5 3 128 0.2 90.7| da3p3 0 0 0 0 0.0 0 0 0.0 0.0| gptid/072fa016-dbf3-11e1-9417-0025908065d8 0 0 0 0 0.0 0 0 0.0 0.0| gpt/swap0 0 0 0 0 0.0 0 0 0.0 0.0| md0 0 0 0 0 0.0 0 0 0.0 0.0| gptid/0739a7b0-dbf3-11e1-9417-0025908065d8 0 0 0 0 0.0 0 0 0.0 0.0| gpt/swap1 0 0 0 0 0.0 0 0 0.0 0.0| gptid/07446e04-dbf3-11e1-9417-0025908065d8 0 0 0 0 0.0 0 0 0.0 0.0| gpt/swap2 0 0 0 0 0.0 0 0 0.0 0.0| gptid/074ee993-dbf3-11e1-9417-0025908065d8 0 0 0 0 0.0 0 0 0.0 0.0| gpt/swap3 0 0 0 0 0.0 0 0 0.0 0.0| mirror/swap0-1 0 0 0 0 0.0 0 0 0.0 0.0| mirror/swap2-3 >> Opteron 6274). There is high load on geom as well... but geom does go >> over 100% CPU, so I suppose it scales. > Actually, GEOM itself is a bottleneck with SSDs and not really scalable > in its current version. If you hit H, you could see that e.g. the g_down > thread is sometimes pinned to 100% CPU or something similar. If all GEOM > threads in your case are individually below 100%, then you didn't hit > the GEOM bottleneck yet. > Ok, but apparently GEOM is not the bottleneck in my case. Daniel From owner-freebsd-fs@FreeBSD.ORG Mon Aug 20 12:27:17 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 CEFFA106566C; Mon, 20 Aug 2012 12:27:17 +0000 (UTC) (envelope-from pavel.priv@hte.vl.net.ua) Received: from relay.hte.vl.net.ua (relay.hte.vl.net.ua [81.17.132.178]) by mx1.freebsd.org (Postfix) with ESMTP id 80EA48FC0A; Mon, 20 Aug 2012 12:27:17 +0000 (UTC) Received: from filter (localhost [127.0.0.1]) by relay.hte.vl.net.ua (Postfix) with ESMTP id 423E01713580; Mon, 20 Aug 2012 15:27:16 +0300 (EEST) X-Virus-Scanned: amavisd-new at hte.vl.net.ua Received: from relay.hte.vl.net.ua ([127.0.0.1]) by filter (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHXZ_7YaZ37n; Mon, 20 Aug 2012 15:27:15 +0300 (EEST) Received: from [192.168.0.200] (unknown [192.168.0.200]) by relay.hte.vl.net.ua (Postfix) with ESMTPA id AE14C1711FE3; Mon, 20 Aug 2012 15:27:15 +0300 (EEST) Message-ID: <50322CF8.8000105@hte.vl.net.ua> Date: Mon, 20 Aug 2012 15:26:32 +0300 From: =?UTF-8?B?0J/QsNCy0LXQuw==?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: =?UTF-8?B?RWR3YXJkIFRvbWFzeiBOYXBpZXJhxYJh?= References: <502FD583.9070105@hte.vl.net.ua> <06453437-D034-41C2-8B7F-15B228AD2532@FreeBSD.org> <503128BB.6040801@hte.vl.net.ua> <788B90E6-B36B-40D3-8C89-BD1A2902D4D5@FreeBSD.org> In-Reply-To: <788B90E6-B36B-40D3-8C89-BD1A2902D4D5@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org Subject: Re: Some of ZFS ACLs doesn't work as expected X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pavel.priv@hte.vl.net.ua List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 12:27:17 -0000 20.08.2012 14:53, Edward Tomasz Napierała пишет: > Wiadomość napisana przez Pavel Bychykhin w dniu 19 sie 2012, o godz. 19:56: >> 19.08.2012 19:40, Edward Tomasz Napierała пишет: >>> Wiadomość napisana przez Pavel Bychykhin w dniu 18 sie 2012, o godz. 19:48: >>>> Dear community! >>>> >>>> After my experiments with ZFS, I concluded, that permissions "delete_child" and "delete" are ignored. >>>> For the create/update/delete operation a list of "rwxp" (read_data/write_data/execute/append_data) is fully sufficient. >>> They are not ignored, but yes, write access on a directory is enough to delete a file. >>> >>>> No need to specify the "delete_child" and "delete" permissions at all, or I don't understand something? >>> Unless you need them - no, you don't. That's why these bits are not set in a default >>> case (so called 'trivial ACL', i.e. no ACL set on a file). >>> >> Could you please provide an example of at least one practical situation, where the "delete_child" and "delete" permissions would be useful? > You could allow for file creation, but deny file removal. Still, as someone > already mentioned, main reason for these to exist is compatibility with Windows > and NFSv4 spec. It's just that they are not _completely_ ignored, like SYNCHRONIZE > or READ_XATTR/WRITE_XATTR are. > Now I understand. This is only for "deny" rules. Thanks a lot. From owner-freebsd-fs@FreeBSD.ORG Mon Aug 20 12:30:57 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 5C02D106566B; Mon, 20 Aug 2012 12:30:57 +0000 (UTC) (envelope-from drb@karlov.mff.cuni.cz) Received: from mail.karlov.mff.cuni.cz (mail.karlov.mff.cuni.cz [195.113.27.114]) by mx1.freebsd.org (Postfix) with ESMTP id AC5BD8FC0C; Mon, 20 Aug 2012 12:30:56 +0000 (UTC) Received: from nat-r.karlov.mff.cuni.cz ([195.113.27.73] helo=[10.32.82.28]) by mail.karlov.mff.cuni.cz with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1T3QeN-000Mt2-Ki; Mon, 20 Aug 2012 14:00:08 +0200 Message-ID: <503226C6.3040201@karlov.mff.cuni.cz> Date: Mon, 20 Aug 2012 14:00:06 +0200 From: =?UTF-8?B?VG9tw6HFoSBEcmJvaGxhdg==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Pavel Bychykhin References: <502FD583.9070105@hte.vl.net.ua> <06453437-D034-41C2-8B7F-15B228AD2532@FreeBSD.org> <503128BB.6040801@hte.vl.net.ua> <788B90E6-B36B-40D3-8C89-BD1A2902D4D5@FreeBSD.org> In-Reply-To: <788B90E6-B36B-40D3-8C89-BD1A2902D4D5@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, =?UTF-8?B?RWR3YXJkIFRvbWFzeiBOYXBpZXJhxYJh?= Subject: Re: Some of ZFS ACLs doesn't work as expected 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, 20 Aug 2012 12:30:57 -0000 On 20.8.2012 13:53, Edward Tomasz Napierała wrote: > Wiadomość napisana przez Pavel Bychykhin w dniu 19 sie 2012, o godz. 19:56: >> 19.08.2012 19:40, Edward Tomasz Napierała пишет: >>> Wiadomość napisana przez Pavel Bychykhin w dniu 18 sie 2012, o godz. 19:48: >>>> Dear community! >>>> >>>> After my experiments with ZFS, I concluded, that permissions "delete_child" and "delete" are ignored. >>>> For the create/update/delete operation a list of "rwxp" (read_data/write_data/execute/append_data) is fully sufficient. >>> >>> They are not ignored, but yes, write access on a directory is enough to delete a file. >>> >>>> No need to specify the "delete_child" and "delete" permissions at all, or I don't understand something? >>> >>> Unless you need them - no, you don't. That's why these bits are not set in a default >>> case (so called 'trivial ACL', i.e. no ACL set on a file). >>> >> >> Could you please provide an example of at least one practical situation, where the "delete_child" and "delete" permissions would be useful? > > You could allow for file creation, but deny file removal. Still, as someone > already mentioned, main reason for these to exist is compatibility with Windows > and NFSv4 spec. It's just that they are not _completely_ ignored, like SYNCHRONIZE > or READ_XATTR/WRITE_XATTR are. Please beware, that based on my experience, SYNCHRONIZE bit is not as ignored as you would probably expect. For example Samba configured to save NT rights in NFSv4 ACLs need 's' for seamless opertion of File Explorer on the other side of Smb... It appeared after some upgrade I made about a year ago or so. T:D From owner-freebsd-fs@FreeBSD.ORG Mon Aug 20 14:01:41 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 1AE0E10656F3 for ; Mon, 20 Aug 2012 14:01:41 +0000 (UTC) (envelope-from etnapierala@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 9090F8FC1B for ; Mon, 20 Aug 2012 14:01:40 +0000 (UTC) Received: by eeke52 with SMTP id e52so1905833eek.13 for ; Mon, 20 Aug 2012 07:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tt7/JzZopIVLIrzpMfG1pypPvn4iPUMhNObopMG7fRw=; b=Ea0h5TuHGQCb2xxThbbQyic3lda9PlfflVZoObuVeVniHrr+ZSlXYE4wQREueWMtkG 6bxjhpsWwshAvL3PKGz1IxkK+LRKDhPBZZ1NSlYy3+BgI2APUCbUUJHC2BRknUCjCxd4 bVwHg9wzGxIY322pfU0NWgNMblRJMfG8NTHxIur2l6uDO6lPtUF0ujcSP/Zkt9Uk6Fp1 CmQHsJbLOfKv0NV3CQRkUKpNimy6+0GnqlrtHipGdT2K574TF41+DOwT2hiLQ1RZtmg3 foyAf+Y5B17o02ULlh+tga1LpRPMGKQqWiog4DsoPZsi6TvmsppODIcxDAlLsurYrhcX B28Q== Received: by 10.14.175.7 with SMTP id y7mr8811915eel.29.1345471299272; Mon, 20 Aug 2012 07:01:39 -0700 (PDT) Received: from [192.168.1.110] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPS id l42sm42229529eep.1.2012.08.20.07.01.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 07:01:38 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <503226C6.3040201@karlov.mff.cuni.cz> Date: Mon, 20 Aug 2012 16:01:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <502FD583.9070105@hte.vl.net.ua> <06453437-D034-41C2-8B7F-15B228AD2532@FreeBSD.org> <503128BB.6040801@hte.vl.net.ua> <788B90E6-B36B-40D3-8C89-BD1A2902D4D5@FreeBSD.org> <503226C6.3040201@karlov.mff.cuni.cz> To: =?iso-8859-2?Q?Tom=E1=B9_Drbohlav?= X-Mailer: Apple Mail (2.1278) Cc: freebsd-fs@freebsd.org Subject: Re: Some of ZFS ACLs doesn't work as expected 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, 20 Aug 2012 14:01:41 -0000 Wiadomo=C5=9B=C4=87 napisana przez Tom=C3=A1=C5=A1 Drbohlav w dniu 20 = sie 2012, o godz. 14:00: > On 20.8.2012 13:53, Edward Tomasz Napiera=C5=82a wrote: >> Wiadomo=C5=9B=C4=87 napisana przez Pavel Bychykhin w dniu 19 sie = 2012, o godz. 19:56: >>> 19.08.2012 19:40, Edward Tomasz Napiera=C5=82a =D0=BF=D0=B8=D1=88=D0=B5= =D1=82: >>>> Wiadomo=C5=9B=C4=87 napisana przez Pavel Bychykhin w dniu 18 sie = 2012, o godz. 19:48: >>>>> Dear community! >>>>>=20 >>>>> After my experiments with ZFS, I concluded, that permissions = "delete_child" and "delete" are ignored. >>>>> For the create/update/delete operation a list of "rwxp" = (read_data/write_data/execute/append_data) is fully sufficient. >>>>=20 >>>> They are not ignored, but yes, write access on a directory is = enough to delete a file. >>>>=20 >>>>> No need to specify the "delete_child" and "delete" permissions at = all, or I don't understand something? >>>>=20 >>>> Unless you need them - no, you don't. That's why these bits are = not set in a default >>>> case (so called 'trivial ACL', i.e. no ACL set on a file). >>>>=20 >>>=20 >>> Could you please provide an example of at least one practical = situation, where the "delete_child" and "delete" permissions would be = useful? >>=20 >> You could allow for file creation, but deny file removal. Still, as = someone >> already mentioned, main reason for these to exist is compatibility = with Windows >> and NFSv4 spec. It's just that they are not _completely_ ignored, = like SYNCHRONIZE >> or READ_XATTR/WRITE_XATTR are. >=20 > Please beware, that based on my experience, SYNCHRONIZE bit is not as = ignored as you would probably expect. For example Samba configured to = save NT rights in NFSv4 ACLs need 's' for seamless opertion of File = Explorer on the other side of Smb... It appeared after some upgrade I = made about a year ago or so. By ignored, I mean ignored by FreeBSD (or Solaris, for that matter) - = FreeBSD stores this permission, but doesn't do anything more about it. Windows = obviously _does_ use it. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-fs@FreeBSD.ORG Tue Aug 21 16:11:26 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 72ED1106564A; Tue, 21 Aug 2012 16:11:26 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id AF9E78FC08; Tue, 21 Aug 2012 16:11:19 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id q7LG7gj9054451; Tue, 21 Aug 2012 19:07:42 +0300 (EEST) Message-ID: <20120821190742.54449@relay.ibs.dn.ua> Date: Tue, 21 Aug 2012 19:07:42 +0300 From: Zeus Panchenko To: Organization: I.B.S. LLC X-Mailer: MH-E 8.2; GNU Mailutils 2.99.97; GNU Emacs 23.4.1 X-Face: &sReWXo3Iwtqql1[My(t1Gkx; y?KF@KF`4X+'9Cs@PtK^y%}^.>Mtbpyz6U=,Op:KPOT.uG )Nvx`=er!l?WASh7KeaGhga"1[&yz$_7ir'cVp7o%CGbJ/V)j/=]vzvvcqcZkf; JDurQG6wTg+?/xA go`}1.Ze//K; Fk&/&OoHd'[b7iGt2UO>o(YskCT[_D)kh4!yY'<&:yt+zM=A`@`~9U+P[qS:f; #9z~ Or/Bo#N-'S'!'[3Wog'ADkyMqmGDvga?WW)qd=?)`Y&k=o}>!ST\ Cc: freebsd-fs@FreeBSD.ORG Subject: `zpool create' fails on geli ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:11:26 -0000 hi all, SYNOPSIS: `zpool create poolname device.eli' available on .eli device only after dd some random data to .eli first I am trying to get ZFS on GELI disk ... Here is the issue: #> uname -a FreeBSD 9.0-RELEASE #0 amd64 for /dev/ada2 I do: #> geli init -K /path/key -s 4096 -a hmac/sha256 -e aes-xts /dev/ada2 Enter new passphrase: Reenter new passphrase: Metadata backup can be found in /var/backups/ada2.eli and can be restored with the following command: # geli restore /var/backups/ada2.eli /dev/ada2 #> geli attach -k /path/key /dev/ada2 now I have .eli device #> ls -al /dev/*eli lrwxr-xr-x 1 root wheel 8 Aug 16 15:43 /dev/ad14.eli -> ada2.eli crw-r----- 1 root operator 0, 99 Aug 16 15:43 /dev/ada2.eli now I am trying to create zfs on it: > zpool create geliz /dev/ada2.eli cannot create 'geliz': one or more devices is currently unavailable `zpool create -f ...' gave the same result and in messages I have plenty rows like these: cat /var/log/messages ... GEOM_ELI: ada2.eli: 131072 bytes corrupted at offset 444539600896. GEOM_ELI: ada2.eli: 131072 bytes corrupted at offset 444539863040. GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 270336. GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 444539609088. GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 444539871232. GEOM_ELI: ada2.eli: 4096 bytes corrupted at offset 444540313600. GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 65536. GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 8192. GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 0. GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 262144. ... but after #> dd if=/dev/random of=/dev/ada2.eli bs=10m count=10 10+0 records in 10+0 records out 104857600 bytes transferred in 7.124000 secs (14718922 bytes/sec) I was able to do it! #> zpool create geliz /dev/ada2.eli pool was successfully created but pool status looks weird for me: #> zpool status geliz pool: geliz state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scan: none requested config: NAME STATE READ WRITE CKSUM geliz ONLINE 0 0 0 ada2.eli ONLINE 10 0 0 errors: No known data errors after `zscub' and `zpool clear' I have clean pool: #> zpool status geliz pool: geliz state: ONLINE scan: scrub repaired 0 in 0h0m with 0 errors on Thu Aug 16 16:36:44 2012 config: NAME STATE READ WRITE CKSUM geliz ONLINE 0 0 0 ada2.eli ONLINE 0 0 0 errors: No known data errors QUESTION: 1. Am I correct to think I really have correct ZFS over GELI set? 2. Why it was needed to dd? What am I missing here, please? may somebody explain that for me please ...? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Tue Aug 21 17:28: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 250521065674 for ; Tue, 21 Aug 2012 17:28:24 +0000 (UTC) (envelope-from a@carniajeu.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D84C58FC12 for ; Tue, 21 Aug 2012 17:28:23 +0000 (UTC) Received: by obbun3 with SMTP id un3so73990obb.13 for ; Tue, 21 Aug 2012 10:28:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=xyAc0Aqjg7DnkLezV/kMPYgv9Hbfy1WnXGBG3k4Vv4A=; b=WUxP14XSj0WteP+pkm4zDNtGCTZYas0beIOwSxyikV6oJ9wp79VgINIKflevQm2qwk 3TVT/+6zBxN3q1UEnYqpGMJQ5EdJfetIJjCYLbJl6hgEeQdn2GevVQ3LcLJ/pzHBcPUX 2LV3f2LSHUfp+cZ4iZGOhOWKG25Z6I7R4Ag3G+WZEFI1i55giUEuNacNQrXMjWMejaZC sjii6LL+GzSYmNGptS70dvig+djnGJK7HhyaVMH3jTrjcNNld6iSpB52U8HBpbIFA1E1 zHoBqtq0jdNnpQwN7fo5WFIxf1IGdVqL5QrLBL1eVdgf7uA+9tbBuyLoHEZ++4xGjVzN KydQ== MIME-Version: 1.0 Received: by 10.182.53.103 with SMTP id a7mr13473515obp.3.1345570103063; Tue, 21 Aug 2012 10:28:23 -0700 (PDT) Sender: a@carniajeu.com Received: by 10.182.114.35 with HTTP; Tue, 21 Aug 2012 10:28:22 -0700 (PDT) X-Originating-IP: [46.53.195.78] In-Reply-To: <20120821190742.54449@relay.ibs.dn.ua> References: <20120821190742.54449@relay.ibs.dn.ua> Date: Tue, 21 Aug 2012 20:28:22 +0300 X-Google-Sender-Auth: LmVeiTxU_UCTFYVrW0OeI0Mb8p8 Message-ID: From: Alaksiej Carniajeu To: Zeus Panchenko Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQncRrPko/LKo9Lb9QPXhlsIl75iqyeiSOCHUbajqGbEIdFs6YEc9TNS5bOTUWs/moNXnS6s Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Subject: Re: `zpool create' fails on geli ... 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, 21 Aug 2012 17:28:24 -0000 Geli doesn't initialize checksums, when geli device is created. They will be calculated only on write. That's why these "XXX bytes corrupted" messages appeared. I believe it's better to fill your whole geli device with any data before use with ZFS, if integrity verification (-a) was enabled for it. On Tue, Aug 21, 2012 at 7:07 PM, Zeus Panchenko wrote: > hi all, > > SYNOPSIS: `zpool create poolname device.eli' available on .eli device only after dd some > random data to .eli first > > I am trying to get ZFS on GELI disk ... > > Here is the issue: > > #> uname -a > FreeBSD 9.0-RELEASE #0 amd64 > > for /dev/ada2 I do: > > #> geli init -K /path/key -s 4096 -a hmac/sha256 -e aes-xts /dev/ada2 > Enter new passphrase: > Reenter new passphrase: > > Metadata backup can be found in /var/backups/ada2.eli and > can be restored with the following command: > > # geli restore /var/backups/ada2.eli /dev/ada2 > > > #> geli attach -k /path/key /dev/ada2 > > now I have .eli device > > #> ls -al /dev/*eli > lrwxr-xr-x 1 root wheel 8 Aug 16 15:43 /dev/ad14.eli -> ada2.eli > crw-r----- 1 root operator 0, 99 Aug 16 15:43 /dev/ada2.eli > > now I am trying to create zfs on it: > >> zpool create geliz /dev/ada2.eli > cannot create 'geliz': one or more devices is currently unavailable > > `zpool create -f ...' gave the same result and in messages I have plenty > rows like these: > > cat /var/log/messages > ... > GEOM_ELI: ada2.eli: 131072 bytes corrupted at offset 444539600896. > GEOM_ELI: ada2.eli: 131072 bytes corrupted at offset 444539863040. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 270336. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 444539609088. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 444539871232. > GEOM_ELI: ada2.eli: 4096 bytes corrupted at offset 444540313600. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 65536. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 8192. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 0. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 262144. > ... > > > > but after > #> dd if=/dev/random of=/dev/ada2.eli bs=10m count=10 > 10+0 records in > 10+0 records out > 104857600 bytes transferred in 7.124000 secs (14718922 bytes/sec) > > I was able to do it! > > #> zpool create geliz /dev/ada2.eli > > pool was successfully created > > but pool status looks weird for me: > > #> zpool status geliz > pool: geliz > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffected. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > geliz ONLINE 0 0 0 > ada2.eli ONLINE 10 0 0 > > errors: No known data errors > > after `zscub' and `zpool clear' I have clean pool: > > #> zpool status geliz > pool: geliz > state: ONLINE > scan: scrub repaired 0 in 0h0m with 0 errors on Thu Aug 16 16:36:44 2012 > config: > > NAME STATE READ WRITE CKSUM > geliz ONLINE 0 0 0 > ada2.eli ONLINE 0 0 0 > > errors: No known data errors > > > QUESTION: > > 1. Am I correct to think I really have correct ZFS over GELI set? > > 2. Why it was needed to dd? What am I missing here, please? > > > may somebody explain that for me please ...? > > -- > Zeus V. Panchenko jid:zeus@im.ibs.dn.ua > IT Dpt., I.B.S. LLC GMT+2 (EET) > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Tue Aug 21 17:30: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 529FD1065741; Tue, 21 Aug 2012 17:30:06 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.93]) by mx1.freebsd.org (Postfix) with ESMTP id E60928FC08; Tue, 21 Aug 2012 17:30:05 +0000 (UTC) Received: from [78.35.144.130] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1T3sDJ-0006EO-PP; Tue, 21 Aug 2012 19:26:01 +0200 Date: Tue, 21 Aug 2012 19:22:55 +0200 From: Fabian Keil To: Zeus Panchenko Message-ID: <20120821192255.1048b445@fabiankeil.de> In-Reply-To: <20120821190742.54449@relay.ibs.dn.ua> References: <20120821190742.54449@relay.ibs.dn.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/JtMKgxnF8HmUGIITc6GY6Fo"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-fs@FreeBSD.ORG, freebsd-geom@FreeBSD.ORG Subject: Re: `zpool create' fails on geli ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 17:30:06 -0000 --Sig_/JtMKgxnF8HmUGIITc6GY6Fo Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Zeus Panchenko wrote: > I am trying to get ZFS on GELI disk ... Good idea, I never use ZFS without it. =20 > Here is the issue: >=20 > #> uname -a > FreeBSD 9.0-RELEASE #0 amd64 >=20 > for /dev/ada2 I do: >=20 > #> geli init -K /path/key -s 4096 -a hmac/sha256 -e aes-xts /dev/ada2 > Enter new passphrase: > Reenter new passphrase: ZFS already provides checksums, so why do you want to use checksums for geli as well? In my opinion "-a hmac/sha256" doesn't add any protection in your case, while reducing the space that is available for ZFS and wasting cpu cycles. I'm not aware of any problem that can be detected by geli's integrity checks but wouldn't be detected by ZFS anyway. ZFS checksums actually offer better protection, as geli only checksums single sectors. > Metadata backup can be found in /var/backups/ada2.eli and > can be restored with the following command: >=20 > # geli restore /var/backups/ada2.eli /dev/ada2 >=20 >=20 > #> geli attach -k /path/key /dev/ada2 >=20 > now I have .eli device >=20 > #> ls -al /dev/*eli > lrwxr-xr-x 1 root wheel 8 Aug 16 15:43 /dev/ad14.eli -> ada2= .eli > crw-r----- 1 root operator 0, 99 Aug 16 15:43 /dev/ada2.eli >=20 > now I am trying to create zfs on it: >=20 > > zpool create geliz /dev/ada2.eli > cannot create 'geliz': one or more devices is currently unavailable >=20 > `zpool create -f ...' gave the same result and in messages I have plenty > rows like these: >=20 > cat /var/log/messages > ... > GEOM_ELI: ada2.eli: 131072 bytes corrupted at offset 444539600896. > GEOM_ELI: ada2.eli: 131072 bytes corrupted at offset 444539863040. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 270336. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 444539609088. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 444539871232. > GEOM_ELI: ada2.eli: 4096 bytes corrupted at offset 444540313600. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 65536. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 8192. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 0. > GEOM_ELI: ada2.eli: 8192 bytes corrupted at offset 262144. > ... Quoting geli(8): | DATA AUTHENTICATION | [..] | It is recommended to write to the whole provider before first use, in | order to make sure that all sectors and their corresponding checksums are | properly initialized into a consistent state. One can safely ignore data | authentication errors that occur immediately after the first time a | provider is attached and before it is initialized in this way. > but after=20 > #> dd if=3D/dev/random of=3D/dev/ada2.eli bs=3D10m count=3D10 > 10+0 records in > 10+0 records out > 104857600 bytes transferred in 7.124000 secs (14718922 bytes/sec) >=20 > I was able to do it! Because this forced geli to create the checksums for the first 100m. Using /dev/zero as source should have worked the same. > #> zpool create geliz /dev/ada2.eli >=20 > pool was successfully created=20 >=20 > but pool status looks weird for me: >=20 > #> zpool status geliz > pool: geliz > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffect= ed. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P > scan: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > geliz ONLINE 0 0 0 > ada2.eli ONLINE 10 0 0 >=20 > errors: No known data errors >=20 > after `zscub' and `zpool clear' I have clean pool: >=20 > #> zpool status geliz > pool: geliz > state: ONLINE > scan: scrub repaired 0 in 0h0m with 0 errors on Thu Aug 16 16:36:44 2012 > config: >=20 > NAME STATE READ WRITE CKSUM > geliz ONLINE 0 0 0 > ada2.eli ONLINE 0 0 0 >=20 > errors: No known data errors I assume this is the result of not forcing geli to generate the checksums for the whole provider as described in the man page. Fabian --Sig_/JtMKgxnF8HmUGIITc6GY6Fo Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAzw/IACgkQBYqIVf93VJ24bQCfWJgiathMk/WYuawZLqOlN8Uv eyEAn2fqN4oq4JcRUhLmq2aKh74ENc9w =TfIC -----END PGP SIGNATURE----- --Sig_/JtMKgxnF8HmUGIITc6GY6Fo-- From owner-freebsd-fs@FreeBSD.ORG Tue Aug 21 17:45:15 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 052A31065673; Tue, 21 Aug 2012 17:45:15 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id DA4368FC18; Tue, 21 Aug 2012 17:45:14 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 61D21173BA; Tue, 21 Aug 2012 10:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1345571114; bh=lYfyxspiFKQTOJUncZZH42DYLP3uPcBzRKjMXvjTPLY=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=aWL1aXLowkF7X5EJAyghYEQHC7xPP67CpDSl/8tmOdMBUXP9OnVtWXmr8E/onUEY3 XQ6fULr6H8ZhNtOetNdPJqdYc8JxnnA1cTTgR9mWxkEa3p8H8VlW2bJUcM4kldEUOs yBIRaQnGiX2nTRe0FX6YnQTlwrI9x6XWurL8Iuik= Message-ID: <5033C929.7020707@delphij.net> Date: Tue, 21 Aug 2012 10:45:13 -0700 From: Xin Li Organization: The freeBSD Project User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.6esrpre) Gecko/20120727 Thunderbird/10.0.6 MIME-Version: 1.0 To: Zeus Panchenko References: <20120821190742.54449@relay.ibs.dn.ua> In-Reply-To: <20120821190742.54449@relay.ibs.dn.ua> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.ORG, freebsd-geom@FreeBSD.ORG Subject: Re: `zpool create' fails on geli ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 17:45:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 08/21/12 09:07, Zeus Panchenko wrote: > hi all, > > SYNOPSIS: `zpool create poolname device.eli' available on .eli > device only after dd some random data to .eli first > > I am trying to get ZFS on GELI disk ... > > Here is the issue: > > #> geli init -K /path/key -s 4096 -a hmac/sha256 -e aes-xts > /dev/ada2 Enter new passphrase: Reenter new passphrase: [...] > #> geli attach -k /path/key /dev/ada2 Normally you will want to fill the device with random data before using. Note that you have specified -a, which makes geli to do checksum authentication, that's not needed because ZFS have built-in end-to-end checksums already. > now I have .eli device > > #> ls -al /dev/*eli lrwxr-xr-x 1 root wheel 8 Aug 16 > 15:43 /dev/ad14.eli -> ada2.eli crw-r----- 1 root operator 0, > 99 Aug 16 15:43 /dev/ada2.eli > > now I am trying to create zfs on it: > >> zpool create geliz /dev/ada2.eli > cannot create 'geliz': one or more devices is currently > unavailable > > `zpool create -f ...' gave the same result and in messages I have > plenty rows like these: These are expected behavior. > cat /var/log/messages ... GEOM_ELI: ada2.eli: 131072 bytes > corrupted at offset 444539600896. GEOM_ELI: ada2.eli: 131072 bytes > corrupted at offset 444539863040. [...] > ... > > but after #> dd if=/dev/random of=/dev/ada2.eli bs=10m count=10 > 10+0 records in 10+0 records out 104857600 bytes transferred in > 7.124000 secs (14718922 bytes/sec) > > I was able to do it! > > #> zpool create geliz /dev/ada2.eli > > pool was successfully created > > but pool status looks weird for me: > > #> zpool status geliz pool: geliz state: ONLINE status: One or more > devices has experienced an unrecoverable error. An attempt was > made to correct the error. Applications are unaffected. action: > Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P scan: none requested > config: > > NAME STATE READ WRITE CKSUM geliz ONLINE 0 > 0 0 ada2.eli ONLINE 10 0 0 > > errors: No known data errors > > after `zscub' and `zpool clear' I have clean pool: Did you see any GELI checksum errors when having this? > #> zpool status geliz pool: geliz state: ONLINE scan: scrub > repaired 0 in 0h0m with 0 errors on Thu Aug 16 16:36:44 2012 > config: > > NAME STATE READ WRITE CKSUM geliz ONLINE 0 > 0 0 ada2.eli ONLINE 0 0 0 > > errors: No known data errors > > > QUESTION: > > 1. Am I correct to think I really have correct ZFS over GELI set? > > 2. Why it was needed to dd? What am I missing here, please? My suggestions: 1. Don't use -a, it's a waste of CPU cycle (and disk space) to do checksums twice -- this won't give more redundancy or more chances to recover data in case of a hardware failure. 2. Do use dd to initialize the GELI device before use. There are several benefits of doing this -- the most important two are -- it wipes existing, possibly sensitive data, and make it harder for attackers to tell where is the important data. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQM8kpAAoJEG80Jeu8UPuzeOAH/i2kG/jN3j58wTe/gG2teKoM 08xy+Lv9lhljihJkUhRx1hAPtYdK1oMKVg7mnQbohSRzjGGqBRnT25ZUD8kbusmW ULDOmSBbnraStNQbBSpnyik/y2trzfne9YzjhH4aB1CKVJ2X4cHTaJIaGv9iQqI3 S8QjEpKCDcpKlEyGlhJ9TPaCqyzpJbw6p5TDGoVEsq9YIiE7BAbrjfw5Pe87HKK0 BAsLqmJYmQSjjLp/g4FK5vjr/zVpGgPcwP7oD0iSXCX7UI7M/Rhj8Rqyai1cv2/g ES7uhpy5ifAUalcuJjIFqox7QC5h2uT0e5/DPNttmXfL1d0yb3FdLPgWkV0GDF0= =v/ZJ -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Tue Aug 21 21:09:35 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 67B3D1065673 for ; Tue, 21 Aug 2012 21:09:35 +0000 (UTC) (envelope-from cheeky.m@live.com) Received: from bay0-omc4-s3.bay0.hotmail.com (bay0-omc4-s3.bay0.hotmail.com [65.54.190.205]) by mx1.freebsd.org (Postfix) with ESMTP id 4DB9D8FC1A for ; Tue, 21 Aug 2012 21:09:35 +0000 (UTC) Received: from BAY170-W86 ([65.54.190.199]) by bay0-omc4-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Aug 2012 14:09:28 -0700 Message-ID: X-Originating-IP: [50.138.191.19] From: Roger Hammerstein To: Date: Tue, 21 Aug 2012 17:09:28 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 21 Aug 2012 21:09:28.0327 (UTC) FILETIME=[40179970:01CD7FE1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: panic while zfs scrubbing 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, 21 Aug 2012 21:09:35 -0000 I have a zpool where scrub seems to cause panics. I do not have zfs in rc.conf=2C but import manually on boot. I start a scrub on a zpool=2C and some time through will get a panic and reboot. After panic and reboot=2C re-importing the pool and allowing the scrub to restart on its own will cause another panic. So I import and immediately stop the scrub for now. ls -la *.{9=2C8=2C10} -rw------- 1 root wheel 150744 Aug 21 16:46 core.txt.10 -rw------- 1 root wheel 147280 Aug 21 11:04 core.txt.8 -rw------- 1 root wheel 148572 Aug 21 14:53 core.txt.9 -rw------- 1 root wheel 457 Aug 21 16:45 info.10 -rw------- 1 root wheel 456 Aug 21 11:04 info.8 -rw------- 1 root wheel 458 Aug 21 14:52 info.9 -rw------- 1 root wheel 643919872 Aug 21 16:46 vmcore.10 -rw------- 1 root wheel 767168512 Aug 21 11:04 vmcore.8 -rw------- 1 root wheel 1097850880 Aug 21 14:53 vmcore.9 9.1-BETA1 FreeBSD 9.1-BETA1 #34: Thu Jul 12 05:57:44 EDT 2012 amd64 4GB of ram=2C 4gb of swap. panic: integer divide fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation=2C Inc. GDB is free software=2C covered by the GNU General Public License=2C and yo= u are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 18: integer divide fault while in kernel mode cpuid =3D 5=3B apic id =3D 05 instruction pointer =3D 0x20:0xffffffff81674a14 stack pointer =3D 0x28:0xffffff810c3d4520 frame pointer =3D 0x28:0xffffff810c3d4540 code segment =3D base 0x0=2C limit 0xfffff=2C type 0x1b =3D DPL 0=2C pres 1=2C long 1=2C def32 0=2C gran 1 processor eflags =3D interrupt enabled=2C resume=2C IOPL =3D 0 current process =3D 9480 (txg_thread_enter) trap number =3D 18 panic: integer divide fault cpuid =3D 5 KDB: stack backtrace: #0 0xffffffff80920346 at kdb_backtrace+0x66 #1 0xffffffff808ea35e at panic+0x1ce #2 0xffffffff80bd7a30 at trap_fatal+0x290 #3 0xffffffff80bd80c5 at trap+0x105 #4 0xffffffff80bc295f at calltrap+0x8 #5 0xffffffff816818cf at vdev_mirror_io_start+0x2bf #6 0xffffffff81699542 at zio_vdev_io_start+0x232 #7 0xffffffff81698fe3 at zio_execute+0xc3 #8 0xffffffff8165ea1c at dsl_scan_scrub_cb+0x3ec #9 0xffffffff8165fe14 at dsl_scan_visitbp+0x534 #10 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 #11 0xffffffff81660c84 at dsl_scan_visitdnode+0x84 #12 0xffffffff81660070 at dsl_scan_visitbp+0x790 #13 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 #14 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 #15 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 #16 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 #17 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 Uptime: 1h51m55s Dumping 614 out of 3818 MB:..3%..11%..21%..32%..42%..53%..63%..71%..81%..92= % Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kerne= l/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bo= ot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:224 #1 0xffffffff808e9e41 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xffffffff808ea337 in panic (fmt=3D0x1
) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xffffffff80bd7a30 in trap_fatal (frame=3D0x12=2C eva=3DVariable "eva" = is not available. ) at /usr/src/sys/amd64/amd64/trap.c:857 #4 0xffffffff80bd80c5 in trap (frame=3D0xffffff810c3d4470) at /usr/src/sys/amd64/amd64/trap.c:599 #5 0xffffffff80bc295f in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #6 0xffffffff81674a14 in spa_get_random (range=3D0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/spa_misc.c:1165 #7 0xffffffff816818cf in vdev_mirror_io_start (zio=3D0xfffffe0037e5e000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/vdev_mirror.c:89 #8 0xffffffff81699542 in zio_vdev_io_start (zio=3D0xfffffe0037e5e000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/zio.c:2305 #9 0xffffffff81698fe3 in zio_execute (zio=3D0xfffffe0037e5e000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/zio.c:1196 #10 0xffffffff8165ea1c in dsl_scan_scrub_cb (dp=3D0xffffff810c3d4538=2C=20 bp=3D0xffffff8003c53480=2C zb=3D0xffffff810c3d4970) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:1737 #11 0xffffffff8165fe14 in dsl_scan_visitbp (bp=3D0xffffff8003c53480=2C=20 zb=3D0xffffff810c3d4970=2C dnp=3D0xffffff8003642200=2C pbuf=3DVariable = "pbuf" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/= zfs/dsl_scan.c:858 #12 0xffffffff8165fd99 in dsl_scan_visitbp (bp=3D0xffffff8003642240=2C=20 zb=3D0xffffff810c3d4a00=2C dnp=3D0xffffff8003642200=2C pbuf=3DVariable = "pbuf" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:684 #13 0xffffffff81660c84 in dsl_scan_visitdnode (scn=3D0xfffffe001523dc00=2C= =20 ds=3D0xfffffe0037abf400=2C ostype=3DDMU_OST_ZFS=2C dnp=3D0xffffff800364= 2200=2C=20 buf=3D0xfffffe00befda9c0=2C object=3D291417=2C tx=3D0xfffffe00151fc400) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:770 #14 0xffffffff81660070 in dsl_scan_visitbp (bp=3D0xffffff800359b900=2C=20 zb=3D0xffffff810c3d4cb0=2C dnp=3D0xfffffe0008076000=2C pbuf=3DVariable = "pbuf" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:718 #15 0xffffffff8165fd99 in dsl_scan_visitbp (bp=3D0xffffff80033e5380=2C=20 zb=3D0xffffff810c3d4e10=2C dnp=3D0xfffffe0008076000=2C pbuf=3DVariable = "pbuf" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:684 #16 0xffffffff8165fd99 in dsl_scan_visitbp (bp=3D0xffffff80033df000=2C=20 zb=3D0xffffff810c3d4f70=2C dnp=3D0xfffffe0008076000=2C pbuf=3DVariable = "pbuf" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:684 #17 0xffffffff8165fd99 in dsl_scan_visitbp (bp=3D0xffffff80033db000=2C=20 zb=3D0xffffff810c3d50d0=2C dnp=3D0xfffffe0008076000=2C pbuf=3DVariable = "pbuf" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:684 #18 0xffffffff8165fd99 in dsl_scan_visitbp (bp=3D0xffffff8003451000=2C=20 zb=3D0xffffff810c3d5230=2C dnp=3D0xfffffe0008076000=2C pbuf=3DVariable = "pbuf" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:684 #19 0xffffffff8165fd99 in dsl_scan_visitbp (bp=3D0xffffff80033d7000=2C=20 zb=3D0xffffff810c3d5390=2C dnp=3D0xfffffe0008076000=2C pbuf=3DVariable = "pbuf" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:684 #20 0xffffffff8165fd99 in dsl_scan_visitbp (bp=3D0xfffffe0008076040=2C=20 zb=3D0xffffff810c3d5420=2C dnp=3D0xfffffe0008076000=2C pbuf=3DVariable = "pbuf" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:684 #21 0xffffffff81660c84 in dsl_scan_visitdnode (scn=3D0xfffffe001523dc00=2C= =20 ds=3D0xfffffe0037abf400=2C ostype=3DDMU_OST_ZFS=2C dnp=3D0xfffffe000807= 6000=2C=20 buf=3D0xfffffe00375996e8=2C object=3D0=2C tx=3D0xfffffe00151fc400) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:770 #22 0xffffffff8165ff9a in dsl_scan_visitbp (bp=3D0xfffffe003729e280=2C=20 zb=3D0xffffff810c3d55f0=2C dnp=3D0x0=2C pbuf=3DVariable "pbuf" is not a= vailable. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:736 #23 0xffffffff816600d7 in dsl_scan_visit_rootbp (scn=3DVariable "scn" is no= t available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:872 #24 0xffffffff81660172 in dsl_scan_visitds (scn=3D0xfffffe001523dc00=2C dso= bj=3D21=2C=20 tx=3D0xfffffe00151fc400) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:1099 #25 0xffffffff81660695 in dsl_scan_sync (dp=3D0xfffffe0037335000=2C=20 tx=3D0xfffffe00151fc400) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:1355 #26 0xffffffff81667e30 in spa_sync (spa=3D0xfffffe0008161000=2C txg=3D97010= ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/spa.c:5711 #27 0xffffffff81678749 in txg_sync_thread (arg=3DVariable "arg" is not avai= lable. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/txg.c:423 #28 0xffffffff808bb4cf in fork_exit ( callout=3D0xffffffff81678610 =2C arg=3D0xfffffe0037335= 000=2C=20 frame=3D0xffffff810c3d5c40) at /usr/src/sys/kern/kern_fork.c:992 #29 0xffffffff80bc2e8e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000001 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000000 in ?? () #44 0x0000000000000000 in ?? () #45 0x0000000000000000 in ?? () #46 0x0000000000000000 in ?? () #47 0x0000000000000000 in ?? () #48 0x0000000000000000 in ?? () #49 0x0000000000000000 in ?? () #50 0x0000000000000000 in ?? () #51 0x0000000000000000 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000005 in ?? () #55 0xffffffff81242b00 in tdq_cpu () #56 0xfffffe0015e9d470 in ?? () #57 0x0000000000000000 in ?? () #58 0xffffff810c3d4580 in ?? () #59 0xffffff810c3d4528 in ?? () #60 0xfffffe00028848e0 in ?? () #61 0xffffffff80912fce in sched_switch (td=3D0xfffffe00370b1470=2C=20 newtd=3D0xfffffe0037335000=2C flags=3DVariable "flags" is not available= . ) at /usr/src/sys/kern/sched_ule.c:1921 Previous frame inner to this frame (corrupt stack?) (kgdb)=20 pool: zzzz state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: scrub canceled on Tue Aug 21 16:53:03 2012 config: NAME STATE READ WRITE CKSUM zzzz ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 ada3 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada6 ONLINE 0 0 0 ada9 ONLINE 0 0 0 ada4 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada5 ONLINE 0 0 0 errors: 4 data errors=2C use '-v' for a list The data errors will go away if the scrub completes=3B it has shown that be= fore. And yes=2C here: 'zpool clear zzzz' pool: zzzz state: ONLINE scan: scrub canceled on Tue Aug 21 17:02:53 2012 config: NAME STATE READ WRITE CKSUM zzzz ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 ada3 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada6 ONLINE 0 0 0 ada9 ONLINE 0 0 0 ada4 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada5 ONLINE 0 0 0 errors: No known data errors The machine passes 'memtest' memory check of over 12 hours. Bad disk ? One of the disks has command errors=2C but no pending sectors to reallocate in smartctl output=2C and there are no disk errors in /var/log/messages. =20 Two sata port multipliers. pmp0 at siisch0 bus 0 scbus6 target 15 lun 0 pmp0: ATA-0 device pmp0: 300.000MB/s transfers (SATA 2.x=2C NONE=2C PIO 8192bytes) pmp0: 5 fan-out ports pmp1 at siisch4 bus 0 scbus10 target 15 lun 0 pmp1: ATA-0 device pmp1: 300.000MB/s transfers (SATA 2.x=2C NONE=2C PIO 8192bytes) pmp1: 5 fan-out ports = From owner-freebsd-fs@FreeBSD.ORG Wed Aug 22 10:24: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 C651C106564A; Wed, 22 Aug 2012 10:24:42 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3ECD88FC16; Wed, 22 Aug 2012 10:24:41 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id q7MAOewi024866; Wed, 22 Aug 2012 13:24:40 +0300 (EEST) Message-ID: <20120822132440.24864@relay.ibs.dn.ua> Date: Wed, 22 Aug 2012 13:24:40 +0300 From: Zeus Panchenko To: In-reply-to: Your message of Tue, 21 Aug 2012 20:28:22 +0300 References: <20120821190742.54449@relay.ibs.dn.ua> Organization: I.B.S. LLC X-Mailer: MH-E 8.2; GNU Mailutils 2.99.97; GNU Emacs 23.4.1 X-Face: &sReWXo3Iwtqql1[My(t1Gkx; y?KF@KF`4X+'9Cs@PtK^y%}^.>Mtbpyz6U=,Op:KPOT.uG )Nvx`=er!l?WASh7KeaGhga"1[&yz$_7ir'cVp7o%CGbJ/V)j/=]vzvvcqcZkf; JDurQG6wTg+?/xA go`}1.Ze//K; Fk&/&OoHd'[b7iGt2UO>o(YskCT[_D)kh4!yY'<&:yt+zM=A`@`~9U+P[qS:f; #9z~ Or/Bo#N-'S'!'[3Wog'ADkyMqmGDvga?WW)qd=?)`Y&k=o}>!ST\ Cc: freebsd-fs@freebsd.org Subject: Re: `zpool create' fails on geli ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 10:24:42 -0000 thanks much to all for help now everything is clear to me and works fine! resume: if geli was initialized with `-a' than we need to fill whole of it to initialize checksums what will make it possible to `zpool create ...' something like this: geli init -K /path/key -s 4096 -a hmac/sha256 -e aes-xts /dev/adaX geli attach -k /path/key /dev/adaX dd if=/dev/zero of=/dev/adaX.eli bs=10m zpool create geliz /dev/adaX.eli but it's better to geli init -K /path/key -s 4096 -e aes-xts /dev/adaX geli attach -k /path/key /dev/adaX zpool create geliz /dev/adaX.eli since `geli -a ...' in this case, is a waste of CPU cycles and disk space. -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Wed Aug 22 10:29:35 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B8F5106564A for ; Wed, 22 Aug 2012 10:29:35 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3978FC12 for ; Wed, 22 Aug 2012 10:29:34 +0000 (UTC) Received: by qcsg15 with SMTP id g15so616784qcs.13 for ; Wed, 22 Aug 2012 03:29:34 -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=ItIIgDP8AQcdE44GkOjX2pQHa8ouP3MIBE0SYdfzeAg=; b=dQxtr1pfEPmLeAeeS9/nUi1Y4/ZiYqCJlV7f1vcRQuo2YowXT543sp13ABnNSzpvuf muco5SXZYO/boquJkK8m9EmJJQDwSno+e6eY2Mu+34ySeKwwD/USK4e0XkQrhFaovYrz KnRFXHvwgfpo38g3etzEdKRacNEi3N64K0atJVJg8e3+Ocj+P4tTPDx0ORHaY+c+7rnS McL/VJWDdozLfrzSbw6IToW4OfTWTWNFkEGInjEl0MvDSRJMQDMVAArbkMk/yOirSw/N Zu2rp6hVbeT/sE1e1g+afJjTaPdObAX7Q1996ogzpn+N+on1+lSF33Z9f704Y/x0EYpZ 7GSQ== MIME-Version: 1.0 Received: by 10.229.134.194 with SMTP id k2mr16631744qct.141.1345631374024; Wed, 22 Aug 2012 03:29:34 -0700 (PDT) Received: by 10.49.4.136 with HTTP; Wed, 22 Aug 2012 03:29:33 -0700 (PDT) In-Reply-To: References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> Date: Wed, 22 Aug 2012 18:29:33 +0800 Message-ID: From: Marcelo Araujo To: =?ISO-8859-1?Q?Karli_Sj=F6berg?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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: Wed, 22 Aug 2012 10:29:35 -0000 2012/8/15 Karli Sj=F6berg > > > > as Marcelo Araujo suggested. See how long it=B4ll take before it stalls t= his > time... > > Dear Karli, Any new or progress with your issue? Best Regards, --=20 Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Wed Aug 22 10:37:25 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 331BE106564A; Wed, 22 Aug 2012 10:37:25 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.93]) by mx1.freebsd.org (Postfix) with ESMTP id DF4058FC0C; Wed, 22 Aug 2012 10:37:24 +0000 (UTC) Received: from [78.35.161.203] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1T48IP-0005BN-Jj; Wed, 22 Aug 2012 12:36:21 +0200 Date: Wed, 22 Aug 2012 12:35:35 +0200 From: Fabian Keil To: Zeus Panchenko Message-ID: <20120822123535.0385f118@fabiankeil.de> In-Reply-To: <20120822132440.24864@relay.ibs.dn.ua> References: <20120821190742.54449@relay.ibs.dn.ua> <20120822132440.24864@relay.ibs.dn.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/kJkciffGM_NNTo9UO5IPhjx"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Subject: Re: `zpool create' fails on geli ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 10:37:25 -0000 --Sig_/kJkciffGM_NNTo9UO5IPhjx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Zeus Panchenko wrote: > resume: >=20 > if geli was initialized with `-a' than we need to fill whole of it to > initialize checksums what will make it possible to `zpool create ...' >=20 > something like this: >=20 > geli init -K /path/key -s 4096 -a hmac/sha256 -e aes-xts /dev/adaX > geli attach -k /path/key /dev/adaX > dd if=3D/dev/zero of=3D/dev/adaX.eli bs=3D10m > zpool create geliz /dev/adaX.eli >=20 > but it's better to >=20 > geli init -K /path/key -s 4096 -e aes-xts /dev/adaX Does your disk actually use 4k sectors? Otherwise it's not clear to me that "-s 4096" makes sense when using ZFS. I'm not claiming that it's obviously wrong, but I'm not aware of any benchmarks that show that it's better than the default in any way. Fabian --Sig_/kJkciffGM_NNTo9UO5IPhjx Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA0tfwACgkQBYqIVf93VJ3mVQCfQfr3BFdUnZMasKy9sKm/P8+z m2gAn34Gf4XRNA81kDj5cWGRBeFefwbS =w8A5 -----END PGP SIGNATURE----- --Sig_/kJkciffGM_NNTo9UO5IPhjx-- From owner-freebsd-fs@FreeBSD.ORG Wed Aug 22 11:27: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 0D91A1065670; Wed, 22 Aug 2012 11:27:21 +0000 (UTC) (envelope-from Karli.Sjoberg@slu.se) Received: from Exchange2.ad.slu.se (exchange2.ad.slu.se [193.10.100.95]) by mx1.freebsd.org (Postfix) with ESMTP id 844548FC12; Wed, 22 Aug 2012 11:27:20 +0000 (UTC) Received: from exmbx3.ad.slu.se ([193.10.100.93]) by Exchange2.ad.slu.se ([193.10.100.95]) with mapi; Wed, 22 Aug 2012 13:27:11 +0200 From: =?iso-8859-1?Q?Karli_Sj=F6berg?= To: "araujo@FreeBSD.org" Date: Wed, 22 Aug 2012 13:27:10 +0200 Thread-Topic: Hang when importing pool Thread-Index: Ac2AWRKA1VwBPQoHQlev3Rqzcr4Zuw== Message-ID: References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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, 22 Aug 2012 11:27:21 -0000 22 aug 2012 kl. 12.29 skrev Marcelo Araujo: 2012/8/15 Karli Sj=F6berg > as Marcelo Araujo suggested. See how long it=B4ll take before it stalls thi= s time... Dear Karli, Any new or progress with your issue? Hey man, glad to hear back from you! Well, not much progress, I=B4m afraid. The constant reboot/import-loop didn= =B4t seem to yield much even after a couple of days, so I=B4ve gotten the d= isks hooked up to yet another server we had and managed to spare. It=B4s fu= gly to say the least, but whatever gets the job done, right:) http://i48.tinypic.com/1z4k0uu.jpg http://i46.tinypic.com/34pxobd.jpg Notice the "elegant" paperclip in the SuperMicro system=B4s ATX connector;) The blade underneath is a Sun Fire X4140 from one of the two original Sun S= torage 7310 HA cluster system that served this data from a JBOD before it w= as moved to the SuperMicro/FreeBSD system. It is equipped with even more RA= M(64GB) but import still stalls like this: http://i49.tinypic.com/2hxvcw3.jpg Oddly enough, Wired RAM is only about 5-5.5GB but it hasn=B4t been doing an= ything productive for about an hour or so... Thoughts? Best Regards, -- Marcelo Araujo araujo@FreeBSD.org Med V=E4nliga H=E4lsningar ---------------------------------------------------------------------------= ---- Karli Sj=F6berg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kron=E5sv=E4gen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se From owner-freebsd-fs@FreeBSD.ORG Wed Aug 22 13: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 90DCF106564A for ; Wed, 22 Aug 2012 13:11:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B1BCE8FC18 for ; Wed, 22 Aug 2012 13:11:45 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA23860; Wed, 22 Aug 2012 16:11:33 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <5034DA84.8050507@FreeBSD.org> Date: Wed, 22 Aug 2012 16:11:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120730 Thunderbird/14.0 MIME-Version: 1.0 To: Roger Hammerstein References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: panic while zfs scrubbing 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, 22 Aug 2012 13:11:46 -0000 on 22/08/2012 00:09 Roger Hammerstein said the following: > > > I have a zpool where scrub seems to cause panics. > > I do not have zfs in rc.conf, but import manually > on boot. > > I start a scrub on a zpool, and some time through will get a panic > and reboot. > After panic and reboot, re-importing the pool and allowing > the scrub to restart on its own will cause another panic. > So I import and immediately stop the scrub for now. > > ls -la *.{9,8,10} > -rw------- 1 root wheel 150744 Aug 21 16:46 core.txt.10 > -rw------- 1 root wheel 147280 Aug 21 11:04 core.txt.8 > -rw------- 1 root wheel 148572 Aug 21 14:53 core.txt.9 > -rw------- 1 root wheel 457 Aug 21 16:45 info.10 > -rw------- 1 root wheel 456 Aug 21 11:04 info.8 > -rw------- 1 root wheel 458 Aug 21 14:52 info.9 > -rw------- 1 root wheel 643919872 Aug 21 16:46 vmcore.10 > -rw------- 1 root wheel 767168512 Aug 21 11:04 vmcore.8 > -rw------- 1 root wheel 1097850880 Aug 21 14:53 vmcore.9 > > > 9.1-BETA1 FreeBSD 9.1-BETA1 #34: Thu Jul 12 05:57:44 EDT 2012 > amd64 > 4GB of ram, 4gb of swap. > > > panic: integer divide fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 18: integer divide fault while in kernel mode > cpuid = 5; apic id = 05 > instruction pointer = 0x20:0xffffffff81674a14 > stack pointer = 0x28:0xffffff810c3d4520 > frame pointer = 0x28:0xffffff810c3d4540 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 9480 (txg_thread_enter) > trap number = 18 > panic: integer divide fault > cpuid = 5 > > KDB: stack backtrace: > #0 0xffffffff80920346 at kdb_backtrace+0x66 > #1 0xffffffff808ea35e at panic+0x1ce > #2 0xffffffff80bd7a30 at trap_fatal+0x290 > #3 0xffffffff80bd80c5 at trap+0x105 > #4 0xffffffff80bc295f at calltrap+0x8 > #5 0xffffffff816818cf at vdev_mirror_io_start+0x2bf > #6 0xffffffff81699542 at zio_vdev_io_start+0x232 > #7 0xffffffff81698fe3 at zio_execute+0xc3 > #8 0xffffffff8165ea1c at dsl_scan_scrub_cb+0x3ec > #9 0xffffffff8165fe14 at dsl_scan_visitbp+0x534 > #10 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 > #11 0xffffffff81660c84 at dsl_scan_visitdnode+0x84 > #12 0xffffffff81660070 at dsl_scan_visitbp+0x790 > #13 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 > #14 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 > #15 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 > #16 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 > #17 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 > Uptime: 1h51m55s > Dumping 614 out of 3818 MB:..3%..11%..21%..32%..42%..53%..63%..71%..81%..92% > > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > 224 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > #1 0xffffffff808e9e41 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xffffffff808ea337 in panic (fmt=0x1
) > at /usr/src/sys/kern/kern_shutdown.c:636 > #3 0xffffffff80bd7a30 in trap_fatal (frame=0x12, eva=Variable "eva" is not available. > ) > at /usr/src/sys/amd64/amd64/trap.c:857 > #4 0xffffffff80bd80c5 in trap (frame=0xffffff810c3d4470) > at /usr/src/sys/amd64/amd64/trap.c:599 > #5 0xffffffff80bc295f in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:228 > #6 0xffffffff81674a14 in spa_get_random (range=0) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:1165 Not sure what triggers this problem but it looks like zio is issued for a block-pointer with no valid DVA. It's either a result of some logical bug in ZFS code or some severe on-disk corruption. > #7 0xffffffff816818cf in vdev_mirror_io_start (zio=0xfffffe0037e5e000) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:89 Could you please print *zio and *zio->io_bp in this frame? It might also be good idea to report this issue to zfs-discuss@opensolaris.org. > #8 0xffffffff81699542 in zio_vdev_io_start (zio=0xfffffe0037e5e000) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2305 > #9 0xffffffff81698fe3 in zio_execute (zio=0xfffffe0037e5e000) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1196 > #10 0xffffffff8165ea1c in dsl_scan_scrub_cb (dp=0xffffff810c3d4538, > bp=0xffffff8003c53480, zb=0xffffff810c3d4970) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:1737 And *bp and *scn here too. > #11 0xffffffff8165fe14 in dsl_scan_visitbp (bp=0xffffff8003c53480, > zb=0xffffff810c3d4970, dnp=0xffffff8003642200, pbuf=Variable "pbuf" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:858 > #12 0xffffffff8165fd99 in dsl_scan_visitbp (bp=0xffffff8003642240, > zb=0xffffff810c3d4a00, dnp=0xffffff8003642200, pbuf=Variable "pbuf" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:684 > #13 0xffffffff81660c84 in dsl_scan_visitdnode (scn=0xfffffe001523dc00, > ds=0xfffffe0037abf400, ostype=DMU_OST_ZFS, dnp=0xffffff8003642200, > buf=0xfffffe00befda9c0, object=291417, tx=0xfffffe00151fc400) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:770 > #14 0xffffffff81660070 in dsl_scan_visitbp (bp=0xffffff800359b900, > zb=0xffffff810c3d4cb0, dnp=0xfffffe0008076000, pbuf=Variable "pbuf" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:718 > #15 0xffffffff8165fd99 in dsl_scan_visitbp (bp=0xffffff80033e5380, > zb=0xffffff810c3d4e10, dnp=0xfffffe0008076000, pbuf=Variable "pbuf" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:684 > #16 0xffffffff8165fd99 in dsl_scan_visitbp (bp=0xffffff80033df000, > zb=0xffffff810c3d4f70, dnp=0xfffffe0008076000, pbuf=Variable "pbuf" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:684 > #17 0xffffffff8165fd99 in dsl_scan_visitbp (bp=0xffffff80033db000, > zb=0xffffff810c3d50d0, dnp=0xfffffe0008076000, pbuf=Variable "pbuf" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:684 > #18 0xffffffff8165fd99 in dsl_scan_visitbp (bp=0xffffff8003451000, > zb=0xffffff810c3d5230, dnp=0xfffffe0008076000, pbuf=Variable "pbuf" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:684 > #19 0xffffffff8165fd99 in dsl_scan_visitbp (bp=0xffffff80033d7000, > zb=0xffffff810c3d5390, dnp=0xfffffe0008076000, pbuf=Variable "pbuf" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:684 > #20 0xffffffff8165fd99 in dsl_scan_visitbp (bp=0xfffffe0008076040, > zb=0xffffff810c3d5420, dnp=0xfffffe0008076000, pbuf=Variable "pbuf" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:684 > #21 0xffffffff81660c84 in dsl_scan_visitdnode (scn=0xfffffe001523dc00, > ds=0xfffffe0037abf400, ostype=DMU_OST_ZFS, dnp=0xfffffe0008076000, > buf=0xfffffe00375996e8, object=0, tx=0xfffffe00151fc400) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:770 > #22 0xffffffff8165ff9a in dsl_scan_visitbp (bp=0xfffffe003729e280, > zb=0xffffff810c3d55f0, dnp=0x0, pbuf=Variable "pbuf" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:736 > #23 0xffffffff816600d7 in dsl_scan_visit_rootbp (scn=Variable "scn" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:872 > #24 0xffffffff81660172 in dsl_scan_visitds (scn=0xfffffe001523dc00, dsobj=21, > tx=0xfffffe00151fc400) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:1099 > #25 0xffffffff81660695 in dsl_scan_sync (dp=0xfffffe0037335000, > tx=0xfffffe00151fc400) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:1355 > #26 0xffffffff81667e30 in spa_sync (spa=0xfffffe0008161000, txg=97010) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:5711 > #27 0xffffffff81678749 in txg_sync_thread (arg=Variable "arg" is not available. > ) > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:423 > #28 0xffffffff808bb4cf in fork_exit ( > callout=0xffffffff81678610 , arg=0xfffffe0037335000, > frame=0xffffff810c3d5c40) at /usr/src/sys/kern/kern_fork.c:992 > #29 0xffffffff80bc2e8e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:602 [snip] -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Aug 22 13:29:08 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 013B31065673; Wed, 22 Aug 2012 13:29:08 +0000 (UTC) (envelope-from fj@wonko.batmule.dk) Received: from wonko.batmule.dk (wonko.batmule.dk [IPv6:2a02:9d0:3020:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 82FEB8FC0C; Wed, 22 Aug 2012 13:29:07 +0000 (UTC) Received: by wonko.batmule.dk (Postfix, from userid 1001) id CE98914675; Wed, 22 Aug 2012 15:29:05 +0200 (CEST) Date: Wed, 22 Aug 2012 15:29:05 +0200 From: Flemming Jacobsen To: freebsd-fs@freebsd.org Message-ID: <20120822132905.GA53612@wonko.batmule.dk> References: <20120821190742.54449@relay.ibs.dn.ua> <20120822132440.24864@relay.ibs.dn.ua> <20120822123535.0385f118@fabiankeil.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120822123535.0385f118@fabiankeil.de> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGPkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDCC399C7 Cc: freebsd-geom@freebsd.org Subject: Re: `zpool create' fails on geli ... 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, 22 Aug 2012 13:29:08 -0000 Fabian Keil wrote: > Zeus Panchenko wrote: > > geli init -K /path/key -s 4096 -e aes-xts /dev/adaX > > Does your disk actually use 4k sectors? Otherwise it's not clear > to me that "-s 4096" makes sense when using ZFS. > > I'm not claiming that it's obviously wrong, but I'm not aware of > any benchmarks that show that it's better than the default in > any way. It is my understanding that creating a 4K setup will prepare you for the day when your replacement drive is a 4K one. No benefit today, but also no real performance hit. And we avoid a real performance hit later. If I am mistaken, then I wold love to hear about it. Regards, Flemming -- Flemming Jacobsen Email: fj@batmule.dk "I don't need The Media to tell me that I should be outraged about a brutal murder. All I need is to be informed that it has happened, and I'll form my own opinion about it." -- The_Morlock (http://slashdot.org/comments.pl?sid=00%2F02%2F21%2F1125208) From owner-freebsd-fs@FreeBSD.ORG Wed Aug 22 15:28:08 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 4F51910657AA for ; Wed, 22 Aug 2012 15:28:08 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id BF4878FC19 for ; Wed, 22 Aug 2012 15:28:07 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3X2CLt6rVPzGMld for ; Wed, 22 Aug 2012 17:28:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:in-reply-to:references:user-agent:date:date :subject:subject:organization:from:from:received:received :received:vbr-info; s=jakla2; t=1345649285; x=1348241286; bh=HgA okl6dsSppwLiX+O5aQaFWEcmY7JSZqRxtcOfCbRU=; b=OviROxkSU/HXrVAsU4P 4DDKwEYzH20okPxe8yGWYzuzegk6MYblZR/AEbXD0p4JWOeuDRVpcvn8iPhx/tCq bFTXQ68A2Xnqu8adozX6aayYaxntp6ievUaZgKQ2fKXW7XwlFCRDAIz3avO/QQ4e IDoIdu0jsduvKQNlc+5T6tC0= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id BH5tK5gK3uEa for ; Wed, 22 Aug 2012 17:28:05 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Wed, 22 Aug 2012 17:28:05 +0200 (CEST) Received: from neli.ijs.si (unknown [IPv6:2001:1470:ff80:0:21c:c0ff:feb1:8c91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id 510B9301 for ; Wed, 22 Aug 2012 17:28:05 +0200 (CEST) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-fs@freebsd.org Date: Wed, 22 Aug 2012 17:28:04 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20120821190742.54449@relay.ibs.dn.ua> <20120822123535.0385f118@fabiankeil.de> <20120822132905.GA53612@wonko.batmule.dk> In-Reply-To: <20120822132905.GA53612@wonko.batmule.dk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201208221728.04712.Mark.Martinec+freebsd@ijs.si> Subject: Re: `zpool create' fails on geli ... 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, 22 Aug 2012 15:28:08 -0000 > Fabian Keil wrote: > > Zeus Panchenko wrote: > > > geli init -K /path/key -s 4096 -e aes-xts /dev/adaX > > > > Does your disk actually use 4k sectors? Otherwise it's not clear > > to me that "-s 4096" makes sense when using ZFS. > > > > I'm not claiming that it's obviously wrong, but I'm not aware of > > any benchmarks that show that it's better than the default in > > any way. It benefits geli performance (tried it, it does): $ man geli -s sectorsize Change decrypted provider's sector size. Increasing sector size allows to increase per- formance, because we need to generate an IV and do encrypt/decrypt for every single sector - less number of sectors means less work to > It is my understanding that creating a 4K setup will prepare you > for the day when your replacement drive is a 4K one. > No benefit today, but also no real performance hit. And we avoid > a real performance hit later. That day has already arrived some time ago. For ZFS on WD20EARS disks, persuading ZFS to use 4k sectors makes a significant performance boost. Mark From owner-freebsd-fs@FreeBSD.ORG Wed Aug 22 15:41:19 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 CE6D3106564A for ; Wed, 22 Aug 2012 15:41:19 +0000 (UTC) (envelope-from boris.astardzhiev@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 3D2DC8FC1C for ; Wed, 22 Aug 2012 15:41:18 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so888975lbb.13 for ; Wed, 22 Aug 2012 08:41:17 -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=Bqf6C0zV/hkblhPBNtiiRYUvArdis9WYmLhtbzDoEdk=; b=SxFy0gYmtlOr4eCwcJDmTPPVVlS5LFcnHuXxprsBIknoyqMVlVmzTdhYepD4aG/uM2 ASuguRwlorkeONqW53bwkWGT38L4ZgI3umTnlSoo8nV/JrPRpByu8OrIbalbrfDmJnyA lckLOQxZn08uNaZI/o0iSpQUZX7qo8XAjwJqQPCyFm12x3slUSgspC5M6327hdww5dmc vApZzZuoMmoWUklIiNa+2YltXpRjMI0bu8dMOPBWkNr742gIVBBJKq1mpB3O0sViOWvy +bZDMfa3CweetAVs47ccKFGUj4PYeJUoAskeNf7EebFqyJ2vNhR3FTFyWcKZ37IGDIQs hagw== MIME-Version: 1.0 Received: by 10.152.103.11 with SMTP id fs11mr21571115lab.23.1345649692532; Wed, 22 Aug 2012 08:34:52 -0700 (PDT) Received: by 10.112.58.2 with HTTP; Wed, 22 Aug 2012 08:34:52 -0700 (PDT) Date: Wed, 22 Aug 2012 18:34:52 +0300 Message-ID: From: Boris Astardzhiev To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: NANDFS: out of space panic 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, 22 Aug 2012 15:41:19 -0000 Hello, firstly a BIG greeting to the contributors of the NANDFS support in FreeBSD. This is a major step in embedded systems development. Now to the point - I have 2 questions. I've been playing with it recently and so far i've noticed an annoying bug. root@sheevaplug:/mnt # df -h Filesystem Size Used Avail Capacity Mounted on 10.100.100.34:/usr/sheeva-fs 7.5G 4.2G 2.7G 61% / devfs 1.0k 1.0k 0B 100% /dev /dev/gnand0s.root 255M 0B 255M 0% /mnt root@sheevaplug:/mnt # uname -a FreeBSD sheevaplug 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r239563M: Wed Aug 22 18:13:56 EEST 2012 root@freebsd9:/usr/obj/arm.arm/usr/src2/sys/SHEEVAPLUG arm As you can see I've mounted a NANDFS device (/dev/gnand0s.root) into /mnt. I can happily read and write data there until I overfill the slice. So there we go: root@sheevaplug:/mnt # dd if=/dev/urandom of=file1234 bs=1M count=255 dd: 1: No space left on device 233+0 records in 232+0 records out 243269632 bytes transferred in 412.222840 secs (590141 bytes/sec) root@sheevaplug:/mnt # Now when I attempt to delete /mnt/file1234 I get a panic: root@smartcpe:/mnt # rm file1234 panic: bmap_truncate_mapping: error 28 when truncate at level 1 KDB: enter: panic [ thread pid 606 tid 100047 ] Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! db> So how do I solve this? It is easily reproduced following this scenario every time. Up to this commit I've made the following minor changes so that Sheevaplug's nandflash can be recognized: freebsd9# svn diff Index: sys/boot/fdt/dts/sheevaplug.dts =================================================================== --- sys/boot/fdt/dts/sheevaplug.dts (revision 239563) +++ sys/boot/fdt/dts/sheevaplug.dts (working copy) @@ -87,16 +87,21 @@ reg = <0x0 0x0 0x00100000>; bank-width = <2>; device-width = <1>; - + slice@0 { reg = <0x0 0x200000>; label = "u-boot"; read-only; - }; + }; - slice@200000 { - reg = <0x200000 0x1fe00000>; - label = "root"; + slice@200000 { + reg = <0x200000 0x600000>; + label = "fbsd-boot"; + }; + + slice@800000 { + reg = <0x800000 0x10000000>; + label = "root"; }; }; }; Index: sys/arm/conf/SHEEVAPLUG =================================================================== --- sys/arm/conf/SHEEVAPLUG (revision 239563) +++ sys/arm/conf/SHEEVAPLUG (working copy) @@ -23,11 +23,11 @@ options NFS_ROOT #NFS usable as /, requires NFSCL options BOOTP options BOOTP_NFSROOT -options BOOTP_NFSV3 -options BOOTP_WIRED_TO=mge0 +#options BOOTP_NFSV3 +#options BOOTP_WIRED_TO=mge0 # Root fs on USB device -#options ROOTDEVNAME=\"ufs:/dev/da0a\" +#options ROOTDEVNAME=\"nandfs:/dev/gnand0s.root\" options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues Index: sys/dev/nand/nand_id.c =================================================================== --- sys/dev/nand/nand_id.c (revision 239563) +++ sys/dev/nand/nand_id.c (working copy) @@ -33,6 +33,8 @@ #include struct nand_params nand_ids[] = { + { { NAND_MAN_SAMSUNG, 0xdc }, "Samsung K9F4G08U0B-PCB0", + 0x200, 0x800, 0x40, 0x40, 0 }, { { NAND_MAN_SAMSUNG, 0x75 }, "Samsung K9F5608U0B", 0x20, 0x200, 0x10, 0x20, 0 }, { { NAND_MAN_SAMSUNG, 0xd3 }, "Samsung NAND 1GiB 3,3V 8-bit", freebsd9# And the second question - is there any documentation abount NANDFS's design i.e layers, models, diagrams? They would be very helpful in pinpointing bugs and reading the code as a whole. Greetings, B. Astardzhiev From owner-freebsd-fs@FreeBSD.ORG Wed Aug 22 19:28:58 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 DA7E8106564A; Wed, 22 Aug 2012 19:28:58 +0000 (UTC) (envelope-from cheeky.m@live.com) Received: from bay0-omc1-s3.bay0.hotmail.com (bay0-omc1-s3.bay0.hotmail.com [65.54.190.14]) by mx1.freebsd.org (Postfix) with ESMTP id BEBDD8FC22; Wed, 22 Aug 2012 19:28:58 +0000 (UTC) Received: from BAY170-W114 ([65.54.190.60]) by bay0-omc1-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Aug 2012 12:27:53 -0700 Message-ID: X-Originating-IP: [209.6.82.6] From: Roger Hammerstein To: Date: Wed, 22 Aug 2012 15:27:53 -0400 Importance: Normal In-Reply-To: <5034DA84.8050507@FreeBSD.org> References: , <5034DA84.8050507@FreeBSD.org> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Aug 2012 19:27:53.0654 (UTC) FILETIME=[39CC0D60:01CD809C] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: RE: panic while zfs scrubbing 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, 22 Aug 2012 19:28:59 -0000 Thank you for the reply. > Not sure what triggers this problem but it looks like zio is issued for a > block-pointer with no valid DVA. It's either a result of some logical bu= g in ZFS > code or some severe on-disk corruption. >=20 > > #7 0xffffffff816818cf in vdev_mirror_io_start (zio=3D0xfffffe0037e5e00= 0) > > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/comm= on/fs/zfs/vdev_mirror.c:89 >=20 > Could you please print *zio and *zio->io_bp in this frame? > It might also be good idea to report this issue to zfs-discuss@opensolari= s.org. /var/crash # kgdb /boot/kernel/kernel ./vmcore.10 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation=2C Inc. GDB is free software=2C covered by the GNU General Public License=2C and yo= u are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 18: integer divide fault while in kernel mode cpuid =3D 5=3B apic id =3D 05 instruction pointer =3D 0x20:0xffffffff81674a14 stack pointer =3D 0x28:0xffffff810c3d4520 frame pointer =3D 0x28:0xffffff810c3d4540 code segment =3D base 0x0=2C limit 0xfffff=2C type 0x1b =3D DPL 0=2C pres 1=2C long 1=2C def32 0=2C gran 1 processor eflags =3D interrupt enabled=2C resume=2C IOPL =3D 0 current process =3D 9480 (txg_thread_enter) trap number =3D 18 panic: integer divide fault cpuid =3D 5 KDB: stack backtrace: #0 0xffffffff80920346 at kdb_backtrace+0x66 #1 0xffffffff808ea35e at panic+0x1ce #2 0xffffffff80bd7a30 at trap_fatal+0x290 #3 0xffffffff80bd80c5 at trap+0x105 #4 0xffffffff80bc295f at calltrap+0x8 #5 0xffffffff816818cf at vdev_mirror_io_start+0x2bf #6 0xffffffff81699542 at zio_vdev_io_start+0x232 #7 0xffffffff81698fe3 at zio_execute+0xc3 #8 0xffffffff8165ea1c at dsl_scan_scrub_cb+0x3ec #9 0xffffffff8165fe14 at dsl_scan_visitbp+0x534 #10 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 #11 0xffffffff81660c84 at dsl_scan_visitdnode+0x84 #12 0xffffffff81660070 at dsl_scan_visitbp+0x790 #13 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 #14 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 #15 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 #16 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 #17 0xffffffff8165fd99 at dsl_scan_visitbp+0x4b9 Uptime: 1h51m55s Dumping 614 out of 3818 MB:..3%..11%..21%..32%..42%..53%..63%..71%..81%..92= % Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kerne= l/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bo= ot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) frame 7 #7 0xffffffff816818cf in vdev_mirror_io_start (zio=3D0xfffffe0037e5e000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/vdev_mirror.c:89 89 mm->mm_preferred =3D spa_get_random(c)=3B (kgdb) p *zio $1 =3D {io_bookmark =3D {zb_objset =3D 21=2C zb_object =3D 291417=2C zb_lev= el =3D 0=2C zb_blkid =3D 41}=2C io_prop =3D { zp_checksum =3D ZIO_CHECKSUM_INHERIT=2C zp_compress =3D ZIO_COMPRESS_IN= HERIT=2C zp_type =3D DMU_OT_NONE=2C zp_level =3D 0 '\0'=2C zp_copies =3D 0 '\0'=2C zp_dedup =3D 0 '\0'=2C z= p_dedup_verify =3D 0 '\0'}=2C io_type =3D ZIO_TYPE_READ=2C io_child_type =3D ZIO_CHILD_LOGICAL=2C io_cm= d =3D 0=2C io_priority =3D 20 '\024'=2C io_reexecute =3D 0 '\0'=2C io_state =3D "\001"=2C io_txg =3D 223=2C io_sp= a =3D 0xfffffe0008161000=2C io_bp =3D 0xfffffe0037e5e060=2C io_bp_override =3D 0x0=2C io_bp_copy =3D = {blk_dva =3D {{dva_word =3D {0=2C 0}}=2C { dva_word =3D {0=2C 0}}=2C {dva_word =3D {0=2C 0}}}=2C blk_prop =3D = 0=2C blk_pad =3D {0=2C 223}=2C blk_phys_birth =3D 223=2C blk_birth =3D 250=2C blk_fill =3D 105=2C blk_cksum =3D {zc_word =3D {63= =2C 125=2C 202=2C 251}}}=2C io_parent_list =3D { list_size =3D 48=2C list_offset =3D 16=2C list_head =3D {list_next =3D = 0xfffffe0037ea28b0=2C list_prev =3D 0xfffffe0037ea28b0}}=2C io_child_list =3D {list_size = =3D 48=2C list_offset =3D 32=2C list_head =3D { list_next =3D 0xfffffe0037e5e110=2C list_prev =3D 0xfffffe0037e5e110}= }=2C io_walk_link =3D 0x0=2C io_logical =3D 0xfffffe0037e5e000=2C io_transform_stack =3D 0x0=2C io_rea= dy =3D 0=2C io_done =3D 0xffffffff8165e130 =2C io_private =3D 0x= 0=2C io_prev_space_delta =3D 0=2C io_bp_orig =3D {blk_dva =3D {{dva_word =3D {0=2C 0}}=2C {dva_word =3D {0= =2C 0}}=2C {dva_word =3D {0=2C 0}}}=2C blk_prop =3D 0=2C blk_pad =3D {0=2C 223}=2C blk_phys_birth =3D 223=2C blk_birth =3D 250= =2C blk_fill =3D 105=2C blk_cksum =3D {zc_word =3D {63=2C 125=2C 202=2C 251}}}=2C io_data =3D 0xfffffe003704e200=2C io_orig_d= ata =3D 0xfffffe003704e200=2C io_size =3D 512=2C io_orig_size =3D 512=2C io_vd =3D 0x0=2C io_vsd =3D 0x0=2C io_vsd_ops =3D= 0x0=2C io_offset =3D 0=2C io_deadline =3D 0=2C io_offset_node =3D {avl_child =3D {0x0=2C 0x0}=2C avl_pcb =3D 0}=2C io_de= adline_node =3D {avl_child =3D {0x0=2C 0x0}=2C avl_pcb =3D 0}=2C io_vdev_tree =3D 0x0=2C io_flags =3D 2097264=2C io_st= age =3D ZIO_STAGE_VDEV_IO_START=2C io_pipeline =3D 2064386=2C io_orig_flags =3D 2097264=2C io_orig_stage =3D= ZIO_STAGE_OPEN=2C io_orig_pipeline =3D 2064386=2C io_error =3D 0=2C io_child_error =3D {0= =2C 0=2C 0=2C 0}=2C io_children =3D {{0=2C 0}=2C {0=2C 0}=2C { 0=2C 0}=2C {0=2C 0}}=2C io_child_count =3D 0=2C io_parent_count =3D 1= =2C io_stall =3D 0x0=2C io_gang_leader =3D 0x0=2C io_gang_tree =3D 0x0=2C io_executor =3D 0xfffffe0015e9d470=2C io_waiter = =3D 0x0=2C io_lock =3D {lock_object =3D { lo_name =3D 0xffffffff81725cee "zio->io_lock"=2C lo_flags =3D 4096000= 0=2C lo_data =3D 0=2C lo_witness =3D 0x0}=2C sx_lock =3D 1}=2C io_cv =3D {cv_description =3D 0xffffffff81725cfd "zio= ->io_cv)"=2C cv_waiters =3D 0}=2C io_cksum_report =3D 0x0=2C io_ena =3D 0=2C io_task =3D {ost_task =3D {ta_= link =3D {stqe_next =3D 0x0}=2C ta_pending =3D 0=2C ta_priority =3D 0=2C ta_func =3D 0=2C ta_context =3D 0x0}=2C ost_func= =3D 0=2C ost_arg =3D 0x0}} (kgdb) (kgdb) p *zio->io_bp $2 =3D {blk_dva =3D {{dva_word =3D {0=2C 0}}=2C {dva_word =3D {0=2C 0}}=2C = {dva_word =3D {0=2C 0}}}=2C blk_prop =3D 0=2C blk_pad =3D { 0=2C 223}=2C blk_phys_birth =3D 223=2C blk_birth =3D 250=2C blk_fill = =3D 105=2C blk_cksum =3D {zc_word =3D {63=2C 125=2C 202=2C 251}}} (kgdb) > > #8 0xffffffff81699542 in zio_vdev_io_start (zio=3D0xfffffe0037e5e000) > > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/comm= on/fs/zfs/zio.c:2305 > > #9 0xffffffff81698fe3 in zio_execute (zio=3D0xfffffe0037e5e000) > > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/comm= on/fs/zfs/zio.c:1196 > > #10 0xffffffff8165ea1c in dsl_scan_scrub_cb (dp=3D0xffffff810c3d4538=2C= =20 > > bp=3D0xffffff8003c53480=2C zb=3D0xffffff810c3d4970) > > at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/comm= on/fs/zfs/dsl_scan.c:1737 >=20 > And *bp and *scn here too. (kgdb) frame 10 #10 0xffffffff8165ea1c in dsl_scan_scrub_cb (dp=3D0xffffff810c3d4538=2C bp= =3D0xffffff8003c53480=2C zb=3D0xffffff810c3d4970) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:1737 1737 zio_nowait(zio_read(NULL=2C spa=2C bp=2C data=2C si= ze=2C (kgdb) p *bp $3 =3D {blk_dva =3D {{dva_word =3D {0=2C 0}}=2C {dva_word =3D {0=2C 0}}=2C = {dva_word =3D {0=2C 0}}}=2C blk_prop =3D 0=2C blk_pad =3D { 0=2C 223}=2C blk_phys_birth =3D 223=2C blk_birth =3D 250=2C blk_fill = =3D 105=2C blk_cksum =3D {zc_word =3D {63=2C 125=2C 202=2C 251}}} (kgdb) p *scn Cannot access memory at address 0x20 (kgdb) = From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 04:04:15 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5437C106564A for ; Thu, 23 Aug 2012 04:04:15 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 046448FC08 for ; Thu, 23 Aug 2012 04:04:14 +0000 (UTC) Received: by qadc11 with SMTP id c11so377034qad.13 for ; Wed, 22 Aug 2012 21:04:14 -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=GdKSYbz4QTO/0GsGVO0+1yHk4pRN87d4mKI/SxgMavw=; b=qc61s+Fbt0zvLaA2MhydSWoWN8NSv7lMuhUWrZg1/bY3DmjSi3LFckG+eq0ZqcppH4 kumDkfRFRWLHXsqStJH83r1+JBnTr0ryPBA4NLlxTiZZ6l2H4i+4jT5ynhC/erj11Ofb NS0xGV3YZLd74d43aLR50Z6m/714/1LPCNSbMovzKYSTUKKAS44Eruy0sHWi9Md1TEZX jC2IoCi4e8eQ8YPqayJCGGOy2fi30fVX2S9I42usX8x131nncWQSaU9gOlMrnd0ITU7X 2vzDSahdnk1EoDK5EpO1c9IApMA0HC0R+YStbswpAkdYeoPVQH1TSUnIDpBuFVLTm76D iLBQ== MIME-Version: 1.0 Received: by 10.224.1.72 with SMTP id 8mr743790qae.76.1345694654144; Wed, 22 Aug 2012 21:04:14 -0700 (PDT) Received: by 10.49.4.136 with HTTP; Wed, 22 Aug 2012 21:04:14 -0700 (PDT) In-Reply-To: References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> Date: Thu, 23 Aug 2012 12:04:14 +0800 Message-ID: From: Marcelo Araujo To: =?ISO-8859-1?Q?Karli_Sj=F6berg?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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: Thu, 23 Aug 2012 04:04:15 -0000 2012/8/22 Karli Sj=C3=B6berg > > 22 aug 2012 kl. 12.29 skrev Marcelo Araujo: > > > > 2012/8/15 Karli Sj=C3=B6berg > >> >> >> >> as Marcelo Araujo suggested. See how long it=C2=B4ll take before it stal= ls >> this time... >> >> > Dear Karli, > > Any new or progress with your issue? > > > Hey man, glad to hear back from you! > > Well, not much progress, I=C2=B4m afraid. The constant reboot/import-loop > didn=C2=B4t seem to yield much even after a couple of days, so I=C2=B4ve = gotten the > disks hooked up to yet another server we had and managed to spare. It=C2= =B4s > fugly to say the least, but whatever gets the job done, right:) > http://i48.tinypic.com/1z4k0uu.jpg > http://i46.tinypic.com/34pxobd.jpg > Notice the "elegant" paperclip in the SuperMicro system=C2=B4s ATX connec= tor;) > > The blade underneath is a Sun Fire X4140 from one of the two original Sun > Storage 7310 HA cluster system that served this data from a JBOD before i= t > was moved to the SuperMicro/FreeBSD system. It is equipped with even more > RAM(64GB) but import still stalls like this: > http://i49.tinypic.com/2hxvcw3.jpg > > Oddly enough, Wired RAM is only about 5-5.5GB but it hasn=C2=B4t been doi= ng > anything productive for about an hour or so... Thoughts? > > Dear, Have you tried to import the pool in readonly mode? readonly=3Don | off If set to on, pool will be imported in read-only mode with the fol= =E2=80=90 lowing restrictions: =C2=B7 Synchronous data in the intent log will not be accessib= le =C2=B7 Properties of the pool can not be changed =C2=B7 Datasets of this pool can only be mounted read-only =C2=B7 To write to a read-only pool, a export and import of th= e pool is required. Best Regards, --=20 Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 06:45:35 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 E1A7B106564A; Thu, 23 Aug 2012 06:45:35 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B573D8FC0A; Thu, 23 Aug 2012 06:45:35 +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 q7N6jZY7047505; Thu, 23 Aug 2012 06:45:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7N6jZQx047501; Thu, 23 Aug 2012 06:45:35 GMT (envelope-from linimon) Date: Thu, 23 Aug 2012 06:45:35 GMT Message-Id: <201208230645.q7N6jZQx047501@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/170912: [zfs] [patch] unnecessarily setting DS_FLAG_INCONSISTENT on async destroyed datasets X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 06:45:36 -0000 Old Synopsis: [zfs] unnecessarily setting DS_FLAG_INCONSISTENT on async destroyed datasets New Synopsis: [zfs] [patch] unnecessarily setting DS_FLAG_INCONSISTENT on async destroyed datasets Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 23 06:45:10 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=170912 From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 08:01:00 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88FCE106564A for ; Thu, 23 Aug 2012 08:01:00 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 76D9C8FC08 for ; Thu, 23 Aug 2012 08:00:59 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA04096; Thu, 23 Aug 2012 11:00:55 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1T4SLX-000OtD-6l; Thu, 23 Aug 2012 11:00:55 +0300 Message-ID: <5035E335.4010103@FreeBSD.org> Date: Thu, 23 Aug 2012 11:00:53 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Roger Hammerstein References: , <5034DA84.8050507@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: panic while zfs scrubbing 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, 23 Aug 2012 08:01:00 -0000 on 22/08/2012 22:27 Roger Hammerstein said the following: > Thank you for the reply. Could you please also provide *bp and *dnp from frame 12? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 08:06:49 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 0F0A01065688; Thu, 23 Aug 2012 08:06:49 +0000 (UTC) (envelope-from Karli.Sjoberg@slu.se) Received: from Exchange1.ad.slu.se (exchange1.ad.slu.se [193.10.100.94]) by mx1.freebsd.org (Postfix) with ESMTP id 678BA8FC0C; Thu, 23 Aug 2012 08:06:48 +0000 (UTC) Received: from exmbx3.ad.slu.se ([193.10.100.93]) by Exchange1.ad.slu.se ([193.10.100.94]) with mapi; Thu, 23 Aug 2012 10:05:36 +0200 From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= To: "araujo@FreeBSD.org" Date: Thu, 23 Aug 2012 10:05:36 +0200 Thread-Topic: Hang when importing pool Thread-Index: Ac2BBhP8QSKlc2tNTZ6FR3HHZsptdg== Message-ID: <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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, 23 Aug 2012 08:06:49 -0000 DQoyMyBhdWcgMjAxMiBrbC4gMDYuMDQgc2tyZXYgTWFyY2VsbyBBcmF1am86DQoNCg0KDQoyMDEy LzgvMjIgS2FybGkgU2rDtmJlcmcgPEthcmxpLlNqb2JlcmdAc2x1LnNlPG1haWx0bzpLYXJsaS5T am9iZXJnQHNsdS5zZT4+DQoNCjIyIGF1ZyAyMDEyIGtsLiAxMi4yOSBza3JldiBNYXJjZWxvIEFy YXVqbzoNCg0KDQoNCjIwMTIvOC8xNSBLYXJsaSBTasO2YmVyZyA8S2FybGkuU2pvYmVyZ0BzbHUu c2U8bWFpbHRvOkthcmxpLlNqb2JlcmdAc2x1LnNlPj4NCg0KDQoNCmFzIE1hcmNlbG8gQXJhdWpv IHN1Z2dlc3RlZC4gU2VlIGhvdyBsb25nIGl0wrRsbCB0YWtlIGJlZm9yZSBpdCBzdGFsbHMgdGhp cyB0aW1lLi4uDQoNCg0KRGVhciBLYXJsaSwNCg0KQW55IG5ldyBvciBwcm9ncmVzcyB3aXRoIHlv dXIgaXNzdWU/DQoNCkhleSBtYW4sIGdsYWQgdG8gaGVhciBiYWNrIGZyb20geW91IQ0KDQpXZWxs LCBub3QgbXVjaCBwcm9ncmVzcywgScK0bSBhZnJhaWQuIFRoZSBjb25zdGFudCByZWJvb3QvaW1w b3J0LWxvb3AgZGlkbsK0dCBzZWVtIHRvIHlpZWxkIG11Y2ggZXZlbiBhZnRlciBhIGNvdXBsZSBv ZiBkYXlzLCBzbyBJwrR2ZSBnb3R0ZW4gdGhlIGRpc2tzIGhvb2tlZCB1cCB0byB5ZXQgYW5vdGhl ciBzZXJ2ZXIgd2UgaGFkIGFuZCBtYW5hZ2VkIHRvIHNwYXJlLiBJdMK0cyBmdWdseSB0byBzYXkg dGhlIGxlYXN0LCBidXQgd2hhdGV2ZXIgZ2V0cyB0aGUgam9iIGRvbmUsIHJpZ2h0OikNCmh0dHA6 Ly9pNDgudGlueXBpYy5jb20vMXo0azB1dS5qcGcNCmh0dHA6Ly9pNDYudGlueXBpYy5jb20vMzRw eG9iZC5qcGcNCk5vdGljZSB0aGUgImVsZWdhbnQiIHBhcGVyY2xpcCBpbiB0aGUgU3VwZXJNaWNy byBzeXN0ZW3CtHMgQVRYIGNvbm5lY3RvcjspDQoNClRoZSBibGFkZSB1bmRlcm5lYXRoIGlzIGEg U3VuIEZpcmUgWDQxNDAgZnJvbSBvbmUgb2YgdGhlIHR3byBvcmlnaW5hbCBTdW4gU3RvcmFnZSA3 MzEwIEhBIGNsdXN0ZXIgc3lzdGVtIHRoYXQgc2VydmVkIHRoaXMgZGF0YSBmcm9tIGEgSkJPRCBi ZWZvcmUgaXQgd2FzIG1vdmVkIHRvIHRoZSBTdXBlck1pY3JvL0ZyZWVCU0Qgc3lzdGVtLiBJdCBp cyBlcXVpcHBlZCB3aXRoIGV2ZW4gbW9yZSBSQU0oNjRHQikgYnV0IGltcG9ydCBzdGlsbCBzdGFs bHMgbGlrZSB0aGlzOg0KaHR0cDovL2k0OS50aW55cGljLmNvbS8yaHh2Y3czLmpwZw0KDQpPZGRs eSBlbm91Z2gsIFdpcmVkIFJBTSBpcyBvbmx5IGFib3V0IDUtNS41R0IgYnV0IGl0IGhhc27CtHQg YmVlbiBkb2luZyBhbnl0aGluZyBwcm9kdWN0aXZlIGZvciBhYm91dCBhbiBob3VyIG9yIHNvLi4u IFRob3VnaHRzPw0KDQoNCkRlYXIsDQoNCkhhdmUgeW91IHRyaWVkIHRvIGltcG9ydCB0aGUgcG9v bCBpbiByZWFkb25seSBtb2RlPw0KICAgICByZWFkb25seT1vbiB8IG9mZg0KICAgICAgICAgSWYg c2V0IHRvIG9uLCBwb29sIHdpbGwgYmUgaW1wb3J0ZWQgaW4gcmVhZC1vbmx5IG1vZGUgd2l0aCB0 aGUgZm9s4oCQDQogICAgICAgICBsb3dpbmcgcmVzdHJpY3Rpb25zOg0KDQogICAgICAgICAgIMK3 ICAgU3luY2hyb25vdXMgZGF0YSBpbiB0aGUgaW50ZW50IGxvZyB3aWxsIG5vdCBiZSBhY2Nlc3Np YmxlDQoNCiAgICAgICAgICAgwrcgICBQcm9wZXJ0aWVzIG9mIHRoZSBwb29sIGNhbiBub3QgYmUg Y2hhbmdlZA0KDQogICAgICAgICAgIMK3ICAgRGF0YXNldHMgb2YgdGhpcyBwb29sIGNhbiBvbmx5 IGJlIG1vdW50ZWQgcmVhZC1vbmx5DQoNCiAgICAgICAgICAgwrcgICBUbyB3cml0ZSB0byBhIHJl YWQtb25seSBwb29sLCBhIGV4cG9ydCBhbmQgaW1wb3J0IG9mIHRoZSBwb29sDQogICAgICAgICAg ICAgICBpcyByZXF1aXJlZC4NCg0KVGhlIGZpcnN0IHRpbWUgSSB0cmllZCB0aGF0LCB0aGUgaW1w b3J0IHNvcnQgb2YgZmluaXNoZWQuIEkgd2FzIGFibGUgdG8gcnVuICJ6cG9vbCBzdGF0dXMiLCBi dXQgInpmcyBsaXN0IiByZXBsaWVkICJubyBkYXRhc2V0cyBhdmFpbGFibGUiIGFuZCAiemZzL3pw b29sIGdldCBhbGwiIHJlcGxpZWQgIkkvTyBjdXJyZW50bHkgc3VzcGVuZGVkIi4gU28gSSByYW4g Inpwb29sIGV4cG9ydCBwb29sMSIsIHdoaWNoIGFsc28gY29tcGxldGVkLiBCdXQgd2hlbiBJIHRy aWVkICJ6cG9vbCBpbXBvcnQgLW8gcmVhZG9ubHk9b24gcG9vbDEiIGFnYWluIGl0IGNvcmUtZHVt cGVkLg0KDQpBZnRlciByZWJvb3QgSSB0cmllZCBhZ2FpbiB3aXRoIHRoZSBzYW1lIHJlc3VsdC4g SSBoYXZlIG1hbmFnZWQgdG8gbWFrZSB0aGUgZHVtcCBhdmFpbGFibGUgZm9yIHlvdSBhdDoNCmh0 dHA6Ly93d3cuc2VuZHNwYWNlLmNvbS9maWxlL2s4bW1uOA0KDQpJIHdvdWxkIGJlIHNvIGdsYWQg aWYgeW91IGNvdWxkIGZpbmQgc29tZXRoaW5nIG9idmlvdXMgaW4gdGhlcmUsIG90aGVyd2lzZSBJ wrRtIGRvbmUgd2l0aCB0aGlzLg0KDQovS2FybGkNCg0KDQoNCkJlc3QgUmVnYXJkcywNCi0tDQpN YXJjZWxvIEFyYXVqbw0KYXJhdWpvQEZyZWVCU0Qub3JnPG1haWx0bzphcmF1am9ARnJlZUJTRC5v cmc+DQoNCg0KDQpNZWQgVsOkbmxpZ2EgSMOkbHNuaW5nYXINCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkthcmxpIFNqw7ZiZXJnDQpTd2VkaXNoIFVuaXZlcnNpdHkgb2YgQWdyaWN1bHR1cmFsIFNj aWVuY2VzDQpCb3ggNzA3OSAoVmlzaXRpbmcgQWRkcmVzcyBLcm9uw6VzdsOkZ2VuIDgpDQpTLTc1 MCAwNyBVcHBzYWxhLCBTd2VkZW4NClBob25lOiAgKzQ2LSgwKTE4LTY3IDE1IDY2DQprYXJsaS5z am9iZXJnQHNsdS5zZTxtYWlsdG86a2FybGkuc2pvYmVyZ0BhZG0uc2x1LnNlPg0KDQo= From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 08:10:34 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 32F4F106564A for ; Thu, 23 Aug 2012 08:10:34 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id CD4408FC08 for ; Thu, 23 Aug 2012 08:10:33 +0000 (UTC) Received: by qcsg15 with SMTP id g15so360876qcs.13 for ; Thu, 23 Aug 2012 01:10:33 -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=6CP8ZjAU3ItScKe7GYCSVbdx7N+PSGHOXrNR2edRjGo=; b=TgJaa6vHgvlrcqQeZRjC1SL08NB+2s6g9dq4VZA+M7wJGGAEZjNQ1DDpUGhO+pDLx0 T8Xh7BRtR0OfEIecwvMW3JVpDYwXbdgV92c+07Ng2LfyKOdvBg/FD2IumEdAzjy12fju V0C6kK6BCw5BDA8abiqFbf3hj53pnU+NQaUzTA7V6zNfDuhKvtKFBOeqhmPSNnwfYkWq Ckf0hy7u+gbZ95Bkg3iW4lrOqmCnk+Wto5aRC9f+xl86R7qnS52FRbOzdKTZsrvsHAk1 UtclvgMZly2RkFugoJIAgnxNPueWeWSE9ctQ73lHjRiUbWIkcvPOaVKpepFJ1ppmsnrW 5Tlg== MIME-Version: 1.0 Received: by 10.224.219.210 with SMTP id hv18mr1553414qab.46.1345709432995; Thu, 23 Aug 2012 01:10:32 -0700 (PDT) Received: by 10.49.4.136 with HTTP; Thu, 23 Aug 2012 01:10:32 -0700 (PDT) In-Reply-To: <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> Date: Thu, 23 Aug 2012 16:10:32 +0800 Message-ID: From: Marcelo Araujo To: =?ISO-8859-1?Q?Karli_Sj=F6berg?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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: Thu, 23 Aug 2012 08:10:34 -0000 2012/8/23 Karli Sj=F6berg > > The first time I tried that, the import sort of finished. I was able to > run "zpool status", but "zfs list" replied "no datasets available" and > "zfs/zpool get all" replied "I/O currently suspended". So I ran "zpool > export pool1", which also completed. But when I tried "zpool import -o > readonly=3Don pool1" again it core-dumped. > > After reboot I tried again with the same result. I have managed to make > the dump available for you at: > http://www.sendspace.com/file/k8mmn8 > > I would be so glad if you could find something obvious in there, otherwis= e > I=B4m done with this. > > /Karli > > Dear Karli, Shall you provide the kernel.symbols? Best Regards, --=20 Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 08:17: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 91379106564A; Thu, 23 Aug 2012 08:17:54 +0000 (UTC) (envelope-from Karli.Sjoberg@slu.se) Received: from Exchange1.ad.slu.se (exchange1.ad.slu.se [193.10.100.94]) by mx1.freebsd.org (Postfix) with ESMTP id 0E00A8FC0A; Thu, 23 Aug 2012 08:17:53 +0000 (UTC) Received: from exmbx3.ad.slu.se ([193.10.100.93]) by Exchange1.ad.slu.se ([193.10.100.94]) with mapi; Thu, 23 Aug 2012 10:17:52 +0200 From: =?iso-8859-1?Q?Karli_Sj=F6berg?= To: "araujo@FreeBSD.org" Date: Thu, 23 Aug 2012 10:17:51 +0200 Thread-Topic: Hang when importing pool Thread-Index: Ac2BB8oo8O3uGKaCTDeN7dJmdRG4YQ== Message-ID: References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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, 23 Aug 2012 08:17:54 -0000 23 aug 2012 kl. 10.10 skrev Marcelo Araujo: 2012/8/23 Karli Sj=F6berg > The first time I tried that, the import sort of finished. I was able to run= "zpool status", but "zfs list" replied "no datasets available" and "zfs/zp= ool get all" replied "I/O currently suspended". So I ran "zpool export pool= 1", which also completed. But when I tried "zpool import -o readonly=3Don p= ool1" again it core-dumped. After reboot I tried again with the same result. I have managed to make the= dump available for you at: http://www.sendspace.com/file/k8mmn8 I would be so glad if you could find something obvious in there, otherwise = I=B4m done with this. /Karli Dear Karli, Shall you provide the kernel.symbols? I csup=B4ed to 9.1-PRERELEASE(if that would make any difference) and compil= ed the kernel without symbols. I could recompile with symbols included if y= ou really need them? Best Regards, -- Marcelo Araujo araujo@FreeBSD.org Med V=E4nliga H=E4lsningar ---------------------------------------------------------------------------= ---- Karli Sj=F6berg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kron=E5sv=E4gen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 08:20:45 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 8C1391065676 for ; Thu, 23 Aug 2012 08:20:45 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 388978FC0A for ; Thu, 23 Aug 2012 08:20:45 +0000 (UTC) Received: by qadc11 with SMTP id c11so467889qad.13 for ; Thu, 23 Aug 2012 01:20:44 -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=h8q5Hu4lhPqCLB9FqS0Y2TJv1ajhLv4oL22IcL4CxYM=; b=n6y9RAUaZOreuSf8Xear7AtEi0PUgb36gDEh+xzm2cbMyEvil9hJKJdkKLj4N1Omb4 ky7db25TRxdXY+/3XOLbDbtwJ2taoIFtXj1osTbEtaN7rWWpaZU/PskSxMcvTJ/n7Ylz l+PrG2o2VdvDZcDhWMw3OFX9KE1KK/R4ofmhs4qjwhElTUlbkrEKFtO8ysrysHZx+lW+ p7U5ohFeBp1w8GhR2cIP57AvSGKNIzC7hNsXo+CKGRiZ9TL47TxH/yaGDEWHepoe0z68 Lj0gV9ng9G5qzBXO7vevDnvwwSKmjI/tGC9EgEFAJAT+jlN6qV00QWGNdL1yoJ91rlS5 gwwA== MIME-Version: 1.0 Received: by 10.229.135.82 with SMTP id m18mr281263qct.76.1345710044549; Thu, 23 Aug 2012 01:20:44 -0700 (PDT) Received: by 10.49.4.136 with HTTP; Thu, 23 Aug 2012 01:20:44 -0700 (PDT) In-Reply-To: References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> Date: Thu, 23 Aug 2012 16:20:44 +0800 Message-ID: From: Marcelo Araujo To: =?ISO-8859-1?Q?Karli_Sj=F6berg?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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: Thu, 23 Aug 2012 08:20:45 -0000 2012/8/23 Karli Sj=F6berg > > > I csup=B4ed to 9.1-PRERELEASE(if that would make any difference) and > compiled the kernel without symbols. I could recompile with symbols > included if you really need them? > > OK, let me check the vmcore tonight at home or maybe during this weekend. As I'm gonna face out two huge Typhoons this weekend, I don't have so much things to do! Best Regards, --=20 Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 08:26: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 771C9106564A; Thu, 23 Aug 2012 08:26:33 +0000 (UTC) (envelope-from Karli.Sjoberg@slu.se) Received: from Exchange1.ad.slu.se (exchange1.ad.slu.se [193.10.100.94]) by mx1.freebsd.org (Postfix) with ESMTP id E24448FC1B; Thu, 23 Aug 2012 08:26:32 +0000 (UTC) Received: from exmbx3.ad.slu.se ([193.10.100.93]) by Exchange1.ad.slu.se ([193.10.100.94]) with mapi; Thu, 23 Aug 2012 10:26:31 +0200 From: =?iso-8859-1?Q?Karli_Sj=F6berg?= To: "araujo@FreeBSD.org" Date: Thu, 23 Aug 2012 10:26:30 +0200 Thread-Topic: Hang when importing pool Thread-Index: Ac2BCP+RwBbIFzygSDqik7C6aPeY+Q== Message-ID: <3455173D-0875-4BFF-ABFF-CCEDEDD75DFE@slu.se> References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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, 23 Aug 2012 08:26:33 -0000 23 aug 2012 kl. 10.20 skrev Marcelo Araujo: 2012/8/23 Karli Sj=F6berg > I csup=B4ed to 9.1-PRERELEASE(if that would make any difference) and compil= ed the kernel without symbols. I could recompile with symbols included if y= ou really need them? OK, let me check the vmcore tonight at home or maybe during this weekend. A= s I'm gonna face out two huge Typhoons this weekend, I don't have so much t= hings to do! Wow, really, thanks! Thanks a bunch! Though it may very well be just anothe= r dead end, I want to be able to say I really have done everything possible= before being forced to throw a years worth of research(the data "trapped" = inside the pool) down the drain. Again, thanks! Best Regards, -- Marcelo Araujo araujo@FreeBSD.org Med V=E4nliga H=E4lsningar ---------------------------------------------------------------------------= ---- Karli Sj=F6berg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kron=E5sv=E4gen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 08:55: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 69903106566B for ; Thu, 23 Aug 2012 08:55:05 +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 DB6108FC0A for ; Thu, 23 Aug 2012 08:55:04 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MRDEV-1TEWaG3pyp-00UeIh; Thu, 23 Aug 2012 10:55:04 +0200 Message-ID: <5035EFE7.9030007@brockmann-consult.de> Date: Thu, 23 Aug 2012 10:55:03 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> <3455173D-0875-4BFF-ABFF-CCEDEDD75DFE@slu.se> In-Reply-To: <3455173D-0875-4BFF-ABFF-CCEDEDD75DFE@slu.se> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:fLLSMAKkPOZhXiN4LcO8qjJoHbHT22pw9/jrTmSrWye 5G8PHa3+Mz3HSLqIGNjTam/zE/8dnqEs9/sK79bnIjNPl5QYE/ 2mPBvdrqb51UV3JSQTT4ZaX+H3Ww9tEYBt7xXMvTqIh1/QbiJl IY+n3eU64UO+ivq+iLDcreHVpvRT40l+8EmUvVODVGGSGIcCSc DmNy34j4BSTMvmMzbPGKMku5uj5w4zkzzNayKUaCi86Se+4RSm p4/Fs8HsOpJD1+PXI7vulx7bXsKs5iF/7oUNvC6ShFV6g3bm33 qdgjPcMLwYhVkypAN+9B0O6KBqCFg+Exs/VmWOpVx5sZam5b6K pFxU0RH3gWtVocKphzhJ28N7oPpntkjIsHrzuEbA6 Subject: Re: Hang when importing pool 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, 23 Aug 2012 08:55:05 -0000 On 08/23/2012 10:26 AM, Karli Sjöberg wrote: > > Wow, really, thanks! Thanks a bunch! Though it may very well be just another dead end, I want to be able to say I really have done everything possible before being forced to throw a years worth of research(the data "trapped" inside the pool) down the drain. Again, thanks! > Without having any experience with zfs data recovery, I suggest you at least try, before abandoning that data, if it is very valuable. Here is a random link I found where a guy demonstrated getting a file out of raidz: http://mbruning.blogspot.de/2009/12/zfs-raidz-data-walk.html Getting a whole file system would likely be a lot of work though. And I asked before, but you didn't answer... have you tried importing it in Solaris? FreeBSD is not perfect, you know.... maybe ZFS has a few advantages on its native platform. (and I would back up with dd before doing anything that can change the data, but you've probably already missed that opportunity on your first "-f" import) From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 08:55: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 D376A1065674 for ; Thu, 23 Aug 2012 08:55:42 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 8052E8FC08 for ; Thu, 23 Aug 2012 08:55:42 +0000 (UTC) Received: by qadc11 with SMTP id c11so482835qad.13 for ; Thu, 23 Aug 2012 01:55:41 -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=LR+iZXGoHDMB1pR+gx+XN2Gq/NNfzNmKGSLTz4pdT3k=; b=zxeTcT7/i8IpmQBDAXv68uLZlKNHZGcC7Pq+Pt2fn2CLz6AlEXcSxGFnJ1Zjl7bvuq jLHRP59fpFT+NrFgi3UBqvt0mojsZAqSc2wP7eDvqnQDh5jWSSKpp+cKPWc9Da1urQP1 pFyudI74tjm7vFaNHipB8705xmB2jIt9iQZ2JUvsQqjWDwe0GY2G4kzac7vd3a50EuYY 6hZwchxXZzrby5OBPuK5Z2CSyBiM2SkjjY31g1ZYhd41o1WD6OJ0aeAZbouWRdUKFFVz 7bRiHsJSb1kAFmiQJwTTYjdMufCg8zhaHVNwuaiGxnE7Bsq/hwW25ogd0McQdx+yeSLz xz2g== MIME-Version: 1.0 Received: by 10.224.214.138 with SMTP id ha10mr1655031qab.51.1345712141874; Thu, 23 Aug 2012 01:55:41 -0700 (PDT) Received: by 10.49.4.136 with HTTP; Thu, 23 Aug 2012 01:55:41 -0700 (PDT) In-Reply-To: <3455173D-0875-4BFF-ABFF-CCEDEDD75DFE@slu.se> References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> <3455173D-0875-4BFF-ABFF-CCEDEDD75DFE@slu.se> Date: Thu, 23 Aug 2012 16:55:41 +0800 Message-ID: From: Marcelo Araujo To: =?ISO-8859-1?Q?Karli_Sj=F6berg?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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: Thu, 23 Aug 2012 08:55:42 -0000 2012/8/23 Karli Sj=F6berg > > 23 aug 2012 kl. 10.20 skrev Marcelo Araujo: > > > > 2012/8/23 Karli Sj=F6berg > >> >> >> I csup=B4ed to 9.1-PRERELEASE(if that would make any difference) and >> compiled the kernel without symbols. I could recompile with symbols >> included if you really need them? >> >> > OK, let me check the vmcore tonight at home or maybe during this weekend. > As I'm gonna face out two huge Typhoons this weekend, I don't have so muc= h > things to do! > > > Wow, really, thanks! Thanks a bunch! Though it may very well be just > another dead end, I want to be able to say I really have done everything > possible before being forced to throw a years worth of research(the data > "trapped" inside the pool) down the drain. Again, thanks! > > > Best Regards, > -- > Marcelo Araujo > araujo@FreeBSD.org > > > > Dear Karli, To work on your vmcore.0 I need your kernel.debug. # cd /usr/obj/usr/src/sys/*KERNCONF*# ls kernel.debug Maybe you have it. If yes, please send me. Best Regards, --=20 Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 09:47:24 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 9C3DD1065670 for ; Thu, 23 Aug 2012 09:47:24 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by mx1.freebsd.org (Postfix) with ESMTP id 57FA68FC18 for ; Thu, 23 Aug 2012 09:47:24 +0000 (UTC) Received: from [78.35.158.19] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1T4Tpt-00068B-6Z for freebsd-fs@freebsd.org; Thu, 23 Aug 2012 11:36:21 +0200 Date: Thu, 23 Aug 2012 11:31:15 +0200 From: Fabian Keil To: freebsd-fs@freebsd.org Message-ID: <20120823113115.298aca04@fabiankeil.de> In-Reply-To: <201208221728.04712.Mark.Martinec+freebsd@ijs.si> References: <20120821190742.54449@relay.ibs.dn.ua> <20120822123535.0385f118@fabiankeil.de> <20120822132905.GA53612@wonko.batmule.dk> <201208221728.04712.Mark.Martinec+freebsd@ijs.si> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/L1r0EPUC5yk2msGK7lFwwLx"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Subject: Re: `zpool create' fails on geli ... 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, 23 Aug 2012 09:47:24 -0000 --Sig_/L1r0EPUC5yk2msGK7lFwwLx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Mark Martinec wrote: > > Fabian Keil wrote: > > > Zeus Panchenko wrote: > > > > geli init -K /path/key -s 4096 -e aes-xts /dev/adaX > > >=20 > > > Does your disk actually use 4k sectors? Otherwise it's not clear > > > to me that "-s 4096" makes sense when using ZFS. > > >=20 > > > I'm not claiming that it's obviously wrong, but I'm not aware of > > > any benchmarks that show that it's better than the default in > > > any way. I probably should have clarified that I don't deny that workloads exist where using 4k sectors indeed improves the performance even if the disk is using smaller sectors. > It benefits geli performance (tried it, it does): You probably didn't test with random read or write operations of less than 4k, for which a smaller sector size should result in better performance. > $ man geli > -s sectorsize Change decrypted provider's sector size. > Increasing sector size allows to increase per- > formance, because we need to generate an IV > and do encrypt/decrypt for every single sector > - less number of sectors means less work to Provided you actually need the content of the whole sector ... And if you always do, why not increase the sector size even further? If -s 4096 would provide the best results for all work loads it probably would be the default already. > > It is my understanding that creating a 4K setup will prepare you > > for the day when your replacement drive is a 4K one. That's true and I didn't consider this (I don't usually replace drives in single-drive pools). > > No benefit today, but also no real performance hit. And we avoid > > a real performance hit later. =20 As I said previously, I'm not aware of any benchmarks that show how much impact the geli sector size has on the ZFS performance. Fabian --Sig_/L1r0EPUC5yk2msGK7lFwwLx Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA1+GcACgkQBYqIVf93VJ2H4gCbBZzL+s0Ez5Bm/zXdZADPxaPl DBMAn1Zv9jqpaGq3GIGFBZJopufKJ6jM =5LU6 -----END PGP SIGNATURE----- --Sig_/L1r0EPUC5yk2msGK7lFwwLx-- From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 09:57:21 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 D17331065670; Thu, 23 Aug 2012 09:57:21 +0000 (UTC) (envelope-from Karli.Sjoberg@slu.se) Received: from Exchange2.ad.slu.se (exchange2.ad.slu.se [193.10.100.95]) by mx1.freebsd.org (Postfix) with ESMTP id 359CE8FC08; Thu, 23 Aug 2012 09:57:21 +0000 (UTC) Received: from exmbx3.ad.slu.se ([193.10.100.93]) by Exchange2.ad.slu.se ([193.10.100.95]) with mapi; Thu, 23 Aug 2012 11:57:19 +0200 From: =?iso-8859-1?Q?Karli_Sj=F6berg?= To: "araujo@FreeBSD.org" Date: Thu, 23 Aug 2012 11:57:18 +0200 Thread-Topic: Hang when importing pool Thread-Index: Ac2BFa7gneLki2ApQv21BbwADLo1FQ== Message-ID: <17488FBA-B8E9-4945-A5FF-DF3E657E6600@slu.se> References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> <3455173D-0875-4BFF-ABFF-CCEDEDD75DFE@slu.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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, 23 Aug 2012 09:57:21 -0000 23 aug 2012 kl. 10.55 skrev Marcelo Araujo: 2012/8/23 Karli Sj=F6berg > 23 aug 2012 kl. 10.20 skrev Marcelo Araujo: 2012/8/23 Karli Sj=F6berg > I csup=B4ed to 9.1-PRERELEASE(if that would make any difference) and compil= ed the kernel without symbols. I could recompile with symbols included if y= ou really need them? OK, let me check the vmcore tonight at home or maybe during this weekend. A= s I'm gonna face out two huge Typhoons this weekend, I don't have so much t= hings to do! Wow, really, thanks! Thanks a bunch! Though it may very well be just anothe= r dead end, I want to be able to say I really have done everything possible= before being forced to throw a years worth of research(the data "trapped" = inside the pool) down the drain. Again, thanks! Best Regards, -- Marcelo Araujo araujo@FreeBSD.org Dear Karli, To work on your vmcore.0 I need your kernel.debug. # cd /usr/obj/usr/src/sys/KERNCONF # ls kernel.debug Maybe you have it. If yes, please send me. As I chose to compile the kernel without debugging, I didn=B4t have that. S= o I compiled a new kernel from the same sources with debugging included and= uploaded that file for you: http://www.sendspace.com/file/updu8x Best Regards, -- Marcelo Araujo araujo@FreeBSD.org Med V=E4nliga H=E4lsningar ---------------------------------------------------------------------------= ---- Karli Sj=F6berg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kron=E5sv=E4gen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 10:45:49 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 50638106564A for ; Thu, 23 Aug 2012 10:45:49 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED84C8FC0C for ; Thu, 23 Aug 2012 10:45:48 +0000 (UTC) Received: by qcsg15 with SMTP id g15so450048qcs.13 for ; Thu, 23 Aug 2012 03:45:48 -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=zGdUb02Pc3f8/STSDx8O8HXRNYlLKH9lm0uC353DKvI=; b=UJ4FPvUZpz5jxm9LPacsLyZ7krwBXJHgY6pVuIP2AoLhuiSKUbJAUEriBg/99RYFHD 671qfhedOSAq+sT9nFyKjz+hFyE0ZyjU1pfpzk+F7YgsW6EZ9Fez32PJ3yPMumdkaaKh +q5ZjaqiH/3uB9XgQLbSwMr0d7SbgGMcwqWo8ti+RLDCCmlFie6YlbWHxophNrFWEtXd zESdgyWtVGStubZpV6d83CIw1G0F8zu+/4CpbtoMx6bNbApGLoXBHXIYYpP7R2MYBU8s kqJbdwu2M0rWVb16TbDy5q8K6v+KdVoxKrijtVjOv4hRDz4CNrOR8RXxThNEvNEn2I0l 2rcQ== MIME-Version: 1.0 Received: by 10.229.134.194 with SMTP id k2mr425819qct.141.1345718747909; Thu, 23 Aug 2012 03:45:47 -0700 (PDT) Received: by 10.49.4.136 with HTTP; Thu, 23 Aug 2012 03:45:47 -0700 (PDT) In-Reply-To: <17488FBA-B8E9-4945-A5FF-DF3E657E6600@slu.se> References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> <3455173D-0875-4BFF-ABFF-CCEDEDD75DFE@slu.se> <17488FBA-B8E9-4945-A5FF-DF3E657E6600@slu.se> Date: Thu, 23 Aug 2012 18:45:47 +0800 Message-ID: From: Marcelo Araujo To: =?ISO-8859-1?Q?Karli_Sj=F6berg?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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: Thu, 23 Aug 2012 10:45:49 -0000 2012/8/23 Karli Sj=F6berg > > As I chose to compile the kernel without debugging, I didn=B4t have that.= So > I compiled a new kernel from the same sources with debugging included and > uploaded that file for you: > http://www.sendspace.com/file/updu8x > > > Dear Karli, Before import the pool; did you try to disable the checksum? Best Regards, --=20 Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 10:48:16 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 EF6E0106566C; Thu, 23 Aug 2012 10:48:16 +0000 (UTC) (envelope-from Karli.Sjoberg@slu.se) Received: from Exchange2.ad.slu.se (exchange2.ad.slu.se [193.10.100.95]) by mx1.freebsd.org (Postfix) with ESMTP id 64A438FC08; Thu, 23 Aug 2012 10:48:16 +0000 (UTC) Received: from exmbx3.ad.slu.se ([193.10.100.93]) by Exchange2.ad.slu.se ([193.10.100.95]) with mapi; Thu, 23 Aug 2012 12:48:08 +0200 From: =?iso-8859-1?Q?Karli_Sj=F6berg?= To: "araujo@FreeBSD.org" Date: Thu, 23 Aug 2012 12:48:07 +0200 Thread-Topic: Hang when importing pool Thread-Index: Ac2BHMiMbtTpGhYMQL+xnx8M7K5n0w== Message-ID: <6887B735-D207-4379-9967-76F21B04943A@slu.se> References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> <3455173D-0875-4BFF-ABFF-CCEDEDD75DFE@slu.se> <17488FBA-B8E9-4945-A5FF-DF3E657E6600@slu.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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, 23 Aug 2012 10:48:17 -0000 23 aug 2012 kl. 12.45 skrev Marcelo Araujo: 2012/8/23 Karli Sj=F6berg > As I chose to compile the kernel without debugging, I didn=B4t have that. S= o I compiled a new kernel from the same sources with debugging included and= uploaded that file for you: http://www.sendspace.com/file/updu8x Dear Karli, Before import the pool; did you try to disable the checksum? No I didn=B4t. Can you do that during import? Like: # zpool import -o checksum=3Doff -o readonly=3Don poolname Best Regards, -- Marcelo Araujo araujo@FreeBSD.org Med V=E4nliga H=E4lsningar ---------------------------------------------------------------------------= ---- Karli Sj=F6berg Swedish University of Agricultural Sciences Box 7079 (Visiting Address Kron=E5sv=E4gen 8) S-750 07 Uppsala, Sweden Phone: +46-(0)18-67 15 66 karli.sjoberg@slu.se From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 11:15:01 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 9DB0E106564A for ; Thu, 23 Aug 2012 11:15:01 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3BDBB8FC0A for ; Thu, 23 Aug 2012 11:15:00 +0000 (UTC) Received: by qcsg15 with SMTP id g15so469493qcs.13 for ; Thu, 23 Aug 2012 04:15:00 -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=paNRFex8JpEX+RoEVwjtPtJ3DhC28pzTXSTYzG1nlAc=; b=C3+K1OLvs50t3An5mM6SMwKtkKAzzPqiGjdBLSekvftsEZXT+XfJsxcYNR9PDtQVvT czy0wzc2NRw1QP/ASJAWihE7B4b24PeYHLPBuabKlHIaFXc/7DZQOfYMJsO67cyo5V8k j/wfG2v/0wfb98VSH/0/EOgwnPQV6kyJdPNFjx/K+P3j2vWFbbhAp7USwlQxo4s1Q0Qs JHcmuIzEkMeHo5aCse+oZaJpGZUoqJrV5Hy9A2oeNj+WfL4ytV808cYpHi5nMp3wcWIz AY+L+0NN+Gi5AzOv0Tm7PKEGj7FO5I98PfTKdv/kVYToe2UZF2e7GDDzbe8D3po5BZzv 9Ypg== MIME-Version: 1.0 Received: by 10.224.214.138 with SMTP id ha10mr2151441qab.51.1345720500447; Thu, 23 Aug 2012 04:15:00 -0700 (PDT) Received: by 10.49.4.136 with HTTP; Thu, 23 Aug 2012 04:15:00 -0700 (PDT) In-Reply-To: <6887B735-D207-4379-9967-76F21B04943A@slu.se> References: <49C9D08A-85EF-4D23-B07F-F3980CBA5A97@slu.se> <20120815073135.GO6757@squishy.elizium.za.net> <02807469-A09D-4692-8530-CCAE31ED0534@slu.se> <3455173D-0875-4BFF-ABFF-CCEDEDD75DFE@slu.se> <17488FBA-B8E9-4945-A5FF-DF3E657E6600@slu.se> <6887B735-D207-4379-9967-76F21B04943A@slu.se> Date: Thu, 23 Aug 2012 19:15:00 +0800 Message-ID: From: Marcelo Araujo To: =?ISO-8859-1?Q?Karli_Sj=F6berg?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Hang when importing pool 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: Thu, 23 Aug 2012 11:15:01 -0000 2012/8/23 Karli Sj=F6berg > > 23 aug 2012 kl. 12.45 skrev Marcelo Araujo: > > > > 2012/8/23 Karli Sj=F6berg > >> >> As I chose to compile the kernel without debugging, I didn=B4t have that= . >> So I compiled a new kernel from the same sources with debugging included >> and uploaded that file for you: >> http://www.sendspace.com/file/updu8x >> >> >> > Dear Karli, > > Before import the pool; did you try to disable the checksum? > > > No I didn=B4t. Can you do that during import? Like: > # zpool import -o checksum=3Doff -o readonly=3Don poolname > > No, there is no option on zpool import. But, maybe there is a way to disable it on zio_checksum.c Look here: http://mail.opensolaris.org/pipermail/zfs-discuss/2007-April/009898.html However, it is just my guess, I need check more your vmcore to maybe try to figure out. Best Regards, --=20 Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 12:10:12 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 6D583106566C; Thu, 23 Aug 2012 12:10:12 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 410DE8FC15; Thu, 23 Aug 2012 12:10:12 +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 q7NCACe9099333; Thu, 23 Aug 2012 12:10:12 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7NCACPr099329; Thu, 23 Aug 2012 12:10:12 GMT (envelope-from linimon) Date: Thu, 23 Aug 2012 12:10:12 GMT Message-Id: <201208231210.q7NCACPr099329@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/170914: [zfs] [patch] Import patchs related with issues 3090 and 3102. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 12:10:12 -0000 Synopsis: [zfs] [patch] Import patchs related with issues 3090 and 3102. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 23 12:10:00 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=170914 From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 13:17: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 AC1FB1065673; Thu, 23 Aug 2012 13:17:42 +0000 (UTC) (envelope-from cheeky.m@live.com) Received: from bay0-omc1-s22.bay0.hotmail.com (bay0-omc1-s22.bay0.hotmail.com [65.54.190.33]) by mx1.freebsd.org (Postfix) with ESMTP id 92B698FC15; Thu, 23 Aug 2012 13:17:42 +0000 (UTC) Received: from BAY170-W83 ([65.54.190.60]) by bay0-omc1-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Aug 2012 06:17:36 -0700 Message-ID: X-Originating-IP: [209.6.82.6] From: Roger Hammerstein To: Date: Thu, 23 Aug 2012 09:17:36 -0400 Importance: Normal In-Reply-To: <5035E335.4010103@FreeBSD.org> References: , <5034DA84.8050507@FreeBSD.org> , <5035E335.4010103@FreeBSD.org> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Aug 2012 13:17:36.0757 (UTC) FILETIME=[A9E85A50:01CD8131] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: RE: panic while zfs scrubbing 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, 23 Aug 2012 13:17:42 -0000 > Date: Thu=2C 23 Aug 2012 11:00:53 +0300 > From: avg@FreeBSD.org > To: cheeky.m@live.com > CC: freebsd-fs@FreeBSD.org > Subject: Re: panic while zfs scrubbing >=20 > on 22/08/2012 22:27 Roger Hammerstein said the following: > > Thank you for the reply. >=20 > Could you please also provide *bp and *dnp from frame 12? (kgdb) frame 12 #12 0xffffffff8165fd99 in dsl_scan_visitbp (bp=3D0xffffff8003642240=2C zb= =3D0xffffff810c3d4a00=2C dnp=3D0xffffff8003642200=2C pbuf=3DVariable "pbuf" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/f= s/zfs/dsl_scan.c:684 684 dsl_scan_visitbp(cbp=2C &czb=2C dnp=2C (kgdb) p *bp $1 =3D {blk_dva =3D {{dva_word =3D {12=2C 2664649997}}=2C {dva_word =3D {12= =2C 274203007}}=2C {dva_word =3D {0=2C 0}}}=2C blk_prop =3D 9300785364916895775=2C blk_pad =3D {0=2C 0}=2C blk_phys_birt= h =3D 0=2C blk_birth =3D 39369=2C blk_fill =3D 6846=2C blk_cksum =3D {zc_word =3D {1203808533638=2C 5961469= 23432012=2C 187461291446205926=2C 6622496048374175611}}} (kgdb) p *dnp $2 =3D {dn_type =3D 19 '\023'=2C dn_indblkshift =3D 14 '\016'=2C dn_nlevels= =3D 2 '\002'=2C dn_nblkptr =3D 1 '\001'=2C dn_bonustype =3D 44 '=2C'=2C dn_checksum =3D 0 '\0'=2C dn_compress =3D 0 = '\0'=2C dn_flags =3D 3 '\003'=2C dn_datablkszsec =3D 256=2C dn_bonuslen =3D 168=2C dn_pad2 =3D "\000\000\0= 00"=2C dn_maxblkid =3D 21=2C dn_used =3D 2891616=2C dn_pad3 =3D {0=2C 0=2C 0=2C 0}=2C dn_blkptr =3D {{= blk_dva =3D {{dva_word =3D {12=2C 2664649997}}=2C { dva_word =3D {12=2C 274203007}}=2C {dva_word =3D {0=2C 0}}}=2C bl= k_prop =3D 9300785364916895775=2C blk_pad =3D { 0=2C 0}=2C blk_phys_birth =3D 0=2C blk_birth =3D 39369=2C blk_fill = =3D 6846=2C blk_cksum =3D {zc_word =3D { 1203808533638=2C 596146923432012=2C 187461291446205926=2C 6622496= 048374175611}}}}=2C dn_bonus =3D "ZP/\000\002\004\030\000\200\201\000\000\000\000\000\000\000= \000=2C\000\000\000\000\000=C9\231"=2C '\0' =2C "=F7\001\= 000\000\000\000\000\000=FAq\000\000\000\000\000\000\004\000\000\000\b\004\0= 00\000=A4=FB\rP\000\000\000\000=E7\222C5\000\000\000\000=A8=FB\rP\000\000\0= 00\000=DBU#0\000\000\000\000=A8=FB\rP\000\000\000\000=DBU#0\000\000\000\000= =A4=FB\rP\000\000\000\000=E7\222C5\000\000\000\000\001\000\000\000\000\000\= 000\000\003\000\000\000\000\000\000\000\000\000\000\020\237\001\036\000\000= \000@ \210\000\022\000\000\000\000@\210\000\022"=2C '\0' = =2C dn_spill =3D {blk_dva =3D {{dva_word =3D {0=2C 0}}=2C {dva_word =3D {0= =2C 0}}=2C { dva_word =3D {0=2C 0}}}=2C blk_prop =3D 0=2C blk_pad =3D {0=2C 0}= =2C blk_phys_birth =3D 0=2C blk_birth =3D 0=2C blk_fill =3D 0=2C blk_cksum =3D {zc_word =3D {0=2C 0=2C 0=2C 0}}}} (kgdb) = From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 14:33:04 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 160BA1065686 for ; Thu, 23 Aug 2012 14:33:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4A45B8FC2B for ; Thu, 23 Aug 2012 14:33:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA06682; Thu, 23 Aug 2012 17:32:53 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <50363F14.5080703@FreeBSD.org> Date: Thu, 23 Aug 2012 17:32:52 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120730 Thunderbird/14.0 MIME-Version: 1.0 To: Roger Hammerstein References: , <5034DA84.8050507@FreeBSD.org> , <5035E335.4010103@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@FreeBSD.org Subject: Re: panic while zfs scrubbing 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, 23 Aug 2012 14:33:04 -0000 on 23/08/2012 16:17 Roger Hammerstein said the following: > > >> Date: Thu, 23 Aug 2012 11:00:53 +0300 >> From: avg@FreeBSD.org >> To: cheeky.m@live.com >> CC: freebsd-fs@FreeBSD.org >> Subject: Re: panic while zfs scrubbing >> >> on 22/08/2012 22:27 Roger Hammerstein said the following: >> > Thank you for the reply. >> >> Could you please also provide *bp and *dnp from frame 12? > > > > (kgdb) frame 12 > #12 0xffffffff8165fd99 in dsl_scan_visitbp (bp=0xffffff8003642240, > zb=0xffffff810c3d4a00, > dnp=0xffffff8003642200, pbuf=Variable "pbuf" is not available. > ) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c:684 > 684 dsl_scan_visitbp(cbp, &czb, dnp, > (kgdb) p *bp > $1 = {blk_dva = {{dva_word = {12, 2664649997}}, {dva_word = {12, 274203007}}, > {dva_word = {0, 0}}}, > blk_prop = 9300785364916895775, blk_pad = {0, 0}, blk_phys_birth = 0, blk_birth > = 39369, > blk_fill = 6846, blk_cksum = {zc_word = {1203808533638, 596146923432012, > 187461291446205926, > 6622496048374175611}}} > (kgdb) p *dnp > $2 = {dn_type = 19 '\023', dn_indblkshift = 14 '\016', dn_nlevels = 2 '\002', > dn_nblkptr = 1 '\001', > dn_bonustype = 44 ',', dn_checksum = 0 '\0', dn_compress = 0 '\0', dn_flags = 3 > '\003', > dn_datablkszsec = 256, dn_bonuslen = 168, dn_pad2 = "\000\000\000", dn_maxblkid > = 21, > dn_used = 2891616, dn_pad3 = {0, 0, 0, 0}, dn_blkptr = {{blk_dva = {{dva_word = > {12, 2664649997}}, { > dva_word = {12, 274203007}}, {dva_word = {0, 0}}}, blk_prop = > 9300785364916895775, blk_pad = { > 0, 0}, blk_phys_birth = 0, blk_birth = 39369, blk_fill = 6846, blk_cksum = > {zc_word = { > 1203808533638, 596146923432012, 187461291446205926, 6622496048374175611}}}}, > dn_bonus = > "ZP/\000\002\004\030\000\200\201\000\000\000\000\000\000\000\000,\000\000\000\000\000É\231", > '\0' , > "÷\001\000\000\000\000\000\000úq\000\000\000\000\000\000\004\000\000\000\b\004\000\000¤û\rP\000\000\000\000ç\222C5\000\000\000\000¨û\rP\000\000\000\000ÛU#0\000\000\000\000¨û\rP\000\000\000\000ÛU#0\000\000\000\000¤û\rP\000\000\000\000ç\222C5\000\000\000\000\001\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\000\000\000\020\237\001\036\000\000\000@ > \210\000\022\000\000\000\000@\210\000\022", '\0' , dn_spill = > {blk_dva = {{dva_word = {0, 0}}, {dva_word = {0, 0}}, { > dva_word = {0, 0}}}, blk_prop = 0, blk_pad = {0, 0}, blk_phys_birth = 0, > blk_birth = 0, > blk_fill = 0, blk_cksum = {zc_word = {0, 0, 0, 0}}}} > (kgdb) > Could you please try the following commands: zdb -R zzzz c:9ED3550D:E00:di zdb -R zzzz c:1058017F:E00:di ? Their output would probably be large, so you could upload it somewhere and post links. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 15:45: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 3830E106567F; Thu, 23 Aug 2012 15:45:22 +0000 (UTC) (envelope-from cheeky.m@live.com) Received: from bay0-omc1-s7.bay0.hotmail.com (bay0-omc1-s7.bay0.hotmail.com [65.54.190.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6578FC27; Thu, 23 Aug 2012 15:45:21 +0000 (UTC) Received: from BAY170-W15 ([65.54.190.60]) by bay0-omc1-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Aug 2012 08:44:16 -0700 Message-ID: X-Originating-IP: [209.6.82.6] From: Roger Hammerstein To: Date: Thu, 23 Aug 2012 11:44:16 -0400 Importance: Normal In-Reply-To: <50363F14.5080703@FreeBSD.org> References: , <5034DA84.8050507@FreeBSD.org> , <5035E335.4010103@FreeBSD.org> , <50363F14.5080703@FreeBSD.org> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Aug 2012 15:44:16.0257 (UTC) FILETIME=[26D17F10:01CD8146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: RE: panic while zfs scrubbing 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, 23 Aug 2012 15:45:22 -0000 > Could you please try the following commands: > zdb -R zzzz c:9ED3550D:E00:di > zdb -R zzzz c:1058017F:E00:di > ? >=20 > Their output would probably be large=2C so you could upload it somewhere = and post links. zdb -R zzzz c:9ED3550D:E00:di Invalid block specifier: c:9ED3550D:E00:di - offset must be a multiple of = sector size zdb -R zzzz c:1058017F:E00:di Invalid block specifier: c:1058017F:E00:di - offset must be a multiple of = sector size sorry=2C the man page isn't immediately helpful for me to guess at alternat= ives to -R = From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 15:50:17 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 19EA81065689 for ; Thu, 23 Aug 2012 15:50:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5AEAD8FC0C for ; Thu, 23 Aug 2012 15:50:16 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA07142; Thu, 23 Aug 2012 18:50:13 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <50365134.9080702@FreeBSD.org> Date: Thu, 23 Aug 2012 18:50:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120730 Thunderbird/14.0 MIME-Version: 1.0 To: Roger Hammerstein References: , <5034DA84.8050507@FreeBSD.org> , <5035E335.4010103@FreeBSD.org> , <50363F14.5080703@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: panic while zfs scrubbing 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, 23 Aug 2012 15:50:17 -0000 on 23/08/2012 18:44 Roger Hammerstein said the following: > >> Could you please try the following commands: >> zdb -R zzzz c:9ED3550D:E00:di >> zdb -R zzzz c:1058017F:E00:di >> ? >> >> Their output would probably be large, so you could upload it somewhere and post > links. > > > zdb -R zzzz c:9ED3550D:E00:di > Invalid block specifier: c:9ED3550D:E00:di - offset must be a multiple of sector size > > zdb -R zzzz c:1058017F:E00:di > Invalid block specifier: c:1058017F:E00:di - offset must be a multiple of sector size > > > sorry, the man page isn't immediately helpful for me to guess at alternatives to -R > Sorry, it's my mistake (forgot to convert blocks to bytes), the commands should be: zdb -R zzzz c:13DA6AA1A00:E00:di zdb -R zzzz c:20B002FE00:E00:di -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 16:05:25 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F4441065672; Thu, 23 Aug 2012 16:05:25 +0000 (UTC) (envelope-from cheeky.m@live.com) Received: from bay0-omc1-s25.bay0.hotmail.com (bay0-omc1-s25.bay0.hotmail.com [65.54.190.36]) by mx1.freebsd.org (Postfix) with ESMTP id 64CD78FC1E; Thu, 23 Aug 2012 16:05:25 +0000 (UTC) Received: from BAY170-W31 ([65.54.190.59]) by bay0-omc1-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Aug 2012 09:04:19 -0700 Message-ID: X-Originating-IP: [209.6.82.6] From: Roger Hammerstein To: Date: Thu, 23 Aug 2012 12:04:19 -0400 Importance: Normal In-Reply-To: <50365134.9080702@FreeBSD.org> References: , <5034DA84.8050507@FreeBSD.org> , <5035E335.4010103@FreeBSD.org> , <50363F14.5080703@FreeBSD.org> , <50365134.9080702@FreeBSD.org> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Aug 2012 16:04:19.0928 (UTC) FILETIME=[F4431D80:01CD8148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: RE: panic while zfs scrubbing 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, 23 Aug 2012 16:05:25 -0000 > Sorry=2C it's my mistake (forgot to convert blocks to bytes)=2C the comma= nds should be: > zdb -R zzzz c:13DA6AA1A00:E00:di > zdb -R zzzz c:20B002FE00:E00:di Thank you again. The 'c' appears to need to be 0 instead. zdb -R zzzz c:13DA6AA1A00:E00:di ***Invalid vdev: c zdb -R zzzz c:20B002FE00:E00:di ***Invalid vdev: c zdb -R zzzz 0:13DA6AA1A00:E00:di Found vdev type: raidz DVA[0]=3D<0:13da66bf800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3bc6f8b3a783:e4c3f7910006453:f26edf447f3b65fd:ec164c8453db20f2 DVA[0]=3D<0:13da66ec800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3f3d89bdc360:fd3b6a3a84a9686:25530314e1c3ecf6:447296ce0a6bc390 DVA[0]=3D<0:13da6719800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3daf62956c37:f7c7779a64b3fe2:3c0fd22767803d2b:aeb8314f905480a0 DVA[0]=3D<0:13da6746800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3dfebf3b9644:f7eae0c61d47155:376e5d62160f2531:fdf29a4ee0c41e32 DVA[0]=3D<0:13da6773800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e5e28364ae6:fb23072309c6c59:2711907b06e88f31:4aa48294b74d6ccd DVA[0]=3D<0:13da67a0800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e9b29bca68c:f9dd6067e0f95d3:dd696cbffca81b1a:6098a15c75a0315d DVA[0]=3D<0:13da67cd800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3decbddda649:f8aae580123fdbe:171399455a8b0008:3fcceeb24066e6ad DVA[0]=3D<0:13da67fa800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e0d8515e875:f8faa63e65af6bb:e44c791f815a020d:d30f9e31e0d42500 DVA[0]=3D<0:13da6827800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3d53ec0fd189:f63b1b726c93f84:192005690aad8dcc:d21c3c58becfff5a DVA[0]=3D<0:13da6881800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3d2c66cd01db:f62054bdfb3ad7e:a4d1f4f15a447958:2fa527a26245710 DVA[0]=3D<0:13da6854800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3d46c2995089:f603cbc5054195d:56a0e0d3127721f1:2f92657062f2cf48 DVA[0]=3D<0:13da68ae800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3d84b82590c4:f58066885037416:842386b78e7800e0:8ff06ca050d5dae0 DVA[0]=3D<0:13da68db800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3d84f14b3e1b:f6fd346e3171b17:c25c9c0d06fcf67e:8f200e3e263c6182 DVA[0]=3D<0:13da6908800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3df04b1abbe2:f7a5216fa52c021:f9058ca1183a0732:d4395b382b587cf1 DVA[0]=3D<0:13da6935800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e6412a7c73b:fa866da21718b43:b99912eed7765f1b:d888d66cd20b5162 DVA[0]=3D<0:13da698f800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e7a75ac74ce:fa2bc60a81ba298:f17af9c8f315c442:d3958c89a4d644c6 DVA[0]=3D<0:13da6962800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e98d90b2567:fb2906fd2fd9419:d5e888314a785d1b:cfdb90ff8ad2c089 DVA[0]=3D<0:13da69bc800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3deb463107df:f7e4d4726d70351:1a7523278bac1eea:cb4b664047c7c610 DVA[0]=3D<0:13da69eb000:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e3edb83cbed:f9065c7d57997b9:ffad12f8540fbd1:b9aad67cd683bcfa DVA[0]=3D<0:13da6a1aa00:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3dc1cdc6c558:f692824525413b6:a114b8077d1ca593:170c6d4e7e2df07f DVA[0]=3D<0:13da6a47a00:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3df551808443:f842dcdc8a32e57:af4094c9cac4733c:c7ac3865df0c4ced DVA[0]=3D<0:13da6a74a00:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e69cad45d5c:f8bc987d5aabad0:e5f72ba62f3b2955:84a2a388440c0d31 DVA[0]=3D<0:ac00:1c400> DVA[1]=3D<0:1ee00:1ea00> DVA[2]=3D<0:1ee00:11400> [= L0 unallocated] inherit inherit BE contiguous unique triple size=3D1c000L/2= 00P birth=3D12L/71P fill=3D93 cksum=3D9a:97:8f:b DVA[0]=3D<0:1fe00:15400> DVA[1]=3D<0:17200:b800> DVA[2]=3D<0:1be00:1dc00> [= L0 unallocated] inherit inherit BE contiguous unique triple size=3Df600L/20= 0P birth=3D235L/214P fill=3D223 cksum=3D3e:4e:b7:dd DVA[0]=3D<0:be00:9e00> DVA[1]=3D<0:17c00:13800> DVA[2]=3D<0:ee00:bc00> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D10000L/200P= birth=3D45L/255P fill=3D110 cksum=3D95:d3:4f:5f DVA[0]=3D<0:19800:1e00> DVA[1]=3D<0:1bc00:1fa00> DVA[2]=3D<0:ee00:17600> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D17600L/20= 0P birth=3D244L/134P fill=3D238 cksum=3D75:85:9e:ed DVA[0]=3D<0:f200:1be00> DVA[1]=3D<0:fe00:fa00> DVA[2]=3D<0:6a00:de00> [L0 u= nallocated] inherit inherit BE contiguous unique triple size=3D1c600L/200P = birth=3D254L/181P fill=3D204 cksum=3Ddf:d7:7f:9d [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D250L/223P fill=3D105 cksum=3D3f:7d:ca:fb DVA[0]=3D<0:8600:1b600> DVA[1]=3D<0:d600:19a00> DVA[2]=3D<0:15200:e800> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D10000L/200= P birth=3D222L/83P fill=3D78 cksum=3Dbd:1f:4f:9f DVA[0]=3D<0:1d200:4c00> DVA[1]=3D<0:1b400:18400> DVA[2]=3D<0:16a00:6c00> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D1cc00L/20= 0P birth=3D95L/221P fill=3D20 cksum=3De7:57:f4:ba [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D245L/58P fill=3D89 cksum=3D75:a7:84:c7 DVA[0]=3D<0:1ac00:be00> DVA[1]=3D<0:fa00:1be00> DVA[2]=3D<0:9200:ce00> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D15600L/200P= birth=3D107L/172P fill=3D127 cksum=3Dc6:c4:c9:bc [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D212L/95P fill=3D40 cksum=3D68:24:9c:ac [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D158L/211P fill=3D207 cksum=3Df6:1a:ce:7b DVA[0]=3D<0:8000:1c400> DVA[1]=3D<0:1b800:19a00> DVA[2]=3D<0:13a00:200> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D17200L/200= P birth=3D211L/14P fill=3D151 cksum=3D3e:8e:6b:4d DVA[0]=3D<0:f400:de00> DVA[1]=3D<0:9400:19c00> DVA[2]=3D<0:1de00:1fa00> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D14000L/200= P birth=3D90L/92P fill=3D255 cksum=3Dde:93:ee:ff DVA[0]=3D<0:1ea00:fe00> DVA[1]=3D<0:1ba00:e800> DVA[2]=3D<0:19600:15e00> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D11000L/20= 0P birth=3D249L/127P fill=3D87 cksum=3Dd3:f4:bf:9f DVA[0]=3D<0:16e00:1ae00> DVA[1]=3D<0:1b800:1be00> DVA[2]=3D<0:3e00:c200> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D20000L/20= 0P birth=3D94L/119P fill=3D254 cksum=3De4:f4:56:76 DVA[0]=3D<0:1aa00:ee00> DVA[1]=3D<0:6e00:e600> DVA[2]=3D<0:11800:7800> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D1dc00L/200P= birth=3D29L/140P fill=3D63 cksum=3Dd8:3d:bf:ba [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D205L/35P fill=3D139 cksum=3Dce:e6:e7:eb [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D95L/239P fill=3D53 cksum=3Dbb:5f:de:de DVA[0]=3D<0:17e00:1f000> DVA[1]=3D<0:ac00:fe00> DVA[2]=3D<0:14e00:11600> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D1b200L/20= 0P birth=3D100L/175P fill=3D252 cksum=3Dd6:16:d:3 DVA[0]=3D<0:17e00:7600> DVA[1]=3D<0:fa00:fa00> DVA[2]=3D<0:7600:12600> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D6800L/200P = birth=3D51L/159P fill=3D238 cksum=3D9b:b1:66:ce DVA[0]=3D<0:e00:9c00> DVA[1]=3D<0:3e00:1de00> DVA[2]=3D<0:2e00:1be00> [L0 u= nallocated] inherit inherit BE contiguous unique triple size=3D1de00L/200P = birth=3D147L/45P fill=3D182 cksum=3Dcb:cf:7:35 [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D126L/31P fill=3D208 cksum=3Dbc:2e:5f:c7 DVA[0]=3D<0:11c00:2a00> DVA[1]=3D<0:800:3a00> DVA[2]=3D<0:5400:1b400> [L0 u= nallocated] inherit inherit BE contiguous unique triple size=3D14000L/200P = birth=3D200L/190P fill=3D7 cksum=3D5e:c4:78:f2 DVA[0]=3D<0:1fa00:7e00> DVA[1]=3D<0:5a00:1d200> DVA[2]=3D<0:13e00:1f600> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D12200L/20= 0P birth=3D173L/97P fill=3D248 cksum=3D4e:c4:9c:ef [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D136L/170P fill=3D229 cksum=3D72:5a:9c:fb DVA[0]=3D<0:13e00:13e00> DVA[1]=3D<0:1e00:3e00> DVA[2]=3D<0:1fc00:3e00> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D3800L/200P= birth=3D251L/173P fill=3D239 cksum=3D9f:c6:3e:8f DVA[0]=3D<0:5a00:1fa00> DVA[1]=3D<0:17e00:d800> DVA[2]=3D<0:12600:13400> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D18200L/20= 0P birth=3D190L/219P fill=3D139 cksum=3D15:57:5f:de DVA[0]=3D<0:fe00:6600> DVA[1]=3D<0:1e600:1d600> DVA[2]=3D<0:fa00:b200> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D1ac00L/200P= birth=3D106L/153P fill=3D237 cksum=3Ddb:c7:3b:ef DVA[0]=3D<0:17e00:19200> DVA[1]=3D<0:9c00:1e00> DVA[2]=3D<0:16e00:7e00> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D1a400L/200= P birth=3D31L/179P fill=3D207 cksum=3D73:ec:9a:84 DVA[0]=3D<0:ea00:fe00> DVA[1]=3D<0:12c00:1b600> DVA[2]=3D<0:19a00:17e00> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D18000L/20= 0P birth=3D15L/229P fill=3D58 cksum=3Da4:c9:f8:a5 DVA[0]=3D<0:1be00:1fa00> DVA[1]=3D<0:18c00:1bc00> DVA[2]=3D<0:200:1a00> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D9c00L/200P= birth=3D122L/235P fill=3D15 cksum=3Df:3e:ef:76 DVA[0]=3D<0:9e00:15e00> DVA[1]=3D<0:13a00:15a00> DVA[2]=3D<0:13e00:1e000> [= L0 unallocated] inherit inherit BE contiguous unique triple size=3Dbc00L/20= 0P birth=3D99L/198P fill=3D173 cksum=3Df7:5:57:cd DVA[0]=3D<0:10200:1aa00> DVA[1]=3D<0:18e00:ea00> DVA[2]=3D<0:18e00:1e400> [= L0 unallocated] inherit inherit BE contiguous unique triple size=3D7e00L/20= 0P birth=3D156L/50P fill=3D91 cksum=3Db7:fe:12:fe DVA[0]=3D<0:fc00:3600> DVA[1]=3D<0:5e00:f600> DVA[2]=3D<0:14e00:1be00> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D2000L/200P = birth=3D251L/210P fill=3D106 cksum=3D9b:6b:2d:ff DVA[0]=3D<0:1f800:c000> DVA[1]=3D<0:b600:1b200> DVA[2]=3D<0:17000:1f200> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3Dd400L/200= P birth=3D228L/245P fill=3D100 cksum=3De9:aa:50:a9 [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D207L/242P fill=3D193 cksum=3D7f:fa:d6:7b DVA[0]=3D<0:14e00:19400> DVA[1]=3D<0:1bc00:17a00> DVA[2]=3D<0:15400:f400> [= L0 unallocated] inherit inherit BE contiguous unique triple size=3D10000L/2= 00P birth=3D126L/114P fill=3D185 cksum=3Db3:bd:b1:60 DVA[0]=3D<0:fa00:14e00> DVA[1]=3D<0:fc00:fc00> DVA[2]=3D<0:1be00:1f200> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D13c00L/200= P birth=3D30L/231P fill=3D143 cksum=3Dce:f7:f0:7a DVA[0]=3D<0:1e600:1d200> DVA[1]=3D<0:12800:1600> DVA[2]=3D<0:1be00:f400> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D1fa00L/20= 0P birth=3D71L/43P fill=3D223 cksum=3Dcf:b1:f8:5d DVA[0]=3D<0:1ee00:1ce00> DVA[1]=3D<0:e000:bc00> DVA[2]=3D<0:15e00:1cc00> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3Dc000L/200= P birth=3D255L/79P fill=3D23 cksum=3Dfc:3a:d8:f8 DVA[0]=3D<0:da00:cc00> DVA[1]=3D<0:17000:15a00> DVA[2]=3D<0:d400:7a00> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D16000L/200P= birth=3D85L/224P fill=3D255 cksum=3D33:f5:cf:ef DVA[0]=3D<0:16e00:1f600> DVA[1]=3D<0:16a00:1d800> DVA[2]=3D<0:1ba00:19e00> = [L0 unallocated] inherit inherit BE contiguous unique triple size=3D1e00L/2= 00P birth=3D141L/57P fill=3D191 cksum=3Da2:73:77:f6 DVA[0]=3D<0:1ea00:17e00> DVA[1]=3D<0:1b600:9400> DVA[2]=3D<0:1ae00:e600> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D1f800L/20= 0P birth=3D210L/238P fill=3D245 cksum=3D33:ff:ea:ff DVA[0]=3D<0:1c600:1ec00> DVA[1]=3D<0:1c200:5e00> DVA[2]=3D<0:1f200:9a00> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3Dde00L/200= P birth=3D197L/48P fill=3D101 cksum=3De4:7e:6d:35 root@host> zdb -R zzzz 0:20B002FE00:E00:di Found vdev type: raidz DVA[0]=3D<0:13da66bf800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3bc6f8b3a783:e4c3f7910006453:f26edf447f3b65fd:ec164c8453db20f2 DVA[0]=3D<0:13da66ec800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3f3d89bdc360:fd3b6a3a84a9686:25530314e1c3ecf6:447296ce0a6bc390 DVA[0]=3D<0:13da6719800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3daf62956c37:f7c7779a64b3fe2:3c0fd22767803d2b:aeb8314f905480a0 DVA[0]=3D<0:13da6746800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3dfebf3b9644:f7eae0c61d47155:376e5d62160f2531:fdf29a4ee0c41e32 DVA[0]=3D<0:13da6773800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e5e28364ae6:fb23072309c6c59:2711907b06e88f31:4aa48294b74d6ccd DVA[0]=3D<0:13da67a0800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e9b29bca68c:f9dd6067e0f95d3:dd696cbffca81b1a:6098a15c75a0315d DVA[0]=3D<0:13da67cd800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3decbddda649:f8aae580123fdbe:171399455a8b0008:3fcceeb24066e6ad DVA[0]=3D<0:13da67fa800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e0d8515e875:f8faa63e65af6bb:e44c791f815a020d:d30f9e31e0d42500 DVA[0]=3D<0:13da6827800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3d53ec0fd189:f63b1b726c93f84:192005690aad8dcc:d21c3c58becfff5a DVA[0]=3D<0:13da6881800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3d2c66cd01db:f62054bdfb3ad7e:a4d1f4f15a447958:2fa527a26245710 DVA[0]=3D<0:13da6854800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3d46c2995089:f603cbc5054195d:56a0e0d3127721f1:2f92657062f2cf48 DVA[0]=3D<0:13da68ae800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3d84b82590c4:f58066885037416:842386b78e7800e0:8ff06ca050d5dae0 DVA[0]=3D<0:13da68db800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3d84f14b3e1b:f6fd346e3171b17:c25c9c0d06fcf67e:8f200e3e263c6182 DVA[0]=3D<0:13da6908800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3df04b1abbe2:f7a5216fa52c021:f9058ca1183a0732:d4395b382b587cf1 DVA[0]=3D<0:13da6935800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e6412a7c73b:fa866da21718b43:b99912eed7765f1b:d888d66cd20b5162 DVA[0]=3D<0:13da698f800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e7a75ac74ce:fa2bc60a81ba298:f17af9c8f315c442:d3958c89a4d644c6 DVA[0]=3D<0:13da6962800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e98d90b2567:fb2906fd2fd9419:d5e888314a785d1b:cfdb90ff8ad2c089 DVA[0]=3D<0:13da69bc800:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3deb463107df:f7e4d4726d70351:1a7523278bac1eea:cb4b664047c7c610 DVA[0]=3D<0:13da69eb000:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e3edb83cbed:f9065c7d57997b9:ffad12f8540fbd1:b9aad67cd683bcfa DVA[0]=3D<0:13da6a1aa00:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3dc1cdc6c558:f692824525413b6:a114b8077d1ca593:170c6d4e7e2df07f DVA[0]=3D<0:13da6a47a00:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3df551808443:f842dcdc8a32e57:af4094c9cac4733c:c7ac3865df0c4ced DVA[0]=3D<0:13da6a74a00:2d000> [L0 ZFS plain file] fletcher4 uncompressed L= E contiguous unique single size=3D20000L/20000P birth=3D39369L/39369P fill= =3D1 cksum=3D3e69cad45d5c:f8bc987d5aabad0:e5f72ba62f3b2955:84a2a388440c0d31 DVA[0]=3D<0:ac00:1c400> DVA[1]=3D<0:1ee00:1ea00> DVA[2]=3D<0:1ee00:11400> [= L0 unallocated] inherit inherit BE contiguous unique triple size=3D1c000L/2= 00P birth=3D12L/71P fill=3D93 cksum=3D9a:97:8f:b DVA[0]=3D<0:1fe00:15400> DVA[1]=3D<0:17200:b800> DVA[2]=3D<0:1be00:1dc00> [= L0 unallocated] inherit inherit BE contiguous unique triple size=3Df600L/20= 0P birth=3D235L/214P fill=3D223 cksum=3D3e:4e:b7:dd DVA[0]=3D<0:be00:9e00> DVA[1]=3D<0:17c00:13800> DVA[2]=3D<0:ee00:bc00> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D10000L/200P= birth=3D45L/255P fill=3D110 cksum=3D95:d3:4f:5f DVA[0]=3D<0:19800:1e00> DVA[1]=3D<0:1bc00:1fa00> DVA[2]=3D<0:ee00:17600> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D17600L/20= 0P birth=3D244L/134P fill=3D238 cksum=3D75:85:9e:ed DVA[0]=3D<0:f200:1be00> DVA[1]=3D<0:fe00:fa00> DVA[2]=3D<0:6a00:de00> [L0 u= nallocated] inherit inherit BE contiguous unique triple size=3D1c600L/200P = birth=3D254L/181P fill=3D204 cksum=3Ddf:d7:7f:9d [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D250L/223P fill=3D105 cksum=3D3f:7d:ca:fb DVA[0]=3D<0:8600:1b600> DVA[1]=3D<0:d600:19a00> DVA[2]=3D<0:15200:e800> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D10000L/200= P birth=3D222L/83P fill=3D78 cksum=3Dbd:1f:4f:9f DVA[0]=3D<0:1d200:4c00> DVA[1]=3D<0:1b400:18400> DVA[2]=3D<0:16a00:6c00> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D1cc00L/20= 0P birth=3D95L/221P fill=3D20 cksum=3De7:57:f4:ba [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D245L/58P fill=3D89 cksum=3D75:a7:84:c7 DVA[0]=3D<0:1ac00:be00> DVA[1]=3D<0:fa00:1be00> DVA[2]=3D<0:9200:ce00> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D15600L/200P= birth=3D107L/172P fill=3D127 cksum=3Dc6:c4:c9:bc [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D212L/95P fill=3D40 cksum=3D68:24:9c:ac [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D158L/211P fill=3D207 cksum=3Df6:1a:ce:7b DVA[0]=3D<0:8000:1c400> DVA[1]=3D<0:1b800:19a00> DVA[2]=3D<0:13a00:200> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D17200L/200= P birth=3D211L/14P fill=3D151 cksum=3D3e:8e:6b:4d DVA[0]=3D<0:f400:de00> DVA[1]=3D<0:9400:19c00> DVA[2]=3D<0:1de00:1fa00> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D14000L/200= P birth=3D90L/92P fill=3D255 cksum=3Dde:93:ee:ff DVA[0]=3D<0:1ea00:fe00> DVA[1]=3D<0:1ba00:e800> DVA[2]=3D<0:19600:15e00> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D11000L/20= 0P birth=3D249L/127P fill=3D87 cksum=3Dd3:f4:bf:9f DVA[0]=3D<0:16e00:1ae00> DVA[1]=3D<0:1b800:1be00> DVA[2]=3D<0:3e00:c200> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D20000L/20= 0P birth=3D94L/119P fill=3D254 cksum=3De4:f4:56:76 DVA[0]=3D<0:1aa00:ee00> DVA[1]=3D<0:6e00:e600> DVA[2]=3D<0:11800:7800> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D1dc00L/200P= birth=3D29L/140P fill=3D63 cksum=3Dd8:3d:bf:ba [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D205L/35P fill=3D139 cksum=3Dce:e6:e7:eb [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D95L/239P fill=3D53 cksum=3Dbb:5f:de:de DVA[0]=3D<0:17e00:1f000> DVA[1]=3D<0:ac00:fe00> DVA[2]=3D<0:14e00:11600> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D1b200L/20= 0P birth=3D100L/175P fill=3D252 cksum=3Dd6:16:d:3 DVA[0]=3D<0:17e00:7600> DVA[1]=3D<0:fa00:fa00> DVA[2]=3D<0:7600:12600> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D6800L/200P = birth=3D51L/159P fill=3D238 cksum=3D9b:b1:66:ce DVA[0]=3D<0:e00:9c00> DVA[1]=3D<0:3e00:1de00> DVA[2]=3D<0:2e00:1be00> [L0 u= nallocated] inherit inherit BE contiguous unique triple size=3D1de00L/200P = birth=3D147L/45P fill=3D182 cksum=3Dcb:cf:7:35 [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D126L/31P fill=3D208 cksum=3Dbc:2e:5f:c7 DVA[0]=3D<0:11c00:2a00> DVA[1]=3D<0:800:3a00> DVA[2]=3D<0:5400:1b400> [L0 u= nallocated] inherit inherit BE contiguous unique triple size=3D14000L/200P = birth=3D200L/190P fill=3D7 cksum=3D5e:c4:78:f2 DVA[0]=3D<0:1fa00:7e00> DVA[1]=3D<0:5a00:1d200> DVA[2]=3D<0:13e00:1f600> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D12200L/20= 0P birth=3D173L/97P fill=3D248 cksum=3D4e:c4:9c:ef [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D136L/170P fill=3D229 cksum=3D72:5a:9c:fb DVA[0]=3D<0:13e00:13e00> DVA[1]=3D<0:1e00:3e00> DVA[2]=3D<0:1fc00:3e00> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D3800L/200P= birth=3D251L/173P fill=3D239 cksum=3D9f:c6:3e:8f DVA[0]=3D<0:5a00:1fa00> DVA[1]=3D<0:17e00:d800> DVA[2]=3D<0:12600:13400> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D18200L/20= 0P birth=3D190L/219P fill=3D139 cksum=3D15:57:5f:de DVA[0]=3D<0:fe00:6600> DVA[1]=3D<0:1e600:1d600> DVA[2]=3D<0:fa00:b200> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D1ac00L/200P= birth=3D106L/153P fill=3D237 cksum=3Ddb:c7:3b:ef DVA[0]=3D<0:17e00:19200> DVA[1]=3D<0:9c00:1e00> DVA[2]=3D<0:16e00:7e00> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D1a400L/200= P birth=3D31L/179P fill=3D207 cksum=3D73:ec:9a:84 DVA[0]=3D<0:ea00:fe00> DVA[1]=3D<0:12c00:1b600> DVA[2]=3D<0:19a00:17e00> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D18000L/20= 0P birth=3D15L/229P fill=3D58 cksum=3Da4:c9:f8:a5 DVA[0]=3D<0:1be00:1fa00> DVA[1]=3D<0:18c00:1bc00> DVA[2]=3D<0:200:1a00> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D9c00L/200P= birth=3D122L/235P fill=3D15 cksum=3Df:3e:ef:76 DVA[0]=3D<0:9e00:15e00> DVA[1]=3D<0:13a00:15a00> DVA[2]=3D<0:13e00:1e000> [= L0 unallocated] inherit inherit BE contiguous unique triple size=3Dbc00L/20= 0P birth=3D99L/198P fill=3D173 cksum=3Df7:5:57:cd DVA[0]=3D<0:10200:1aa00> DVA[1]=3D<0:18e00:ea00> DVA[2]=3D<0:18e00:1e400> [= L0 unallocated] inherit inherit BE contiguous unique triple size=3D7e00L/20= 0P birth=3D156L/50P fill=3D91 cksum=3Db7:fe:12:fe DVA[0]=3D<0:fc00:3600> DVA[1]=3D<0:5e00:f600> DVA[2]=3D<0:14e00:1be00> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D2000L/200P = birth=3D251L/210P fill=3D106 cksum=3D9b:6b:2d:ff DVA[0]=3D<0:1f800:c000> DVA[1]=3D<0:b600:1b200> DVA[2]=3D<0:17000:1f200> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3Dd400L/200= P birth=3D228L/245P fill=3D100 cksum=3De9:aa:50:a9 [L0 unallocated] inherit inherit BE contiguous unique zero size=3D200L/200P= birth=3D207L/242P fill=3D193 cksum=3D7f:fa:d6:7b DVA[0]=3D<0:14e00:19400> DVA[1]=3D<0:1bc00:17a00> DVA[2]=3D<0:15400:f400> [= L0 unallocated] inherit inherit BE contiguous unique triple size=3D10000L/2= 00P birth=3D126L/114P fill=3D185 cksum=3Db3:bd:b1:60 DVA[0]=3D<0:fa00:14e00> DVA[1]=3D<0:fc00:fc00> DVA[2]=3D<0:1be00:1f200> [L0= unallocated] inherit inherit BE contiguous unique triple size=3D13c00L/200= P birth=3D30L/231P fill=3D143 cksum=3Dce:f7:f0:7a DVA[0]=3D<0:1e600:1d200> DVA[1]=3D<0:12800:1600> DVA[2]=3D<0:1be00:f400> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D1fa00L/20= 0P birth=3D71L/43P fill=3D223 cksum=3Dcf:b1:f8:5d DVA[0]=3D<0:1ee00:1ce00> DVA[1]=3D<0:e000:bc00> DVA[2]=3D<0:15e00:1cc00> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3Dc000L/200= P birth=3D255L/79P fill=3D23 cksum=3Dfc:3a:d8:f8 DVA[0]=3D<0:da00:cc00> DVA[1]=3D<0:17000:15a00> DVA[2]=3D<0:d400:7a00> [L0 = unallocated] inherit inherit BE contiguous unique triple size=3D16000L/200P= birth=3D85L/224P fill=3D255 cksum=3D33:f5:cf:ef DVA[0]=3D<0:16e00:1f600> DVA[1]=3D<0:16a00:1d800> DVA[2]=3D<0:1ba00:19e00> = [L0 unallocated] inherit inherit BE contiguous unique triple size=3D1e00L/2= 00P birth=3D141L/57P fill=3D191 cksum=3Da2:73:77:f6 DVA[0]=3D<0:1ea00:17e00> DVA[1]=3D<0:1b600:9400> DVA[2]=3D<0:1ae00:e600> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3D1f800L/20= 0P birth=3D210L/238P fill=3D245 cksum=3D33:ff:ea:ff DVA[0]=3D<0:1c600:1ec00> DVA[1]=3D<0:1c200:5e00> DVA[2]=3D<0:1f200:9a00> [L= 0 unallocated] inherit inherit BE contiguous unique triple size=3Dde00L/200= P birth=3D197L/48P fill=3D101 cksum=3De4:7e:6d:35 root@host> It says vdev type raidz when it is a raidz2. = From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 16:42:32 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 547E7106567A for ; Thu, 23 Aug 2012 16:42:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B18C18FC27 for ; Thu, 23 Aug 2012 16:42:31 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA07426; Thu, 23 Aug 2012 19:42:27 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <50365D73.9020508@FreeBSD.org> Date: Thu, 23 Aug 2012 19:42:27 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120730 Thunderbird/14.0 MIME-Version: 1.0 To: Roger Hammerstein References: , <5034DA84.8050507@FreeBSD.org> , <5035E335.4010103@FreeBSD.org> , <50363F14.5080703@FreeBSD.org> , <50365134.9080702@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: panic while zfs scrubbing 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, 23 Aug 2012 16:42:32 -0000 on 23/08/2012 19:04 Roger Hammerstein said the following: > >> Sorry, it's my mistake (forgot to convert blocks to bytes), the commands should be: >> zdb -R zzzz c:13DA6AA1A00:E00:di >> zdb -R zzzz c:20B002FE00:E00:di > > Thank you again. > > The 'c' appears to need to be 0 instead. > > zdb -R zzzz c:13DA6AA1A00:E00:di > ***Invalid vdev: c > zdb -R zzzz c:20B002FE00:E00:di > ***Invalid vdev: c OK, good catch. > zdb -R zzzz 0:13DA6AA1A00:E00:di > Found vdev type: raidz > DVA[0]=<0:13da66bf800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3bc6f8b3a783:e4c3f7910006453:f26edf447f3b65fd:ec164c8453db20f2 > DVA[0]=<0:13da66ec800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3f3d89bdc360:fd3b6a3a84a9686:25530314e1c3ecf6:447296ce0a6bc390 > DVA[0]=<0:13da6719800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3daf62956c37:f7c7779a64b3fe2:3c0fd22767803d2b:aeb8314f905480a0 > DVA[0]=<0:13da6746800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3dfebf3b9644:f7eae0c61d47155:376e5d62160f2531:fdf29a4ee0c41e32 > DVA[0]=<0:13da6773800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3e5e28364ae6:fb23072309c6c59:2711907b06e88f31:4aa48294b74d6ccd > DVA[0]=<0:13da67a0800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3e9b29bca68c:f9dd6067e0f95d3:dd696cbffca81b1a:6098a15c75a0315d > DVA[0]=<0:13da67cd800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3decbddda649:f8aae580123fdbe:171399455a8b0008:3fcceeb24066e6ad > DVA[0]=<0:13da67fa800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3e0d8515e875:f8faa63e65af6bb:e44c791f815a020d:d30f9e31e0d42500 > DVA[0]=<0:13da6827800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3d53ec0fd189:f63b1b726c93f84:192005690aad8dcc:d21c3c58becfff5a > DVA[0]=<0:13da6881800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3d2c66cd01db:f62054bdfb3ad7e:a4d1f4f15a447958:2fa527a26245710 > DVA[0]=<0:13da6854800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3d46c2995089:f603cbc5054195d:56a0e0d3127721f1:2f92657062f2cf48 > DVA[0]=<0:13da68ae800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3d84b82590c4:f58066885037416:842386b78e7800e0:8ff06ca050d5dae0 > DVA[0]=<0:13da68db800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3d84f14b3e1b:f6fd346e3171b17:c25c9c0d06fcf67e:8f200e3e263c6182 > DVA[0]=<0:13da6908800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3df04b1abbe2:f7a5216fa52c021:f9058ca1183a0732:d4395b382b587cf1 > DVA[0]=<0:13da6935800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3e6412a7c73b:fa866da21718b43:b99912eed7765f1b:d888d66cd20b5162 > DVA[0]=<0:13da698f800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3e7a75ac74ce:fa2bc60a81ba298:f17af9c8f315c442:d3958c89a4d644c6 > DVA[0]=<0:13da6962800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3e98d90b2567:fb2906fd2fd9419:d5e888314a785d1b:cfdb90ff8ad2c089 > DVA[0]=<0:13da69bc800:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3deb463107df:f7e4d4726d70351:1a7523278bac1eea:cb4b664047c7c610 > DVA[0]=<0:13da69eb000:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3e3edb83cbed:f9065c7d57997b9:ffad12f8540fbd1:b9aad67cd683bcfa > DVA[0]=<0:13da6a1aa00:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3dc1cdc6c558:f692824525413b6:a114b8077d1ca593:170c6d4e7e2df07f > DVA[0]=<0:13da6a47a00:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3df551808443:f842dcdc8a32e57:af4094c9cac4733c:c7ac3865df0c4ced > DVA[0]=<0:13da6a74a00:2d000> [L0 ZFS plain file] fletcher4 uncompressed LE > contiguous unique single size=20000L/20000P birth=39369L/39369P fill=1 > cksum=3e69cad45d5c:f8bc987d5aabad0:e5f72ba62f3b2955:84a2a388440c0d31 > > > > > > > > > > > DVA[0]=<0:ac00:1c400> DVA[1]=<0:1ee00:1ea00> DVA[2]=<0:1ee00:11400> [L0 > unallocated] inherit inherit BE contiguous unique triple size=1c000L/200P > birth=12L/71P fill=93 cksum=9a:97:8f:b [snip] Thank you for this data. Please see if the following patch may help you. --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c @@ -801,7 +801,7 @@ dsl_scan_visitbp(blkptr_t *bp, const zbookmark_t *zb, if (dsl_scan_check_resume(scn, dnp, zb)) return; - if (bp->blk_birth == 0) + if (bp->blk_birth == 0 || BP_GET_TYPE(bp) == DMU_OT_NONE) return; scn->scn_visited_this_txg++; -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 19:40:06 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 D8282106564A for ; Thu, 23 Aug 2012 19:40:06 +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 B95B78FC08 for ; Thu, 23 Aug 2012 19:40:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7NJe6Rm055709 for ; Thu, 23 Aug 2012 19:40:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7NJe6bS055708; Thu, 23 Aug 2012 19:40:06 GMT (envelope-from gnats) Date: Thu, 23 Aug 2012 19:40:06 GMT Message-Id: <201208231940.q7NJe6bS055708@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/170912: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:40:07 -0000 The following reply was made to PR kern/170912; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/170912: commit references a PR Date: Thu, 23 Aug 2012 19:33:09 +0000 (UTC) Author: mm Date: Thu Aug 23 19:32:57 2012 New Revision: 239620 URL: http://svn.freebsd.org/changeset/base/239620 Log: Merge recent vendor changes: 3086 unnecessarily setting DS_FLAG_INCONSISTENT on async destroyed datasets 3090 vdev_reopen() during reguid causes vdev to be treated as corrupt 3102 vdev_uberblock_load() and vdev_validate() may read the wrong label Referenes: https://www.illumos.org/issues/3086 https://www.illumos.org/issues/3090 https://www.illumos.org/issues/3102 PR: kern/170912, kern/170914 Obtained from: illumos (changeset #13776, #13777) MFC after: 2 weeks Modified: head/cddl/contrib/opensolaris/cmd/ztest/ztest.c head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/txg.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil_impl.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c Directory Properties: head/cddl/contrib/opensolaris/ (props changed) head/cddl/contrib/opensolaris/lib/libzfs/ (props changed) head/sys/cddl/contrib/opensolaris/ (props changed) Modified: head/cddl/contrib/opensolaris/cmd/ztest/ztest.c ============================================================================== --- head/cddl/contrib/opensolaris/cmd/ztest/ztest.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/cddl/contrib/opensolaris/cmd/ztest/ztest.c Thu Aug 23 19:32:57 2012 (r239620) @@ -364,7 +364,7 @@ ztest_info_t ztest_info[] = { { ztest_spa_rename, 1, &zopt_rarely }, { ztest_scrub, 1, &zopt_rarely }, { ztest_dsl_dataset_promote_busy, 1, &zopt_rarely }, - { ztest_vdev_attach_detach, 1, &zopt_rarely }, + { ztest_vdev_attach_detach, 1, &zopt_rarely }, { ztest_vdev_LUN_growth, 1, &zopt_rarely }, { ztest_vdev_add_remove, 1, &ztest_opts.zo_vdevtime }, @@ -415,6 +415,13 @@ static spa_t *ztest_spa = NULL; static ztest_ds_t *ztest_ds; static mutex_t ztest_vdev_lock; + +/* + * The ztest_name_lock protects the pool and dataset namespace used by + * the individual tests. To modify the namespace, consumers must grab + * this lock as writer. Grabbing the lock as reader will ensure that the + * namespace does not change while the lock is held. + */ static rwlock_t ztest_name_lock; static boolean_t ztest_dump_core = B_TRUE; @@ -2225,6 +2232,7 @@ ztest_zil_remount(ztest_ds_t *zd, uint64 { objset_t *os = zd->zd_os; + VERIFY(mutex_lock(&zd->zd_dirobj_lock) == 0); (void) rw_wrlock(&zd->zd_zilog_lock); /* zfsvfs_teardown() */ @@ -2235,6 +2243,7 @@ ztest_zil_remount(ztest_ds_t *zd, uint64 zil_replay(os, zd, ztest_replay_vector); (void) rw_unlock(&zd->zd_zilog_lock); + VERIFY(mutex_unlock(&zd->zd_dirobj_lock) == 0); } /* @@ -4860,10 +4869,16 @@ ztest_reguid(ztest_ds_t *zd, uint64_t id { spa_t *spa = ztest_spa; uint64_t orig, load; + int error; orig = spa_guid(spa); load = spa_load_guid(spa); - if (spa_change_guid(spa) != 0) + + (void) rw_wrlock(&ztest_name_lock); + error = spa_change_guid(spa); + (void) rw_unlock(&ztest_name_lock); + + if (error != 0) return; if (ztest_opts.zo_verbose >= 3) { @@ -5540,8 +5555,15 @@ ztest_freeze(void) */ kernel_init(FREAD | FWRITE); VERIFY3U(0, ==, spa_open(ztest_opts.zo_pool, &spa, FTAG)); + ASSERT(spa_freeze_txg(spa) == UINT64_MAX); VERIFY3U(0, ==, ztest_dataset_open(0)); ztest_dataset_close(0); + + spa->spa_debug = B_TRUE; + ztest_spa = spa; + txg_wait_synced(spa_get_dsl(spa), 0); + ztest_reguid(NULL, 0); + spa_close(spa, FTAG); kernel_fini(); } Modified: head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c ============================================================================== --- head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c Thu Aug 23 19:32:57 2012 (r239620) @@ -21,7 +21,7 @@ /* * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. * Copyright 2011 Nexenta Systems, Inc. All rights reserved. - * Copyright (c) 2011 by Delphix. All rights reserved. + * Copyright (c) 2012 by Delphix. All rights reserved. */ /* @@ -437,8 +437,8 @@ get_configs(libzfs_handle_t *hdl, pool_l uint_t i, nspares, nl2cache; boolean_t config_seen; uint64_t best_txg; - char *name, *hostname, *comment; - uint64_t version, guid; + char *name, *hostname; + uint64_t guid; uint_t children = 0; nvlist_t **child = NULL; uint_t holes; @@ -524,61 +524,54 @@ get_configs(libzfs_handle_t *hdl, pool_l * configuration: * * version - * pool guid - * name + * pool guid + * name + * pool txg (if available) * comment (if available) - * pool state + * pool state * hostid (if available) * hostname (if available) */ - uint64_t state; + uint64_t state, version, pool_txg; + char *comment = NULL; - verify(nvlist_lookup_uint64(tmp, - ZPOOL_CONFIG_VERSION, &version) == 0); - if (nvlist_add_uint64(config, - ZPOOL_CONFIG_VERSION, version) != 0) - goto nomem; - verify(nvlist_lookup_uint64(tmp, - ZPOOL_CONFIG_POOL_GUID, &guid) == 0); - if (nvlist_add_uint64(config, - ZPOOL_CONFIG_POOL_GUID, guid) != 0) - goto nomem; - verify(nvlist_lookup_string(tmp, - ZPOOL_CONFIG_POOL_NAME, &name) == 0); - if (nvlist_add_string(config, - ZPOOL_CONFIG_POOL_NAME, name) != 0) - goto nomem; + version = fnvlist_lookup_uint64(tmp, + ZPOOL_CONFIG_VERSION); + fnvlist_add_uint64(config, + ZPOOL_CONFIG_VERSION, version); + guid = fnvlist_lookup_uint64(tmp, + ZPOOL_CONFIG_POOL_GUID); + fnvlist_add_uint64(config, + ZPOOL_CONFIG_POOL_GUID, guid); + name = fnvlist_lookup_string(tmp, + ZPOOL_CONFIG_POOL_NAME); + fnvlist_add_string(config, + ZPOOL_CONFIG_POOL_NAME, name); - /* - * COMMENT is optional, don't bail if it's not - * there, instead, set it to NULL. - */ - if (nvlist_lookup_string(tmp, - ZPOOL_CONFIG_COMMENT, &comment) != 0) - comment = NULL; - else if (nvlist_add_string(config, - ZPOOL_CONFIG_COMMENT, comment) != 0) - goto nomem; + if (nvlist_lookup_uint64(tmp, + ZPOOL_CONFIG_POOL_TXG, &pool_txg) == 0) + fnvlist_add_uint64(config, + ZPOOL_CONFIG_POOL_TXG, pool_txg); - verify(nvlist_lookup_uint64(tmp, - ZPOOL_CONFIG_POOL_STATE, &state) == 0); - if (nvlist_add_uint64(config, - ZPOOL_CONFIG_POOL_STATE, state) != 0) - goto nomem; + if (nvlist_lookup_string(tmp, + ZPOOL_CONFIG_COMMENT, &comment) == 0) + fnvlist_add_string(config, + ZPOOL_CONFIG_COMMENT, comment); + + state = fnvlist_lookup_uint64(tmp, + ZPOOL_CONFIG_POOL_STATE); + fnvlist_add_uint64(config, + ZPOOL_CONFIG_POOL_STATE, state); hostid = 0; if (nvlist_lookup_uint64(tmp, ZPOOL_CONFIG_HOSTID, &hostid) == 0) { - if (nvlist_add_uint64(config, - ZPOOL_CONFIG_HOSTID, hostid) != 0) - goto nomem; - verify(nvlist_lookup_string(tmp, - ZPOOL_CONFIG_HOSTNAME, - &hostname) == 0); - if (nvlist_add_string(config, - ZPOOL_CONFIG_HOSTNAME, - hostname) != 0) - goto nomem; + fnvlist_add_uint64(config, + ZPOOL_CONFIG_HOSTID, hostid); + hostname = fnvlist_lookup_string(tmp, + ZPOOL_CONFIG_HOSTNAME); + fnvlist_add_string(config, + ZPOOL_CONFIG_HOSTNAME, hostname); } config_seen = B_TRUE; Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c Thu Aug 23 19:32:57 2012 (r239620) @@ -1769,15 +1769,15 @@ dmu_init(void) dnode_init(); dbuf_init(); zfetch_init(); - arc_init(); l2arc_init(); + arc_init(); } void dmu_fini(void) { - l2arc_fini(); arc_fini(); + l2arc_fini(); zfetch_fini(); dbuf_fini(); dnode_fini(); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c Thu Aug 23 19:32:57 2012 (r239620) @@ -1649,13 +1649,6 @@ dmu_recv_existing_end(dmu_recv_cookie_t dsl_dataset_t *ds = drc->drc_logical_ds; int err, myerr; - /* - * XXX hack; seems the ds is still dirty and dsl_pool_zil_clean() - * expects it to have a ds_user_ptr (and zil), but clone_swap() - * can close it. - */ - txg_wait_synced(ds->ds_dir->dd_pool, 0); - if (dsl_dataset_tryown(ds, FALSE, dmu_recv_tag)) { err = dsl_dataset_clone_swap(drc->drc_real_ds, ds, drc->drc_force); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c Thu Aug 23 19:32:57 2012 (r239620) @@ -106,14 +106,8 @@ dsl_dataset_block_born(dsl_dataset_t *ds ASSERT(BP_GET_TYPE(bp) != DMU_OT_NONE); ASSERT(DMU_OT_IS_VALID(BP_GET_TYPE(bp))); if (ds == NULL) { - /* - * Account for the meta-objset space in its placeholder - * dsl_dir. - */ - ASSERT3U(compressed, ==, uncompressed); /* it's all metadata */ - dsl_dir_diduse_space(tx->tx_pool->dp_mos_dir, DD_USED_HEAD, - used, compressed, uncompressed, tx); - dsl_dir_dirty(tx->tx_pool->dp_mos_dir, tx); + dsl_pool_mos_diduse_space(tx->tx_pool, + used, compressed, uncompressed); return; } dmu_buf_will_dirty(ds->ds_dbuf, tx); @@ -149,15 +143,9 @@ dsl_dataset_block_kill(dsl_dataset_t *ds ASSERT(used > 0); if (ds == NULL) { - /* - * Account for the meta-objset space in its placeholder - * dataset. - */ dsl_free(tx->tx_pool, tx->tx_txg, bp); - - dsl_dir_diduse_space(tx->tx_pool->dp_mos_dir, DD_USED_HEAD, - -used, -compressed, -uncompressed, tx); - dsl_dir_dirty(tx->tx_pool->dp_mos_dir, tx); + dsl_pool_mos_diduse_space(tx->tx_pool, + -used, -compressed, -uncompressed); return (used); } ASSERT3P(tx->tx_pool, ==, ds->ds_dir->dd_pool); @@ -1116,26 +1104,26 @@ dsl_dataset_destroy(dsl_dataset_t *ds, v dummy_ds.ds_dir = dd; dummy_ds.ds_object = ds->ds_object; - /* - * Check for errors and mark this ds as inconsistent, in - * case we crash while freeing the objects. - */ - err = dsl_sync_task_do(dd->dd_pool, dsl_dataset_destroy_begin_check, - dsl_dataset_destroy_begin_sync, ds, NULL, 0); - if (err) - goto out; - - err = dmu_objset_from_ds(ds, &os); - if (err) - goto out; - - /* - * If async destruction is not enabled try to remove all objects - * while in the open context so that there is less work to do in - * the syncing context. - */ if (!spa_feature_is_enabled(dsl_dataset_get_spa(ds), &spa_feature_table[SPA_FEATURE_ASYNC_DESTROY])) { + /* + * Check for errors and mark this ds as inconsistent, in + * case we crash while freeing the objects. + */ + err = dsl_sync_task_do(dd->dd_pool, + dsl_dataset_destroy_begin_check, + dsl_dataset_destroy_begin_sync, ds, NULL, 0); + if (err) + goto out; + + err = dmu_objset_from_ds(ds, &os); + if (err) + goto out; + + /* + * Remove all objects while in the open context so that + * there is less work to do in the syncing context. + */ for (obj = 0; err == 0; err = dmu_object_next(os, &obj, FALSE, ds->ds_phys->ds_prev_snap_txg)) { /* @@ -1146,30 +1134,25 @@ dsl_dataset_destroy(dsl_dataset_t *ds, v } if (err != ESRCH) goto out; - } - /* - * Only the ZIL knows how to free log blocks. - */ - zil_destroy(dmu_objset_zil(os), B_FALSE); - - /* - * Sync out all in-flight IO. - */ - txg_wait_synced(dd->dd_pool, 0); - - /* - * If we managed to free all the objects in open - * context, the user space accounting should be zero. - */ - if (ds->ds_phys->ds_bp.blk_fill == 0 && - dmu_objset_userused_enabled(os)) { - uint64_t count; + /* + * Sync out all in-flight IO. + */ + txg_wait_synced(dd->dd_pool, 0); - ASSERT(zap_count(os, DMU_USERUSED_OBJECT, &count) != 0 || - count == 0); - ASSERT(zap_count(os, DMU_GROUPUSED_OBJECT, &count) != 0 || - count == 0); + /* + * If we managed to free all the objects in open + * context, the user space accounting should be zero. + */ + if (ds->ds_phys->ds_bp.blk_fill == 0 && + dmu_objset_userused_enabled(os)) { + uint64_t count; + + ASSERT(zap_count(os, DMU_USERUSED_OBJECT, + &count) != 0 || count == 0); + ASSERT(zap_count(os, DMU_GROUPUSED_OBJECT, + &count) != 0 || count == 0); + } } rw_enter(&dd->dd_pool->dp_config_rwlock, RW_READER); @@ -1906,6 +1889,7 @@ dsl_dataset_destroy_sync(void *arg1, voi } else { zfeature_info_t *async_destroy = &spa_feature_table[SPA_FEATURE_ASYNC_DESTROY]; + objset_t *os; /* * There's no next snapshot, so this is a head dataset. @@ -1917,6 +1901,8 @@ dsl_dataset_destroy_sync(void *arg1, voi dsl_deadlist_free(mos, ds->ds_phys->ds_deadlist_obj, tx); ds->ds_phys->ds_deadlist_obj = 0; + VERIFY3U(0, ==, dmu_objset_from_ds(ds, &os)); + if (!spa_feature_is_enabled(dp->dp_spa, async_destroy)) { err = old_synchronous_dataset_destroy(ds, tx); } else { @@ -1926,12 +1912,12 @@ dsl_dataset_destroy_sync(void *arg1, voi */ uint64_t used, comp, uncomp; - ASSERT(err == 0 || err == EBUSY); + zil_destroy_sync(dmu_objset_zil(os), tx); + if (!spa_feature_is_active(dp->dp_spa, async_destroy)) { spa_feature_incr(dp->dp_spa, async_destroy, tx); - dp->dp_bptree_obj = bptree_alloc( - dp->dp_meta_objset, tx); - VERIFY(zap_add(dp->dp_meta_objset, + dp->dp_bptree_obj = bptree_alloc(mos, tx); + VERIFY(zap_add(mos, DMU_POOL_DIRECTORY_OBJECT, DMU_POOL_BPTREE_OBJ, sizeof (uint64_t), 1, &dp->dp_bptree_obj, tx) == 0); @@ -1944,7 +1930,7 @@ dsl_dataset_destroy_sync(void *arg1, voi ASSERT(!DS_UNIQUE_IS_ACCURATE(ds) || ds->ds_phys->ds_unique_bytes == used); - bptree_add(dp->dp_meta_objset, dp->dp_bptree_obj, + bptree_add(mos, dp->dp_bptree_obj, &ds->ds_phys->ds_bp, ds->ds_phys->ds_prev_snap_txg, used, comp, uncomp, tx); dsl_dir_diduse_space(ds->ds_dir, DD_USED_HEAD, @@ -2233,7 +2219,6 @@ dsl_dataset_sync(dsl_dataset_t *ds, zio_ dmu_buf_will_dirty(ds->ds_dbuf, tx); ds->ds_phys->ds_fsid_guid = ds->ds_fsid_guid; - dsl_dir_dirty(ds->ds_dir, tx); dmu_objset_sync(ds->ds_objset, zio, tx); } Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c Thu Aug 23 19:32:57 2012 (r239620) @@ -195,7 +195,6 @@ errout: kmem_free(dd, sizeof (dsl_dir_t)); dmu_buf_rele(dbuf, tag); return (err); - } void @@ -229,7 +228,7 @@ dsl_dir_name(dsl_dir_t *dd, char *buf) } } -/* Calculate name legnth, avoiding all the strcat calls of dsl_dir_name */ +/* Calculate name length, avoiding all the strcat calls of dsl_dir_name */ int dsl_dir_namelen(dsl_dir_t *dd) { @@ -593,8 +592,6 @@ dsl_dir_sync(dsl_dir_t *dd, dmu_tx_t *tx { ASSERT(dmu_tx_is_syncing(tx)); - dmu_buf_will_dirty(dd->dd_dbuf, tx); - mutex_enter(&dd->dd_lock); ASSERT3U(dd->dd_tempreserved[tx->tx_txg&TXG_MASK], ==, 0); dprintf_dd(dd, "txg=%llu towrite=%lluK\n", tx->tx_txg, @@ -951,8 +948,6 @@ dsl_dir_diduse_space(dsl_dir_t *dd, dd_u ASSERT(dmu_tx_is_syncing(tx)); ASSERT(type < DD_USED_NUM); - dsl_dir_dirty(dd, tx); - if (needlock) mutex_enter(&dd->dd_lock); accounted_delta = parent_delta(dd, dd->dd_phys->dd_used_bytes, used); @@ -961,6 +956,7 @@ dsl_dir_diduse_space(dsl_dir_t *dd, dd_u dd->dd_phys->dd_compressed_bytes >= -compressed); ASSERT(uncompressed >= 0 || dd->dd_phys->dd_uncompressed_bytes >= -uncompressed); + dmu_buf_will_dirty(dd->dd_dbuf, tx); dd->dd_phys->dd_used_bytes += used; dd->dd_phys->dd_uncompressed_bytes += uncompressed; dd->dd_phys->dd_compressed_bytes += compressed; @@ -1002,13 +998,13 @@ dsl_dir_transfer_space(dsl_dir_t *dd, in if (delta == 0 || !(dd->dd_phys->dd_flags & DD_FLAG_USED_BREAKDOWN)) return; - dsl_dir_dirty(dd, tx); if (needlock) mutex_enter(&dd->dd_lock); ASSERT(delta > 0 ? dd->dd_phys->dd_used_breakdown[oldtype] >= delta : dd->dd_phys->dd_used_breakdown[newtype] >= -delta); ASSERT(dd->dd_phys->dd_used_bytes >= ABS(delta)); + dmu_buf_will_dirty(dd->dd_dbuf, tx); dd->dd_phys->dd_used_breakdown[oldtype] -= delta; dd->dd_phys->dd_used_breakdown[newtype] += delta; if (needlock) Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c Thu Aug 23 19:32:57 2012 (r239620) @@ -42,6 +42,7 @@ #include #include #include +#include int zfs_no_write_throttle = 0; int zfs_write_limit_shift = 3; /* 1/8th of physical memory */ @@ -111,12 +112,12 @@ dsl_pool_open_impl(spa_t *spa, uint64_t txg_list_create(&dp->dp_dirty_datasets, offsetof(dsl_dataset_t, ds_dirty_link)); + txg_list_create(&dp->dp_dirty_zilogs, + offsetof(zilog_t, zl_dirty_link)); txg_list_create(&dp->dp_dirty_dirs, offsetof(dsl_dir_t, dd_dirty_link)); txg_list_create(&dp->dp_sync_tasks, offsetof(dsl_sync_task_group_t, dstg_node)); - list_create(&dp->dp_synced_datasets, sizeof (dsl_dataset_t), - offsetof(dsl_dataset_t, ds_synced_link)); mutex_init(&dp->dp_lock, NULL, MUTEX_DEFAULT, NULL); @@ -249,9 +250,9 @@ dsl_pool_close(dsl_pool_t *dp) dmu_objset_evict(dp->dp_meta_objset); txg_list_destroy(&dp->dp_dirty_datasets); + txg_list_destroy(&dp->dp_dirty_zilogs); txg_list_destroy(&dp->dp_sync_tasks); txg_list_destroy(&dp->dp_dirty_dirs); - list_destroy(&dp->dp_synced_datasets); arc_flush(dp->dp_spa); txg_fini(dp); @@ -331,6 +332,21 @@ dsl_pool_create(spa_t *spa, nvlist_t *zp return (dp); } +/* + * Account for the meta-objset space in its placeholder dsl_dir. + */ +void +dsl_pool_mos_diduse_space(dsl_pool_t *dp, + int64_t used, int64_t comp, int64_t uncomp) +{ + ASSERT3U(comp, ==, uncomp); /* it's all metadata */ + mutex_enter(&dp->dp_lock); + dp->dp_mos_used_delta += used; + dp->dp_mos_compressed_delta += comp; + dp->dp_mos_uncompressed_delta += uncomp; + mutex_exit(&dp->dp_lock); +} + static int deadlist_enqueue_cb(void *arg, const blkptr_t *bp, dmu_tx_t *tx) { @@ -349,11 +365,14 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t dmu_tx_t *tx; dsl_dir_t *dd; dsl_dataset_t *ds; - dsl_sync_task_group_t *dstg; objset_t *mos = dp->dp_meta_objset; hrtime_t start, write_time; uint64_t data_written; int err; + list_t synced_datasets; + + list_create(&synced_datasets, sizeof (dsl_dataset_t), + offsetof(dsl_dataset_t, ds_synced_link)); /* * We need to copy dp_space_towrite() before doing @@ -376,7 +395,7 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t * may sync newly-created datasets on pass 2. */ ASSERT(!list_link_active(&ds->ds_synced_link)); - list_insert_tail(&dp->dp_synced_datasets, ds); + list_insert_tail(&synced_datasets, ds); dsl_dataset_sync(ds, zio, tx); } DTRACE_PROBE(pool_sync__1setup); @@ -386,15 +405,20 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t ASSERT(err == 0); DTRACE_PROBE(pool_sync__2rootzio); - for (ds = list_head(&dp->dp_synced_datasets); ds; - ds = list_next(&dp->dp_synced_datasets, ds)) + /* + * After the data blocks have been written (ensured by the zio_wait() + * above), update the user/group space accounting. + */ + for (ds = list_head(&synced_datasets); ds; + ds = list_next(&synced_datasets, ds)) dmu_objset_do_userquota_updates(ds->ds_objset, tx); /* * Sync the datasets again to push out the changes due to * userspace updates. This must be done before we process the - * sync tasks, because that could cause a snapshot of a dataset - * whose ds_bp will be rewritten when we do this 2nd sync. + * sync tasks, so that any snapshots will have the correct + * user accounting information (and we won't get confused + * about which blocks are part of the snapshot). */ zio = zio_root(dp->dp_spa, NULL, NULL, ZIO_FLAG_MUSTSUCCEED); while (ds = txg_list_remove(&dp->dp_dirty_datasets, txg)) { @@ -405,30 +429,42 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t err = zio_wait(zio); /* - * Move dead blocks from the pending deadlist to the on-disk - * deadlist. + * Now that the datasets have been completely synced, we can + * clean up our in-memory structures accumulated while syncing: + * + * - move dead blocks from the pending deadlist to the on-disk deadlist + * - clean up zil records + * - release hold from dsl_dataset_dirty() */ - for (ds = list_head(&dp->dp_synced_datasets); ds; - ds = list_next(&dp->dp_synced_datasets, ds)) { + while (ds = list_remove_head(&synced_datasets)) { + objset_t *os = ds->ds_objset; bplist_iterate(&ds->ds_pending_deadlist, deadlist_enqueue_cb, &ds->ds_deadlist, tx); + ASSERT(!dmu_objset_is_dirty(os, txg)); + dmu_buf_rele(ds->ds_dbuf, ds); } - while (dstg = txg_list_remove(&dp->dp_sync_tasks, txg)) { - /* - * No more sync tasks should have been added while we - * were syncing. - */ - ASSERT(spa_sync_pass(dp->dp_spa) == 1); - dsl_sync_task_group_sync(dstg, tx); - } - DTRACE_PROBE(pool_sync__3task); - start = gethrtime(); while (dd = txg_list_remove(&dp->dp_dirty_dirs, txg)) dsl_dir_sync(dd, tx); write_time += gethrtime() - start; + /* + * The MOS's space is accounted for in the pool/$MOS + * (dp_mos_dir). We can't modify the mos while we're syncing + * it, so we remember the deltas and apply them here. + */ + if (dp->dp_mos_used_delta != 0 || dp->dp_mos_compressed_delta != 0 || + dp->dp_mos_uncompressed_delta != 0) { + dsl_dir_diduse_space(dp->dp_mos_dir, DD_USED_HEAD, + dp->dp_mos_used_delta, + dp->dp_mos_compressed_delta, + dp->dp_mos_uncompressed_delta, tx); + dp->dp_mos_used_delta = 0; + dp->dp_mos_compressed_delta = 0; + dp->dp_mos_uncompressed_delta = 0; + } + start = gethrtime(); if (list_head(&mos->os_dirty_dnodes[txg & TXG_MASK]) != NULL || list_head(&mos->os_free_dnodes[txg & TXG_MASK]) != NULL) { @@ -444,6 +480,27 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t hrtime_t, dp->dp_read_overhead); write_time -= dp->dp_read_overhead; + /* + * If we modify a dataset in the same txg that we want to destroy it, + * its dsl_dir's dd_dbuf will be dirty, and thus have a hold on it. + * dsl_dir_destroy_check() will fail if there are unexpected holds. + * Therefore, we want to sync the MOS (thus syncing the dd_dbuf + * and clearing the hold on it) before we process the sync_tasks. + * The MOS data dirtied by the sync_tasks will be synced on the next + * pass. + */ + DTRACE_PROBE(pool_sync__3task); + if (!txg_list_empty(&dp->dp_sync_tasks, txg)) { + dsl_sync_task_group_t *dstg; + /* + * No more sync tasks should have been added while we + * were syncing. + */ + ASSERT(spa_sync_pass(dp->dp_spa) == 1); + while (dstg = txg_list_remove(&dp->dp_sync_tasks, txg)) + dsl_sync_task_group_sync(dstg, tx); + } + dmu_tx_commit(tx); dp->dp_space_towrite[txg & TXG_MASK] = 0; @@ -492,15 +549,14 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t void dsl_pool_sync_done(dsl_pool_t *dp, uint64_t txg) { + zilog_t *zilog; dsl_dataset_t *ds; - objset_t *os; - while (ds = list_head(&dp->dp_synced_datasets)) { - list_remove(&dp->dp_synced_datasets, ds); - os = ds->ds_objset; - zil_clean(os->os_zil, txg); - ASSERT(!dmu_objset_is_dirty(os, txg)); - dmu_buf_rele(ds->ds_dbuf, ds); + while (zilog = txg_list_remove(&dp->dp_dirty_zilogs, txg)) { + ds = dmu_objset_ds(zilog->zl_os); + zil_clean(zilog, txg); + ASSERT(!dmu_objset_is_dirty(zilog->zl_os, txg)); + dmu_buf_rele(ds->ds_dbuf, zilog); } ASSERT(!dmu_objset_is_dirty(dp->dp_meta_objset, txg)); } Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c Thu Aug 23 19:32:57 2012 (r239620) @@ -120,6 +120,8 @@ const zio_taskq_info_t zio_taskqs[ZIO_TY static dsl_syncfunc_t spa_sync_version; static dsl_syncfunc_t spa_sync_props; +static dsl_checkfunc_t spa_change_guid_check; +static dsl_syncfunc_t spa_change_guid_sync; static boolean_t spa_has_active_shared_spare(spa_t *spa); static int spa_load_impl(spa_t *spa, uint64_t, nvlist_t *config, spa_load_state_t state, spa_import_type_t type, boolean_t mosconfig, @@ -683,6 +685,56 @@ spa_prop_clear_bootfs(spa_t *spa, uint64 } } +/*ARGSUSED*/ +static int +spa_change_guid_check(void *arg1, void *arg2, dmu_tx_t *tx) +{ + spa_t *spa = arg1; + uint64_t *newguid = arg2; + vdev_t *rvd = spa->spa_root_vdev; + uint64_t vdev_state; + + spa_config_enter(spa, SCL_STATE, FTAG, RW_READER); + vdev_state = rvd->vdev_state; + spa_config_exit(spa, SCL_STATE, FTAG); + + if (vdev_state != VDEV_STATE_HEALTHY) + return (ENXIO); + + ASSERT3U(spa_guid(spa), !=, *newguid); + + return (0); +} + +static void +spa_change_guid_sync(void *arg1, void *arg2, dmu_tx_t *tx) +{ + spa_t *spa = arg1; + uint64_t *newguid = arg2; + uint64_t oldguid; + vdev_t *rvd = spa->spa_root_vdev; + + oldguid = spa_guid(spa); + + spa_config_enter(spa, SCL_STATE, FTAG, RW_READER); + rvd->vdev_guid = *newguid; + rvd->vdev_guid_sum += (*newguid - oldguid); + vdev_config_dirty(rvd); + spa_config_exit(spa, SCL_STATE, FTAG); + +#ifdef __FreeBSD__ + /* + * TODO: until recent illumos logging changes are merged + * log reguid as pool property change + */ + spa_history_log_internal(LOG_POOL_PROPSET, spa, tx, + "guid change old=%llu new=%llu", oldguid, *newguid); +#else + spa_history_log_internal(spa, "guid change", tx, "old=%lld new=%lld", + oldguid, *newguid); +#endif +} + /* * Change the GUID for the pool. This is done so that we can later * re-import a pool built from a clone of our own vdevs. We will modify @@ -695,29 +747,23 @@ spa_prop_clear_bootfs(spa_t *spa, uint64 int spa_change_guid(spa_t *spa) { - uint64_t oldguid, newguid; - uint64_t txg; - - if (!(spa_mode_global & FWRITE)) - return (EROFS); - - txg = spa_vdev_enter(spa); - - if (spa->spa_root_vdev->vdev_state != VDEV_STATE_HEALTHY) - return (spa_vdev_exit(spa, NULL, txg, ENXIO)); + int error; + uint64_t guid; - oldguid = spa_guid(spa); - newguid = spa_generate_guid(NULL); - ASSERT3U(oldguid, !=, newguid); + mutex_enter(&spa_namespace_lock); + guid = spa_generate_guid(NULL); - spa->spa_root_vdev->vdev_guid = newguid; - spa->spa_root_vdev->vdev_guid_sum += (newguid - oldguid); + error = dsl_sync_task_do(spa_get_dsl(spa), spa_change_guid_check, + spa_change_guid_sync, spa, &guid, 5); - vdev_config_dirty(spa->spa_root_vdev); + if (error == 0) { + spa_config_sync(spa, B_FALSE, B_TRUE); + spa_event_notify(spa, NULL, ESC_ZFS_POOL_REGUID); + } - spa_event_notify(spa, NULL, ESC_ZFS_POOL_REGUID); + mutex_exit(&spa_namespace_lock); - return (spa_vdev_exit(spa, NULL, txg, 0)); + return (error); } /* @@ -6107,6 +6153,9 @@ spa_sync(spa_t *spa, uint64_t txg) rvd->vdev_children, txg, B_TRUE); } + if (error == 0) + spa->spa_last_synced_guid = rvd->vdev_guid; + spa_config_exit(spa, SCL_STATE, FTAG); if (error == 0) Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c Thu Aug 23 19:32:57 2012 (r239620) @@ -1352,16 +1352,29 @@ spa_name(spa_t *spa) uint64_t spa_guid(spa_t *spa) { + dsl_pool_t *dp = spa_get_dsl(spa); + uint64_t guid; + /* * If we fail to parse the config during spa_load(), we can go through * the error path (which posts an ereport) and end up here with no root * vdev. We stash the original pool guid in 'spa_config_guid' to handle * this case. */ - if (spa->spa_root_vdev != NULL) + if (spa->spa_root_vdev == NULL) + return (spa->spa_config_guid); + + guid = spa->spa_last_synced_guid != 0 ? + spa->spa_last_synced_guid : spa->spa_root_vdev->vdev_guid; + + /* + * Return the most recently synced out guid unless we're + * in syncing context. + */ + if (dp && dsl_pool_sync_context(dp)) return (spa->spa_root_vdev->vdev_guid); else - return (spa->spa_config_guid); + return (guid); } uint64_t Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h Thu Aug 23 19:32:57 2012 (r239620) @@ -82,7 +82,6 @@ typedef struct dsl_pool { /* No lock needed - sync context only */ blkptr_t dp_meta_rootbp; - list_t dp_synced_datasets; hrtime_t dp_read_overhead; uint64_t dp_throughput; /* bytes per millisec */ uint64_t dp_write_limit; @@ -96,10 +95,14 @@ typedef struct dsl_pool { kmutex_t dp_lock; uint64_t dp_space_towrite[TXG_SIZE]; uint64_t dp_tempreserved[TXG_SIZE]; + uint64_t dp_mos_used_delta; + uint64_t dp_mos_compressed_delta; + uint64_t dp_mos_uncompressed_delta; /* Has its own locking */ tx_state_t dp_tx; txg_list_t dp_dirty_datasets; + txg_list_t dp_dirty_zilogs; txg_list_t dp_dirty_dirs; txg_list_t dp_sync_tasks; @@ -139,6 +142,8 @@ int dsl_read_nolock(zio_t *pio, spa_t *s void dsl_pool_create_origin(dsl_pool_t *dp, dmu_tx_t *tx); void dsl_pool_upgrade_clones(dsl_pool_t *dp, dmu_tx_t *tx); void dsl_pool_upgrade_dir_clones(dsl_pool_t *dp, dmu_tx_t *tx); +void dsl_pool_mos_diduse_space(dsl_pool_t *dp, + int64_t used, int64_t comp, int64_t uncomp); taskq_t *dsl_pool_vnrele_taskq(dsl_pool_t *dp); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h Thu Aug 23 19:32:57 2012 (r239620) @@ -141,6 +141,7 @@ struct spa { vdev_t *spa_root_vdev; /* top-level vdev container */ uint64_t spa_config_guid; /* config pool guid */ uint64_t spa_load_guid; /* spa_load initialized guid */ + uint64_t spa_last_synced_guid; /* last synced guid */ list_t spa_config_dirty_list; /* vdevs with dirty config */ list_t spa_state_dirty_list; /* vdevs with dirty state */ spa_aux_vdev_t spa_spares; /* hot spares */ Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/txg.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/txg.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/txg.h Thu Aug 23 19:32:57 2012 (r239620) @@ -22,6 +22,9 @@ * Copyright 2010 Sun Microsystems, Inc. All rights reserved. * Use is subject to license terms. */ +/* + * Copyright (c) 2012 by Delphix. All rights reserved. + */ #ifndef _SYS_TXG_H #define _SYS_TXG_H @@ -115,7 +118,7 @@ extern boolean_t txg_sync_waiting(struct extern void txg_list_create(txg_list_t *tl, size_t offset); extern void txg_list_destroy(txg_list_t *tl); -extern int txg_list_empty(txg_list_t *tl, uint64_t txg); +extern boolean_t txg_list_empty(txg_list_t *tl, uint64_t txg); extern int txg_list_add(txg_list_t *tl, void *p, uint64_t txg); extern int txg_list_add_tail(txg_list_t *tl, void *p, uint64_t txg); extern void *txg_list_remove(txg_list_t *tl, uint64_t txg); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h Thu Aug 23 19:32:57 2012 (r239620) @@ -142,7 +142,7 @@ extern nvlist_t *vdev_config_generate(sp struct uberblock; extern uint64_t vdev_label_offset(uint64_t psize, int l, uint64_t offset); extern int vdev_label_number(uint64_t psise, uint64_t offset); -extern nvlist_t *vdev_label_read_config(vdev_t *vd, int label); +extern nvlist_t *vdev_label_read_config(vdev_t *vd, uint64_t txg); extern void vdev_uberblock_load(vdev_t *, struct uberblock *, nvlist_t **); typedef enum { Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil.h Thu Aug 23 19:32:57 2012 (r239620) @@ -20,6 +20,7 @@ */ /* * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012 by Delphix. All rights reserved. */ /* Portions Copyright 2010 Robert Milkowski */ @@ -395,6 +396,7 @@ extern void zil_replay(objset_t *os, voi zil_replay_func_t *replay_func[TX_MAX_TYPE]); extern boolean_t zil_replaying(zilog_t *zilog, dmu_tx_t *tx); extern void zil_destroy(zilog_t *zilog, boolean_t keep_first); +extern void zil_destroy_sync(zilog_t *zilog, dmu_tx_t *tx); extern void zil_rollback_destroy(zilog_t *zilog, dmu_tx_t *tx); extern itx_t *zil_itx_create(uint64_t txtype, size_t lrsize); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil_impl.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil_impl.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil_impl.h Thu Aug 23 19:32:57 2012 (r239620) @@ -20,6 +20,7 @@ */ /* * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012 by Delphix. All rights reserved. */ /* Portions Copyright 2010 Robert Milkowski */ @@ -130,6 +131,7 @@ struct zilog { zil_header_t zl_old_header; /* debugging aid */ uint_t zl_prev_blks[ZIL_PREV_BLKS]; /* size - sector rounded */ uint_t zl_prev_rotor; /* rotor for zl_prev[] */ + txg_node_t zl_dirty_link; /* protected by dp_dirty_zilogs list */ }; typedef struct zil_bp_node { Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c Thu Aug 23 19:32:57 2012 (r239620) @@ -21,6 +21,7 @@ /* * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. * Portions Copyright 2011 Martin Matuska + * Copyright (c) 2012 by Delphix. All rights reserved. */ #include @@ -596,7 +597,7 @@ txg_list_destroy(txg_list_t *tl) mutex_destroy(&tl->tl_lock); } -int +boolean_t txg_list_empty(txg_list_t *tl, uint64_t txg) { return (tl->tl_head[txg & TXG_MASK] == NULL); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c Thu Aug 23 19:32:57 2012 (r239620) @@ -1328,9 +1328,9 @@ vdev_validate(vdev_t *vd, boolean_t stri if (vd->vdev_ops->vdev_op_leaf && vdev_readable(vd)) { uint64_t aux_guid = 0; nvlist_t *nvl; + uint64_t txg = strict ? spa->spa_config_txg : -1ULL; - if ((label = vdev_label_read_config(vd, VDEV_BEST_LABEL)) == - NULL) { + if ((label = vdev_label_read_config(vd, txg)) == NULL) { vdev_set_state(vd, B_TRUE, VDEV_STATE_CANT_OPEN, VDEV_AUX_BAD_LABEL); return (0); @@ -1512,7 +1512,7 @@ vdev_reopen(vdev_t *vd) !l2arc_vdev_present(vd)) l2arc_add_vdev(spa, vd); } else { - (void) vdev_validate(vd, B_TRUE); + (void) vdev_validate(vd, spa_last_synced_txg(spa)); } /* @@ -1971,7 +1971,7 @@ vdev_validate_aux(vdev_t *vd) if (!vdev_readable(vd)) return (0); *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 19:40:08 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 A11001065670 for ; Thu, 23 Aug 2012 19:40:08 +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 84A898FC1B for ; Thu, 23 Aug 2012 19:40:08 +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 q7NJe88P055716 for ; Thu, 23 Aug 2012 19:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7NJe8G4055715; Thu, 23 Aug 2012 19:40:08 GMT (envelope-from gnats) Date: Thu, 23 Aug 2012 19:40:08 GMT Message-Id: <201208231940.q7NJe8G4055715@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/170914: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:40:08 -0000 The following reply was made to PR kern/170914; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/170914: commit references a PR Date: Thu, 23 Aug 2012 19:33:09 +0000 (UTC) Author: mm Date: Thu Aug 23 19:32:57 2012 New Revision: 239620 URL: http://svn.freebsd.org/changeset/base/239620 Log: Merge recent vendor changes: 3086 unnecessarily setting DS_FLAG_INCONSISTENT on async destroyed datasets 3090 vdev_reopen() during reguid causes vdev to be treated as corrupt 3102 vdev_uberblock_load() and vdev_validate() may read the wrong label Referenes: https://www.illumos.org/issues/3086 https://www.illumos.org/issues/3090 https://www.illumos.org/issues/3102 PR: kern/170912, kern/170914 Obtained from: illumos (changeset #13776, #13777) MFC after: 2 weeks Modified: head/cddl/contrib/opensolaris/cmd/ztest/ztest.c head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/txg.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil_impl.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c Directory Properties: head/cddl/contrib/opensolaris/ (props changed) head/cddl/contrib/opensolaris/lib/libzfs/ (props changed) head/sys/cddl/contrib/opensolaris/ (props changed) Modified: head/cddl/contrib/opensolaris/cmd/ztest/ztest.c ============================================================================== --- head/cddl/contrib/opensolaris/cmd/ztest/ztest.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/cddl/contrib/opensolaris/cmd/ztest/ztest.c Thu Aug 23 19:32:57 2012 (r239620) @@ -364,7 +364,7 @@ ztest_info_t ztest_info[] = { { ztest_spa_rename, 1, &zopt_rarely }, { ztest_scrub, 1, &zopt_rarely }, { ztest_dsl_dataset_promote_busy, 1, &zopt_rarely }, - { ztest_vdev_attach_detach, 1, &zopt_rarely }, + { ztest_vdev_attach_detach, 1, &zopt_rarely }, { ztest_vdev_LUN_growth, 1, &zopt_rarely }, { ztest_vdev_add_remove, 1, &ztest_opts.zo_vdevtime }, @@ -415,6 +415,13 @@ static spa_t *ztest_spa = NULL; static ztest_ds_t *ztest_ds; static mutex_t ztest_vdev_lock; + +/* + * The ztest_name_lock protects the pool and dataset namespace used by + * the individual tests. To modify the namespace, consumers must grab + * this lock as writer. Grabbing the lock as reader will ensure that the + * namespace does not change while the lock is held. + */ static rwlock_t ztest_name_lock; static boolean_t ztest_dump_core = B_TRUE; @@ -2225,6 +2232,7 @@ ztest_zil_remount(ztest_ds_t *zd, uint64 { objset_t *os = zd->zd_os; + VERIFY(mutex_lock(&zd->zd_dirobj_lock) == 0); (void) rw_wrlock(&zd->zd_zilog_lock); /* zfsvfs_teardown() */ @@ -2235,6 +2243,7 @@ ztest_zil_remount(ztest_ds_t *zd, uint64 zil_replay(os, zd, ztest_replay_vector); (void) rw_unlock(&zd->zd_zilog_lock); + VERIFY(mutex_unlock(&zd->zd_dirobj_lock) == 0); } /* @@ -4860,10 +4869,16 @@ ztest_reguid(ztest_ds_t *zd, uint64_t id { spa_t *spa = ztest_spa; uint64_t orig, load; + int error; orig = spa_guid(spa); load = spa_load_guid(spa); - if (spa_change_guid(spa) != 0) + + (void) rw_wrlock(&ztest_name_lock); + error = spa_change_guid(spa); + (void) rw_unlock(&ztest_name_lock); + + if (error != 0) return; if (ztest_opts.zo_verbose >= 3) { @@ -5540,8 +5555,15 @@ ztest_freeze(void) */ kernel_init(FREAD | FWRITE); VERIFY3U(0, ==, spa_open(ztest_opts.zo_pool, &spa, FTAG)); + ASSERT(spa_freeze_txg(spa) == UINT64_MAX); VERIFY3U(0, ==, ztest_dataset_open(0)); ztest_dataset_close(0); + + spa->spa_debug = B_TRUE; + ztest_spa = spa; + txg_wait_synced(spa_get_dsl(spa), 0); + ztest_reguid(NULL, 0); + spa_close(spa, FTAG); kernel_fini(); } Modified: head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c ============================================================================== --- head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_import.c Thu Aug 23 19:32:57 2012 (r239620) @@ -21,7 +21,7 @@ /* * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. * Copyright 2011 Nexenta Systems, Inc. All rights reserved. - * Copyright (c) 2011 by Delphix. All rights reserved. + * Copyright (c) 2012 by Delphix. All rights reserved. */ /* @@ -437,8 +437,8 @@ get_configs(libzfs_handle_t *hdl, pool_l uint_t i, nspares, nl2cache; boolean_t config_seen; uint64_t best_txg; - char *name, *hostname, *comment; - uint64_t version, guid; + char *name, *hostname; + uint64_t guid; uint_t children = 0; nvlist_t **child = NULL; uint_t holes; @@ -524,61 +524,54 @@ get_configs(libzfs_handle_t *hdl, pool_l * configuration: * * version - * pool guid - * name + * pool guid + * name + * pool txg (if available) * comment (if available) - * pool state + * pool state * hostid (if available) * hostname (if available) */ - uint64_t state; + uint64_t state, version, pool_txg; + char *comment = NULL; - verify(nvlist_lookup_uint64(tmp, - ZPOOL_CONFIG_VERSION, &version) == 0); - if (nvlist_add_uint64(config, - ZPOOL_CONFIG_VERSION, version) != 0) - goto nomem; - verify(nvlist_lookup_uint64(tmp, - ZPOOL_CONFIG_POOL_GUID, &guid) == 0); - if (nvlist_add_uint64(config, - ZPOOL_CONFIG_POOL_GUID, guid) != 0) - goto nomem; - verify(nvlist_lookup_string(tmp, - ZPOOL_CONFIG_POOL_NAME, &name) == 0); - if (nvlist_add_string(config, - ZPOOL_CONFIG_POOL_NAME, name) != 0) - goto nomem; + version = fnvlist_lookup_uint64(tmp, + ZPOOL_CONFIG_VERSION); + fnvlist_add_uint64(config, + ZPOOL_CONFIG_VERSION, version); + guid = fnvlist_lookup_uint64(tmp, + ZPOOL_CONFIG_POOL_GUID); + fnvlist_add_uint64(config, + ZPOOL_CONFIG_POOL_GUID, guid); + name = fnvlist_lookup_string(tmp, + ZPOOL_CONFIG_POOL_NAME); + fnvlist_add_string(config, + ZPOOL_CONFIG_POOL_NAME, name); - /* - * COMMENT is optional, don't bail if it's not - * there, instead, set it to NULL. - */ - if (nvlist_lookup_string(tmp, - ZPOOL_CONFIG_COMMENT, &comment) != 0) - comment = NULL; - else if (nvlist_add_string(config, - ZPOOL_CONFIG_COMMENT, comment) != 0) - goto nomem; + if (nvlist_lookup_uint64(tmp, + ZPOOL_CONFIG_POOL_TXG, &pool_txg) == 0) + fnvlist_add_uint64(config, + ZPOOL_CONFIG_POOL_TXG, pool_txg); - verify(nvlist_lookup_uint64(tmp, - ZPOOL_CONFIG_POOL_STATE, &state) == 0); - if (nvlist_add_uint64(config, - ZPOOL_CONFIG_POOL_STATE, state) != 0) - goto nomem; + if (nvlist_lookup_string(tmp, + ZPOOL_CONFIG_COMMENT, &comment) == 0) + fnvlist_add_string(config, + ZPOOL_CONFIG_COMMENT, comment); + + state = fnvlist_lookup_uint64(tmp, + ZPOOL_CONFIG_POOL_STATE); + fnvlist_add_uint64(config, + ZPOOL_CONFIG_POOL_STATE, state); hostid = 0; if (nvlist_lookup_uint64(tmp, ZPOOL_CONFIG_HOSTID, &hostid) == 0) { - if (nvlist_add_uint64(config, - ZPOOL_CONFIG_HOSTID, hostid) != 0) - goto nomem; - verify(nvlist_lookup_string(tmp, - ZPOOL_CONFIG_HOSTNAME, - &hostname) == 0); - if (nvlist_add_string(config, - ZPOOL_CONFIG_HOSTNAME, - hostname) != 0) - goto nomem; + fnvlist_add_uint64(config, + ZPOOL_CONFIG_HOSTID, hostid); + hostname = fnvlist_lookup_string(tmp, + ZPOOL_CONFIG_HOSTNAME); + fnvlist_add_string(config, + ZPOOL_CONFIG_HOSTNAME, hostname); } config_seen = B_TRUE; Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c Thu Aug 23 19:32:57 2012 (r239620) @@ -1769,15 +1769,15 @@ dmu_init(void) dnode_init(); dbuf_init(); zfetch_init(); - arc_init(); l2arc_init(); + arc_init(); } void dmu_fini(void) { - l2arc_fini(); arc_fini(); + l2arc_fini(); zfetch_fini(); dbuf_fini(); dnode_fini(); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c Thu Aug 23 19:32:57 2012 (r239620) @@ -1649,13 +1649,6 @@ dmu_recv_existing_end(dmu_recv_cookie_t dsl_dataset_t *ds = drc->drc_logical_ds; int err, myerr; - /* - * XXX hack; seems the ds is still dirty and dsl_pool_zil_clean() - * expects it to have a ds_user_ptr (and zil), but clone_swap() - * can close it. - */ - txg_wait_synced(ds->ds_dir->dd_pool, 0); - if (dsl_dataset_tryown(ds, FALSE, dmu_recv_tag)) { err = dsl_dataset_clone_swap(drc->drc_real_ds, ds, drc->drc_force); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c Thu Aug 23 19:32:57 2012 (r239620) @@ -106,14 +106,8 @@ dsl_dataset_block_born(dsl_dataset_t *ds ASSERT(BP_GET_TYPE(bp) != DMU_OT_NONE); ASSERT(DMU_OT_IS_VALID(BP_GET_TYPE(bp))); if (ds == NULL) { - /* - * Account for the meta-objset space in its placeholder - * dsl_dir. - */ - ASSERT3U(compressed, ==, uncompressed); /* it's all metadata */ - dsl_dir_diduse_space(tx->tx_pool->dp_mos_dir, DD_USED_HEAD, - used, compressed, uncompressed, tx); - dsl_dir_dirty(tx->tx_pool->dp_mos_dir, tx); + dsl_pool_mos_diduse_space(tx->tx_pool, + used, compressed, uncompressed); return; } dmu_buf_will_dirty(ds->ds_dbuf, tx); @@ -149,15 +143,9 @@ dsl_dataset_block_kill(dsl_dataset_t *ds ASSERT(used > 0); if (ds == NULL) { - /* - * Account for the meta-objset space in its placeholder - * dataset. - */ dsl_free(tx->tx_pool, tx->tx_txg, bp); - - dsl_dir_diduse_space(tx->tx_pool->dp_mos_dir, DD_USED_HEAD, - -used, -compressed, -uncompressed, tx); - dsl_dir_dirty(tx->tx_pool->dp_mos_dir, tx); + dsl_pool_mos_diduse_space(tx->tx_pool, + -used, -compressed, -uncompressed); return (used); } ASSERT3P(tx->tx_pool, ==, ds->ds_dir->dd_pool); @@ -1116,26 +1104,26 @@ dsl_dataset_destroy(dsl_dataset_t *ds, v dummy_ds.ds_dir = dd; dummy_ds.ds_object = ds->ds_object; - /* - * Check for errors and mark this ds as inconsistent, in - * case we crash while freeing the objects. - */ - err = dsl_sync_task_do(dd->dd_pool, dsl_dataset_destroy_begin_check, - dsl_dataset_destroy_begin_sync, ds, NULL, 0); - if (err) - goto out; - - err = dmu_objset_from_ds(ds, &os); - if (err) - goto out; - - /* - * If async destruction is not enabled try to remove all objects - * while in the open context so that there is less work to do in - * the syncing context. - */ if (!spa_feature_is_enabled(dsl_dataset_get_spa(ds), &spa_feature_table[SPA_FEATURE_ASYNC_DESTROY])) { + /* + * Check for errors and mark this ds as inconsistent, in + * case we crash while freeing the objects. + */ + err = dsl_sync_task_do(dd->dd_pool, + dsl_dataset_destroy_begin_check, + dsl_dataset_destroy_begin_sync, ds, NULL, 0); + if (err) + goto out; + + err = dmu_objset_from_ds(ds, &os); + if (err) + goto out; + + /* + * Remove all objects while in the open context so that + * there is less work to do in the syncing context. + */ for (obj = 0; err == 0; err = dmu_object_next(os, &obj, FALSE, ds->ds_phys->ds_prev_snap_txg)) { /* @@ -1146,30 +1134,25 @@ dsl_dataset_destroy(dsl_dataset_t *ds, v } if (err != ESRCH) goto out; - } - /* - * Only the ZIL knows how to free log blocks. - */ - zil_destroy(dmu_objset_zil(os), B_FALSE); - - /* - * Sync out all in-flight IO. - */ - txg_wait_synced(dd->dd_pool, 0); - - /* - * If we managed to free all the objects in open - * context, the user space accounting should be zero. - */ - if (ds->ds_phys->ds_bp.blk_fill == 0 && - dmu_objset_userused_enabled(os)) { - uint64_t count; + /* + * Sync out all in-flight IO. + */ + txg_wait_synced(dd->dd_pool, 0); - ASSERT(zap_count(os, DMU_USERUSED_OBJECT, &count) != 0 || - count == 0); - ASSERT(zap_count(os, DMU_GROUPUSED_OBJECT, &count) != 0 || - count == 0); + /* + * If we managed to free all the objects in open + * context, the user space accounting should be zero. + */ + if (ds->ds_phys->ds_bp.blk_fill == 0 && + dmu_objset_userused_enabled(os)) { + uint64_t count; + + ASSERT(zap_count(os, DMU_USERUSED_OBJECT, + &count) != 0 || count == 0); + ASSERT(zap_count(os, DMU_GROUPUSED_OBJECT, + &count) != 0 || count == 0); + } } rw_enter(&dd->dd_pool->dp_config_rwlock, RW_READER); @@ -1906,6 +1889,7 @@ dsl_dataset_destroy_sync(void *arg1, voi } else { zfeature_info_t *async_destroy = &spa_feature_table[SPA_FEATURE_ASYNC_DESTROY]; + objset_t *os; /* * There's no next snapshot, so this is a head dataset. @@ -1917,6 +1901,8 @@ dsl_dataset_destroy_sync(void *arg1, voi dsl_deadlist_free(mos, ds->ds_phys->ds_deadlist_obj, tx); ds->ds_phys->ds_deadlist_obj = 0; + VERIFY3U(0, ==, dmu_objset_from_ds(ds, &os)); + if (!spa_feature_is_enabled(dp->dp_spa, async_destroy)) { err = old_synchronous_dataset_destroy(ds, tx); } else { @@ -1926,12 +1912,12 @@ dsl_dataset_destroy_sync(void *arg1, voi */ uint64_t used, comp, uncomp; - ASSERT(err == 0 || err == EBUSY); + zil_destroy_sync(dmu_objset_zil(os), tx); + if (!spa_feature_is_active(dp->dp_spa, async_destroy)) { spa_feature_incr(dp->dp_spa, async_destroy, tx); - dp->dp_bptree_obj = bptree_alloc( - dp->dp_meta_objset, tx); - VERIFY(zap_add(dp->dp_meta_objset, + dp->dp_bptree_obj = bptree_alloc(mos, tx); + VERIFY(zap_add(mos, DMU_POOL_DIRECTORY_OBJECT, DMU_POOL_BPTREE_OBJ, sizeof (uint64_t), 1, &dp->dp_bptree_obj, tx) == 0); @@ -1944,7 +1930,7 @@ dsl_dataset_destroy_sync(void *arg1, voi ASSERT(!DS_UNIQUE_IS_ACCURATE(ds) || ds->ds_phys->ds_unique_bytes == used); - bptree_add(dp->dp_meta_objset, dp->dp_bptree_obj, + bptree_add(mos, dp->dp_bptree_obj, &ds->ds_phys->ds_bp, ds->ds_phys->ds_prev_snap_txg, used, comp, uncomp, tx); dsl_dir_diduse_space(ds->ds_dir, DD_USED_HEAD, @@ -2233,7 +2219,6 @@ dsl_dataset_sync(dsl_dataset_t *ds, zio_ dmu_buf_will_dirty(ds->ds_dbuf, tx); ds->ds_phys->ds_fsid_guid = ds->ds_fsid_guid; - dsl_dir_dirty(ds->ds_dir, tx); dmu_objset_sync(ds->ds_objset, zio, tx); } Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c Thu Aug 23 19:32:57 2012 (r239620) @@ -195,7 +195,6 @@ errout: kmem_free(dd, sizeof (dsl_dir_t)); dmu_buf_rele(dbuf, tag); return (err); - } void @@ -229,7 +228,7 @@ dsl_dir_name(dsl_dir_t *dd, char *buf) } } -/* Calculate name legnth, avoiding all the strcat calls of dsl_dir_name */ +/* Calculate name length, avoiding all the strcat calls of dsl_dir_name */ int dsl_dir_namelen(dsl_dir_t *dd) { @@ -593,8 +592,6 @@ dsl_dir_sync(dsl_dir_t *dd, dmu_tx_t *tx { ASSERT(dmu_tx_is_syncing(tx)); - dmu_buf_will_dirty(dd->dd_dbuf, tx); - mutex_enter(&dd->dd_lock); ASSERT3U(dd->dd_tempreserved[tx->tx_txg&TXG_MASK], ==, 0); dprintf_dd(dd, "txg=%llu towrite=%lluK\n", tx->tx_txg, @@ -951,8 +948,6 @@ dsl_dir_diduse_space(dsl_dir_t *dd, dd_u ASSERT(dmu_tx_is_syncing(tx)); ASSERT(type < DD_USED_NUM); - dsl_dir_dirty(dd, tx); - if (needlock) mutex_enter(&dd->dd_lock); accounted_delta = parent_delta(dd, dd->dd_phys->dd_used_bytes, used); @@ -961,6 +956,7 @@ dsl_dir_diduse_space(dsl_dir_t *dd, dd_u dd->dd_phys->dd_compressed_bytes >= -compressed); ASSERT(uncompressed >= 0 || dd->dd_phys->dd_uncompressed_bytes >= -uncompressed); + dmu_buf_will_dirty(dd->dd_dbuf, tx); dd->dd_phys->dd_used_bytes += used; dd->dd_phys->dd_uncompressed_bytes += uncompressed; dd->dd_phys->dd_compressed_bytes += compressed; @@ -1002,13 +998,13 @@ dsl_dir_transfer_space(dsl_dir_t *dd, in if (delta == 0 || !(dd->dd_phys->dd_flags & DD_FLAG_USED_BREAKDOWN)) return; - dsl_dir_dirty(dd, tx); if (needlock) mutex_enter(&dd->dd_lock); ASSERT(delta > 0 ? dd->dd_phys->dd_used_breakdown[oldtype] >= delta : dd->dd_phys->dd_used_breakdown[newtype] >= -delta); ASSERT(dd->dd_phys->dd_used_bytes >= ABS(delta)); + dmu_buf_will_dirty(dd->dd_dbuf, tx); dd->dd_phys->dd_used_breakdown[oldtype] -= delta; dd->dd_phys->dd_used_breakdown[newtype] += delta; if (needlock) Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c Thu Aug 23 19:32:57 2012 (r239620) @@ -42,6 +42,7 @@ #include #include #include +#include int zfs_no_write_throttle = 0; int zfs_write_limit_shift = 3; /* 1/8th of physical memory */ @@ -111,12 +112,12 @@ dsl_pool_open_impl(spa_t *spa, uint64_t txg_list_create(&dp->dp_dirty_datasets, offsetof(dsl_dataset_t, ds_dirty_link)); + txg_list_create(&dp->dp_dirty_zilogs, + offsetof(zilog_t, zl_dirty_link)); txg_list_create(&dp->dp_dirty_dirs, offsetof(dsl_dir_t, dd_dirty_link)); txg_list_create(&dp->dp_sync_tasks, offsetof(dsl_sync_task_group_t, dstg_node)); - list_create(&dp->dp_synced_datasets, sizeof (dsl_dataset_t), - offsetof(dsl_dataset_t, ds_synced_link)); mutex_init(&dp->dp_lock, NULL, MUTEX_DEFAULT, NULL); @@ -249,9 +250,9 @@ dsl_pool_close(dsl_pool_t *dp) dmu_objset_evict(dp->dp_meta_objset); txg_list_destroy(&dp->dp_dirty_datasets); + txg_list_destroy(&dp->dp_dirty_zilogs); txg_list_destroy(&dp->dp_sync_tasks); txg_list_destroy(&dp->dp_dirty_dirs); - list_destroy(&dp->dp_synced_datasets); arc_flush(dp->dp_spa); txg_fini(dp); @@ -331,6 +332,21 @@ dsl_pool_create(spa_t *spa, nvlist_t *zp return (dp); } +/* + * Account for the meta-objset space in its placeholder dsl_dir. + */ +void +dsl_pool_mos_diduse_space(dsl_pool_t *dp, + int64_t used, int64_t comp, int64_t uncomp) +{ + ASSERT3U(comp, ==, uncomp); /* it's all metadata */ + mutex_enter(&dp->dp_lock); + dp->dp_mos_used_delta += used; + dp->dp_mos_compressed_delta += comp; + dp->dp_mos_uncompressed_delta += uncomp; + mutex_exit(&dp->dp_lock); +} + static int deadlist_enqueue_cb(void *arg, const blkptr_t *bp, dmu_tx_t *tx) { @@ -349,11 +365,14 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t dmu_tx_t *tx; dsl_dir_t *dd; dsl_dataset_t *ds; - dsl_sync_task_group_t *dstg; objset_t *mos = dp->dp_meta_objset; hrtime_t start, write_time; uint64_t data_written; int err; + list_t synced_datasets; + + list_create(&synced_datasets, sizeof (dsl_dataset_t), + offsetof(dsl_dataset_t, ds_synced_link)); /* * We need to copy dp_space_towrite() before doing @@ -376,7 +395,7 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t * may sync newly-created datasets on pass 2. */ ASSERT(!list_link_active(&ds->ds_synced_link)); - list_insert_tail(&dp->dp_synced_datasets, ds); + list_insert_tail(&synced_datasets, ds); dsl_dataset_sync(ds, zio, tx); } DTRACE_PROBE(pool_sync__1setup); @@ -386,15 +405,20 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t ASSERT(err == 0); DTRACE_PROBE(pool_sync__2rootzio); - for (ds = list_head(&dp->dp_synced_datasets); ds; - ds = list_next(&dp->dp_synced_datasets, ds)) + /* + * After the data blocks have been written (ensured by the zio_wait() + * above), update the user/group space accounting. + */ + for (ds = list_head(&synced_datasets); ds; + ds = list_next(&synced_datasets, ds)) dmu_objset_do_userquota_updates(ds->ds_objset, tx); /* * Sync the datasets again to push out the changes due to * userspace updates. This must be done before we process the - * sync tasks, because that could cause a snapshot of a dataset - * whose ds_bp will be rewritten when we do this 2nd sync. + * sync tasks, so that any snapshots will have the correct + * user accounting information (and we won't get confused + * about which blocks are part of the snapshot). */ zio = zio_root(dp->dp_spa, NULL, NULL, ZIO_FLAG_MUSTSUCCEED); while (ds = txg_list_remove(&dp->dp_dirty_datasets, txg)) { @@ -405,30 +429,42 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t err = zio_wait(zio); /* - * Move dead blocks from the pending deadlist to the on-disk - * deadlist. + * Now that the datasets have been completely synced, we can + * clean up our in-memory structures accumulated while syncing: + * + * - move dead blocks from the pending deadlist to the on-disk deadlist + * - clean up zil records + * - release hold from dsl_dataset_dirty() */ - for (ds = list_head(&dp->dp_synced_datasets); ds; - ds = list_next(&dp->dp_synced_datasets, ds)) { + while (ds = list_remove_head(&synced_datasets)) { + objset_t *os = ds->ds_objset; bplist_iterate(&ds->ds_pending_deadlist, deadlist_enqueue_cb, &ds->ds_deadlist, tx); + ASSERT(!dmu_objset_is_dirty(os, txg)); + dmu_buf_rele(ds->ds_dbuf, ds); } - while (dstg = txg_list_remove(&dp->dp_sync_tasks, txg)) { - /* - * No more sync tasks should have been added while we - * were syncing. - */ - ASSERT(spa_sync_pass(dp->dp_spa) == 1); - dsl_sync_task_group_sync(dstg, tx); - } - DTRACE_PROBE(pool_sync__3task); - start = gethrtime(); while (dd = txg_list_remove(&dp->dp_dirty_dirs, txg)) dsl_dir_sync(dd, tx); write_time += gethrtime() - start; + /* + * The MOS's space is accounted for in the pool/$MOS + * (dp_mos_dir). We can't modify the mos while we're syncing + * it, so we remember the deltas and apply them here. + */ + if (dp->dp_mos_used_delta != 0 || dp->dp_mos_compressed_delta != 0 || + dp->dp_mos_uncompressed_delta != 0) { + dsl_dir_diduse_space(dp->dp_mos_dir, DD_USED_HEAD, + dp->dp_mos_used_delta, + dp->dp_mos_compressed_delta, + dp->dp_mos_uncompressed_delta, tx); + dp->dp_mos_used_delta = 0; + dp->dp_mos_compressed_delta = 0; + dp->dp_mos_uncompressed_delta = 0; + } + start = gethrtime(); if (list_head(&mos->os_dirty_dnodes[txg & TXG_MASK]) != NULL || list_head(&mos->os_free_dnodes[txg & TXG_MASK]) != NULL) { @@ -444,6 +480,27 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t hrtime_t, dp->dp_read_overhead); write_time -= dp->dp_read_overhead; + /* + * If we modify a dataset in the same txg that we want to destroy it, + * its dsl_dir's dd_dbuf will be dirty, and thus have a hold on it. + * dsl_dir_destroy_check() will fail if there are unexpected holds. + * Therefore, we want to sync the MOS (thus syncing the dd_dbuf + * and clearing the hold on it) before we process the sync_tasks. + * The MOS data dirtied by the sync_tasks will be synced on the next + * pass. + */ + DTRACE_PROBE(pool_sync__3task); + if (!txg_list_empty(&dp->dp_sync_tasks, txg)) { + dsl_sync_task_group_t *dstg; + /* + * No more sync tasks should have been added while we + * were syncing. + */ + ASSERT(spa_sync_pass(dp->dp_spa) == 1); + while (dstg = txg_list_remove(&dp->dp_sync_tasks, txg)) + dsl_sync_task_group_sync(dstg, tx); + } + dmu_tx_commit(tx); dp->dp_space_towrite[txg & TXG_MASK] = 0; @@ -492,15 +549,14 @@ dsl_pool_sync(dsl_pool_t *dp, uint64_t t void dsl_pool_sync_done(dsl_pool_t *dp, uint64_t txg) { + zilog_t *zilog; dsl_dataset_t *ds; - objset_t *os; - while (ds = list_head(&dp->dp_synced_datasets)) { - list_remove(&dp->dp_synced_datasets, ds); - os = ds->ds_objset; - zil_clean(os->os_zil, txg); - ASSERT(!dmu_objset_is_dirty(os, txg)); - dmu_buf_rele(ds->ds_dbuf, ds); + while (zilog = txg_list_remove(&dp->dp_dirty_zilogs, txg)) { + ds = dmu_objset_ds(zilog->zl_os); + zil_clean(zilog, txg); + ASSERT(!dmu_objset_is_dirty(zilog->zl_os, txg)); + dmu_buf_rele(ds->ds_dbuf, zilog); } ASSERT(!dmu_objset_is_dirty(dp->dp_meta_objset, txg)); } Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c Thu Aug 23 19:32:57 2012 (r239620) @@ -120,6 +120,8 @@ const zio_taskq_info_t zio_taskqs[ZIO_TY static dsl_syncfunc_t spa_sync_version; static dsl_syncfunc_t spa_sync_props; +static dsl_checkfunc_t spa_change_guid_check; +static dsl_syncfunc_t spa_change_guid_sync; static boolean_t spa_has_active_shared_spare(spa_t *spa); static int spa_load_impl(spa_t *spa, uint64_t, nvlist_t *config, spa_load_state_t state, spa_import_type_t type, boolean_t mosconfig, @@ -683,6 +685,56 @@ spa_prop_clear_bootfs(spa_t *spa, uint64 } } +/*ARGSUSED*/ +static int +spa_change_guid_check(void *arg1, void *arg2, dmu_tx_t *tx) +{ + spa_t *spa = arg1; + uint64_t *newguid = arg2; + vdev_t *rvd = spa->spa_root_vdev; + uint64_t vdev_state; + + spa_config_enter(spa, SCL_STATE, FTAG, RW_READER); + vdev_state = rvd->vdev_state; + spa_config_exit(spa, SCL_STATE, FTAG); + + if (vdev_state != VDEV_STATE_HEALTHY) + return (ENXIO); + + ASSERT3U(spa_guid(spa), !=, *newguid); + + return (0); +} + +static void +spa_change_guid_sync(void *arg1, void *arg2, dmu_tx_t *tx) +{ + spa_t *spa = arg1; + uint64_t *newguid = arg2; + uint64_t oldguid; + vdev_t *rvd = spa->spa_root_vdev; + + oldguid = spa_guid(spa); + + spa_config_enter(spa, SCL_STATE, FTAG, RW_READER); + rvd->vdev_guid = *newguid; + rvd->vdev_guid_sum += (*newguid - oldguid); + vdev_config_dirty(rvd); + spa_config_exit(spa, SCL_STATE, FTAG); + +#ifdef __FreeBSD__ + /* + * TODO: until recent illumos logging changes are merged + * log reguid as pool property change + */ + spa_history_log_internal(LOG_POOL_PROPSET, spa, tx, + "guid change old=%llu new=%llu", oldguid, *newguid); +#else + spa_history_log_internal(spa, "guid change", tx, "old=%lld new=%lld", + oldguid, *newguid); +#endif +} + /* * Change the GUID for the pool. This is done so that we can later * re-import a pool built from a clone of our own vdevs. We will modify @@ -695,29 +747,23 @@ spa_prop_clear_bootfs(spa_t *spa, uint64 int spa_change_guid(spa_t *spa) { - uint64_t oldguid, newguid; - uint64_t txg; - - if (!(spa_mode_global & FWRITE)) - return (EROFS); - - txg = spa_vdev_enter(spa); - - if (spa->spa_root_vdev->vdev_state != VDEV_STATE_HEALTHY) - return (spa_vdev_exit(spa, NULL, txg, ENXIO)); + int error; + uint64_t guid; - oldguid = spa_guid(spa); - newguid = spa_generate_guid(NULL); - ASSERT3U(oldguid, !=, newguid); + mutex_enter(&spa_namespace_lock); + guid = spa_generate_guid(NULL); - spa->spa_root_vdev->vdev_guid = newguid; - spa->spa_root_vdev->vdev_guid_sum += (newguid - oldguid); + error = dsl_sync_task_do(spa_get_dsl(spa), spa_change_guid_check, + spa_change_guid_sync, spa, &guid, 5); - vdev_config_dirty(spa->spa_root_vdev); + if (error == 0) { + spa_config_sync(spa, B_FALSE, B_TRUE); + spa_event_notify(spa, NULL, ESC_ZFS_POOL_REGUID); + } - spa_event_notify(spa, NULL, ESC_ZFS_POOL_REGUID); + mutex_exit(&spa_namespace_lock); - return (spa_vdev_exit(spa, NULL, txg, 0)); + return (error); } /* @@ -6107,6 +6153,9 @@ spa_sync(spa_t *spa, uint64_t txg) rvd->vdev_children, txg, B_TRUE); } + if (error == 0) + spa->spa_last_synced_guid = rvd->vdev_guid; + spa_config_exit(spa, SCL_STATE, FTAG); if (error == 0) Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c Thu Aug 23 19:32:57 2012 (r239620) @@ -1352,16 +1352,29 @@ spa_name(spa_t *spa) uint64_t spa_guid(spa_t *spa) { + dsl_pool_t *dp = spa_get_dsl(spa); + uint64_t guid; + /* * If we fail to parse the config during spa_load(), we can go through * the error path (which posts an ereport) and end up here with no root * vdev. We stash the original pool guid in 'spa_config_guid' to handle * this case. */ - if (spa->spa_root_vdev != NULL) + if (spa->spa_root_vdev == NULL) + return (spa->spa_config_guid); + + guid = spa->spa_last_synced_guid != 0 ? + spa->spa_last_synced_guid : spa->spa_root_vdev->vdev_guid; + + /* + * Return the most recently synced out guid unless we're + * in syncing context. + */ + if (dp && dsl_pool_sync_context(dp)) return (spa->spa_root_vdev->vdev_guid); else - return (spa->spa_config_guid); + return (guid); } uint64_t Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dsl_pool.h Thu Aug 23 19:32:57 2012 (r239620) @@ -82,7 +82,6 @@ typedef struct dsl_pool { /* No lock needed - sync context only */ blkptr_t dp_meta_rootbp; - list_t dp_synced_datasets; hrtime_t dp_read_overhead; uint64_t dp_throughput; /* bytes per millisec */ uint64_t dp_write_limit; @@ -96,10 +95,14 @@ typedef struct dsl_pool { kmutex_t dp_lock; uint64_t dp_space_towrite[TXG_SIZE]; uint64_t dp_tempreserved[TXG_SIZE]; + uint64_t dp_mos_used_delta; + uint64_t dp_mos_compressed_delta; + uint64_t dp_mos_uncompressed_delta; /* Has its own locking */ tx_state_t dp_tx; txg_list_t dp_dirty_datasets; + txg_list_t dp_dirty_zilogs; txg_list_t dp_dirty_dirs; txg_list_t dp_sync_tasks; @@ -139,6 +142,8 @@ int dsl_read_nolock(zio_t *pio, spa_t *s void dsl_pool_create_origin(dsl_pool_t *dp, dmu_tx_t *tx); void dsl_pool_upgrade_clones(dsl_pool_t *dp, dmu_tx_t *tx); void dsl_pool_upgrade_dir_clones(dsl_pool_t *dp, dmu_tx_t *tx); +void dsl_pool_mos_diduse_space(dsl_pool_t *dp, + int64_t used, int64_t comp, int64_t uncomp); taskq_t *dsl_pool_vnrele_taskq(dsl_pool_t *dp); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/spa_impl.h Thu Aug 23 19:32:57 2012 (r239620) @@ -141,6 +141,7 @@ struct spa { vdev_t *spa_root_vdev; /* top-level vdev container */ uint64_t spa_config_guid; /* config pool guid */ uint64_t spa_load_guid; /* spa_load initialized guid */ + uint64_t spa_last_synced_guid; /* last synced guid */ list_t spa_config_dirty_list; /* vdevs with dirty config */ list_t spa_state_dirty_list; /* vdevs with dirty state */ spa_aux_vdev_t spa_spares; /* hot spares */ Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/txg.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/txg.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/txg.h Thu Aug 23 19:32:57 2012 (r239620) @@ -22,6 +22,9 @@ * Copyright 2010 Sun Microsystems, Inc. All rights reserved. * Use is subject to license terms. */ +/* + * Copyright (c) 2012 by Delphix. All rights reserved. + */ #ifndef _SYS_TXG_H #define _SYS_TXG_H @@ -115,7 +118,7 @@ extern boolean_t txg_sync_waiting(struct extern void txg_list_create(txg_list_t *tl, size_t offset); extern void txg_list_destroy(txg_list_t *tl); -extern int txg_list_empty(txg_list_t *tl, uint64_t txg); +extern boolean_t txg_list_empty(txg_list_t *tl, uint64_t txg); extern int txg_list_add(txg_list_t *tl, void *p, uint64_t txg); extern int txg_list_add_tail(txg_list_t *tl, void *p, uint64_t txg); extern void *txg_list_remove(txg_list_t *tl, uint64_t txg); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h Thu Aug 23 19:32:57 2012 (r239620) @@ -142,7 +142,7 @@ extern nvlist_t *vdev_config_generate(sp struct uberblock; extern uint64_t vdev_label_offset(uint64_t psize, int l, uint64_t offset); extern int vdev_label_number(uint64_t psise, uint64_t offset); -extern nvlist_t *vdev_label_read_config(vdev_t *vd, int label); +extern nvlist_t *vdev_label_read_config(vdev_t *vd, uint64_t txg); extern void vdev_uberblock_load(vdev_t *, struct uberblock *, nvlist_t **); typedef enum { Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil.h Thu Aug 23 19:32:57 2012 (r239620) @@ -20,6 +20,7 @@ */ /* * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012 by Delphix. All rights reserved. */ /* Portions Copyright 2010 Robert Milkowski */ @@ -395,6 +396,7 @@ extern void zil_replay(objset_t *os, voi zil_replay_func_t *replay_func[TX_MAX_TYPE]); extern boolean_t zil_replaying(zilog_t *zilog, dmu_tx_t *tx); extern void zil_destroy(zilog_t *zilog, boolean_t keep_first); +extern void zil_destroy_sync(zilog_t *zilog, dmu_tx_t *tx); extern void zil_rollback_destroy(zilog_t *zilog, dmu_tx_t *tx); extern itx_t *zil_itx_create(uint64_t txtype, size_t lrsize); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil_impl.h ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil_impl.h Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zil_impl.h Thu Aug 23 19:32:57 2012 (r239620) @@ -20,6 +20,7 @@ */ /* * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012 by Delphix. All rights reserved. */ /* Portions Copyright 2010 Robert Milkowski */ @@ -130,6 +131,7 @@ struct zilog { zil_header_t zl_old_header; /* debugging aid */ uint_t zl_prev_blks[ZIL_PREV_BLKS]; /* size - sector rounded */ uint_t zl_prev_rotor; /* rotor for zl_prev[] */ + txg_node_t zl_dirty_link; /* protected by dp_dirty_zilogs list */ }; typedef struct zil_bp_node { Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c Thu Aug 23 19:32:57 2012 (r239620) @@ -21,6 +21,7 @@ /* * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. * Portions Copyright 2011 Martin Matuska + * Copyright (c) 2012 by Delphix. All rights reserved. */ #include @@ -596,7 +597,7 @@ txg_list_destroy(txg_list_t *tl) mutex_destroy(&tl->tl_lock); } -int +boolean_t txg_list_empty(txg_list_t *tl, uint64_t txg) { return (tl->tl_head[txg & TXG_MASK] == NULL); Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c Thu Aug 23 18:14:59 2012 (r239619) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c Thu Aug 23 19:32:57 2012 (r239620) @@ -1328,9 +1328,9 @@ vdev_validate(vdev_t *vd, boolean_t stri if (vd->vdev_ops->vdev_op_leaf && vdev_readable(vd)) { uint64_t aux_guid = 0; nvlist_t *nvl; + uint64_t txg = strict ? spa->spa_config_txg : -1ULL; - if ((label = vdev_label_read_config(vd, VDEV_BEST_LABEL)) == - NULL) { + if ((label = vdev_label_read_config(vd, txg)) == NULL) { vdev_set_state(vd, B_TRUE, VDEV_STATE_CANT_OPEN, VDEV_AUX_BAD_LABEL); return (0); @@ -1512,7 +1512,7 @@ vdev_reopen(vdev_t *vd) !l2arc_vdev_present(vd)) l2arc_add_vdev(spa, vd); } else { - (void) vdev_validate(vd, B_TRUE); + (void) vdev_validate(vd, spa_last_synced_txg(spa)); } /* @@ -1971,7 +1971,7 @@ vdev_validate_aux(vdev_t *vd) if (!vdev_readable(vd)) return (0); *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Aug 23 23:17:25 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 8EA031065670; Thu, 23 Aug 2012 23:17:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6269F8FC16; Thu, 23 Aug 2012 23:17:25 +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 q7NNHPLl081477; Thu, 23 Aug 2012 23:17:25 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7NNHPBB081473; Thu, 23 Aug 2012 23:17:25 GMT (envelope-from linimon) Date: Thu, 23 Aug 2012 23:17:25 GMT Message-Id: <201208232317.q7NNHPBB081473@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/170945: [gpt] disk layout not portable between direct connect and USB bridge 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, 23 Aug 2012 23:17:25 -0000 Old Synopsis: disk layout not portable between direct connect and USB bridge New Synopsis: [gpt] disk layout not portable between direct connect and USB bridge Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 23 23:16:39 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=170945 From owner-freebsd-fs@FreeBSD.ORG Fri Aug 24 01:15:31 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 DD798106564A for ; Fri, 24 Aug 2012 01:15:31 +0000 (UTC) (envelope-from trent@snakebite.org) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by mx1.freebsd.org (Postfix) with ESMTP id BBF248FC15 for ; Fri, 24 Aug 2012 01:15:31 +0000 (UTC) Received: from exhub01.exchhosting.com (192.168.11.213) by exhub07.exchhosting.com (192.168.11.103) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 23 Aug 2012 18:15:25 -0700 Received: from localhost (35.8.247.10) by exchange.liveoffice.com (192.168.11.213) with Microsoft SMTP Server id 8.3.213.0; Thu, 23 Aug 2012 18:15:24 -0700 Date: Thu, 23 Aug 2012 21:15:17 -0400 From: Trent Nelson To: Message-ID: <20120824011517.GJ42732@snakebite.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: chmod -h 000x against symlink has bizarre results on ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 01:15:32 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Hi folks, I recently set up a FreeBSD build slave for the Python project, and noticed some symlink tests were failing in a very strange way (http://bugs.python.org/issue15748). When chmod -h 000x is done against a file/link of length less than 24, the target seems to get padded out to 24 with 0s. If it's longer than 24, it'll get truncated. 'x' can be 7, 6, 5 or 4 and the behaviour is the same. Here's the output from the attached test_readlink.sh, also available at http://bugs.python.org/file26979/test_readlink.sh: % ./test_readlink.sh ****** TEST 1: link/target length less than 24 ****** before chmod -h 0007: -rw-r----- /tmp/lt24 lrwxr-x--- /tmp/lt24.lnk->/tmp/lt24 python os.readlink(/tmp/lt24.lnk): '/tmp/lt24' after chmod -h 0007: -rw-r----- /tmp/lt24 l------rwx /tmp/lt24.lnk->/tmp/lt24 python os.readlink(/tmp/lt24.lnk): '/tmp/lt24\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ target is padded out with NULLs to 24 ****** TEST 2: link/target length longer than 24 ****** before chmod -h 0007: -rw-r----- /tmp/definitelywaylongerthantwentyfour lrwxr-x--- /tmp/definitelywaylongerthantwentyfour.lnk->/tmp/definitelywaylongerthantwentyfour python os.readlink(/tmp/definitelywaylongerthantwentyfour.lnk): '/tmp/definitelywaylongerthantwentyfour' after chmod -h 0007: -rw-r----- /tmp/definitelywaylongerthantwentyfour l------rwx /tmp/definitelywaylongerthantwentyfour.lnk->/tmp/definitelywaylonger python os.readlink(/tmp/definitelywaylongerthantwentyfour.lnk): '/tmp/definitelywaylonger' ^^^^^^^^^^^^^^^^^^^^^^^^ target gets truncated to 24 ****** Other modes... ****** after chmod -h 0006: l------rw- /tmp/definitelywaylongerthantwentyfour.lnk->/tmp/definitelywaylonger after chmod -h 0005: l------r-x /tmp/definitelywaylongerthantwentyfour.lnk->/tmp/definitelywaylonger after chmod -h 0004: l------r-- /tmp/definitelywaylongerthantwentyfour.lnk->/tmp/definitelywaylonger after chmod -h 0000: l--------- /tmp/definitelywaylongerthantwentyfour.lnk->/tmp/definitelywaylongerthantwentyfour This only happens on ZFS. I'm on v28, don't have any v15s lying around. I'm perplexed. Can others reproduce it? Regards, Trent. --3V7upXqbjpZ4EhLz-- From owner-freebsd-fs@FreeBSD.ORG Fri Aug 24 07:43: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 88C2B106566B for ; Fri, 24 Aug 2012 07:43:12 +0000 (UTC) (envelope-from trent@snakebite.org) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4008FC08 for ; Fri, 24 Aug 2012 07:43:12 +0000 (UTC) Received: from EXHUB02.exchhosting.com (192.168.11.214) by exhub06.exchhosting.com (192.168.11.102) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 24 Aug 2012 00:43:11 -0700 Received: from localhost (35.8.247.10) by exchange.liveoffice.com (192.168.11.214) with Microsoft SMTP Server id 8.3.213.0; Fri, 24 Aug 2012 00:43:10 -0700 Date: Fri, 24 Aug 2012 03:43:10 -0400 From: Trent Nelson To: "freebsd-fs@freebsd.org" Message-ID: <20120824074309.GC93736@snakebite.org> References: <20120824011517.GJ42732@snakebite.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20120824011517.GJ42732@snakebite.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: chmod -h 000x against symlink has bizarre results on ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 07:43:12 -0000 On Thu, Aug 23, 2012 at 06:15:17PM -0700, Trent Nelson wrote: > Here's the output from the attached test_readlink.sh, also available > at http://bugs.python.org/file26979/test_readlink.sh: Looks like the attachment got stripped. I've pasted it below. Trent. -- test_readlink.sh -- #!/bin/sh # If /tmp isn't backed by a ZFS file system, change it to something that is. _base=/tmp if [ -z "$(zfs list -H -o mountpoint | grep ^$_base)" ]; then echo error: \'$_base\' is not backed by ZFS exit 1 fi _python=$(which python 2> /dev/null) _test() { local _file _symlink _py _file=$1 _mode=$2 if [ -z "$_mode" ]; then _mode=0007 fi _symlink=$_file.lnk _py="import os; print(repr(os.readlink('$_symlink')))" rm -rf $_file $_symlink echo file > $_file ln -s $_file $_symlink echo before chmod -h $_mode: ls -l $_file | awk '{ print $1 " " $9 };' ls -l $_symlink | awk '{ print $1 " " $9 $10 $11 };' if [ -f "$_python" ]; then echo "python os.readlink($_symlink): " eval "$_python" -c \""$_py"\" fi chmod -h $_mode $_symlink echo after chmod -h $_mode: ls -l $_file | awk '{ print $1 " " $9 };' ls -l $_symlink | awk '{ print $1 " " $9 $10 $11 };' if [ -f "$_python" ]; then echo "python os.readlink($_symlink): " eval "$_python" -c \""$_py"\" fi } _quick_test() { local _file _symlink _file=$1 _mode=$2 if [ -z "$_mode" ]; then _mode=0007 fi _symlink=$_file.lnk rm -rf $_file $_symlink echo file > $_file ln -s $_file $_symlink chmod -h $_mode $_symlink echo after chmod -h $_mode: ls -l $_symlink | awk '{ print $1 " " $9 $10 $11 };' } echo echo "****** TEST 1: link/target length less than 24 ******" _test $_base/lt24 echo " ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^" echo "target is padded out with NULLs to 24" echo; echo for _ in 1 2 ; do echo; done echo "****** TEST 2: link/target length longer than 24 ******" _test $_base/definitelywaylongerthantwentyfour echo " ^^^^^^^^^^^^^^^^^^^^^^^^" echo "target gets truncated to 24" echo; echo echo echo "****** Other modes... ******" _quick_test $_base/definitelywaylongerthantwentyfour 0006 _quick_test $_base/definitelywaylongerthantwentyfour 0005 _quick_test $_base/definitelywaylongerthantwentyfour 0004 _quick_test $_base/definitelywaylongerthantwentyfour 0000 echo; echo # vim:set ts=8 sw=4 sts=4 tw=78 et: From owner-freebsd-fs@FreeBSD.ORG Fri Aug 24 11:30:39 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 88A75106566B for ; Fri, 24 Aug 2012 11:30:39 +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 5A8698FC16 for ; Fri, 24 Aug 2012 11:30:39 +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 q7OBUceS001224 for ; Fri, 24 Aug 2012 11:30:39 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7OBUa24001103; Fri, 24 Aug 2012 11:30:37 GMT (envelope-from gnats) Date: Fri, 24 Aug 2012 11:30:37 GMT Message-Id: <201208241130.q7OBUa24001103@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Andrey V. Elsukov" Cc: Subject: Re: kern/170945: [gpt] disk layout not portable between direct connect and USB bridge X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Andrey V. Elsukov" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 11:30:39 -0000 The following reply was made to PR kern/170945; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-followup@FreeBSD.org, freebsd@sopwith.solgatos.com Cc: Subject: Re: kern/170945: [gpt] disk layout not portable between direct connect and USB bridge Date: Fri, 24 Aug 2012 15:29:04 +0400 Hi, GPT uses logical block addresses, not bytes. So, if you changed sector size, then you lose the access to the GPT. If you want get access to GPT, that has been created on the device with 4k sized sector, then you can use geom_nop(4). -- WBR, Andrey V. Elsukov From owner-freebsd-fs@FreeBSD.ORG Fri Aug 24 11:33:53 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85336106566C; Fri, 24 Aug 2012 11:33:53 +0000 (UTC) (envelope-from cheeky.m@live.com) Received: from bay0-omc1-s15.bay0.hotmail.com (bay0-omc1-s15.bay0.hotmail.com [65.54.190.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6528FC08; Fri, 24 Aug 2012 11:33:53 +0000 (UTC) Received: from BAY170-W113 ([65.54.190.60]) by bay0-omc1-s15.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Aug 2012 04:32:47 -0700 Message-ID: X-Originating-IP: [209.6.82.6] From: Roger Hammerstein To: Date: Fri, 24 Aug 2012 07:32:47 -0400 Importance: Normal In-Reply-To: <50365D73.9020508@FreeBSD.org> References: , <5034DA84.8050507@FreeBSD.org>, , <5035E335.4010103@FreeBSD.org>, , <50363F14.5080703@FreeBSD.org>, , <50365134.9080702@FreeBSD.org>, , <50365D73.9020508@FreeBSD.org> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Aug 2012 11:32:47.0555 (UTC) FILETIME=[2FAA0930:01CD81EC] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: RE: panic while zfs scrubbing 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, 24 Aug 2012 11:33:53 -0000 > Thank you for this data. > Please see if the following patch may help you. >=20 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c > @@ -801=2C7 +801=2C7 @@ dsl_scan_visitbp(blkptr_t *bp=2C const zbookmark_= t *zb=2C > if (dsl_scan_check_resume(scn=2C dnp=2C zb)) > return=3B >=20 > - if (bp->blk_birth =3D=3D 0) > + if (bp->blk_birth =3D=3D 0 || BP_GET_TYPE(bp) =3D=3D DMU_OT_NONE) > return=3B >=20 > scn->scn_visited_this_txg++=3B it worked to get through an entire scrub. zpool status -v zzzz pool: zzzz state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: scrub repaired 135K in 3h46m with 4 errors on Thu Aug 23 17:14:50 2= 012 config: NAME STATE READ WRITE CKSUM zzzz ONLINE 0 0 4 raidz2-0 ONLINE 0 0 8 ada3 ONLINE 0 0 0 ada7 ONLINE 0 0 4 ada6 ONLINE 0 0 0 ada9 ONLINE 0 0 0 ada4 ONLINE 0 0 0 ada2 ONLINE 0 0 2 ada5 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: I started a second scrub. = From owner-freebsd-fs@FreeBSD.ORG Sat Aug 25 15:46:55 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 56C6D1065670 for ; Sat, 25 Aug 2012 15:46:55 +0000 (UTC) (envelope-from antonintessier@live.fr) Received: from dub0-omc4-s24.dub0.hotmail.com (dub0-omc4-s24.dub0.hotmail.com [157.55.2.99]) by mx1.freebsd.org (Postfix) with ESMTP id E591C8FC1C for ; Sat, 25 Aug 2012 15:46:54 +0000 (UTC) Received: from DUB109-W58 ([157.55.2.73]) by dub0-omc4-s24.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Aug 2012 08:45:45 -0700 Message-ID: X-Originating-IP: [93.182.219.16] From: antonin tessier To: Date: Sat, 25 Aug 2012 17:45:46 +0200 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 25 Aug 2012 15:45:45.0581 (UTC) FILETIME=[B0E2C1D0:01CD82D8] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Recover ZFS pool after having deleted zfs configuration file in /boot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 15:46:55 -0000 Hello=2C When I try to create a zpool with "zpool create home /dev/ada0p7"=2C I get = this error "/dev/ada0p7 is part of potentially active pool 'home'. But "zpo= ol list" tells me no pool exists. That issue is very disturbing since /dev/= ada0p7 was mounted as /usr/home=2C so I can't get my data back... Thank you for your time=2C Gollum=20 = From owner-freebsd-fs@FreeBSD.ORG Sat Aug 25 16:08:42 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDAD71065670 for ; Sat, 25 Aug 2012 16:08:42 +0000 (UTC) (envelope-from artemb@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 5AF948FC1A for ; Sat, 25 Aug 2012 16:08:41 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so2025814lbb.13 for ; Sat, 25 Aug 2012 09:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gQM85xPWtlSzcwjFMa+bzm2YXap2UQp6LxswwQrjmiM=; b=Tkmmxr7XzJuNhwpcDVsI/nxMbC4dzPyQC99eVYc6TV7TXdjP2BoqkioG1CUH2yqGqU UAbBk0te6ZIrPIFtBgeE2RQUMefTyKzKwHIuymeUN56LydupbQHE+do3/zN66blrX+zx TdHki5iYgqF4g2hECHRr4tiW/B75Qnlle3RwK6OEZtsuly4ZmmZQ3vvXbTWhDFRT+6y1 l35Sz9/qZUFqsHiMs6bk8MxY4QK7CvIRNqY5rUgounszOOprTI45xl4vqDmrCVdYMtjF ICevJntsTlTOaC0BimT44o+DNQKDJ4Fz3Hj0Qy6C0Ekg/QCIyckp3vGqT/Frch45NIH5 sGew== MIME-Version: 1.0 Received: by 10.152.125.133 with SMTP id mq5mr9196580lab.12.1345910920865; Sat, 25 Aug 2012 09:08:40 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.112.23.164 with HTTP; Sat, 25 Aug 2012 09:08:40 -0700 (PDT) In-Reply-To: References: Date: Sat, 25 Aug 2012 09:08:40 -0700 X-Google-Sender-Auth: 14lGPD4c5QF9Pm64vwEI3PyyJ2Q Message-ID: From: Artem Belevich To: antonin tessier Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Recover ZFS pool after having deleted zfs configuration file in /boot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 16:08:43 -0000 > When I try to create a zpool with "zpool create home /dev/ada0p7", I get this error "/dev/ada0p7 is part of potentially active pool 'home'. ZFS had just saved your data from your attempt to destroy it. > But "zpool list" tells me no pool exists. That issue is very disturbing since /dev/ada0p7 was mounted as /usr/home, so I can't get my data back... try "zfs import" and see if it finds your pool. If it does, do 'zfs import home' and zfs should make your pool available again. --Artem From owner-freebsd-fs@FreeBSD.ORG Sat Aug 25 17:22:17 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 A049E106564A for ; Sat, 25 Aug 2012 17:22:17 +0000 (UTC) (envelope-from antonintessier@live.fr) Received: from dub0-omc4-s33.dub0.hotmail.com (dub0-omc4-s33.dub0.hotmail.com [157.55.2.108]) by mx1.freebsd.org (Postfix) with ESMTP id 36EE18FC12 for ; Sat, 25 Aug 2012 17:22:16 +0000 (UTC) Received: from DUB109-W39 ([157.55.2.72]) by dub0-omc4-s33.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Aug 2012 10:21:09 -0700 Message-ID: X-Originating-IP: [93.182.219.16] From: antonin tessier To: Date: Sat, 25 Aug 2012 19:21:09 +0200 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 25 Aug 2012 17:21:09.0684 (UTC) FILETIME=[04B78F40:01CD82E6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Recover ZFS pool after having deleted zfs configuration file in /boot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 17:22:17 -0000 > try "zfs import" and see if it finds your pool. If it does=2C do 'zfs import home' and zfs should make your pool available again. You obviously meant "zpool import"=2C but this don't find my pool... = From owner-freebsd-fs@FreeBSD.ORG Sat Aug 25 17:41:36 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 6317F106564A for ; Sat, 25 Aug 2012 17:41:36 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews01.kpnxchange.com (cpsmtpb-ews01.kpnxchange.com [213.75.39.4]) by mx1.freebsd.org (Postfix) with ESMTP id DF53F8FC14 for ; Sat, 25 Aug 2012 17:41:35 +0000 (UTC) Received: from cpsps-ews02.kpnxchange.com ([10.94.84.169]) by cpsmtpb-ews01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Aug 2012 19:40:28 +0200 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews02.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 25 Aug 2012 19:40:28 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 25 Aug 2012 19:40:28 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 512AB2202 for ; Sat, 25 Aug 2012 19:40:27 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: Date: Sat, 25 Aug 2012 19:40:26 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.01 (FreeBSD) X-OriginalArrivalTime: 25 Aug 2012 17:40:28.0623 (UTC) FILETIME=[B77F9DF0:01CD82E8] Subject: Re: Recover ZFS pool after having deleted zfs configuration file in /boot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 17:41:36 -0000 On Sat, 25 Aug 2012 19:21:09 +0200, antonin tessier wrote: > >> try "zfs import" and see if it finds your pool. If it does, do 'zfs > import home' and zfs should make your pool available again. > > You obviously meant "zpool import", but this don't find my pool... > _______________________________________________ > 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" > Or try 'zpool import -D'. -D Lists destroyed pools only. It can help if you mail the output from the commands you run. That might give other people clues you don't recognize. Regards, Ronald.