From owner-freebsd-fs@FreeBSD.ORG Sun Dec 9 17:24:45 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C56EE78A; Sun, 9 Dec 2012 17:24:45 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8ED1C8FC14; Sun, 9 Dec 2012 17:24:45 +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 qB9HOjl8097607; Sun, 9 Dec 2012 17:24:45 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qB9HOjVc097603; Sun, 9 Dec 2012 17:24:45 GMT (envelope-from linimon) Date: Sun, 9 Dec 2012 17:24:45 GMT Message-Id: <201212091724.qB9HOjVc097603@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174264: [zfs] ZFS can only set 121 ACL's instead of 1024 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 17:24:45 -0000 Old Synopsis: ZFS can only set 121 ACL's instead of 1024 New Synopsis: [zfs] ZFS can only set 121 ACL's instead of 1024 Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Dec 9 17:24:30 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=174264 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 10 01:14:44 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F76865D; Mon, 10 Dec 2012 01:14:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4C6908FC08; Mon, 10 Dec 2012 01:14:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBA1Ei6J022532; Mon, 10 Dec 2012 01:14:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBA1EiPN022528; Mon, 10 Dec 2012 01:14:44 GMT (envelope-from linimon) Date: Mon, 10 Dec 2012 01:14:44 GMT Message-Id: <201212100114.qBA1EiPN022528@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174310: [zfs] root point mounting broken on CURRENT with multiple pools X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 01:14:44 -0000 Synopsis: [zfs] root point mounting broken on CURRENT with multiple pools Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 10 01:13:55 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=174310 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 10 04:42:27 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 AB69789F for ; Mon, 10 Dec 2012 04:42:27 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED548FC13 for ; Mon, 10 Dec 2012 04:42:26 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so2099902lah.13 for ; Sun, 09 Dec 2012 20:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0zdEFE/m7GprczwdGf9SEwLc7mEY0sQslEmx3Brsaks=; b=TyfO1ZknlmS8IN9UcAhhK2xZQQbQy26piOAq4BJMiSxs3j0+au2laka3fKOBXnFxfw umCVuN4053UrCJ/+aOLoiOPlLK7f2QkXd1HgYKJpp+HtYA4WjzCf6YdnLZUD3p9i3/dv +AkS2Kc4sewq6hBwXb1ledx/iWW/00Om7jiKs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=0zdEFE/m7GprczwdGf9SEwLc7mEY0sQslEmx3Brsaks=; b=N8ISQwFnwl22ySXrlcWG1iH7GKbENnmwTjLIrakhusZs+o7omAbMKmNpUJpTchzC57 5D53W9WLVS9JwJekNpCQPlwNZmgl+UvPQvRp6cF+LDOeWEV8rhbeegP3lZpZdNB+ISEY 7fLfnAy37OWf3/DEsJ96MKareuaRQsllEqPsdQtkk6Y7RvF3QMSHbJQcKSODiAhn1f6z pW6cFGHh/LO48T8dIVz9s6rfPvKf6lvW8HN0gEI1JcjC2We7bAKpHfDAsQPOOusJmbDU s9lbL+8uZ1mZ74uf3Myv+wAkSdPaXv1Z0nX7DOyJhSMg3aZHiXmIq0SlS8OQDcRHz7aX Fviw== Received: by 10.152.145.162 with SMTP id sv2mr4226134lab.41.1355114545839; Sun, 09 Dec 2012 20:42:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.43.229 with HTTP; Sun, 9 Dec 2012 20:41:55 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Sun, 9 Dec 2012 23:41:55 -0500 Message-ID: Subject: Re: GELI on USB To: Ali Mashtizadeh Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQksPcGvjGQWZxl6XMfB+IjGbKvwi+Hy3dHzenxCygdK/i7z9XzhECwyRmTCsHIysUYbBQDX Cc: freebsd-fs@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 04:42:27 -0000 On 5 December 2012 04:54, Ali Mashtizadeh wrote: > I think I found a possible bug in 9.1 where I configured an encrypted > root partition on a USB key and I have trouble entering the password > from what seems like a race. Could you please submit a PR about this so it doesn't get lost in the archives of the mailing list? -- Eitan Adler From owner-freebsd-fs@FreeBSD.ORG Mon Dec 10 07:20:22 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2505D953; Mon, 10 Dec 2012 07:20:22 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E40258FC0C; Mon, 10 Dec 2012 07:20:21 +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 qBA7KLpJ048987; Mon, 10 Dec 2012 07:20:21 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBA7KL1m048983; Mon, 10 Dec 2012 07:20:21 GMT (envelope-from linimon) Date: Mon, 10 Dec 2012 07:20:21 GMT Message-Id: <201212100720.qBA7KL1m048983@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174315: [zfs] chflags uchg not supported X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 07:20:22 -0000 Synopsis: [zfs] chflags uchg not supported Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 10 07:20:06 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=174315 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 10 10:52:00 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1267A0F; Mon, 10 Dec 2012 10:52:00 +0000 (UTC) (envelope-from trasz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id AAF708FC0C; Mon, 10 Dec 2012 10:52:00 +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 qBAAq0rX062777; Mon, 10 Dec 2012 10:52:00 GMT (envelope-from trasz@freefall.freebsd.org) Received: (from trasz@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBAAq0kq062773; Mon, 10 Dec 2012 10:52:00 GMT (envelope-from trasz) Date: Mon, 10 Dec 2012 10:52:00 GMT Message-Id: <201212101052.qBAAq0kq062773@freefall.freebsd.org> To: trasz@FreeBSD.org, freebsd-fs@FreeBSD.org, trasz@FreeBSD.org From: trasz@FreeBSD.org Subject: Re: kern/174264: [zfs] ZFS can only set 121 ACL's instead of 1024 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 10:52:00 -0000 Synopsis: [zfs] ZFS can only set 121 ACL's instead of 1024 Responsible-Changed-From-To: freebsd-fs->trasz Responsible-Changed-By: trasz Responsible-Changed-When: Mon Dec 10 10:52:00 UTC 2012 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=174264 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 10 11:06:43 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 50553EF3 for ; Mon, 10 Dec 2012 11:06:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 31C768FC18 for ; Mon, 10 Dec 2012 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBAB6hdB064220 for ; Mon, 10 Dec 2012 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBAB6gQ4064218 for freebsd-fs@FreeBSD.org; Mon, 10 Dec 2012 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Dec 2012 11:06:42 GMT Message-Id: <201212101106.qBAB6gQ4064218@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 11:06:43 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/174060 fs [ext2fs] Ext2FS system crashes (buffer overflow?) o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool o kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173234 fs [zfs] [patch] Allow filtering of properties on zfs rec o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/172259 fs [zfs] [patch] ZFS fails to receive valid snapshots (pa o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165923 fs [nfs] Writing to NFS-backed mmapped files fails if flu o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o conf/144213 fs [rc.d] [patch] Disappearing zvols on reboot o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 296 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Dec 10 19:39:02 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A74E4A5 for ; Mon, 10 Dec 2012 19:39:02 +0000 (UTC) (envelope-from lists@hurricane-ridge.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B9A668FC1A for ; Mon, 10 Dec 2012 19:39:01 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo14so3743406vcb.13 for ; Mon, 10 Dec 2012 11:38:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=GQ53HxXJB5HBIhD4bCa/bsTsSnIGWo2juuFTwQXLLuo=; b=cCMpLnHIjrX/+tWj7hfIjBTete98oWYKbzAaRQMxhlQBRL2rBnpIHQfiRWL1c2cRJS nnwq/TQY8VritwR2m9FSGWllsHMV5dqsXo+DaDF0CmOo6pVGAu1/e31l+NsxtAfUChmq elpTK/x4hoDhmeexLL7VaI542lY9jPNhmRmHenw9RXPEOh1H0gNsP/YIn4OgAO0clGK5 aT12ve95CjYgNAhvaijYcheCYxH+RobEAoB4ptecJAB7weLGTilFHYVFrCuXn1D51ue6 OaY4DwYlU+wfwMAmxWrYB7SJECX2KCsl0PUpHRXfvGQpWGKwGsNtT81hdD5hj6S/KUSz xLYQ== MIME-Version: 1.0 Received: by 10.52.35.20 with SMTP id d20mr8400470vdj.50.1355168335581; Mon, 10 Dec 2012 11:38:55 -0800 (PST) Received: by 10.58.38.138 with HTTP; Mon, 10 Dec 2012 11:38:55 -0800 (PST) X-Originating-IP: [209.124.184.194] Date: Mon, 10 Dec 2012 11:38:55 -0800 Message-ID: Subject: ZFS mirrored separate log device replacement scans entire pool? From: Andrew Leonard To: freebsd-fs@freebsd.org X-Gm-Message-State: ALoCoQljkiheBVsQKEN4YLhpQP7wHS8FIrl8Xtbm3WqTvXiB5WEnwY5750has1aljc8gv7RQ7+KG Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 19:39:02 -0000 This is likely more of a curiosity than an issue, unless it indicates I did something wrong: Why does replacing half of a mirrored ZFS separate log cause the entire zpool to be scanned? To wit: > zpool status pool: tank01 state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Mon Dec 10 11:15:49 2012 7.54T scanned out of 27.0T at 3.12G/s, 1h46m to go 0 resilvered, 27.93% done config: NAME STATE READ WRITE CKSUM tank01 DEGRADED 0 0 0 raidz2-0 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 da6 ONLINE 0 0 0 da7 ONLINE 0 0 0 da8 ONLINE 0 0 0 da9 ONLINE 0 0 0 da10 ONLINE 0 0 0 da11 ONLINE 0 0 0 raidz2-1 ONLINE 0 0 0 da12 ONLINE 0 0 0 da13 ONLINE 0 0 0 da14 ONLINE 0 0 0 da15 ONLINE 0 0 0 da16 ONLINE 0 0 0 da17 ONLINE 0 0 0 da18 ONLINE 0 0 0 da19 ONLINE 0 0 0 da20 ONLINE 0 0 0 da21 ONLINE 0 0 0 raidz2-2 ONLINE 0 0 0 da22 ONLINE 0 0 0 da23 ONLINE 0 0 0 da24 ONLINE 0 0 0 da32 ONLINE 0 0 0 da26 ONLINE 0 0 0 da27 ONLINE 0 0 0 da33 ONLINE 0 0 0 da29 ONLINE 0 0 0 da30 ONLINE 0 0 0 da31 ONLINE 0 0 0 logs mirror-3 DEGRADED 0 0 0 da34 ONLINE 0 0 0 replacing-1 OFFLINE 0 0 0 1754652639903581713 OFFLINE 0 0 0 was /dev/da35 da25 ONLINE 0 0 0 errors: No known data errors > zpool get version tank01 NAME PROPERTY VALUE SOURCE tank01 version 28 default > zfs get version tank01 NAME PROPERTY VALUE SOURCE tank01 version 5 - > uname -a FreeBSD zfs12.sbri.org 8.3-STABLE FreeBSD 8.3-STABLE #0: Sun Aug 12 07:31:24 PDT 2012 root@zfs12.sbri.org:/usr/obj/usr/src/sys/GENERIC amd64 Thanks, Andy From owner-freebsd-fs@FreeBSD.ORG Mon Dec 10 21:30:02 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95E964BE for ; Mon, 10 Dec 2012 21:30:02 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6C38FC13 for ; Mon, 10 Dec 2012 21:30:01 +0000 (UTC) Received: from conversation.bsdunix.ch (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id DB4DC12AA2; Mon, 10 Dec 2012 21:20:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by conversation.bsdunix.ch (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-8_WUfgqMU2; Mon, 10 Dec 2012 21:20:46 +0000 (UTC) Received: from toms-saftbook.home (177-185.107-92.cust.bluewin.ch [92.107.185.177]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTPSA id 189CE12A9E; Mon, 10 Dec 2012 21:20:46 +0000 (UTC) Message-ID: <50C6522D.6080808@bsdunix.ch> Date: Mon, 10 Dec 2012 22:20:45 +0100 From: Tom User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: ZFS mirrored separate log device replacement scans entire pool? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 21:30:02 -0000 Hi Andrew Use remove and add for log devices instead of replace. This prevents the pool from resilvering and takes only a couple of seconds. Regards, Tom Am 10.12.12 20:38, schrieb Andrew Leonard: > This is likely more of a curiosity than an issue, unless it indicates I did > something wrong: Why does replacing half of a mirrored ZFS separate log > cause the entire zpool to be scanned? To wit: > >> zpool status > pool: tank01 > state: DEGRADED > status: One or more devices is currently being resilvered. The pool will > continue to function, possibly in a degraded state. > action: Wait for the resilver to complete. > scan: resilver in progress since Mon Dec 10 11:15:49 2012 > 7.54T scanned out of 27.0T at 3.12G/s, 1h46m to go > 0 resilvered, 27.93% done > config: > > NAME STATE READ WRITE CKSUM > tank01 DEGRADED 0 0 0 > raidz2-0 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > da4 ONLINE 0 0 0 > da5 ONLINE 0 0 0 > da6 ONLINE 0 0 0 > da7 ONLINE 0 0 0 > da8 ONLINE 0 0 0 > da9 ONLINE 0 0 0 > da10 ONLINE 0 0 0 > da11 ONLINE 0 0 0 > raidz2-1 ONLINE 0 0 0 > da12 ONLINE 0 0 0 > da13 ONLINE 0 0 0 > da14 ONLINE 0 0 0 > da15 ONLINE 0 0 0 > da16 ONLINE 0 0 0 > da17 ONLINE 0 0 0 > da18 ONLINE 0 0 0 > da19 ONLINE 0 0 0 > da20 ONLINE 0 0 0 > da21 ONLINE 0 0 0 > raidz2-2 ONLINE 0 0 0 > da22 ONLINE 0 0 0 > da23 ONLINE 0 0 0 > da24 ONLINE 0 0 0 > da32 ONLINE 0 0 0 > da26 ONLINE 0 0 0 > da27 ONLINE 0 0 0 > da33 ONLINE 0 0 0 > da29 ONLINE 0 0 0 > da30 ONLINE 0 0 0 > da31 ONLINE 0 0 0 > logs > mirror-3 DEGRADED 0 0 0 > da34 ONLINE 0 0 0 > replacing-1 OFFLINE 0 0 0 > 1754652639903581713 OFFLINE 0 0 0 was /dev/da35 > da25 ONLINE 0 0 0 > > errors: No known data errors >> zpool get version tank01 > NAME PROPERTY VALUE SOURCE > tank01 version 28 default >> zfs get version tank01 > NAME PROPERTY VALUE SOURCE > tank01 version 5 - >> uname -a > FreeBSD zfs12.sbri.org 8.3-STABLE FreeBSD 8.3-STABLE #0: Sun Aug 12 > 07:31:24 PDT 2012 root@zfs12.sbri.org:/usr/obj/usr/src/sys/GENERIC > amd64 > > Thanks, > Andy > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Tue Dec 11 01:34: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 9047793D for ; Tue, 11 Dec 2012 01:34:56 +0000 (UTC) (envelope-from danila.casciola@skytv.it) Received: from sd-36302.dedibox.fr (mail.gaybak.com [88.190.41.174]) by mx1.freebsd.org (Postfix) with ESMTP id D19188FC0C for ; Tue, 11 Dec 2012 01:34:54 +0000 (UTC) Received: from [88.190.41.174] by sd-36302.dedibox.fr id VdImCL3ouvCB with SMTP; Tue, 11 Dec 2012 02:34:54 +0100 Date: Tue, 11 Dec 2012 02:34:54 +0100 From: "Antonia" X-Mailer: The Bat! (v4.4.63.5) Educational X-Priority: 3 (Normal) Message-ID: <027039331.44907720700621@sd-36302.dedibox.fr> To: Subject: Fwd: Il tuo ordine viene elaborato MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 01:34:56 -0000 Il tuo ordine viene elaborato, vedere il risultato del profilo a: http://ajutorpc.ro/Richiesta.zip?_id_freebsd-fs@freebsd.org == Tel.: (956) 840 33 579 From owner-freebsd-fs@FreeBSD.ORG Tue Dec 11 02:32:27 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 40DEF3E0 for ; Tue, 11 Dec 2012 02:32:27 +0000 (UTC) (envelope-from giovanna.bianchi@sfera.rcs.it) Received: from sd-36302.dedibox.fr (mail.gaybak.com [88.190.41.174]) by mx1.freebsd.org (Postfix) with ESMTP id 968228FC0C for ; Tue, 11 Dec 2012 02:32:25 +0000 (UTC) Received: from [88.190.41.174] by sd-36302.dedibox.fr id J8m8gYbdWm7z with SMTP; Tue, 11 Dec 2012 03:32:25 +0100 Date: Tue, 11 Dec 2012 03:32:25 +0100 From: "Index" X-Mailer: The Bat! (v4.08.1) Home X-Priority: 3 (Normal) Message-ID: <6781259565.72680855411130@sd-36302.dedibox.fr> To: Subject: Conferma richiesta. MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 02:32:27 -0000 Il tuo ordine viene elaborato, vedere il risultato del profilo a: http://agrocolumna.ro/Richiesta.zip == Tel.: (696) 886 71 357 From owner-freebsd-fs@FreeBSD.ORG Tue Dec 11 10:58: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 196E3A68 for ; Tue, 11 Dec 2012 10:58:53 +0000 (UTC) (envelope-from marco@tols.org) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by mx1.freebsd.org (Postfix) with ESMTP id 527778FC14 for ; Tue, 11 Dec 2012 10:58:52 +0000 (UTC) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TiNY1-0007qB-09; Tue, 11 Dec 2012 11:58:51 +0100 Received: from [10.120.14.250] by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TiNY0-0006lG-SX; Tue, 11 Dec 2012 11:58:48 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: ZFS mirrored separate log device replacement scans entire pool? From: Marco van Tol In-Reply-To: <50C6522D.6080808@bsdunix.ch> Date: Tue, 11 Dec 2012 11:58:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <837C1B26-8BD2-4BD5-8281-36A2CD5ED323@tols.org> References: <50C6522D.6080808@bsdunix.ch> To: Tom X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121211 clean X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.8 points pts rule name description ---- ---------------------- ------------------------------------ 0.1 SARE_SUB_OBFU_OTHER FVGT - subject contains odd letter combinations -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 428ccdbe43205e483f75bd4ab79aeab30cbf4d93c8301310176d0ca5583c6ff7 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 10:58:53 -0000 Just nitpicking, but in case of this mirror, detach and attach probably work better then remove and add. If you want to play it save, first attach the new drive (making it a 3 way mirror) before detaching the old one (making it 2 way again). Right? :-) Marco On Dec 10, 2012, at 22:20, Tom wrote: > Hi Andrew >=20 > Use remove and add for log devices instead of replace. This prevents = the > pool from resilvering and takes only a couple of seconds. >=20 > Regards, > Tom > Am 10.12.12 20:38, schrieb Andrew Leonard: >> This is likely more of a curiosity than an issue, unless it indicates = I did >> something wrong: Why does replacing half of a mirrored ZFS separate = log >> cause the entire zpool to be scanned? To wit: >>=20 >>> zpool status >> pool: tank01 >> state: DEGRADED >> status: One or more devices is currently being resilvered. The pool = will >> continue to function, possibly in a degraded state. >> action: Wait for the resilver to complete. >> scan: resilver in progress since Mon Dec 10 11:15:49 2012 >> 7.54T scanned out of 27.0T at 3.12G/s, 1h46m to go >> 0 resilvered, 27.93% done >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> tank01 DEGRADED 0 0 0 >> raidz2-0 ONLINE 0 0 0 >> da2 ONLINE 0 0 0 >> da3 ONLINE 0 0 0 >> da4 ONLINE 0 0 0 >> da5 ONLINE 0 0 0 >> da6 ONLINE 0 0 0 >> da7 ONLINE 0 0 0 >> da8 ONLINE 0 0 0 >> da9 ONLINE 0 0 0 >> da10 ONLINE 0 0 0 >> da11 ONLINE 0 0 0 >> raidz2-1 ONLINE 0 0 0 >> da12 ONLINE 0 0 0 >> da13 ONLINE 0 0 0 >> da14 ONLINE 0 0 0 >> da15 ONLINE 0 0 0 >> da16 ONLINE 0 0 0 >> da17 ONLINE 0 0 0 >> da18 ONLINE 0 0 0 >> da19 ONLINE 0 0 0 >> da20 ONLINE 0 0 0 >> da21 ONLINE 0 0 0 >> raidz2-2 ONLINE 0 0 0 >> da22 ONLINE 0 0 0 >> da23 ONLINE 0 0 0 >> da24 ONLINE 0 0 0 >> da32 ONLINE 0 0 0 >> da26 ONLINE 0 0 0 >> da27 ONLINE 0 0 0 >> da33 ONLINE 0 0 0 >> da29 ONLINE 0 0 0 >> da30 ONLINE 0 0 0 >> da31 ONLINE 0 0 0 >> logs >> mirror-3 DEGRADED 0 0 0 >> da34 ONLINE 0 0 0 >> replacing-1 OFFLINE 0 0 0 >> 1754652639903581713 OFFLINE 0 0 0 was /dev/da35 >> da25 ONLINE 0 0 0 >>=20 >> errors: No known data errors >>> zpool get version tank01 >> NAME PROPERTY VALUE SOURCE >> tank01 version 28 default >>> zfs get version tank01 >> NAME PROPERTY VALUE SOURCE >> tank01 version 5 - >>> uname -a >> FreeBSD zfs12.sbri.org 8.3-STABLE FreeBSD 8.3-STABLE #0: Sun Aug 12 >> 07:31:24 PDT 2012 = root@zfs12.sbri.org:/usr/obj/usr/src/sys/GENERIC >> amd64 >>=20 >> Thanks, >> Andy >> _______________________________________________ >> 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" >>=20 >=20 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" --=20 Marco van Tol From owner-freebsd-fs@FreeBSD.ORG Tue Dec 11 14:09:31 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE73FECC; Tue, 11 Dec 2012 14:09:31 +0000 (UTC) (envelope-from smh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2CA8FC13; Tue, 11 Dec 2012 14:09:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBBE9VhP073581; Tue, 11 Dec 2012 14:09:31 GMT (envelope-from smh@freefall.freebsd.org) Received: (from smh@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBBE9VWl073577; Tue, 11 Dec 2012 14:09:31 GMT (envelope-from smh) Date: Tue, 11 Dec 2012 14:09:31 GMT Message-Id: <201212111409.qBBE9VWl073577@freefall.freebsd.org> To: smh@FreeBSD.org, freebsd-fs@FreeBSD.org, smh@FreeBSD.org From: smh@FreeBSD.org Subject: Re: kern/172259: [zfs] [patch] ZFS fails to receive valid snapshots (patch included) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 14:09:31 -0000 Synopsis: [zfs] [patch] ZFS fails to receive valid snapshots (patch included) Responsible-Changed-From-To: freebsd-fs->smh Responsible-Changed-By: smh Responsible-Changed-When: Tue Dec 11 14:09:31 UTC 2012 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=172259 From owner-freebsd-fs@FreeBSD.ORG Tue Dec 11 14:10:25 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3A99FCC; Tue, 11 Dec 2012 14:10:25 +0000 (UTC) (envelope-from smh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 90B748FC17; Tue, 11 Dec 2012 14:10: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 qBBEAPSN073845; Tue, 11 Dec 2012 14:10:25 GMT (envelope-from smh@freefall.freebsd.org) Received: (from smh@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBBEAPxR073841; Tue, 11 Dec 2012 14:10:25 GMT (envelope-from smh) Date: Tue, 11 Dec 2012 14:10:25 GMT Message-Id: <201212111410.qBBEAPxR073841@freefall.freebsd.org> To: smh@FreeBSD.org, freebsd-fs@FreeBSD.org, smh@FreeBSD.org From: smh@FreeBSD.org Subject: Re: kern/173234: [zfs] [patch] Allow filtering of properties on zfs receive (patch included) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 14:10:25 -0000 Synopsis: [zfs] [patch] Allow filtering of properties on zfs receive (patch included) Responsible-Changed-From-To: freebsd-fs->smh Responsible-Changed-By: smh Responsible-Changed-When: Tue Dec 11 14:10:25 UTC 2012 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=173234 From owner-freebsd-fs@FreeBSD.ORG Tue Dec 11 21:57:26 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 602D8DA8; Tue, 11 Dec 2012 21:57:26 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2B2508FC08; Tue, 11 Dec 2012 21:57:26 +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 qBBLvQDO010064; Tue, 11 Dec 2012 21:57:26 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBBLvQXL010060; Tue, 11 Dec 2012 21:57:26 GMT (envelope-from linimon) Date: Tue, 11 Dec 2012 21:57:26 GMT Message-Id: <201212112157.qBBLvQXL010060@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174372: [zfs] Pagefault appears to be related to ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 21:57:26 -0000 Old Synopsis: Pagefault appears to be related to ZFS New Synopsis: [zfs] Pagefault appears to be related to ZFS Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Dec 11 21:57:12 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=174372 From owner-freebsd-fs@FreeBSD.ORG Wed Dec 12 13:04:33 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5186127B; Wed, 12 Dec 2012 13:04:33 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 501C68FC14; Wed, 12 Dec 2012 13:04:31 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so595663lah.13 for ; Wed, 12 Dec 2012 05:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dBeY2vQEtDb+ubQlKhMH8x583lRKGAadgenKXi3hxyM=; b=Rl9P4pCEcHsw2RlDWCnSk62U+26LVENHxdnneIX9G2gt/DK8hARovuKOkGvaI7T+Ni PvArIFAJLXGkzxeKfpD8i6tqvDBfAlF4ivTrmdJRgDozAW6gs5/cRW877+bbPtxiTSPI wX5unOXpNTI5V0wq02O+/tswkuvXT+P/qQFLzebW57OOnAAwaAkP+vJE7Vmudf8n6wfM QXdp6aEMqEM9ljOwVfrRlFvs9MkuU6y1em/exvNn9BkBEuun42toeUw+4r3JuFEHX3Tg ozwIM0OPj1SKghjXulIhyZ1Fs4V3klaTOdBgDcnxtzdDFXbUoZ2lvf9h6n7xjSnt6sEC rNxg== Received: by 10.152.108.48 with SMTP id hh16mr964882lab.25.1355317471103; Wed, 12 Dec 2012 05:04:31 -0800 (PST) Received: from [192.168.1.129] ([91.196.229.122]) by mx.google.com with ESMTPS id ti4sm10660662lab.1.2012.12.12.05.04.27 (version=SSLv3 cipher=OTHER); Wed, 12 Dec 2012 05:04:29 -0800 (PST) Message-ID: <50C880D7.1040907@gmail.com> Date: Wed, 12 Dec 2012 15:04:23 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> In-Reply-To: <20121203224132.GJ3013@kib.kiev.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, dim@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 13:04:33 -0000 04.12.2012 00:41, Konstantin Belousov: > Please try the patch below. It might give an immediate relief, but still > there are many offenders in the backtrace. I'm having almost the same issue and the patch doesn't work for me. Trying to mount root from zfs:limb0 []... Fatal double fault: eip = 0x835a6bce esp = 0x875c2fd4 ebp = 0x875c3018 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(8380283b,20646920,3030203d,3831000a,a3a000a,...) at db_trace_self_wrapper+0x36/frame 0x83a10f10 kdb_backtrace(8383658f,0,83837c3d,83a10fc0,0,...) at kdb_backtrace+0x30/frame 0x83a10f70 panic(83837c3d,0,0,0,875c3018,...) at panic+0x1bc/frame 0x83a10fb4 dblfault_handler() at cpu_fetch_syscall_args/frame 0x83a10fb4 --- trap 0x17, eip = 8x835a6bce, esp = 0x875c2fd4, ebp = 0x875c3018 --- witness_checkorder(843df808,9,8382a15c,7dd,0,...) at witness_checkorder+0x2e/frame 0x875c3018 _mtx_lock_flags(843df808,0,8382a15c,7dd,202,...) at _mtx_lock_flags+0x7a/frame 0x875c3040 uma_zalloc_arg(843de960,0,102,2,2,...) at uma_zalloc_arg+0x5df/franc 0x875c3090 malloc(38,83d03100,102,875c3138,83c01d1a,...) at malloc+0xe9/frame 0x875c30c0 zfs_kmem_alloc(38,102,8,83cab2fe,157,...) at zfs_kmem_alloc+0x20/frame 0x875c30d4 vdev_mirror_io_start(87e3eb20,10,B7e3eb20,1,87d3f618,...) at vdev_mirror_io_start+0x14a/frame 0x875c3138 zio_vdev_io_start(87e3eb20,8795dbcO,87e3eb20,875c3340,200,...) at zio_vdev_io_start+0x1a6/frame Ox875c3180 zio_execute(87e3eb20.87c8f000,880a0640,8807d400,200,...) at zio_execute+0x103/frame 0x875c31b0 spa_load_verify_cb(87c8f000,0,880a0640,87f7b708,875c3340,...) at spa_load_verify_cb+0x89/frame 0x875c31f0 traverse_visitbp(87f7b708,880a0640,875c3340,875c3db8,0,...) at traverse_visitbp+0x1e6/frame 0x875c3320 traverse_dnode(87f7b708,15,0,3,O,...) at traverse_dnode+0x92/frame 0x875c337O traverse_visitbp(87f7b6cc,880a4000,875c3520,87f7b744,83b92d10,...) at traverse_visitbp+0xc40/frame 0x875c34a0 traverse_visitbp(87f7b744,88096000,875c3650,87f7b834,83b92d10,...) at traverse_visitbp+0xd33/frame 0xB75c35d0 traverse_visitbp(87f7b834,88074000,875c3780,87f7b8ac,83b92d10,...) at traverse_visitbp+0xd33/frame 0x875c3700 traverse_visitbp(87f7b8ac,8806c000,875c38b0,87f7b924,83b92d10,...) at traverse_visitbp+0xd33/frame 0x875c3830 traverse_visitbp(87f7b924,88064000,875c39e0,87f7b99c,83b92d10,...) at traverse_visitbp+0xd33/frame 0x875c3960 traverse_visitbp(87f7b99c,87fce000,875c3b10,87f7ba14,83b92d10,...) at traverse_visitbp+0xd33/frame 0x875c3a90 traverse_visitbp(87f7ba14,88061040,875c3be0,875c3db8,0,...) at traverse_visitbp+0xd33/frame 0x875c3bc0 traverse_dnode(87f7ba14,15,0,0,0,...) at traverse_dnode+0x92/frame 0x875c3c10 traverse_visitbp(0,87f8ee80,875c3d68,2,834,...) at traverse_visitbp+0x822/frame 0x875c3d40 traverse_impl(15,0,87f8ee80,261400,0,...) at traverse_impl+0x268/frane 0x875c3df0 traverse_pool(87c8f000,261400,0,d,83bec290,...) at traverse_pool+0x273/frame 0x875c3e90 spa_load(0,1,875c4034,83ca82f2,8,...) at spa_load+0x1d8f/frame 0x875c3fa8 spa_load(0,0,83a48934,1,14,...) at spa_load+0x114c/frame 0x875c40c0 spa_load_best(0,ffffffff,ffffffff,1,0,...) at spa_load_best+0x71/frame 0x875c3e90 spa_open_common(83ca3ca6,0,0,875c42f0,83bb9dec,...) at spa_open_common+0x11a/frame 0x875c4174 spa_open(875c41e0,875c41dc,83ca3ca6,0,0,...) at spa_open+0x27/frame 0x875c4188 dsl_dir_open_spa(0,87d47350,83ca4039,875c4358,875c4354,...) at dsl_dir_open_spa+0x6c/frame 0x875c42f0 dsl_dataset_hold(87d47350,87a36000,875c43a0,87a36000,87a36000,...) at dsl_data_hold+0x3a/frame 0x875c436c dsl_dataset_own(87d47350,0,87a3600,875c43a0,83d01e30,...) at dsl_dataset_own+0x21/frame 0x875c4388 dmu_objset_own(87d4350,2,1,87a36000,875c43f0,...) at dmu_objset_own+0x2a/frame 0x875c43b0 zfsvfs_create(87d47350,875c4504,83cb0b68,68e,87d47350,...) at zfsvfs_create+0x4c/frame 0x875c4400 zfs_mount(87d40ce4,83cb5Bd0,87d46300,87957500,8384fd28,...) at zfs_mount+0x4a9/frame 0x875c4630 vfs_donmount(8795dbc0,4000,0,875c48b8,87d46380,...) at vfs_donmount+0xc94/frame 0x875c48a0 kernel_mount(87d473d0,4000,0,0,839de044,...) at kernel_mount+0x6b/frame 0x875c48e0 parse_mount(87d47400,8385a800,0,1,0,...) at parse_mount+0x622/frame 0x875c49f8 vfs_mountroot(83a491c4,4,837f68a2,2ba,0,...) at vfs_mountroot+0x6f1/frame 0x875c4c60 start_init(0,875c4d08,837f8f83,3d8,0,...) at start_init+0x6a/frame 0x875c4ccc fork_exit(835107b0,0,875c4d08) at fork_init+0x7c/frame 0x875c4cf4 fork_trampoline() at fork_trampoline+0x8/frame 0x875c4cf4 --- trap 0, eip = 0, esp = 0x875c4d40, ebp = O --- KDB: enter: panic [ thread pid 1 tid 100002 J Stopped at kdb_enter+0x3d: movl $O,kdb_why db> Source pictures are at https://picasaweb.google.com/104021007361271711472/I386ZfsDoubleFault?authuser=0&feat=directlink just in case I missed something. -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Wed Dec 12 14:20: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 60C6698C; Wed, 12 Dec 2012 14:20:01 +0000 (UTC) (envelope-from olavgg@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 086E08FC13; Wed, 12 Dec 2012 14:20:00 +0000 (UTC) Received: by mail-gh0-f182.google.com with SMTP id z15so143290ghb.13 for ; Wed, 12 Dec 2012 06:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iGAH3i73fuGXzFMmSM0DKPxjb3dlDIrRXEtxTrx8NF0=; b=yTmRR6NUv8X5TIPMsL6KZrgbtMVyNKXr4fxsl7wUcnGNBYnuO+uWOX/shk2jpX8NwY 41pH/N9uu9QbaKrDcX2S+XlhXPIIpCcWTxGjzxODXQvTx6t9ASCXcvd4iMKsQP9p5i0I jxzFRg3rxLcFGDvr6dD4og+eYsDnFOs4TBDG517seaK9ct1h11BmMEfTdhoUdgSPgJ60 acbIxiWxe13ISyaXeQOB6ecvtB7H7QrKz19/jlZXsbpdWv7AY53WzpSYHoS++x6j7B04 tyk0+XxjyHEXowir/XzELY1Z6KOjqqgnIr4qVCq9aTLwLberNxiih6SfMvgCLL2dX7Ku qkyg== MIME-Version: 1.0 Received: by 10.58.48.231 with SMTP id p7mr603571ven.11.1355321998719; Wed, 12 Dec 2012 06:19:58 -0800 (PST) Received: by 10.58.254.195 with HTTP; Wed, 12 Dec 2012 06:19:58 -0800 (PST) Date: Wed, 12 Dec 2012 15:19:58 +0100 Message-ID: Subject: find vs ls performance for walking folders, are there any faster options? From: =?ISO-8859-1?Q?Olav_Gr=F8n=E5s_Gjerde?= To: freebsd-performance@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 14:20:01 -0000 I'm working on scanning filesystems to build a file search engine and came over something interesting. I can walk through 300 000 folders in ~19.5seconds with this command: ls -Ra | grep -e "./.*:" | sed "s/://" With find, it surprisingly takes ~50.5 seconds.: find . -type d My results are based on five runs of each command to warm up the disk cache. I've tried both this with both UFS and ZFS, and both filesystems shows the same speed difference. On a modern Linux distribution(Ubuntu 12.10 with EXT4), ls is just slight faster than find(about 15-20%). Are there a faster way to walk folders on FreeBSD? Are there some options(sysctl) I could tune to improve the performance? From owner-freebsd-fs@FreeBSD.ORG Wed Dec 12 14:51: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 BED28408; Wed, 12 Dec 2012 14:51:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8278FC12; Wed, 12 Dec 2012 14:51:00 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBCEoq9S001612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 01:50:53 +1100 Date: Thu, 13 Dec 2012 01:50:52 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: =?ISO-8859-1?Q?Olav_Gr=F8n=E5s_Gjerde?= Subject: Re: find vs ls performance for walking folders, are there any faster options? In-Reply-To: Message-ID: <20121213012632.M1201@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-821341582-1355323852=:1201" X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zr21sKHG c=1 sm=1 a=yebKrrqT3fcA:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=On_ekTe0GqwA:10 a=6nvIKyoRHYfj9tnll-sA:9 a=45ClL6m2LaAA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: freebsd-fs@freebsd.org, freebsd-performance@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 14:51:01 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-821341582-1355323852=:1201 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 12 Dec 2012, [ISO-8859-1] Olav Gr=F8n=E5s Gjerde wrote: > I'm working on scanning filesystems to build a file search engine and > came over something interesting. > > I can walk through 300 000 folders in ~19.5seconds with this command: > ls -Ra | grep -e "./.*:" | sed "s/://" > > With find, it surprisingly takes ~50.5 seconds.: > find . -type d This is because 'find' with '-type' lstats all the files. It doesn't use DT_DIR from dirent for some reason. ls can be slowed down similarly using -F. > My results are based on five runs of each command to warm up the disk cac= he. > I've tried both this with both UFS and ZFS, and both filesystems shows > the same speed difference. I get almost exactly the same ratio of speeds on an old version of FreeBSD. All the data was cached, and there were only 7 symlinks. Thr file system was mounted with -noatime, so the cache actually worked. > On a modern Linux distribution(Ubuntu 12.10 with EXT4), ls is just > slight faster than find(about 15-20%). Apparently lstat() is relatively much slower in FreeBSD. It only takes 5 usec here, but that is a lot for converting cached data (getpid() takes 0.2 usec). A file system mounted with -atime might be much slower, for writing directory timestamps (the sync of the timestamps is delayed, but it is a very heavyweight operation). > Are there a faster way to walk folders on FreeBSD? Are there some > options(sysctl) I could tune to improve the performance? Nothing much faster than find without -type. Whatever fts(3) gives. Bruce --0-821341582-1355323852=:1201-- From owner-freebsd-fs@FreeBSD.ORG Wed Dec 12 19:35:44 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47038E52; Wed, 12 Dec 2012 19:35:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id F17A48FC1B; Wed, 12 Dec 2012 19:35:43 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:5821:52ef:5e7d:addd] (unknown [IPv6:2001:7b8:3a7:0:5821:52ef:5e7d:addd]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6DBF45C37; Wed, 12 Dec 2012 20:35:42 +0100 (CET) Message-ID: <50C8DC8E.1080204@FreeBSD.org> Date: Wed, 12 Dec 2012 20:35:42 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Volodymyr Kostyrko Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> In-Reply-To: <50C880D7.1040907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:35:44 -0000 On 2012-12-12 14:04, Volodymyr Kostyrko wrote: > 04.12.2012 00:41, Konstantin Belousov: >> Please try the patch below. It might give an immediate relief, but still >> there are many offenders in the backtrace. > > I'm having almost the same issue and the patch doesn't work for me. ... Looking at the stack frame addresses, it seems some of them are mangled. Did you type this by hand? The differences between subsequent frames are a bit strange because of it (and because of awk's integer processing): _mtx_lock_flags 40 uma_zalloc_arg 80 malloc 48 zfs_kmem_alloc 20 vdev_mirror_io_start 100 zio_vdev_io_start -2270966072 zio_execute 2270966192 spa_load_verify_cb 64 traverse_visitbp 304 traverse_dnode -2129031145 traverse_visitbp 2129031529 traverse_visitbp 805306672 traverse_visitbp -805306064 traverse_visitbp 304 traverse_visitbp 304 traverse_visitbp 304 traverse_visitbp 304 traverse_dnode 80 traverse_visitbp 304 traverse_impl 176 traverse_pool 160 spa_load 280 spa_load 280 spa_load_best -560 spa_open_common 740 spa_open 20 dsl_dir_open_spa 360 dsl_dataset_hold 124 dsl_dataset_own 28 dmu_objset_own 40 zfsvfs_create 80 zfs_mount 560 vfs_donmount 624 kernel_mount 64 parse_mount 280 vfs_mountroot 616 start_init 108 fork_exit 40 fork_trampoline 0 The kernel stack is just 8,192 bytes; since you can see these routines are all consuming massive amounts of stack, and the calls are very deeply nested, it is almost inevitable that it would crash. Especially the recursive spa_load and traverse_visitbp calls are scary, because that can grow out of hand very quickly. It is probably tricky to remove the recursion... From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 10:25:51 2012 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0AD593C; Thu, 13 Dec 2012 10:25:51 +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 84E848FC19; Thu, 13 Dec 2012 10:25:50 +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 MAA13707; Thu, 13 Dec 2012 12:25:48 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50C9AD2C.7000301@FreeBSD.org> Date: Thu, 13 Dec 2012 12:25:48 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> <50C8DC8E.1080204@FreeBSD.org> In-Reply-To: <50C8DC8E.1080204@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Volodymyr Kostyrko , freebsd-current@FreeBSD.org, fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 10:25:51 -0000 on 12/12/2012 21:35 Dimitry Andric said the following: > Especially the recursive spa_load and traverse_visitbp calls are scary, > because that can grow out of hand very quickly. It is probably tricky > to remove the recursion... Re-entering spa_load once is normal and is expected. traverse_visitbp is also expected to recurse depending on data layout. So yeah, it's probably even trickier than teaching clang to allocate smaller stack frames ;-) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 10:36:58 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2B0EC8; Thu, 13 Dec 2012 10:36:58 +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 C6BA18FC0C; Thu, 13 Dec 2012 10:36:57 +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 MAA13845; Thu, 13 Dec 2012 12:36:54 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50C9AFC6.6080902@FreeBSD.org> Date: Thu, 13 Dec 2012 12:36:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: olivier olivier Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 10:36:58 -0000 I decided to share here the comment that I made in private, so that more people could potentially benefit from it. on 03/12/2012 20:41 olivier olivier said the following: > Hi all > After upgrading from 9.0-RELEASE to 9.1-PRERELEASE #0 r243679 I'm having > severe problems with NFS sharing of a ZFS volume. nfsd appears to hang at > random times (between once every couple hours to once every two days) while > accessing a ZFS volume, and the only way I have found of resolving the > problem is to reboot. The server console is sometimes still responsive > during the nfsd hang, and I can read and write files to the same ZFS volume > while nfsd is hung. I am pasting below the output of procstat -kk on nfsd, > and details of my pool (nfsstat on the server gets hung when the problem > has started occurring, and does not produce any output). The pool is v28 > and was created from a bunch of volumes attached over Fibre Channel using > the mpt driver. My system has a Supermicro board and 4 AMD Opteron 6274 > CPUs. > > I did not experience any nfsd hangs with 9.0-RELEASE (same machine, > essentially same configuration, same usage pattern). > > I would greatly appreciate any help to resolve this problem! I've looked at the provided data and I do not see anything that implicates ZFS. My rules of the thumb for ZFS hangs: - if there are threads in zio_wait - if you can firm that they are indeed stuck there[*] - if there are no threads in zio_interrupt [*] you have to be sure that a thread just sits in zio_wait and doesn't make any forward progress as opposed to the thread doing a lot of I/O and thus having a high probability of being seen in zio_wait. Then it is most likely that the problem is at the storage level. Most likely it is a bug in storage controller driver which allowed an I/O request to get lost (instead of "errored out" or timed out). `camcontrol tags -v` can be used to query depth of a queue for each disk and determine the bad one. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 12:29:26 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D6DDB7; Thu, 13 Dec 2012 12:29:26 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 61BCC8FC08; Thu, 13 Dec 2012 12:29:25 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so986444bkc.13 for ; Thu, 13 Dec 2012 04:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=D1UYFwr8ACvDOt8LYE2rEHeZQDRe9ontGpWFGB6DvM4=; b=vYOW5y5TpUEaDHA1O5VjOLgFYLqfkwrDz9tF8IXEP4NWlGCn6RybjGQVGQmCU5FYCp zeIEQOMhMXlwbPLs/lY8sLZeI1xulDC30bshKwQg6jszBS86ImiA7CSI5j3YQklWqFGi H7yhwh1DCuFYJxTFFSMKB26feoXo0yvq8OpqhODj4COjs79VtgfM5Z6xg96IxCsnib7l yYXtEvhgQJL37HbsMtYVhdH++itVM2D2evmFKySmNPBtXeX9O8DKYmNMAJLFyr3ldQHu pzeov3w316igGrdgra9ZH3Dj94CZsm1VhDZoF/yRuAS5bM4CXEJ0QHJ7lUS5ich6sT9i 2/Uw== Received: by 10.204.6.87 with SMTP id 23mr905559bky.78.1355401764304; Thu, 13 Dec 2012 04:29:24 -0800 (PST) Received: from [192.168.1.129] ([91.196.229.122]) by mx.google.com with ESMTPS id u3sm1182439bkw.9.2012.12.13.04.29.21 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 04:29:22 -0800 (PST) Message-ID: <50C9CA1C.8030002@gmail.com> Date: Thu, 13 Dec 2012 14:29:16 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> <50C8DC8E.1080204@FreeBSD.org> In-Reply-To: <50C8DC8E.1080204@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 12:29:26 -0000 12.12.2012 21:35, Dimitry Andric: > On 2012-12-12 14:04, Volodymyr Kostyrko wrote: >> 04.12.2012 00:41, Konstantin Belousov: >>> Please try the patch below. It might give an immediate relief, but still >>> there are many offenders in the backtrace. >> >> I'm having almost the same issue and the patch doesn't work for me. > ... > > Looking at the stack frame addresses, it seems some of them are mangled. > Did you type this by hand? The differences between subsequent frames > are a bit strange because of it (and because of awk's integer > processing): Yes, I had typed that by hand. I attached link to the pictures just in case. > The kernel stack is just 8,192 bytes; since you can see these routines > are all consuming massive amounts of stack, and the calls are very > deeply nested, it is almost inevitable that it would crash. > > Especially the recursive spa_load and traverse_visitbp calls are scary, > because that can grow out of hand very quickly. It is probably tricky > to remove the recursion... After playing more with this kernel I also found it can crash not only by this scenario. There are different possible ways. I actually don't think there's a point fixing it right now. New clang is coming anyway... -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 14:21:46 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 5E6B1F8E for ; Thu, 13 Dec 2012 14:21:46 +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 AB9D48FC0C for ; Thu, 13 Dec 2012 14:21:45 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id qBDELbSY078333 for ; Thu, 13 Dec 2012 16:21:38 +0200 (EET) Message-ID: <20121213162137.78332@relay.ibs.dn.ua> Date: Thu, 13 Dec 2012 16:21:37 +0300 From: Zeus Panchenko To: cc: Subject: snapshot management tool? 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\ X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:21:46 -0000 hi all, please, share what are you using to manage snapshots in ports collection I see: zfs-periodic zfs-snapshot-mgmt zfsnap zfstools is it planned to implement some native tool? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 14:37:23 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 9D41342D for ; Thu, 13 Dec 2012 14:37:23 +0000 (UTC) (envelope-from michael@fuckner.net) Received: from mo6-p00-ob.rzone.de (mo6-p00-ob.rzone.de [IPv6:2a01:238:20a:202:5300::1]) by mx1.freebsd.org (Postfix) with ESMTP id F06B28FC08 for ; Thu, 13 Dec 2012 14:37:22 +0000 (UTC) X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTEGbkn8hussqFHiy/c+oYVPeezIVIZYA== X-RZG-CLASS-ID: mo00 Received: from omgreatgod.store (com4.strato.de [81.169.145.237]) by smtp.strato.de (josoe mo24) (RZmta 31.9 AUTH) with (RC4-MD5 encrypted) ESMTPA id v05f53oBDDimU3 ; Thu, 13 Dec 2012 15:37:19 +0100 (CET) Date: Thu, 13 Dec 2012 15:37:19 +0100 (CET) From: Michael Fuckner To: Zeus Panchenko , freebsd-fs@freebsd.org Message-ID: <1738431772.1451114.1355409439719.JavaMail.open-xchange@com4.strato.de> In-Reply-To: <20121213162137.78332@relay.ibs.dn.ua> References: <20121213162137.78332@relay.ibs.dn.ua> Subject: Re: snapshot management tool? MIME-Version: 1.0 X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v6.20.7-Rev6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Michael Fuckner List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:37:23 -0000 zfs snapshot... what exactly do you mean with "manage"? Regards, Michael! Zeus Panchenko hat am 13. Dezember 2012 um 14:21 geschrieben: > hi all, > > please, share what are you using to manage snapshots > > in ports collection I see: > > zfs-periodic > zfs-snapshot-mgmt > zfsnap > zfstools > > > is it planned to implement some native tool? > > -- > Zeus V. Panchenko jid:zeus@im.ibs.dn.ua > IT Dpt., I.B.S. LLC GMT+2 (EET) > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 14:37:27 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 95B82432 for ; Thu, 13 Dec 2012 14:37:27 +0000 (UTC) (envelope-from gerrit.kuehn@aei.mpg.de) Received: from umail.aei.mpg.de (umail.aei.mpg.de [194.94.224.6]) by mx1.freebsd.org (Postfix) with ESMTP id 3B24F8FC12 for ; Thu, 13 Dec 2012 14:37:25 +0000 (UTC) Received: from mailgate.aei.mpg.de (mailgate.aei.mpg.de [194.94.224.5]) by umail.aei.mpg.de (Postfix) with ESMTP id 4EA092005F8; Thu, 13 Dec 2012 15:28:41 +0100 (CET) Received: from mailgate.aei.mpg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 423C5406ACA; Thu, 13 Dec 2012 15:28:41 +0100 (CET) Received: from intranet.aei.uni-hannover.de (ahin1.aei.uni-hannover.de [130.75.117.40]) by mailgate.aei.mpg.de (Postfix) with ESMTP id 2C5C9406AC1; Thu, 13 Dec 2012 15:28:41 +0100 (CET) Received: from cascade.aei.uni-hannover.de ([130.75.117.3]) by intranet.aei.uni-hannover.de (Lotus Domino Release 8.5.3) with ESMTP id 2012121315283082-32079 ; Thu, 13 Dec 2012 15:28:30 +0100 Date: Thu, 13 Dec 2012 15:28:30 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-fs@freebsd.org Subject: Re: snapshot management tool? Message-Id: <20121213152830.24105ef4.gerrit.kuehn@aei.mpg.de> In-Reply-To: <20121213162137.78332@relay.ibs.dn.ua> References: <20121213162137.78332@relay.ibs.dn.ua> Organization: Max Planck Gesellschaft X-Mailer: Sylpheed 3.1.3 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on intranet/aei-hannover(Release 8.5.3|September 15, 2011) at 12/13/2012 15:28:30, Serialize by Router on intranet/aei-hannover(Release 8.5.3|September 15, 2011) at 12/13/2012 15:28:40, Serialize complete at 12/13/2012 15:28:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.13.142127 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MIME_LOWER_CASE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_200_299 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, SMALL_BODY 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS ' X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:37:27 -0000 On Thu, 13 Dec 2012 16:21:37 +0300 Zeus Panchenko wrote about snapshot management tool?: ZP> in ports collection I see: ZP> ZP> zfs-periodic ZP> zfs-snapshot-mgmt ZP> zfsnap ZP> zfstools sysutils/freebsd-snapshot cu Gerrit From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 14:42:33 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 563F57ED for ; Thu, 13 Dec 2012 14:42:33 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id BD8508FC13 for ; Thu, 13 Dec 2012 14:42:32 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1818948lah.13 for ; Thu, 13 Dec 2012 06:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/4CmNFnAvrIV2LZWFLwFszUsyrKt9ac2thV9c+1YXCs=; b=zw9NGRDsY6fjLo5ePY4zskG4xksGuipi7WCBiDT6QvugYdpV9HJTtuOp0adf+y+BBV 2Oe7VUr+gkESx2hOwpKEQNF8FtUfPylQSv3iZ/T5rMhftu/8Ur3WWAl3xzYVdGqAi1z8 GfM/p80GnqlOXb9/dvw93z0DT4yDWZgQgT8+VP9/Nwtqyrfi6Q0vzzU+32om8OgRDdVn 2nmCjahvf72Iq/9BlsFfLZVgB3ljBVMMvqKu9yrXg4tgkqlqfGXB2XTUnWD8KUmiLuFk hybLZ9yASdtU+b1dgdSw5jOQ7PguYsEc6D7jQXCAF3Pq16GyRSe08TG3v+kQhJ7S+01Y Epbw== Received: by 10.112.17.129 with SMTP id o1mr1027132lbd.54.1355409751594; Thu, 13 Dec 2012 06:42:31 -0800 (PST) Received: from [192.168.1.129] (schavemaker.nl. [213.84.84.186]) by mx.google.com with ESMTPS id v7sm811807lbj.13.2012.12.13.06.42.29 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 06:42:30 -0800 (PST) Message-ID: <50C9E955.1030001@gmail.com> Date: Thu, 13 Dec 2012 15:42:29 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: snapshot management tool? References: <20121213162137.78332@relay.ibs.dn.ua> In-Reply-To: <20121213162137.78332@relay.ibs.dn.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 14:42:33 -0000 Zeus Panchenko schreef: > hi all, > > please, share what are you using to manage snapshots > > in ports collection I see: > > zfs-periodic > zfs-snapshot-mgmt > zfsnap > zfstools > > > is it planned to implement some native tool? > I use zfs-periodic. I have a simple pool setup, so no need for advanced stuff. It was the first i tried and it did what it supossed to do. So i never looked at the other solutions I made myself a zfs send script to send the snapshot taken by zfs-periodic gets send to a target host. gr johan Hendriks From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 15:18:39 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 CDC9724B for ; Thu, 13 Dec 2012 15:18:39 +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 248FA8FC13 for ; Thu, 13 Dec 2012 15:18:38 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id qBDFIaDi083700 for ; Thu, 13 Dec 2012 17:18:37 +0200 (EET) Message-ID: <20121213171836.83698@relay.ibs.dn.ua> Date: Thu, 13 Dec 2012 17:18:36 +0300 From: Zeus Panchenko To: Subject: Re: snapshot management tool? In-reply-to: Your message of Thu, 13 Dec 2012 15:37:19 +0100 (CET) <1738431772.1451114.1355409439719.JavaMail.open-xchange@com4.strato.de> References: <20121213162137.78332@relay.ibs.dn.ua> <1738431772.1451114.1355409439719.JavaMail.open-xchange@com4.strato.de> 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\ X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:18:39 -0000 Michael Fuckner wrote: > zfs snapshot... what exactly do you mean with "manage"? making and rotation -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 16:57:58 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB2BB23F for ; Thu, 13 Dec 2012 16:57:58 +0000 (UTC) (envelope-from marco@tols.org) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4668FC15 for ; Thu, 13 Dec 2012 16:57:58 +0000 (UTC) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TjC6d-0000JG-8c; Thu, 13 Dec 2012 17:57:56 +0100 Received: from [10.120.15.7] by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1TjC6d-0005Nh-4v; Thu, 13 Dec 2012 17:57:55 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: snapshot management tool? From: Marco van Tol In-Reply-To: <20121213162137.78332@relay.ibs.dn.ua> Date: Thu, 13 Dec 2012 17:57:54 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0B1A30EF-0DD8-424E-9079-DA13EF75AD1D@tols.org> References: <20121213162137.78332@relay.ibs.dn.ua> To: Zeus Panchenko X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121213 clean X-RIPE-Spam-Level: - X-RIPE-Spam-Report: Spam Total Points: -1.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 428ccdbe43205e483f75bd4ab79aeab35bb071209718bc6e4974ee8efce25fe9 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:57:58 -0000 On Dec 13, 2012, at 14:21, Zeus Panchenko wrote: > hi all, > > please, share what are you using to manage snapshots > > in ports collection I see: > > zfs-periodic > zfs-snapshot-mgmt > zfsnap > zfstools > > is it planned to implement some native tool? I like zfsnap best. Moved over to it coming from zfs-periodic, but I forgot why so it probably wasn't too important. :) -- Marco van Tol From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 17:46:46 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 79D7DF1E; Thu, 13 Dec 2012 17:46:46 +0000 (UTC) (envelope-from olivier777a7@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3AF7C8FC0A; Thu, 13 Dec 2012 17:46:46 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id n2so879137dad.13 for ; Thu, 13 Dec 2012 09:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d63E96/6160OLuVcKEgRLI9BksImtpZrzihnFDIb9Cs=; b=JjQxTfDP4AKXnqM/YL2NgjD74nFs31qT8WyfTYQWvjNVy/OnbTeP32797INyCx2PEX NoHUnRP33qVuEaLGwyfftnK8mEruGxUu0XcUSGweYk/IlQnN6CRZq5TFOXVI1iHkTfmq R2mfsec+2vusnipQwCpkEppaoImHrMJL9nL4mss6jeOuPmL/Zp4TgDwJ4SNE468kfscg ZZtTtR31awZc6+fMZatF9teTCX4m7mvyD49MFgH865TpAPsu9xlCcQKOAsHqT7JOXjB7 IFpWQKkYYCR65u7nUUmZC+U8owQYMDFtCKOQZEX+e3UtppvUluGIqTjuVnwmdHToUW1R /5pw== MIME-Version: 1.0 Received: by 10.68.204.103 with SMTP id kx7mr7773087pbc.33.1355420795250; Thu, 13 Dec 2012 09:46:35 -0800 (PST) Received: by 10.66.148.136 with HTTP; Thu, 13 Dec 2012 09:46:35 -0800 (PST) In-Reply-To: <50C9AFC6.6080902@FreeBSD.org> References: <50C9AFC6.6080902@FreeBSD.org> Date: Thu, 13 Dec 2012 09:46:35 -0800 Message-ID: Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE From: olivier To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:46:46 -0000 Thanks. I'll be sure to follow your suggestions next time this happens. I have a naive question/suggestion though. I see from browsing past discussions on ZFS problems that it has been suggested a number of times that problems that appear to originate in ZFS in fact come from lower layers; in particular because of driver bugs or disks in the process of failing. It seems that it can take a lot of time to troubleshoot such problems. I accept that ZFS behavior correctly leaves dealing with timeouts to lower layers, but it seems to me that the ZFS layer would be a great place to warn the user about issues and provide some information to troubleshoot them. For example, if some I/O requests get lost because of a buggy driver, the driver itself might not be the best place to identify those lost requests. But perhaps we could have a compile time option in ZFS code that spits out a warning if it gets stuck waiting for a particular request to come back for more than say 10 seconds, and identifies the problematic disk? I'm sure there would be cases where these warnings would be unwarranted, and I imagine that changes in the code to provide such warnings would impact performance; so one certainly would not want that code active by default. But someone in my position could certainly recompile the kernel with a ZFS debugging option turned on to figure out the problem. I understand that ZFS code comes from upstream, and that you guys probably want to keep FreeBSD-specific changes minimal. If that's a big problem, even just a patch provided "as such" that does not make it into the FreeBSD code base might be extremely useful. I wish I could help write something like that, but I know very little about the kernel or ZFS. I would certainly be willing to help with testing. Just my 2 cents worth. Thanks for the help Olivier On Thu, Dec 13, 2012 at 2:36 AM, Andriy Gapon wrote: > > I decided to share here the comment that I made in private, so that more > people > could potentially benefit from it. > > on 03/12/2012 20:41 olivier olivier said the following: > > Hi all > > After upgrading from 9.0-RELEASE to 9.1-PRERELEASE #0 r243679 I'm having > > severe problems with NFS sharing of a ZFS volume. nfsd appears to hang at > > random times (between once every couple hours to once every two days) > while > > accessing a ZFS volume, and the only way I have found of resolving the > > problem is to reboot. The server console is sometimes still responsive > > during the nfsd hang, and I can read and write files to the same ZFS > volume > > while nfsd is hung. I am pasting below the output of procstat -kk on > nfsd, > > and details of my pool (nfsstat on the server gets hung when the problem > > has started occurring, and does not produce any output). The pool is v28 > > and was created from a bunch of volumes attached over Fibre Channel using > > the mpt driver. My system has a Supermicro board and 4 AMD Opteron 6274 > > CPUs. > > > > I did not experience any nfsd hangs with 9.0-RELEASE (same machine, > > essentially same configuration, same usage pattern). > > > > I would greatly appreciate any help to resolve this problem! > > > I've looked at the provided data and I do not see anything that implicates > ZFS. > My rules of the thumb for ZFS hangs: > - if there are threads in zio_wait > - if you can firm that they are indeed stuck there[*] > - if there are no threads in zio_interrupt > > [*] you have to be sure that a thread just sits in zio_wait and doesn't > make any > forward progress as opposed to the thread doing a lot of I/O and thus > having a > high probability of being seen in zio_wait. > > Then it is most likely that the problem is at the storage level. > Most likely it is a bug in storage controller driver which allowed an I/O > request > to get lost (instead of "errored out" or timed out). > > `camcontrol tags -v` can be used to query depth of a queue for each > disk > and determine the bad one. > > -- > Andriy Gapon > From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 17:54: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 28B9131A; Thu, 13 Dec 2012 17:54:06 +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 414318FC08; Thu, 13 Dec 2012 17:54:04 +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 TAA18521; Thu, 13 Dec 2012 19:54:02 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50CA1639.1010409@FreeBSD.org> Date: Thu, 13 Dec 2012 19:54:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: olivier Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE References: <50C9AFC6.6080902@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:54:06 -0000 on 13/12/2012 19:46 olivier said the following: > Thanks. I'll be sure to follow your suggestions next time this happens. > > I have a naive question/suggestion though. I see from browsing past discussions on > ZFS problems that it has been suggested a number of times that problems that > appear to originate in ZFS in fact come from lower layers; in particular because > of driver bugs or disks in the process of failing. It seems that it can take a lot > of time to troubleshoot such problems. I accept that ZFS behavior correctly leaves > dealing with timeouts to lower layers, but it seems to me that the ZFS layer would > be a great place to warn the user about issues and provide some information to > troubleshoot them. > > For example, if some I/O requests get lost because of a buggy driver, the driver > itself might not be the best place to identify those lost requests. But perhaps we > could have a compile time option in ZFS code that spits out a warning if it gets > stuck waiting for a particular request to come back for more than say 10 seconds, > and identifies the problematic disk? I'm sure there would be cases where these > warnings would be unwarranted, and I imagine that changes in the code to provide > such warnings would impact performance; so one certainly would not want that code > active by default. But someone in my position could certainly recompile the kernel > with a ZFS debugging option turned on to figure out the problem. > > I understand that ZFS code comes from upstream, and that you guys probably want to > keep FreeBSD-specific changes minimal. If that's a big problem, even just a patch > provided "as such" that does not make it into the FreeBSD code base might be > extremely useful. I wish I could help write something like that, but I know very > little about the kernel or ZFS. I would certainly be willing to help with testing. Google for "zfs deadman". This is already committed upstream and I think that it is imported into FreeBSD, but I am not sure... Maybe it's imported just into the vendor area and is not merged yet. So, when enabled this logic would panic a system as a way of letting know that something is wrong. You can read in the links why panic was selected for this job. And speaking FreeBSD-centric - I think that our CAM layer would be a perfect place to detect such issues in non-ZFS-specific way. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 18:14:04 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9002816; Thu, 13 Dec 2012 18:14:04 +0000 (UTC) (envelope-from olivier777a7@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id A859E8FC0A; Thu, 13 Dec 2012 18:14:04 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so1625773pad.13 for ; Thu, 13 Dec 2012 10:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6g0nOaq98CKYWgII6U589p3f1nd+p0JLBaOiH3ur4K0=; b=0bGzf/ZWuD0qlbcKx7GezWr3ZHtaCp4Oq9q7t6DjD73Ji3ot1d2uCjpFEW0KmEKYqq xJGLYsP5QI0qDrqfWD56Px6SiCBz5zX6QWxmS0OLFMmRSvgBbDW4QoYrZYaBe3PDS8Ke Ce84g9rvNEL2O7HQZaCaHbH3uUVfkQGUAVe6SXkFAu5I+jBnus8ZVDSGWVHUWZBfdMtw 5QxZdBZfqL/v46Ak4BqkZxDIU2mh3aDqj8CRW+4Iknqvi0fcaLEuREZi8CqudF7tRKt5 Dk8IHNDYn2plkZCns0iFFrAYQp8noECLArPjJ+yFG83HLajTZ5WCoV8pn6K4E3SOz1mN jEGg== MIME-Version: 1.0 Received: by 10.68.132.34 with SMTP id or2mr7752908pbb.133.1355422443853; Thu, 13 Dec 2012 10:14:03 -0800 (PST) Received: by 10.66.148.136 with HTTP; Thu, 13 Dec 2012 10:14:03 -0800 (PST) In-Reply-To: <50CA1639.1010409@FreeBSD.org> References: <50C9AFC6.6080902@FreeBSD.org> <50CA1639.1010409@FreeBSD.org> Date: Thu, 13 Dec 2012 10:14:03 -0800 Message-ID: Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE From: olivier To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:14:05 -0000 On Thu, Dec 13, 2012 at 9:54 AM, Andriy Gapon wrote: > Google for "zfs deadman". This is already committed upstream and I think > that it > is imported into FreeBSD, but I am not sure... Maybe it's imported just > into the > vendor area and is not merged yet. > Yes, that's exactly what I had in mind. The logic for panicking makes sense. As far as I can tell you're correct that deadman is in the vendor area but not merged. Any idea when it might make it into 9-STABLE? Thanks Olivier > So, when enabled this logic would panic a system as a way of letting know > that > something is wrong. You can read in the links why panic was selected for > this job. > > And speaking FreeBSD-centric - I think that our CAM layer would be a > perfect place > to detect such issues in non-ZFS-specific way. > > -- > Andriy Gapon > From owner-freebsd-fs@FreeBSD.ORG Thu Dec 13 19:38: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 D83DB73C; Thu, 13 Dec 2012 19:38:05 +0000 (UTC) (envelope-from olavgg@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 68EDC8FC12; Thu, 13 Dec 2012 19:38:04 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so2895550vba.13 for ; Thu, 13 Dec 2012 11:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8slPrRYAkN+K2QTxu6RxYrTYbPHymezf2j7FxgDaEhY=; b=IwNVVxuRwGOHVL/BovxQI80qBm/7IaYpQriiJx7+dibZfvAxY4tQy77koGfGO5mHvW pt6gd+vndWF9eY32SbsHgeAVi1zHN764aKtB4H48+byB3SKwBwDb1kdVCwxld2eboLFy MxA9c4/aDo1ZRbSXfftV7yFT+pxbIlaObfyzZYbCKAVWLvsaJsxZ0wnlg7P32n05bR8f A7QwK/be1iqsxmmCwCcmdmb3q7qBR9d/R06ZJFemK/9xOsJdDj0JqSOzTOPtIc+8ozMI bpucarTMTfPALhOL+9u4un4M7LHI+0mQ7GKERa4TXHYbfpdetJRibrzxzyzJ7CESU6bb X4mA== MIME-Version: 1.0 Received: by 10.220.238.148 with SMTP id ks20mr5586184vcb.5.1355427482862; Thu, 13 Dec 2012 11:38:02 -0800 (PST) Received: by 10.58.254.195 with HTTP; Thu, 13 Dec 2012 11:38:02 -0800 (PST) In-Reply-To: <20121213012632.M1201@besplex.bde.org> References: <20121213012632.M1201@besplex.bde.org> Date: Thu, 13 Dec 2012 20:38:02 +0100 Message-ID: Subject: Re: find vs ls performance for walking folders, are there any faster options? From: =?ISO-8859-1?Q?Olav_Gr=F8n=E5s_Gjerde?= To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-performance@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:38:06 -0000 Thank you, that was a really good answer. On Wed, Dec 12, 2012 at 3:50 PM, Bruce Evans wrote: > On Wed, 12 Dec 2012, [ISO-8859-1] Olav Gr=F8n=E5s Gjerde wrote: > >> I'm working on scanning filesystems to build a file search engine and >> came over something interesting. >> >> I can walk through 300 000 folders in ~19.5seconds with this command: >> ls -Ra | grep -e "./.*:" | sed "s/://" >> >> With find, it surprisingly takes ~50.5 seconds.: >> find . -type d > > > This is because 'find' with '-type' lstats all the files. It doesn't > use DT_DIR from dirent for some reason. ls can be slowed down similarly > using -F. > > >> My results are based on five runs of each command to warm up the disk >> cache. >> I've tried both this with both UFS and ZFS, and both filesystems shows >> the same speed difference. > > > I get almost exactly the same ratio of speeds on an old version of FreeBS= D. > All the data was cached, and there were only 7 symlinks. Thr file system > was mounted with -noatime, so the cache actually worked. > > >> On a modern Linux distribution(Ubuntu 12.10 with EXT4), ls is just >> slight faster than find(about 15-20%). > > > Apparently lstat() is relatively much slower in FreeBSD. It only takes > 5 usec here, but that is a lot for converting cached data (getpid() > takes 0.2 usec). A file system mounted with -atime might be much > slower, for writing directory timestamps (the sync of the timestamps > is delayed, but it is a very heavyweight operation). > > >> Are there a faster way to walk folders on FreeBSD? Are there some >> options(sysctl) I could tune to improve the performance? > > > Nothing much faster than find without -type. Whatever fts(3) gives. > > Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Dec 14 06:14: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 D0792D3C; Fri, 14 Dec 2012 06:14:16 +0000 (UTC) (envelope-from olivier777a7@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 853A88FC0C; Fri, 14 Dec 2012 06:14:16 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so1975695pad.13 for ; Thu, 13 Dec 2012 22:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lD8ye38yOiC5Jllvu4GChUMBUnwpuV1W3TwPBjmwkdc=; b=l0hy/U0D9YWmYjHUsUOU5DX/DfSx9KYWHGCq33K/ReOdpXQWW9TMfSNxn//mtRmMsP yAbnjfbPby1d8tayMjeiOkmvesPz/xhG6oVkCPpcWsenBYWWCyucQHR5LR2XC9kpggMO INapMSGn2/cLBqAL6TMsrV4pnQ46Ss5B/CBqJg1pIMtj1xqMMscmuLUAhPtS6f4PdaDE xIXUtaWXJ9j5BhnY0UbMyFSdLyFXC1/oJ3TwFBkWQ9mvIgWT6NPcJIdre/rJ8CqxHcV3 qbSJuoDPMBdnLl7idpOv9nn+JoP7PULB3AMFyddbfzwprCGC5KtgXEpa6I+JpjDAwDFM AiuQ== MIME-Version: 1.0 Received: by 10.68.238.165 with SMTP id vl5mr13179584pbc.0.1355465655907; Thu, 13 Dec 2012 22:14:15 -0800 (PST) Received: by 10.66.148.136 with HTTP; Thu, 13 Dec 2012 22:14:15 -0800 (PST) In-Reply-To: References: <50C9AFC6.6080902@FreeBSD.org> <50CA1639.1010409@FreeBSD.org> Date: Thu, 13 Dec 2012 22:14:15 -0800 Message-ID: Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE From: olivier To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org, ken@FreeBSD.org, freebsd-stable@freebsd.org, Kashyap.Desai@lsi.com X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 06:14:17 -0000 For what it's worth, I think I might have solved my problem by reverting to an older version of the mps driver. I checked out a recent version of 9-STABLE and reversed the changes in http://svnweb.freebsd.org/base?view=revision&revision=230592 (perhaps there was a simpler way of reverting to the older mps driver). So far so good, no hang even when hammering the file system. This does not conclusively prove that the new LSI mps driver is at fault, but that seems to be a likely explanation. Thanks to everybody who pointed me in the right direction. Hope this helps others who run into similar problems with 9.1 Olivier On Thu, Dec 13, 2012 at 10:14 AM, olivier wrote: > > > On Thu, Dec 13, 2012 at 9:54 AM, Andriy Gapon wrote: > >> Google for "zfs deadman". This is already committed upstream and I think >> that it >> is imported into FreeBSD, but I am not sure... Maybe it's imported just >> into the >> vendor area and is not merged yet. >> > > Yes, that's exactly what I had in mind. The logic for panicking makes > sense. > As far as I can tell you're correct that deadman is in the vendor area but > not merged. Any idea when it might make it into 9-STABLE? > Thanks > Olivier > > > > >> So, when enabled this logic would panic a system as a way of letting know >> that >> something is wrong. You can read in the links why panic was selected for >> this job. >> >> And speaking FreeBSD-centric - I think that our CAM layer would be a >> perfect place >> to detect such issues in non-ZFS-specific way. >> >> -- >> Andriy Gapon >> > > From owner-freebsd-fs@FreeBSD.ORG Fri Dec 14 09:53: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 8729D6E5 for ; Fri, 14 Dec 2012 09:53:21 +0000 (UTC) (envelope-from paranormal@isgroup.com.ua) Received: from isgroup.com.ua (mail.isgroup.com.ua [46.229.54.104]) by mx1.freebsd.org (Postfix) with ESMTP id D03F68FC08 for ; Fri, 14 Dec 2012 09:53:20 +0000 (UTC) Received: from [192.168.11.5] (unused-213.111.71.78.bilink.ua [213.111.71.78] (may be forged)) (authenticated bits=0) by isgroup.com.ua (8.14.5/8.14.5) with ESMTP id qBE8KK6b013349 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 14 Dec 2012 10:20:20 +0200 (EET) (envelope-from paranormal@isgroup.com.ua) Subject: Re: snapshot management tool? From: paranormal To: freebsd-fs@freebsd.org In-Reply-To: <20121213162137.78332@relay.ibs.dn.ua> References: <20121213162137.78332@relay.ibs.dn.ua> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-aCMuJl41PGNt/6XKe2Wn" Date: Fri, 14 Dec 2012 11:52:45 +0200 Message-ID: <1355478765.36863.15.camel@eva02> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-101.0 required=5.0 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on isgroup.com.ua X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 09:53:21 -0000 --=-aCMuJl41PGNt/6XKe2Wn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I like zfs-snapshot-mgmt because of yaml. You can do weird things with yaml. system: &system # Create snapshots every 24 hours, starting at 20:00. creation_rule: at_multiple: 1440 offset: 1200 # Keep daily snapshots created at 20:00 (in this case all). preservation_rules: - { for_minutes: 5760, at_multiple: 1440, offset: 1200 } snapshot_prefix: auto- filesystems: zroot: *system zroot/local: *system zroot/var: *system On Thu, 2012-12-13 at 16:21 +0300, Zeus Panchenko wrote: > hi all, >=20 > please, share what are you using to manage snapshots >=20 > in ports collection I see: >=20 > zfs-periodic > zfs-snapshot-mgmt > zfsnap > zfstools >=20 >=20 > is it planned to implement some native tool? >=20 --=-aCMuJl41PGNt/6XKe2Wn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAABAgAGBQJQyvbsAAoJEOKdyUSm7MVLGCgP/2z6QmLKJbXpLVZef/mn0JbD Jqf6Ta/GncOCV+n242XfDrEnSmWRKx4S/lA0RXa2SoyD4Jf5MJnxOHNO8RVAiVwQ w65pBvlmDedmycoXdQ00GrrEFzycULzu9vTW9h/KxkUYiB5ppW32g3QM8D0dbLtS Ek0rmV+iiC3nLjmvBaWw1AphIHqUOfW8ftaVR/GHj9AH5YeuExDQ5jd+TZF3CpRn l2f/7uJ3/86rmabs75QOAoMUI+eZsb+EE/k+WpBkMPeJ4yl4Ek10yQ9MuBNmjMVa t74XSjzQoJ+uvMK4sq4kmB2LoMXo80hHo9KvgR4jaropb97Xs7vH5cS2tMp65eh6 ZGKyciNGeJUxi5ZPvtcnk7e8zf/8WQbAkGbxy78TE+3NRU4+tz8E96ZCMSgne+YK PQ4jKkuj1m1UzwgELB7SltS6fB1i2ZqTM1cNbcCqr8fIFs5Ab2GrjtZDCWC1tNye oCax53VjUElRS7rMgrKKOlq/3PQxERtBhucAUz9ORVTgynd3jFegBKcPa9XY7fkn aqXFr9vgVJJ3Nn0Co54CbSLqX5MP4mqPaSNBVGIFRP7GbeVwvwzaQFN6Px3K7FYx Qkel1KHyy9LvYGww+NqJPUAAShqiLEgnzNA6RhjqYHHEssI7saG3cwSLvNlyGa2x 6yv+cu+4LeXqWj/jzl0N =J907 -----END PGP SIGNATURE----- --=-aCMuJl41PGNt/6XKe2Wn-- From owner-freebsd-fs@FreeBSD.ORG Fri Dec 14 13:51: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 240DA807 for ; Fri, 14 Dec 2012 13:51:49 +0000 (UTC) (envelope-from jas@cse.yorku.ca) Received: from bronze.cs.yorku.ca (bronze.cs.yorku.ca [130.63.95.34]) by mx1.freebsd.org (Postfix) with ESMTP id D8D288FC13 for ; Fri, 14 Dec 2012 13:51:48 +0000 (UTC) Received: from [130.63.97.125] (ident=jas) by bronze.cs.yorku.ca with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TjVQZ-0005lh-C7; Fri, 14 Dec 2012 08:35:47 -0500 Message-ID: <50CB2B33.6000103@cse.yorku.ca> Date: Fri, 14 Dec 2012 08:35:47 -0500 From: Jason Keltz User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, olivier777a7@gmail.com Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE References: <50C9AFC6.6080902@FreeBSD.org> <50CA1639.1010409@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Spam-Level: - X-Spam-Report: Content preview: Hi Olivier, I'm running a system using the mps driver under 9.1. The system has two 9205-8e cards and one 9207-8i. Can you give me the code that you're running that might eventually cause the lockup, and I'll try to see if I can make it happen here? If it happens in multiple mps installations, maybe someone can look at the driver to see what the issue might be. Since my system isn't yet in production, I'm more than happy to leave it running a test.... [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 13:51:49 -0000 Hi Olivier, I'm running a system using the mps driver under 9.1. The system has two 9205-8e cards and one 9207-8i. Can you give me the code that you're running that might eventually cause the lockup, and I'll try to see if I can make it happen here? If it happens in multiple mps installations, maybe someone can look at the driver to see what the issue might be. Since my system isn't yet in production, I'm more than happy to leave it running a test.... Jason. On 12/14/2012 01:14 AM, olivier wrote: > For what it's worth, I think I might have solved my problem by reverting to > an older version of the mps driver. I checked out a recent version of > 9-STABLE and reversed the changes in > http://svnweb.freebsd.org/base?view=revision&revision=230592 (perhaps there > was a simpler way of reverting to the older mps driver). So far so good, no > hang even when hammering the file system. > > This does not conclusively prove that the new LSI mps driver is at fault, > but that seems to be a likely explanation. > > Thanks to everybody who pointed me in the right direction. Hope this helps > others who run into similar problems with 9.1 > Olivier > > On Thu, Dec 13, 2012 at 10:14 AM, olivier wrote: > >> >> On Thu, Dec 13, 2012 at 9:54 AM, Andriy Gapon wrote: >> >>> Google for "zfs deadman". This is already committed upstream and I think >>> that it >>> is imported into FreeBSD, but I am not sure... Maybe it's imported just >>> into the >>> vendor area and is not merged yet. >>> >> Yes, that's exactly what I had in mind. The logic for panicking makes >> sense. >> As far as I can tell you're correct that deadman is in the vendor area but >> not merged. Any idea when it might make it into 9-STABLE? >> Thanks >> Olivier >> >> >> >> >>> So, when enabled this logic would panic a system as a way of letting know >>> that >>> something is wrong. You can read in the links why panic was selected for >>> this job. >>> >>> And speaking FreeBSD-centric - I think that our CAM layer would be a >>> perfect place >>> to detect such issues in non-ZFS-specific way. >>> >>> -- >>> Andriy Gapon >>> >> > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Dec 14 15:29:19 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8127C674 for ; Fri, 14 Dec 2012 15:29:19 +0000 (UTC) (envelope-from olivier777a7@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0D08FC13 for ; Fri, 14 Dec 2012 15:29:19 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so2242974pbc.13 for ; Fri, 14 Dec 2012 07:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zy3VVPzj01Nv0K+ET0GEKel7VUOCU/iYy75AkOXBJy4=; b=LgvYXgBjitIvRn/d19jJ3vsLvoZItWaK0SzSQuE9fYjy6ZpHy+PRIRh2Nl7j2L6jRr XU04LweNB/r1XeZCBTnnnCZJzreUC1LfOs1V4XVQGaJxaJqeHCbG6ssO3NNRMzEuxmbd m+LeosHtGmYqEUwgPTdZ3RmD1aBA84xfY35RzBa4YWgIFMFv0R0AcisEQQqjKbwsTm4w V1fRseVIoAWBxRTw+i+e5MLMcLDUDGBBV1x1l9jZ0WXFsyNm3xulH6nL4jgr8RZAeobV ZvY9XmTguA2ASjhVSPQCaB7NwK10ncXf1ko1QYRSeTXgM9ZVdEkhpiQj1I9as1l3z2YE qCNg== MIME-Version: 1.0 Received: by 10.66.73.132 with SMTP id l4mr16730057pav.48.1355498958874; Fri, 14 Dec 2012 07:29:18 -0800 (PST) Received: by 10.66.148.136 with HTTP; Fri, 14 Dec 2012 07:29:18 -0800 (PST) In-Reply-To: <50CB2B33.6000103@cse.yorku.ca> References: <50C9AFC6.6080902@FreeBSD.org> <50CA1639.1010409@FreeBSD.org> <50CB2B33.6000103@cse.yorku.ca> Date: Fri, 14 Dec 2012 07:29:18 -0800 Message-ID: Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE From: olivier To: Jason Keltz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:29:19 -0000 Unfortunately I don't have a single piece of code that triggers this. This happens on a server than a bunch of other machines can access simultaneously. My impression is that perhaps sustained concurrent reads or writes are what causes the problem. So maybe run a bunch of dd if=/dev/random of=temp bs=xx in parallel, or use something like bonnie++? Olivier On Fri, Dec 14, 2012 at 5:35 AM, Jason Keltz wrote: > Hi Olivier, > > I'm running a system using the mps driver under 9.1. The system has two > 9205-8e cards and one 9207-8i. Can you give me the code that you're > running that might eventually cause the lockup, and I'll try to see if I > can make it happen here? If it happens in multiple mps installations, > maybe someone can look at the driver to see what the issue might be. Since > my system isn't yet in production, I'm more than happy to leave it running > a test.... > > Jason. > > > On 12/14/2012 01:14 AM, olivier wrote: > >> For what it's worth, I think I might have solved my problem by reverting >> to >> an older version of the mps driver. I checked out a recent version of >> 9-STABLE and reversed the changes in >> http://svnweb.freebsd.org/**base?view=revision&revision=**230592(perhaps there >> was a simpler way of reverting to the older mps driver). So far so good, >> no >> hang even when hammering the file system. >> >> This does not conclusively prove that the new LSI mps driver is at fault, >> but that seems to be a likely explanation. >> >> Thanks to everybody who pointed me in the right direction. Hope this helps >> others who run into similar problems with 9.1 >> Olivier >> >> On Thu, Dec 13, 2012 at 10:14 AM, olivier wrote: >> >> >>> On Thu, Dec 13, 2012 at 9:54 AM, Andriy Gapon wrote: >>> >>> Google for "zfs deadman". This is already committed upstream and I >>>> think >>>> that it >>>> is imported into FreeBSD, but I am not sure... Maybe it's imported just >>>> into the >>>> vendor area and is not merged yet. >>>> >>>> Yes, that's exactly what I had in mind. The logic for panicking makes >>> sense. >>> As far as I can tell you're correct that deadman is in the vendor area >>> but >>> not merged. Any idea when it might make it into 9-STABLE? >>> Thanks >>> Olivier >>> >>> >>> >>> >>> So, when enabled this logic would panic a system as a way of letting >>>> know >>>> that >>>> something is wrong. You can read in the links why panic was selected >>>> for >>>> this job. >>>> >>>> And speaking FreeBSD-centric - I think that our CAM layer would be a >>>> perfect place >>>> to detect such issues in non-ZFS-specific way. >>>> >>>> -- >>>> Andriy Gapon >>>> >>>> >>> ______________________________**_________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@**freebsd.org >> " >> > > From owner-freebsd-fs@FreeBSD.ORG Fri Dec 14 18:13:33 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3AC179B for ; Fri, 14 Dec 2012 18:13:33 +0000 (UTC) (envelope-from rcartwri@asu.edu) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 58ADA8FC08 for ; Fri, 14 Dec 2012 18:13:33 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so6408222iec.13 for ; Fri, 14 Dec 2012 10:13:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=TCccf/NuOiAtiT6yKTFP08HMMf0LuP3gZ4LuGYrMoac=; b=BKcfM8Zf6UzaOIKhEeU/V92M7eES01DRAh1ck8fWUEqpRpQDDwcVNgGlZZNIqe4Mhf SD8ERDNOeNUez1djsljRi/iuJqRjmc762P2tUFpXwAFxDFWk8/pyRp5nziWsy5UVizTW dxvXG0SkSCEb9odIpeaeu8z+vC73xTUTRvIJgvrWVhVRwqCOR8lsXmCukB54S8gtyo10 KCu/U4zswZfhRlGPdIsTd+4mYzEzLenUJIYluzXTmTL7FdMP+KexKz51xx9C9flMwQFz kQMOKXv3Kues//o+ugR7jpLEl+hzwNfBp7atgGhvquqbdsngg8+yJIm3OzIU1m/vPIi6 h//A== MIME-Version: 1.0 Received: by 10.43.62.133 with SMTP id xa5mr5353944icb.28.1355508809897; Fri, 14 Dec 2012 10:13:29 -0800 (PST) Received: by 10.64.64.39 with HTTP; Fri, 14 Dec 2012 10:13:29 -0800 (PST) In-Reply-To: References: <50C9AFC6.6080902@FreeBSD.org> <50CA1639.1010409@FreeBSD.org> Date: Fri, 14 Dec 2012 11:13:29 -0700 Message-ID: Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE From: "Reed A. Cartwright" To: olivier Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmyhRcmxyg87LEMMYUPDiT0WJPvkCXMPhcolJTVX1i1mlW36BW/EuphmxVKE00r+/N3oIMg Cc: freebsd-fs@freebsd.org, "freebsd-stable@freebsd.org" , ken@freebsd.org, Kashyap.Desai@lsi.com, Andriy Gapon X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:13:33 -0000 I need to do this as well. Can you give me a quick primer on the commands you used to revert to the earlier driver? On Thu, Dec 13, 2012 at 11:14 PM, olivier wrote: > For what it's worth, I think I might have solved my problem by reverting to > an older version of the mps driver. I checked out a recent version of > 9-STABLE and reversed the changes in > http://svnweb.freebsd.org/base?view=revision&revision=230592 (perhaps there > was a simpler way of reverting to the older mps driver). So far so good, no > hang even when hammering the file system. > > This does not conclusively prove that the new LSI mps driver is at fault, > but that seems to be a likely explanation. > > Thanks to everybody who pointed me in the right direction. Hope this helps > others who run into similar problems with 9.1 > Olivier > > On Thu, Dec 13, 2012 at 10:14 AM, olivier wrote: > >> >> >> On Thu, Dec 13, 2012 at 9:54 AM, Andriy Gapon wrote: >> >>> Google for "zfs deadman". This is already committed upstream and I think >>> that it >>> is imported into FreeBSD, but I am not sure... Maybe it's imported just >>> into the >>> vendor area and is not merged yet. >>> >> >> Yes, that's exactly what I had in mind. The logic for panicking makes >> sense. >> As far as I can tell you're correct that deadman is in the vendor area but >> not merged. Any idea when it might make it into 9-STABLE? >> Thanks >> Olivier >> >> >> >> >>> So, when enabled this logic would panic a system as a way of letting know >>> that >>> something is wrong. You can read in the links why panic was selected for >>> this job. >>> >>> And speaking FreeBSD-centric - I think that our CAM layer would be a >>> perfect place >>> to detect such issues in non-ZFS-specific way. >>> >>> -- >>> Andriy Gapon >>> >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Reed A. Cartwright, PhD Assistant Professor of Genomics, Evolution, and Bioinformatics School of Life Sciences Center for Evolutionary Medicine and Informatics The Biodesign Institute Arizona State University From owner-freebsd-fs@FreeBSD.ORG Fri Dec 14 18:33:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14AA2C0; Fri, 14 Dec 2012 18:33:10 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 788E28FC08; Fri, 14 Dec 2012 18:33:09 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id qBEILlY9066662; Fri, 14 Dec 2012 11:21:47 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id qBEILltT066661; Fri, 14 Dec 2012 11:21:47 -0700 (MST) (envelope-from ken) Date: Fri, 14 Dec 2012 11:21:47 -0700 From: "Kenneth D. Merry" To: olivier Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE Message-ID: <20121214182147.GA66456@nargothrond.kdm.org> References: <50C9AFC6.6080902@FreeBSD.org> <50CA1639.1010409@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Kashyap.Desai@lsi.com, Andriy Gapon X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:33:10 -0000 This doesn't quite make sense. In your original email, you said that you're using a mpt-based Fibre Channel card and have a ZFS filesystem on top of that. If that's the case, why would going back to an older version of the mps(4) driver change things at all? It has no support for that hardware. Ken On Thu, Dec 13, 2012 at 22:14:15 -0800, olivier wrote: > For what it's worth, I think I might have solved my problem by reverting to > an older version of the mps driver. I checked out a recent version of > 9-STABLE and reversed the changes in > http://svnweb.freebsd.org/base?view=revision&revision=230592 (perhaps there > was a simpler way of reverting to the older mps driver). So far so good, no > hang even when hammering the file system. > > This does not conclusively prove that the new LSI mps driver is at fault, > but that seems to be a likely explanation. > > Thanks to everybody who pointed me in the right direction. Hope this helps > others who run into similar problems with 9.1 > Olivier > > On Thu, Dec 13, 2012 at 10:14 AM, olivier wrote: > > > > > > > On Thu, Dec 13, 2012 at 9:54 AM, Andriy Gapon wrote: > > > >> Google for "zfs deadman". This is already committed upstream and I think > >> that it > >> is imported into FreeBSD, but I am not sure... Maybe it's imported just > >> into the > >> vendor area and is not merged yet. > >> > > > > Yes, that's exactly what I had in mind. The logic for panicking makes > > sense. > > As far as I can tell you're correct that deadman is in the vendor area but > > not merged. Any idea when it might make it into 9-STABLE? > > Thanks > > Olivier > > > > > > > > > >> So, when enabled this logic would panic a system as a way of letting know > >> that > >> something is wrong. You can read in the links why panic was selected for > >> this job. > >> > >> And speaking FreeBSD-centric - I think that our CAM layer would be a > >> perfect place > >> to detect such issues in non-ZFS-specific way. > >> > >> -- > >> Andriy Gapon > >> > > > > -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-fs@FreeBSD.ORG Fri Dec 14 19:19:47 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (unknown [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 168A6824; Fri, 14 Dec 2012 19:19:47 +0000 (UTC) (envelope-from olivier777a7@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A44D08FC0A; Fri, 14 Dec 2012 19:19:46 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so2371163pbc.13 for ; Fri, 14 Dec 2012 11:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ET5VX6TXjBFws3SOtAy/UObtCXX6Br02btDImzD5ILA=; b=i1A+4vV4tIYiEkFYaNHdNn5+I0bxTcmx3GuL843+crSrC8AOmXDkVC8OYvlicgeA/y B/JjyNk/OUD/2Cv6lHcB4av3yEdXEkUsnBWip+MAuh2ynaRwon/qZFZ3TffeSROTRgXd B6bdh82XiRwE5t2OxRDBmErZj4DDxIwUKKZBcPaJZdztBVWZ8Q1JObuPOtooIi77ORxk EALMk6dFfGgG+IKcnLPxybh1ND/sy5euyeNyWCffGvkeuBcd14VHs0J7MxlpLKl9K8l4 aZ4YThXerIdNPZs8EpjbeaLIJ9x1s3hd4bw7ue8j+JzUWR+7rbLtf3/PKnollf03RRHF oIxw== MIME-Version: 1.0 Received: by 10.66.75.162 with SMTP id d2mr18415078paw.27.1355512780539; Fri, 14 Dec 2012 11:19:40 -0800 (PST) Received: by 10.66.148.136 with HTTP; Fri, 14 Dec 2012 11:19:40 -0800 (PST) In-Reply-To: <20121214182147.GA66456@nargothrond.kdm.org> References: <50C9AFC6.6080902@FreeBSD.org> <50CA1639.1010409@FreeBSD.org> <20121214182147.GA66456@nargothrond.kdm.org> Date: Fri, 14 Dec 2012 11:19:40 -0800 Message-ID: Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE From: olivier To: "Kenneth D. Merry" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Kashyap.Desai@lsi.com, Andriy Gapon X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 19:19:47 -0000 Sorry about the confusion. I'd forgotten to mention that a few of the disks in the pool in which that ZFS filesystem resides are actually provided through the mps driver. In other words, my pool has a couple disks it sees through the mps driver, and other disks it sees through the mpt driver. (For the sake of completeness, the same machine also has ZFS on root, with a pool formed from a single mps disk; I haven't formally excluded that the hangs are due to my root pool but that probably doesn't change the problem). Reed: I'm happy to provide my compiled kernel for you to try out (if you're using generic). To compile yourself, checkout 9-STABLE, replace /usr/src/sys/dev/mps by the version from 9.0, and edit sys/conf/files and sys/modules/mps/Makefile to revert the diffs shown in http://svnweb.freebsd.org/base?view=revision&revision=230592 I'm sure there's a more elegant way of doing this (would it be safe to just copy over mps.ko from 9.0?). Olivier On Fri, Dec 14, 2012 at 10:21 AM, Kenneth D. Merry wrote: > > This doesn't quite make sense. In your original email, you said that > you're using a mpt-based Fibre Channel card and have a ZFS filesystem on > top of that. > > If that's the case, why would going back to an older version of the mps(4) > driver change things at all? It has no support for that hardware. > > Ken > > On Thu, Dec 13, 2012 at 22:14:15 -0800, olivier wrote: > > For what it's worth, I think I might have solved my problem by reverting > to > > an older version of the mps driver. I checked out a recent version of > > 9-STABLE and reversed the changes in > > http://svnweb.freebsd.org/base?view=revision&revision=230592 (perhaps > there > > was a simpler way of reverting to the older mps driver). So far so good, > no > > hang even when hammering the file system. > > > > This does not conclusively prove that the new LSI mps driver is at fault, > > but that seems to be a likely explanation. > > > > Thanks to everybody who pointed me in the right direction. Hope this > helps > > others who run into similar problems with 9.1 > > Olivier > > > > On Thu, Dec 13, 2012 at 10:14 AM, olivier > wrote: > > > > > > > > > > > On Thu, Dec 13, 2012 at 9:54 AM, Andriy Gapon wrote: > > > > > >> Google for "zfs deadman". This is already committed upstream and I > think > > >> that it > > >> is imported into FreeBSD, but I am not sure... Maybe it's imported > just > > >> into the > > >> vendor area and is not merged yet. > > >> > > > > > > Yes, that's exactly what I had in mind. The logic for panicking makes > > > sense. > > > As far as I can tell you're correct that deadman is in the vendor area > but > > > not merged. Any idea when it might make it into 9-STABLE? > > > Thanks > > > Olivier > > > > > > > > > > > > > > >> So, when enabled this logic would panic a system as a way of letting > know > > >> that > > >> something is wrong. You can read in the links why panic was selected > for > > >> this job. > > >> > > >> And speaking FreeBSD-centric - I think that our CAM layer would be a > > >> perfect place > > >> to detect such issues in non-ZFS-specific way. > > >> > > >> -- > > >> Andriy Gapon > > >> > > > > > > > > -- > Kenneth Merry > ken@FreeBSD.ORG > From owner-freebsd-fs@FreeBSD.ORG Fri Dec 14 21:55:16 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAD9519F5; Fri, 14 Dec 2012 21:55:16 +0000 (UTC) (envelope-from crees@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 784518FC0A; Fri, 14 Dec 2012 21:55:16 +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 qBEJO1WS081647; Fri, 14 Dec 2012 19:24:01 GMT (envelope-from crees@freefall.freebsd.org) Received: (from crees@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBEJO0GO081643; Fri, 14 Dec 2012 19:24:00 GMT (envelope-from crees) Date: Fri, 14 Dec 2012 19:24:00 GMT Message-Id: <201212141924.qBEJO0GO081643@freefall.freebsd.org> To: ruben@verweg.com, crees@FreeBSD.org, freebsd-fs@FreeBSD.org From: crees@FreeBSD.org Subject: Re: conf/144213: [rc.d] [patch] Disappearing zvols on reboot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 21:55:16 -0000 Synopsis: [rc.d] [patch] Disappearing zvols on reboot State-Changed-From-To: open->closed State-Changed-By: crees State-Changed-When: Fri Dec 14 19:23:59 UTC 2012 State-Changed-Why: volinit is no longer in FreeBSD, and this bug can't be reproduced in a recent version of FreeBSD. http://lists.freebsd.org/pipermail/freebsd-rc/2012-October/003055.html Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=144213 From owner-freebsd-fs@FreeBSD.ORG Sat Dec 15 01:49: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 D39F52D4 for ; Sat, 15 Dec 2012 01:49:15 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 9093D8FC14 for ; Sat, 15 Dec 2012 01:49:15 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 2B0697E820; Sat, 15 Dec 2012 12:49:06 +1100 (EST) Message-ID: <50CBD711.8090607@freebsd.org> Date: Sat, 15 Dec 2012 12:49:05 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: Zeus Panchenko Subject: Re: snapshot management tool? References: <20121213162137.78332@relay.ibs.dn.ua> In-Reply-To: <20121213162137.78332@relay.ibs.dn.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 01:49:15 -0000 On 12/14/12 00:21, Zeus Panchenko wrote: > hi all, > > please, share what are you using to manage snapshots > > in ports collection I see: > > zfs-periodic > zfs-snapshot-mgmt > zfsnap > zfstools I use zfsnap on all my ZFS based systems e.g. root@newtcphub:~ # tail -n 15 /etc/crontab # Remove snapshots with an expired TTL at 05:35/17:35 each day. 35 5,17 * * * root /usr/local/sbin/zfSnap -d -p 15mins_ -p daily_ -p weekly_ -p monthly_ # Take 15min snapshots of important filesystems, rolling them every 3 days. 8/15 * * * * root /usr/local/sbin/zfSnap -S -s -a 3d -p 15mins_ -R newtcphub newtcphub/usr newtcphub/var -r newtcphub/home newtcphub/data # Take daily snapshots of important filesystems at 06:10, rolling them every 14 days. 10 6 * * * root /usr/local/sbin/zfSnap -S -s -a 14d -p daily_ -R newtcphub newtcphub/usr newtcphub/var -r newtcphub/home newtcphub/data # Take weekly snapshots of important filesystems at 06:25 on Sundays, rolling them every 6 weeks. 25 6 * * sun root /usr/local/sbin/zfSnap -Ss -a 6w -p weekly_ -R newtcphub newtcphub/usr newtcphub/var -r newtcphub/home newtcphub/data # Take monthly snapshots of important filesystems at 06:35 on the 1st of each month, rolling them every 4 months. 35 6 1 * * root /usr/local/sbin/zfSnap -Ss -a 4m -p monthly_ -R newtcphub newtcphub/usr newtcphub/var -r newtcphub/home newtcphub/data Haven't tried the other ports so don't have an opinion on them. Cheers, Lawrence From owner-freebsd-fs@FreeBSD.ORG Sat Dec 15 14:24: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 772605EE for ; Sat, 15 Dec 2012 14:24:26 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id C2B8C8FC12 for ; Sat, 15 Dec 2012 14:24:25 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id E090FF2584F; Sat, 15 Dec 2012 15:19:03 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 10.0913] X-CRM114-CacheID: sfid-20121215_15190_90677E42 X-CRM114-Status: Good ( pR: 10.0913 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sat Dec 15 15:19:03 2012 X-DSPAM-Confidence: 0.6566 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50cc86d7748791819472988 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, the+code, 0.00426, svn, 0.00461, revision, 0.00503, can+I, 0.00503, stack, 0.00613, I+get, 0.00669, it's+the, 0.00735, it's+the, 0.00735, panics, 0.00787, this?, 0.00847, =+0, 0.00861, =+0, 0.00861, Received*Sat+15, 0.99000, Date*15+Dec, 0.99000, If+it's, 0.01000, Subject*panic, 0.01000, file+system, 0.01000, Received*15+Dec, 0.99000, backtrace, 0.01000, 597, 0.01000, Subject*zfs, 0.01000, Date*Sat+15, 0.99000, the+latter, 0.01000, User-Agent*i686, 0.01156, User-Agent*Mozilla/5.0+(X11, 0.01156, X-Spambayes-Classification: ham; 0.00 Received: from [192.168.3.2] (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 69540F25844 for ; Sat, 15 Dec 2012 15:19:02 +0100 (CET) Message-ID: <50CC86D4.2070502@fsn.hu> Date: Sat, 15 Dec 2012 15:19:00 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: zfs panic, solaris_assert Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 14:24:26 -0000 Hi, Since running svn revision r243704 I get frequent panics: panic: solaris assert: sa.sa_magic == 0x2F505A (0x4f22a8ed == 0x2f505a), file: /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, line: 597 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1ce assfail3() at assfail3+0x29 zfs_space_delta_cb() at zfs_space_delta_cb+0xbe dmu_objset_userquota_get_ids() at dmu_objset_userquota_get_ids+0x142 dnode_sync() at dnode_sync+0xc5 dmu_objset_sync_dnodes() at dmu_objset_sync_dnodes+0x5d dmu_objset_sync() at dmu_objset_sync+0x17f dsl_pool_sync() at dsl_pool_sync+0xca spa_sync() at spa_sync+0x34a txg_sync_thread() at txg_sync_thread+0x139 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff90231accf0, rbp = 0 --- I can't tell whether it's the data or the code. If the latter, is this fixed in later revisions? If it's the file system, what can I do with this? From owner-freebsd-fs@FreeBSD.ORG Sat Dec 15 14:25:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02D56680 for ; Sat, 15 Dec 2012 14:25:28 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 79A358FC14 for ; Sat, 15 Dec 2012 14:25:26 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Tjsg3-0006X6-LV for freebsd-fs@freebsd.org; Sat, 15 Dec 2012 15:25:20 +0100 Received: from h253044.upc-h.chello.nl ([62.194.253.44] helo=pinky) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tjsg3-0005go-1E for freebsd-fs@freebsd.org; Sat, 15 Dec 2012 15:25:19 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: snapshot management tool? References: <20121213162137.78332@relay.ibs.dn.ua> <50CBD711.8090607@freebsd.org> Date: Sat, 15 Dec 2012 15:25:21 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <50CBD711.8090607@freebsd.org> User-Agent: Opera Mail/12.11 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 488b5a33f748713be529de57fa847022 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 14:25:28 -0000 On Sat, 15 Dec 2012 02:49:05 +0100, Lawrence Stewart wrote: > On 12/14/12 00:21, Zeus Panchenko wrote: >> hi all, >> >> please, share what are you using to manage snapshots >> >> in ports collection I see: >> >> zfs-periodic >> zfs-snapshot-mgmt >> zfsnap >> zfstools > > I use zfsnap on all my ZFS based systems e.g. > > root@newtcphub:~ # tail -n 15 /etc/crontab > > # Remove snapshots with an expired TTL at 05:35/17:35 each day. > 35 5,17 * * * root /usr/local/sbin/zfSnap > -d -p 15mins_ -p daily_ -p weekly_ -p monthly_ > > # Take 15min snapshots of important filesystems, rolling them every 3 > days. > 8/15 * * * * root /usr/local/sbin/zfSnap > -S -s -a 3d -p 15mins_ -R newtcphub newtcphub/usr newtcphub/var -r > newtcphub/home newtcphub/data > > # Take daily snapshots of important filesystems at 06:10, rolling them > every 14 days. > 10 6 * * * root /usr/local/sbin/zfSnap > -S -s -a 14d -p daily_ -R newtcphub newtcphub/usr newtcphub/var -r > newtcphub/home newtcphub/data > > # Take weekly snapshots of important filesystems at 06:25 on Sundays, > rolling them every 6 weeks. > 25 6 * * sun root /usr/local/sbin/zfSnap > -Ss -a 6w -p weekly_ -R newtcphub newtcphub/usr newtcphub/var -r > newtcphub/home newtcphub/data > > # Take monthly snapshots of important filesystems at 06:35 on the 1st of > each month, rolling them every 4 months. > 35 6 1 * * root /usr/local/sbin/zfSnap > -Ss -a 4m -p monthly_ -R newtcphub newtcphub/usr newtcphub/var -r > newtcphub/home newtcphub/data > > > Haven't tried the other ports so don't have an opinion on them. > > Cheers, > Lawrence Does this also work for a home computer which is not always on? I'm curious about how people handle that. Ronald. From owner-freebsd-fs@FreeBSD.ORG Sat Dec 15 14:36:28 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E0B1D73 for ; Sat, 15 Dec 2012 14:36:28 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 94C658FC0A for ; Sat, 15 Dec 2012 14:36:27 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 3C0FAF2594F; Sat, 15 Dec 2012 15:36:26 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 16.3457] X-CRM114-CacheID: sfid-20121215_15362_D4695073 X-CRM114-Status: Good ( pR: 16.3457 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sat Dec 15 15:36:26 2012 X-DSPAM-Confidence: 0.9954 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50cc8ae9830292009013148 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, MFC, 0.00096, >+Hi, 0.00139, wrote+>, 0.00225, Hi+>, 0.00231, >+I, 0.00255, >+It, 0.00277, >+>, 0.00359, >+>, 0.00359, this+>, 0.00369, References*fsn.hu>, 0.00426, the+code, 0.00426, In-Reply-To*fsn.hu>, 0.00461, svn, 0.00461, revision, 0.00503, can+I, 0.00503, 11+29, 0.00552, >+If, 0.00592, wrote, 0.00592, stack, 0.00613, I+get, 0.00669, 0+>, 0.00690, 0+>, 0.00690, it's+the, 0.00735, it's+the, 0.00735, c+>, 0.00787, X-Spambayes-Classification: ham; 0.00 Received: from [192.168.3.2] (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 28B44F2593E for ; Sat, 15 Dec 2012 15:36:23 +0100 (CET) Message-ID: <50CC8AE5.5070804@fsn.hu> Date: Sat, 15 Dec 2012 15:36:21 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: zfs panic, solaris_assert References: <50CC86D4.2070502@fsn.hu> In-Reply-To: <50CC86D4.2070502@fsn.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 14:36:28 -0000 On 12/15/2012 03:19 PM, Attila Nagy wrote: > Hi, > > Since running svn revision r243704 I get frequent panics: > panic: solaris assert: sa.sa_magic == 0x2F505A (0x4f22a8ed == 0x2f505a), > file: > /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, > line: 597 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x1ce > assfail3() at assfail3+0x29 > zfs_space_delta_cb() at zfs_space_delta_cb+0xbe > dmu_objset_userquota_get_ids() at dmu_objset_userquota_get_ids+0x142 > dnode_sync() at dnode_sync+0xc5 > dmu_objset_sync_dnodes() at dmu_objset_sync_dnodes+0x5d > dmu_objset_sync() at dmu_objset_sync+0x17f > dsl_pool_sync() at dsl_pool_sync+0xca > spa_sync() at spa_sync+0x34a > txg_sync_thread() at txg_sync_thread+0x139 > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff90231accf0, rbp = 0 --- > > I can't tell whether it's the data or the code. If the latter, is this > fixed in later revisions? > If it's the file system, what can I do with this? > It seems this is introduced with the following mega-MFC: r243674 | mm | 2012-11-29 15:05:04 +0100 (Thu, 29 Nov 2012) | 223 lines From owner-freebsd-fs@FreeBSD.ORG Sat Dec 15 15:00:04 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A249AAD3 for ; Sat, 15 Dec 2012 15:00:04 +0000 (UTC) (envelope-from graudeejs@yandex.ru) Received: from forward2h.mail.yandex.net (forward2h.mail.yandex.net [IPv6:2a02:6b8:0:f05::2]) by mx1.freebsd.org (Postfix) with ESMTP id 128BA8FC0C for ; Sat, 15 Dec 2012 15:00:04 +0000 (UTC) Received: from web16h.yandex.ru (web16h.yandex.ru [84.201.186.45]) by forward2h.mail.yandex.net (Yandex) with ESMTP id 931967016B0; Sat, 15 Dec 2012 19:00:02 +0400 (MSK) Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web16h.yandex.ru (Yandex) with ESMTP id 2151A59800A8; Sat, 15 Dec 2012 19:00:02 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1355583602; bh=7r7u/JZNvCrl6GCYv2FZJYzJrBK9aA+0LmHy/pAznT0=; h=From:To:In-Reply-To:References:Subject:Date; b=k9etysQHCFVs3mIOFmyvPWtGv4jr82UL/i8mG5JfLUbI5ZUZrWW0Q6B4emHk13tpY SBWSqJwaDrfof7wmplYn2sks2mwNK6NAs44hhcyJ3oiRe/kor8+VbWifF2bFP52YXi 2BU9C1DzqZ2fCrk3GFYXfSbU2R+Qt8/H4zYDM2c8= Received: from mpe-11-155.mpe.lv (mpe-11-155.mpe.lv [83.241.11.155]) by web16h.yandex.ru with HTTP; Sat, 15 Dec 2012 19:00:01 +0400 From: Aldis Berjoza Envelope-From: graudeejs@yandex.ru To: Ronald Klop , "freebsd-fs@freebsd.org" In-Reply-To: References: <20121213162137.78332@relay.ibs.dn.ua> <50CBD711.8090607@freebsd.org> Subject: Re: snapshot management tool? MIME-Version: 1.0 Message-Id: <2330171355583601@web16h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 15 Dec 2012 17:00:01 +0200 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 15:00:04 -0000 15.12.2012, 16:25, "Ronald Klop" : > On Sat, 15 Dec 2012 02:49:05 +0100, Lawrence Stewart > wrote: > >> šOn 12/14/12 00:21, Zeus Panchenko wrote: >>> šhi all, >>> >>> šplease, share what are you using to manage snapshots >>> >>> šin ports collection I see: >>> >>> šzfs-periodic >>> šzfs-snapshot-mgmt >>> šzfsnap >>> šzfstools >> šI use zfsnap on all my ZFS based systems e.g. >> >> šroot@newtcphub:~ # tail -n 15 /etc/crontab >> >> š# Remove snapshots with an expired TTL at 05:35/17:35 each day. >> š35 ššššš5,17 ššš* šššššš* šššššš* ššššššroot ššš/usr/local/sbin/zfSnap >> š-d -p 15mins_ -p daily_ -p weekly_ -p monthly_ >> >> š# Take 15min snapshots of important filesystems, rolling them every 3 >> šdays. >> š8/15 ššš* šššššš* šššššš* šššššš* ššššššroot ššš/usr/local/sbin/zfSnap >> š-S -s -a 3d -p 15mins_ -R newtcphub newtcphub/usr newtcphub/var -r >> šnewtcphub/home newtcphub/data >> >> š# Take daily snapshots of important filesystems at 06:10, rolling them >> ševery 14 days. >> š10 ššššš6 šššššš* šššššš* šššššš* ššššššroot ššš/usr/local/sbin/zfSnap >> š-S -s -a 14d -p daily_ -R newtcphub newtcphub/usr newtcphub/var -r >> šnewtcphub/home newtcphub/data >> >> š# Take weekly snapshots of important filesystems at 06:25 on Sundays, >> šrolling them every 6 weeks. >> š25 ššššš6 šššššš* šššššš* ššššššsun ššššroot ššš/usr/local/sbin/zfSnap >> š-Ss -a 6w -p weekly_ -R newtcphub newtcphub/usr newtcphub/var -r >> šnewtcphub/home newtcphub/data >> >> š# Take monthly snapshots of important filesystems at 06:35 on the 1st of >> šeach month, rolling them every 4 months. >> š35 ššššš6 šššššš1 šššššš* šššššš* ššššššroot ššš/usr/local/sbin/zfSnap >> š-Ss -a 4m -p monthly_ -R newtcphub newtcphub/usr newtcphub/var -r >> šnewtcphub/home newtcphub/data >> >> šHaven't tried the other ports so don't have an opinion on them. >> >> šCheers, >> šLawrence > > Does this also work for a home computer which is not always on? I'm > curious about how people handle that. > > Ronald. > _______________________________________________ > 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" For home computer I install and adjust sysutils/anacron port -- Aldis Berjoza FreeBSD addict From owner-freebsd-fs@FreeBSD.ORG Sat Dec 15 16:09: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 B9289C56 for ; Sat, 15 Dec 2012 16:09:26 +0000 (UTC) (envelope-from jmt@lf28.net) Received: from dumont.lf28.net (dumont.lf28.net [72.52.97.118]) by mx1.freebsd.org (Postfix) with ESMTP id 9B6F68FC16 for ; Sat, 15 Dec 2012 16:09:26 +0000 (UTC) Received: from [192.168.142.41] (helo=joshua.lf28.net) by dumont.lf28.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TjuIl-00019R-Ea for freebsd-fs@freebsd.org; Sat, 15 Dec 2012 09:09:25 -0700 Received: from joshua.lf28.net ([192.168.142.41] helo=localhost ident=www) by joshua.lf28.net with esmtp (Exim 4.77) (envelope-from ) id 1TjuId-0001Ng-6J for freebsd-fs@freebsd.org; Sat, 15 Dec 2012 17:09:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 15 Dec 2012 17:09:15 +0100 From: Markus Teichmann To: Subject: Corrupt zfs-pool after ex/import Mail-Reply-To: Message-ID: <1928230629e762cbf1b6ac1e1263d609@imap.lf28.net> X-Sender: jmt@lf28.net User-Agent: Roundcube Webmail/0.8.1 X-Spam_score: -1.0 X-R: esmtp X-Spam_bar: - X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: jmt@lf28.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 16:09:26 -0000 I lost a single device zfs pool with export/import. history: I had a zfs root pool and wanted to move it on a mirrored pool. So I moved the root environment from single device pool sys to the new pool sys0. Than I booted on the new pool sys0 and renamed the old pool sys to sys1. Next I booted sys1 and renamed sys0 to sys. This was the last time the old pool was accessible. There was one problem when I booted sys1. Zpool showed me 3 pools, sys, sys0 and sys1. So the renaming from sys to sys1 had some failures. I exported the pool sys and then renamed sys0 to sys. Next time I booted the new pool and the old was lost. All the happens on 9-RELEASE. Now I installed 10-CURRENT, but the result is the same. Meanwhile I renamed the new mirrored pool sys back to sys0. So I can work on the old pool without naming problems. The old pool still belongs to the name sys. What I've done till now: #zpool import pool: sys id: 874712540419822651 state: FAULTED status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. see: http://illumos.org/msg/ZFS-8000-5E config: sys FAULTED corrupted data 14109631078429946324 FAULTED corrupted data #zdb -l /dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b -------------------------------------------- LABEL 0 -------------------------------------------- version: 28 name: 'sys' state: 1 txg: 840285 pool_guid: 874712540419822651 hostid: 4266313884 hostname: 'mcp.lf28.net' top_guid: 14109631078429946324 guid: 14109631078429946324 vdev_children: 1 vdev_tree: type: 'disk' id: 0 guid: 14109631078429946324 path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' whole_disk: 1 metaslab_array: 30 metaslab_shift: 34 ashift: 12 asize: 1991803142144 is_log: 0 create_txg: 4 -------------------------------------------- LABEL 1 -------------------------------------------- version: 28 name: 'sys' state: 1 txg: 840285 pool_guid: 874712540419822651 hostid: 4266313884 hostname: 'mcp.lf28.net' top_guid: 14109631078429946324 guid: 14109631078429946324 vdev_children: 1 vdev_tree: type: 'disk' id: 0 guid: 14109631078429946324 path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' whole_disk: 1 metaslab_array: 30 metaslab_shift: 34 ashift: 12 asize: 1991803142144 is_log: 0 create_txg: 4 -------------------------------------------- LABEL 2 -------------------------------------------- version: 28 name: 'sys' state: 1 txg: 840285 pool_guid: 874712540419822651 hostid: 4266313884 hostname: 'mcp.lf28.net' top_guid: 14109631078429946324 guid: 14109631078429946324 vdev_children: 1 vdev_tree: type: 'disk' id: 0 guid: 14109631078429946324 path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' whole_disk: 1 metaslab_array: 30 metaslab_shift: 34 ashift: 12 asize: 1991803142144 is_log: 0 create_txg: 4 -------------------------------------------- LABEL 3 -------------------------------------------- version: 28 name: 'sys' state: 1 txg: 840285 pool_guid: 874712540419822651 hostid: 4266313884 hostname: 'mcp.lf28.net' top_guid: 14109631078429946324 guid: 14109631078429946324 vdev_children: 1 vdev_tree: type: 'disk' id: 0 guid: 14109631078429946324 path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' whole_disk: 1 metaslab_array: 30 metaslab_shift: 34 ashift: 12 asize: 1991803142144 is_log: 0 create_txg: 4 #zdb -e sys Configuration for import: vdev_children: 1 version: 28 pool_guid: 874712540419822651 name: 'sys' txg: 840285 state: 1 hostid: 4266313884 hostname: 'mcp.lf28.net' vdev_tree: type: 'root' id: 0 guid: 874712540419822651 children[0]: type: 'disk' id: 0 guid: 14109631078429946324 phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' whole_disk: 1 metaslab_array: 30 metaslab_shift: 34 ashift: 12 asize: 1991803142144 is_log: 0 create_txg: 4 path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' zdb: can't open 'sys': Input/output error #zdb -Fe sys Configuration for import: vdev_children: 1 version: 28 pool_guid: 874712540419822651 name: 'sys' txg: 840285 state: 1 hostid: 4266313884 hostname: 'mcp.lf28.net' vdev_tree: type: 'root' id: 0 guid: 874712540419822651 children[0]: type: 'disk' id: 0 guid: 14109631078429946324 phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' whole_disk: 1 metaslab_array: 30 metaslab_shift: 34 ashift: 12 asize: 1991803142144 is_log: 0 create_txg: 4 path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' zdb: can't open 'sys': Input/output error #zdb -Xe sys Configuration for import: vdev_children: 1 version: 28 pool_guid: 874712540419822651 name: 'sys' txg: 840285 state: 1 hostid: 4266313884 hostname: 'mcp.lf28.net' vdev_tree: type: 'root' id: 0 guid: 874712540419822651 children[0]: type: 'disk' id: 0 guid: 14109631078429946324 phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' whole_disk: 1 metaslab_array: 30 metaslab_shift: 34 ashift: 12 asize: 1991803142144 is_log: 0 create_txg: 4 path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b' zdb: can't open 'sys': Too many open files Now I need some help/advice to get the pool working again. It does not seem to be a hardware issue, because the disk is only some month old and there are no messages from the kernel. Any ideas are welcome. Markus Teichmann PS: Sorry for my broken English, I'll try my very best... From owner-freebsd-fs@FreeBSD.ORG Sat Dec 15 16:43:45 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 2F94F994 for ; Sat, 15 Dec 2012 16:43:45 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id D821A8FC1B for ; Sat, 15 Dec 2012 16:43:44 +0000 (UTC) Received: from conversation.bsdunix.ch (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id DC8A314435 for ; Sat, 15 Dec 2012 16:43:36 +0000 (UTC) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by conversation.bsdunix.ch (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-UEirtYtmUh for ; Sat, 15 Dec 2012 16:43:36 +0000 (UTC) Received: from toms-saftbook.home (177-185.107-92.cust.bluewin.ch [92.107.185.177]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTPSA id 7628114432 for ; Sat, 15 Dec 2012 16:43:36 +0000 (UTC) Message-ID: <50CCA8B8.7010808@bsdunix.ch> Date: Sat, 15 Dec 2012 17:43:36 +0100 From: Tom User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Subject: zfs: is it possible to set metaslab_debug to 1? Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 16:43:45 -0000 Hi, Is it possible to set metaslab_debug to 1 on freebsd without recompiling: usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c /* * Metaslab debugging: when set, keeps all space maps in core to verify frees. */ static int metaslab_debug = 0; Is this even possible on FreeBSD? It often helps with ZFS perfomance issues on Solaris with lots of ram. Regards, Tom From owner-freebsd-fs@FreeBSD.ORG Sat Dec 15 21:05:20 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B65EEC69 for ; Sat, 15 Dec 2012 21:05:20 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB318FC12 for ; Sat, 15 Dec 2012 21:05:19 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so3698495lbb.13 for ; Sat, 15 Dec 2012 13:05:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=SoYqNjnQYOzB/Y5qPlQfP3nCEuJDhyUint1bY0WUglg=; b=lXwXJWj1dSlXtGJkRLWkISRtpXsNfP5/zyIMGpag8G+0+XDICXCfrxnyluYLyomvOX OefNgjxx2bOvwOhzteAp2xCuh1NVch7A45oH+LhuvGgvb593dKOmrquIMB5F9nexWnqJ ci4EEHvSQrE4kFraAK3Mbc4xT3yRNVzc13pY7aPwRAFK3ExG5APxmAzXvGoIjUF0TQce 1o7FkD6UYfNDPrXhRC+qrSJLnGG4ifGJ22HaGcTqE6qGMNojVY8pGxjHfyLXpc3Ke5u5 Mb738BmRebEJKey/CrSztVgJM9USD0Dt1HcCSzd7tix3y44ent87Ain5GIyMG2rDai47 rdIw== MIME-Version: 1.0 Received: by 10.152.105.203 with SMTP id go11mr6252365lab.53.1355605513104; Sat, 15 Dec 2012 13:05:13 -0800 (PST) Received: by 10.112.68.170 with HTTP; Sat, 15 Dec 2012 13:05:12 -0800 (PST) In-Reply-To: <50CC8AE5.5070804@fsn.hu> References: <50CC86D4.2070502@fsn.hu> <50CC8AE5.5070804@fsn.hu> Date: Sat, 15 Dec 2012 22:05:12 +0100 Message-ID: Subject: Re: zfs panic, solaris_assert From: Damien Fleuriot To: Attila Nagy Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkh2MsPSYhf1ZbCx3T8Ib17ysWE4DsoknDjJ3nnv1StdOLzW5M7R4cuA1EpscSspiwlxnwD Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 21:05:20 -0000 On 15 December 2012 15:36, Attila Nagy wrote: > On 12/15/2012 03:19 PM, Attila Nagy wrote: >> >> Hi, >> >> Since running svn revision r243704 I get frequent panics: >> panic: solaris assert: sa.sa_magic == 0x2F505A (0x4f22a8ed == 0x2f505a), >> file: >> /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, >> line: 597 >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> kdb_backtrace() at kdb_backtrace+0x37 >> panic() at panic+0x1ce >> assfail3() at assfail3+0x29 >> zfs_space_delta_cb() at zfs_space_delta_cb+0xbe >> dmu_objset_userquota_get_ids() at dmu_objset_userquota_get_ids+0x142 >> dnode_sync() at dnode_sync+0xc5 >> dmu_objset_sync_dnodes() at dmu_objset_sync_dnodes+0x5d >> dmu_objset_sync() at dmu_objset_sync+0x17f >> dsl_pool_sync() at dsl_pool_sync+0xca >> spa_sync() at spa_sync+0x34a >> txg_sync_thread() at txg_sync_thread+0x139 >> fork_exit() at fork_exit+0x11f >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip = 0, rsp = 0xffffff90231accf0, rbp = 0 --- >> >> I can't tell whether it's the data or the code. If the latter, is this >> fixed in later revisions? >> If it's the file system, what can I do with this? >> > It seems this is introduced with the following mega-MFC: > r243674 | mm | 2012-11-29 15:05:04 +0100 (Thu, 29 Nov 2012) | 223 lines > For what it's worth, running on amd64 with 4gb ram: 10-CURRENT r244183: Thu Dec 13 15:35:28 UTC 2012 And not experiencing ZFS/solaris problems. Loader tunables: vm.kmem_size="3072M" vfs.zfs.arc_min="128M" vfs.zfs.arc_max="2048M"