From owner-freebsd-fs@FreeBSD.ORG Sun Dec 4 00:17:51 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACD0B106567C; Sun, 4 Dec 2011 00:17:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 842348FC08; Sun, 4 Dec 2011 00:17:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pB40Hp82077436; Sun, 4 Dec 2011 00:17:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pB40HoGQ077431; Sun, 4 Dec 2011 00:17:50 GMT (envelope-from linimon) Date: Sun, 4 Dec 2011 00:17:50 GMT Message-Id: <201112040017.pB40HoGQ077431@freefall.freebsd.org> To: gpr@mail.ru, linimon@FreeBSD.org, freebsd-fs@FreeBSD.org, ivoras@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/159418: [tmpfs] [panic] [patch] tmpfs kernel panic: recursing on non recursive lockmgr tmpfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 00:17:51 -0000 Synopsis: [tmpfs] [panic] [patch] tmpfs kernel panic: recursing on non recursive lockmgr tmpfs State-Changed-From-To: open->patched State-Changed-By: linimon State-Changed-When: Sun Dec 4 00:17:03 UTC 2011 State-Changed-Why: Over to committer as MFC reminder. Responsible-Changed-From-To: freebsd-fs->ivoras Responsible-Changed-By: linimon Responsible-Changed-When: Sun Dec 4 00:17:03 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=159418 From owner-freebsd-fs@FreeBSD.ORG Sun Dec 4 16:34:36 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB4711065755 for ; Sun, 4 Dec 2011 16:34:36 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0348FC12 for ; Sun, 4 Dec 2011 16:34:36 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2oX8drk23moxitALBI= X-RZG-CLASS-ID: mo05 Received: from [192.168.179.42] (hmbg-5f7607ae.pool.mediaWays.net [95.118.7.174]) by smtp.strato.de (fruni mo23) (RZmta 26.10 AUTH) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id I05c9enB4ECF1E for ; Sun, 4 Dec 2011 17:34:32 +0100 (MET) Message-ID: <4EDBA116.3000008@brockmann-consult.de> Date: Sun, 04 Dec 2011 17:34:30 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20111101034118.GA73746@FreeBSD.org> <20111124230822.GA96603@johnny.reilly.home> In-Reply-To: <20111124230822.GA96603@johnny.reilly.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: (Yet Another) Damaged directory on ZFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 16:34:36 -0000 Am 25.11.2011 00:08, schrieb Andrew Reilly: > On Tue, Nov 01, 2011 at 03:41:18AM +0000, John wrote: >> Hi Folks, >> >> We have a zfs fileserver running 9.0-RC1 which appears to have locked >> up in a manner similar to the "Damanged directory on ZFS" thread. >> >> It started after a zfs snapshat which appears to have hung. At >> that point, an "ls" command on a directory which is either empty >> or contains only other directories works correctly. An "ls" on >> a directory containing a file will hang. > Just want to add a sort-of "me too", to this question, in the > hope that I will learn something useful. > > For a couple of weeks I've been seeing messages in > my daily security reports along the lines of: find: > /usr/src/.zfs/snapshot: bad file descriptor > > I can get the same message now by just cd'ing into one of the > two "broken" .zfs directories and comparing ls -F output with a > version that doesn't check the inode data: > > ls: snapshot: Bad file descriptor > shares/ > > "zfs list -r -t snapshot" shows all of the snapshots created by > my nightly backups to still exist, seemingly. > > A zpool scrub tank did not change or make them go away. > > No processes appear to be stuck, wedged or otherwise broken. > > FWIW I'm running: > FreeBSD johnny.reilly.home 9.0-RC1 FreeBSD 9.0-RC1 #4: Sat Nov 5 14:52:15 EST 2011 root@johnny.reilly.home:/usr/obj/usr/src/sys/GENERIC amd64 > > Cheers, > I have a similar problem, but the lines in my log are clearly from nfs. Here is one (which shows up when doing a HUP on nfsd): Oct 31 14:55:39 bcnas1 mountd[47733]: can't delete exports for /tank/fs1/.zfs/snapshot/daily-2011-10-06T09:27:52: Invalid argument I don't have any logs old enough to have it, but I also vaguely remember the words "bad file descriptor". So I decided to set: zfs set snapdir=hidden and now the problem is gone. nfsd no longer knows there is a .zfs directory, so it does not try to scan it and export it. However, if I manually type in "ls.zfs/snapshot" on the NFS client, it does indeed hang the dataset, but not the whole system, and on a "shutdown -r now" the system hangs due to a process failing to stop. Then when rebooting, there is no lost data. Everything runs normally again until another "ls .zfs/snapshot" is run. Long ago, still seeing the errors in the log, I could list in the .zfs directory without a hang, but the snapshots looked all wrong; they would look like a different directory rather than the root of the tree, or they would not be directories, but some kind of binary file. The hanging started after more snapshots were created. Does this match your experience at all? Can you show us the full lines from the log? (see how my log line says mountd, which gives us a hint that the "can't delete ..." message does not) From owner-freebsd-fs@FreeBSD.ORG Mon Dec 5 08:02:50 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF627106566B for ; Mon, 5 Dec 2011 08:02:49 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5109A8FC0A for ; Mon, 5 Dec 2011 08:02:48 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 3CD93A99; Mon, 5 Dec 2011 09:02:47 +0100 (CET) Date: Mon, 5 Dec 2011 09:01:48 +0100 From: Pawel Jakub Dawidek To: Kirk McKusick Message-ID: <20111205080148.GA1660@garage.freebsd.pl> References: <20111125110235.GB1642@garage.freebsd.pl> <201112020236.pB22aQi6059579@chez.mckusick.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <201112020236.pB22aQi6059579@chez.mckusick.com> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 08:02:50 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 01, 2011 at 06:36:26PM -0800, Kirk McKusick wrote: > > > No. Softupdates do not need flushes. > >=20 > > Well, they do for two reasons: > > 1. To properly handle sync operations (fsync(2), O_SYNC). > > 2. To maintain consistent on-disk structures. >=20 > SU does not use synchronous writes to maintain consistency (see below). > It rarely uses synchronous writes even to immplement fsync. Instead it > issues async I/O requests for all the blocks necessary to ensure that > the inode in question is stable. It then waits until all of those writes > have been acknowledged. When they have been acknowledged the fsync > returns. If the subsystem acknowledges them before they are truely on > stable store, then SU and correspondingly the caller of fsync is screwed. >=20 > The one place where a synchronous write (bwrite) is used is when the > completion of a particular I/O is needed to make progress on many other > things (usually an update to the SUJ log) in which case SU will force a > flush on that I/O (e.g., bwrite it) to hasten it along. We clearly talk about different layers:) By sync writes I meant disk writes, ie. when you send write to disk it will ack the write only when the data hit stable storage, not disk write cache. > > The second point is there, because BIO_FLUSH is the only way to avoid > > reordering (apart from turning off disk write cache). > >=20 > > SU assumes no I/O reordering will happen, which is very weak assumption. >=20 > SU has no problems with reordering. It makes no assumptions on the > order in which its I/O operations are done. Its only requirement is > that it not be told that something is stable before it truely is > stable. Because the way that it maintains consistency is to not > issue a write on something before it knows that something that it > depends on for consistency is in fact stable. But it has no problem > with any of its outstanding writes being done in any particular order. Again, different layers:) The reordering I worry about is at disk level. When you write a bunch of blocks they are really stored in disk write cache. Disk sends you ack eventhough the data is not on the stable storage yet. Under assumption that previous data is safe you send more data that is also placed in disk write cache. At some point disk decides to flush its write cache, but it will most likely sort the blocks by offset, which will mess your initial ordering and the data you sent last may hit the disk first. To avoid this reordering to happen you either need to turn off disk write cache or send BIO_FLUSH between those two write groups. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk7cemwACgkQForvXbEpPzRM5wCdEZ9t/6Pjmc3n4tFKAuvZhZez j3YAoJHrEavD788zQXMjhNvoubiCYwjm =oQHg -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-freebsd-fs@FreeBSD.ORG Mon Dec 5 11:02:58 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E6141065672; Mon, 5 Dec 2011 11:02:58 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id F0A338FC08; Mon, 5 Dec 2011 11:02:57 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:69b8:2555:9d19:7f7b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 046954AC31; Mon, 5 Dec 2011 15:02:55 +0400 (MSK) Date: Mon, 5 Dec 2011 15:02:54 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <62478423.20111205150254@serebryakov.spb.ru> To: Pawel Jakub Dawidek In-Reply-To: <20111205080148.GA1660@garage.freebsd.pl> References: <20111125110235.GB1642@garage.freebsd.pl> <201112020236.pB22aQi6059579@chez.mckusick.com> <20111205080148.GA1660@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Kirk McKusick , freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 11:02:58 -0000 Hello, Pawel. You wrote 5 =E4=E5=EA=E0=E1=F0=FF 2011 =E3., 12:01:48: > Again, different layers:) The reordering I worry about is at disk level. > When you write a bunch of blocks they are really stored in disk write > cache. Disk sends you ack eventhough the data is not on the stable > storage yet. Under assumption that previous data is safe you send more > data that is also placed in disk write cache. At some point disk decides > to flush its write cache, but it will most likely sort the blocks by > offset, which will mess your initial ordering and the data you sent last > may hit the disk first. > To avoid this reordering to happen you either need to turn off disk > write cache or send BIO_FLUSH between those two write groups. As far as I understand Kostik and Kirk, it is Ok, as long as disk is able to flush whole cache in case of crash or power failure, and disks (or controllers) which are not able to do so, considered deeply broken. If disk (or controller) is able not to lose data in any crash, it is not so important, when and how data will be written, as READ of data from cache will return "written" one and there is no time frame when outer layers (driver, geom and UFS) could see un-ordered (or old) data at all. So, disk (or controller) could ACK write as soon as data in its (battery/super-capacitor/whatever protected) cache memory. In case of software (GEOM) cache, here is one big flaw: even if computer as whole (and RAM, where cache resides, as part of computer) is protected with battery (UPS with notification about battery and line power state), software crash could prevent cache from being flushed to stable device (disk). And in this scenario ACKing data which is copied into cache, but not written (maybe, to hardware cache of disk, not disk itself) is dangerous. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Mon Dec 5 11:06:58 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E998106568A for ; Mon, 5 Dec 2011 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA528FC08 for ; Mon, 5 Dec 2011 11:06:58 +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 pB5B6wKx081170 for ; Mon, 5 Dec 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pB5B6vBg081168 for freebsd-fs@FreeBSD.org; Mon, 5 Dec 2011 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Dec 2011 11:06:57 GMT Message-Id: <201112051106.pB5B6vBg081168@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 11:06:58 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/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/162564 fs [ext2fs][patch] fs/ext2fs: Add include guard 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/162083 fs [zfs] [panic] zfs unmount -f pool o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161674 fs [ufs] snapshot on journaled ufs doesn't work 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/161511 fs [unionfs] Filesystem deadlocks when using multiple uni 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 Random UFS root filesystem corruption with SU+J [regre 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/159971 fs [ffs] [panic] panic with soft updates journaling durin 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/159233 fs [ext2fs] [patch] fs/ext2fs: finish reallocblk implemen o kern/159232 fs [ext2fs] [patch] fs/ext2fs: merge ext2_readwrite into 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/158711 fs [ffs] [panic] panic in ffs_blkfree and ffs_valloc o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157722 fs [geli] unable to newfs a geli encrypted partition 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 f 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/153847 fs [nfs] [panic] Kernel panic from incorrect m_free in nf o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/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 f sparc/123566 fs [zfs] zpool import issue: EOVERFLOW o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/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 bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o 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 259 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Dec 5 22:34:50 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA1C3106564A for ; Mon, 5 Dec 2011 22:34:50 +0000 (UTC) (envelope-from kungfujesus06@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7109D8FC0A for ; Mon, 5 Dec 2011 22:34:50 +0000 (UTC) Received: by qabg14 with SMTP id g14so767700qab.13 for ; Mon, 05 Dec 2011 14:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=ph/2HDIUImVHaGw2IQ1Y4swhYBvc6nlcEMeb0d2vmsE=; b=JxDSXzL170oYyA+7Q2GW8B5ddmrg3wnzB9DPXojAnohyd8fFEUHxkKU8sLpNekWuel 9MCeBU6BQ7nhiMJuQUJ41C818sNHXYfa8rbo1i+fcEFhjwofY80dC5vDSnxNbuqKDOHt bxIQB73Hgsk1oG1LFNgcahrh6xuGwrapOZBjs= Received: by 10.224.96.84 with SMTP id g20mr5599831qan.17.1323122838268; Mon, 05 Dec 2011 14:07:18 -0800 (PST) Received: from freebsdbox.adamsnet ([72.49.234.31]) by mx.google.com with ESMTPS id bw9sm27978975qab.18.2011.12.05.14.07.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Dec 2011 14:07:17 -0800 (PST) Date: Mon, 5 Dec 2011 17:07:15 -0500 From: Adam Stylinski To: freebsd-fs@freebsd.org Message-ID: <20111205220715.GA36072@freebsdbox.adamsnet> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: weird bug with ZFS and SLOG X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:34:50 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The worst case scenario happened to me where my dedicated SLOG decided to d= rop off the controller and thus prevent me from importing my pool. I quick= ly upgrade to FreeBSD 9.0-RC2 after testing this scenario in a VM. It has = worked successfully in a VM, but it is not working on my hardware for whate= ver reason. I rollback the pool with zpool import -F share, seems ok, file= s are there, finishes scrub, very little corruption. I upgrade the pool to= V28, and the fs's to v5. I then do a: zpool remove share 15752248745115926170 It returns no errors and pretends like the operation worked, it even appen= ds it to my zpool history. However, when I do a zpool status, this is what= I get: [adam@nasbox ~]$ zpool status pool: share state: DEGRADED status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub repaired 0 in 8h57m with 0 errors on Mon Dec 5 12:48:28 2011 config: NAME STATE READ WRITE CKSUM share DEGRADED 0 0 0 raidz1-0 ONLINE 0 0 0 ada4 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 da3 ONLINE 0 0 0 da0 ONLINE 0 0 0 da2 ONLINE 0 0 0 da1 ONLINE 0 0 0 raidz1-2 ONLINE 0 0 0 aacd0 ONLINE 0 0 0 aacd1 ONLINE 0 0 0 aacd2 ONLINE 0 0 0 aacd3 ONLINE 0 0 0 raidz1-4 ONLINE 0 0 0 aacd4 ONLINE 0 0 0 aacd5 ONLINE 0 0 0 aacd6 ONLINE 0 0 0 aacd7 ONLINE 0 0 0 logs 15752248745115926170 UNAVAIL 0 0 0 was /dev/ada2 errors: 3 data errors, use '-v' for a list Here is the ending output of zpool history: 2011-12-05.03:38:50 zpool upgrade -V 28 -a 2011-12-05.03:39:09 zpool export share 2011-12-05.03:39:33 zpool import -m share 2011-12-05.03:40:05 zpool remove share 15752248745115926170 2011-12-05.03:41:04 zpool remove share 15752248745115926170 2011-12-05.03:41:18 zpool export share 2011-12-05.03:41:56 zpool import -m share 2011-12-05.03:43:47 zpool remove share 15752248745115926170 2011-12-05.03:47:54 zpool remove share 15752248745115926170 2011-12-05.03:51:20 zpool scrub share 2011-12-05.16:33:01 zfs create share/vardb2 2011-12-05.16:33:32 zfs set compression=3Dgzip-9 share/vardb2 2011-12-05.16:33:38 zfs set atime=3Doff share/vardb2 2011-12-05.16:39:37 zfs destroy share/vardb 2011-12-05.16:39:47 zfs rename share/vardb2 share/vardb 2011-12-05.16:39:53 zfs set mountpoint=3D/var/db share/vardb 2011-12-05.16:47:24 zpool clear share 2011-12-05.16:48:41 zpool remove share 15752248745115926170 2011-12-05.16:53:15 zpool export -f share 2011-12-05.16:55:21 zpool import -m share 2011-12-05.16:55:52 zpool remove share 15752248745115926170 2011-12-05.16:56:56 zpool remove share -f 15752248745115926170 2011-12-05.17:04:07 zpool remove share 15752248745115926170 What is going on here and how do I fix it? =20 --=20 Adam Stylinski PGP Key: http://pohl.ececs.uc.edu/~adam/publickey.pub Blog: http://technicallyliving.blogspot.com --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAEBAgAGBQJO3UCRAAoJED6sRHE6Tvmn8rMQAK2UnDYK3K9EIEr4j1l065dl RWBj4mNPfq53L0wUcKyJwlWAdENnwX2XPxds79vfaskIqbfm8d54ooSD6Xq8MxTk vY+O5DWHGYu2aSedIK1UPrhQy7yoH42/h4GREqTC/XpdKjWXdTlBaX7m3d9e4Eu5 GZg32LtbVrNymm4fZ2tId3g+o312NTRt4zpaqZR9a3C/sYGrBhw2G5gTUGUl9JIQ EQwZhEXDUvILh2aeO7kM1vUtDHkeq2HzUu0am0QxkWmUlkL9a3NkVt+97kwUQTvg ymAF8+Um6OtBP1029N5YMEyLhmZIAEtSg/88dFMMlzD2ZwBkyVTMJ/9s3V7FLcPQ KkfVdmrbIoniO+NJ9nIiXRHlH2Ta/qkFFf7M/1TMKO0SD2uy4GyiH3IENCTxlJ0K 6rbJrSNZGTv0F97nnhpaouY6cLG8R386ijYOCc1B3LvaFIV1H8L79hFhVyiioTA1 jMWvYsnYGNeC/UruI3k7QcxMBAq1xvyR64MCYx6l+j/Bxf/r4utwdG7SOLYoZtEW N6eI6mpnkYbwiHRbS0rqXvHc4rbuoxxc75qnChM7s2f4z1velZXIBuvKZhYBoVR7 li3mckdnVf9XGMtsD6KMX6tblaGPmKjNwiaOAMwwHbL9mJcFyE109nKYK180u7b/ ORm5/yTbnbRvjR3frLSw =ymyG -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 6 01:36:30 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02BEC106566B; Tue, 6 Dec 2011 01:36:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 705AE8FC0A; Tue, 6 Dec 2011 01:36:29 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEABtx3U6DaFvO/2dsb2JhbABEFoRvpkSBcgEBAQMBAQEBIAQnIAsbGBEZAgQlAQkmBggHBAEcBIdmCKMIkX+KC4EWBIgthWGELYIhiRCJJg X-IronPort-AV: E=Sophos;i="4.71,302,1320642000"; d="scan'208";a="146907470" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 05 Dec 2011 20:36:28 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 49612B3FBD; Mon, 5 Dec 2011 20:36:28 -0500 (EST) Date: Mon, 5 Dec 2011 20:36:28 -0500 (EST) From: Rick Macklem To: John Message-ID: <1318843827.953380.1323135388258.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110825203151.GA61776@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_953379_5444943.1323135388257" X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: F_RDLCK lock to FreeBSD NFS server fails to R/O target file [PATCH] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 01:36:30 -0000 ------=_Part_953379_5444943.1323135388257 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit John wrote: > After pondering the best way to allow the VOP_ACCESS() call to > only query for the permissions really needed, I've come up with > a patch that minimally adds one parameter to the nlm_get_vfs_state() > function call with the lock type from the original argp. > > http://people.freebsd.org/~jwd/nlm_prot_impl.c.accmode.patch > > I'd appreciate a review and seeing what might be required to commit > this prior to 9 release. > > Thanks, > John > > ----- John's Original Message ----- > > Hi Fellow NFS'ers, > > > > I believe I have found the problem we've been having with read > > locks > > while attaching to a FreeBSD NFS server. > > > > In sys/nlm/nlm_prot_impl.c, function nlm_get_vfs_state(), there > > is a call > > to VOP_ACCESS() as follows: > > > > /* > > * Check cred. > > */ > > NLM_DEBUG(3, "nlm_get_vfs_state(): Calling > > VOP_ACCESS(VWRITE) with cred->cr_uid=%d\n",cred->cr_uid); > > error = VOP_ACCESS(vs->vs_vp, VWRITE, cred, curthread); > > if (error) { > > NLM_DEBUG(3, "nlm_get_vfs_state(): caller_name = %s > > VOP_ACCESS() returns %d\n", > > host->nh_caller_name, error); > > goto out; > > } > > > > The file being accessed is read only to the user, and open()ed > > with > > O_RDONLY. The lock being requested is for a read. > > > > fd = open(filename, O_RDONLY, 0); > > ... > > > > lblk.l_type = F_RDLCK; > > lblk.l_start = 0; > > lblk.l_whence= SEEK_SET; > > lblk.l_len = 0; > > lblk.l_pid = 0; > > rc = fcntl(fd, F_SETLK, &lblk); > > > > Running the above from a remote system, the lock call fails with > > errno set to ENOLCK. Given cred->cr_uid comes in as 227 which is > > my uid on the remote system. Since the file is R/O to me, and the > > VOP_ACCESS() is asking for VWRITE, it fails with errno 13, EACCES, > > Permission denied. > > > > The above operations work correctly to some of our other > > favorite big-name nfs vendors :-) > > > > Opinions on the "correct" way to fix this? > > > > 1. Since we're only asking for a read lock, why do we need to ask > > for VWRITE? I may not understand an underlying requirement for > > the VWRITE so please feel free to educate me if needed. > > > > Something like: request == F_RDLCK ? VREAD : VWRITE > > (need to figure out where to get the request from in this > > context). > > > > 2. Attempt VWRITE, fallback to VREAD... seems off to me though. > > I think I prefer this approach because it will never fail unless it would fail without the patch. For the case where the client uid has write but not read permission and attempts an F_RDLCK, I believe your patch would fail the request whereas it will succeed without your patch. (Although I'll admit I didn't actually test this.;-) Doing VOP_ACCESS(..VWRITE..) first and only doing a VOP_ACCESS(..VREAD..) if the VOP_ACCESS(..VWRITE..) fails will preserve current behaviour fot the non-failing case, but allow an F_RDLCK for uids with read-only access. I've attached a patch that does this variant. John, could you test this patch? And does anyone have an opinion w.r.t. which variant of the patch is more appropriate? Thanks in advance for your help, rick > > 3. Other? > > > > I appreciate any thoughts on this. > > > > Thanks, > > John > > > > While they might not follow style(9) completely, I've uploaded > > my patch to nlm_prot.impl.c with the NLM_DEBUG() calls i've added. > > I'd appreciate it if someone would consider committing them so > > who ever debugs this file next will have them available. > > > > http://people.freebsd.org/~jwd/nlm_prot_impl.c.patch > > > _______________________________________________ > 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" ------=_Part_953379_5444943.1323135388257 Content-Type: text/x-patch; name=nlmrlock.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=nlmrlock.patch LS0tIG5sbS9ubG1fcHJvdF9pbXBsLmMuc2F2CTIwMTEtMTItMDUgMTA6NTk6MDAuMDAwMDAwMDAw IC0wNTAwCisrKyBubG0vbmxtX3Byb3RfaW1wbC5jCTIwMTEtMTItMDUgMjA6MDk6MDMuMDAwMDAw MDAwIC0wNTAwCkBAIC0xNzc0LDcgKzE3NzQsNyBAQCBzdHJ1Y3QgdmZzX3N0YXRlIHsKIAogc3Rh dGljIGludAogbmxtX2dldF92ZnNfc3RhdGUoc3RydWN0IG5sbV9ob3N0ICpob3N0LCBzdHJ1Y3Qg c3ZjX3JlcSAqcnFzdHAsCi0gICAgZmhhbmRsZV90ICpmaHAsIHN0cnVjdCB2ZnNfc3RhdGUgKnZz KQorICAgIGZoYW5kbGVfdCAqZmhwLCBzdHJ1Y3QgdmZzX3N0YXRlICp2cywgYm9vbF90IGV4Y2x1 c2l2ZSkKIHsKIAlpbnQgZXJyb3IsIGV4ZmxhZ3M7CiAJc3RydWN0IHVjcmVkICpjcmVkID0gTlVM TCwgKmNyZWRhbm9uOwpAQCAtMTgxNiw2ICsxODE2LDggQEAgbmxtX2dldF92ZnNfc3RhdGUoc3Ry dWN0IG5sbV9ob3N0ICpob3N0LAogCSAqIENoZWNrIGNyZWQuCiAJICovCiAJZXJyb3IgPSBWT1Bf QUNDRVNTKHZzLT52c192cCwgVldSSVRFLCBjcmVkLCBjdXJ0aHJlYWQpOworCWlmIChlcnJvciAh PSAwICYmICFleGNsdXNpdmUpCisJCWVycm9yID0gVk9QX0FDQ0VTUyh2cy0+dnNfdnAsIFZSRUFE LCBjcmVkLCBjdXJ0aHJlYWQpOwogCWlmIChlcnJvcikKIAkJZ290byBvdXQ7CiAKQEAgLTE4OTYs NyArMTg5OCw3IEBAIG5sbV9kb190ZXN0KG5sbTRfdGVzdGFyZ3MgKmFyZ3AsIG5sbTRfdGUKIAkJ Z290byBvdXQ7CiAJfQogCi0JZXJyb3IgPSBubG1fZ2V0X3Zmc19zdGF0ZShob3N0LCBycXN0cCwg JmZoLCAmdnMpOworCWVycm9yID0gbmxtX2dldF92ZnNfc3RhdGUoaG9zdCwgcnFzdHAsICZmaCwg JnZzLCBhcmdwLT5leGNsdXNpdmUpOwogCWlmIChlcnJvcikgewogCQlyZXN1bHQtPnN0YXQuc3Rh dCA9IG5sbV9jb252ZXJ0X2Vycm9yKGVycm9yKTsKIAkJZ290byBvdXQ7CkBAIC0yMDAxLDcgKzIw MDMsNyBAQCBubG1fZG9fbG9jayhubG00X2xvY2thcmdzICphcmdwLCBubG00X3JlCiAJCWdvdG8g b3V0OwogCX0KIAotCWVycm9yID0gbmxtX2dldF92ZnNfc3RhdGUoaG9zdCwgcnFzdHAsICZmaCwg JnZzKTsKKwllcnJvciA9IG5sbV9nZXRfdmZzX3N0YXRlKGhvc3QsIHJxc3RwLCAmZmgsICZ2cywg YXJncC0+ZXhjbHVzaXZlKTsKIAlpZiAoZXJyb3IpIHsKIAkJcmVzdWx0LT5zdGF0LnN0YXQgPSBu bG1fY29udmVydF9lcnJvcihlcnJvcik7CiAJCWdvdG8gb3V0OwpAQCAtMjE4MCw3ICsyMTgyLDcg QEAgbmxtX2RvX2NhbmNlbChubG00X2NhbmNhcmdzICphcmdwLCBubG00XwogCQlnb3RvIG91dDsK IAl9CiAKLQllcnJvciA9IG5sbV9nZXRfdmZzX3N0YXRlKGhvc3QsIHJxc3RwLCAmZmgsICZ2cyk7 CisJZXJyb3IgPSBubG1fZ2V0X3Zmc19zdGF0ZShob3N0LCBycXN0cCwgJmZoLCAmdnMsIGFyZ3At PmV4Y2x1c2l2ZSk7CiAJaWYgKGVycm9yKSB7CiAJCXJlc3VsdC0+c3RhdC5zdGF0ID0gbmxtX2Nv bnZlcnRfZXJyb3IoZXJyb3IpOwogCQlnb3RvIG91dDsKQEAgLTIyNjksNyArMjI3MSwxMSBAQCBu bG1fZG9fdW5sb2NrKG5sbTRfdW5sb2NrYXJncyAqYXJncCwgbmxtCiAJCWdvdG8gb3V0OwogCX0K IAotCWVycm9yID0gbmxtX2dldF92ZnNfc3RhdGUoaG9zdCwgcnFzdHAsICZmaCwgJnZzKTsKKwkv KgorCSAqIFNwZWNpZnkgRkFMU0Ugc28gdGhhdCBpdCB3aWxsIHRyeSB0aGUgY2FzZSB3aGVyZSB0 aGVyZSBpcworCSAqIFZSRUFEIGFjY2Vzcywgd2hlbiBWV1JJVEUgYWNjZXNzIGlzIGRlbmllZC4K KwkgKi8KKwllcnJvciA9IG5sbV9nZXRfdmZzX3N0YXRlKGhvc3QsIHJxc3RwLCAmZmgsICZ2cywg RkFMU0UpOwogCWlmIChlcnJvcikgewogCQlyZXN1bHQtPnN0YXQuc3RhdCA9IG5sbV9jb252ZXJ0 X2Vycm9yKGVycm9yKTsKIAkJZ290byBvdXQ7Cg== ------=_Part_953379_5444943.1323135388257-- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 6 02:41:20 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3B921065672; Tue, 6 Dec 2011 02:41:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3519A8FC1B; Tue, 6 Dec 2011 02:41:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAF2A3U6DaFvO/2dsb2JhbAA8CBaEb6ZFgXIBAQEDAQEBASAEJyALBRYYAgINGQIpAQkmBggHBAEcBIdmCKJ8kgSBMoZAghyBFgSILYoQgiGJEoko X-IronPort-AV: E=Sophos;i="4.71,302,1320642000"; d="scan'208";a="146912902" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 05 Dec 2011 21:41:19 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 20411B3F09; Mon, 5 Dec 2011 21:41:19 -0500 (EST) Date: Mon, 5 Dec 2011 21:41:19 -0500 (EST) From: Rick Macklem To: John Message-ID: <904229020.955656.1323139279117.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110825203151.GA61776@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: F_RDLCK lock to FreeBSD NFS server fails to R/O target file (nasty little bug) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 02:41:20 -0000 John wrote: > After pondering the best way to allow the VOP_ACCESS() call to > only query for the permissions really needed, I've come up with > a patch that minimally adds one parameter to the nlm_get_vfs_state() > function call with the lock type from the original argp. > > http://people.freebsd.org/~jwd/nlm_prot_impl.c.accmode.patch > > I'd appreciate a review and seeing what might be required to commit > this prior to 9 release. > Doing a little testing with your patch, I came across this nasty little bug. I have a little program that does the following: - opens a file read/write - waits for user input - does read and write locks (non overlapping byte ranges) - does an unlock of all bytes covered by the above locks I ran it as follows: - had a file on the NFSv3 mount point (which is using the NLM) not owned by the user running the above program, with file mode 0666 - the program opens the file read/write and waits for user input --> on the server, I did a "chmod 622 " - gave it user input, so it then did the above locks (with your patch, the read lock fails although the read lock works for the unpatched NLM and my variant of the patch) - it also does the unlock and doesn't complain of a failure. ---> The ugly bug is that, for your patch, the unlock has failed silently. If you subsequently try and write lock a byte range overlapping the write lock byte range above, the attempt fails, since it is still locked by the client. ---> I don't know of an easy way to get rid of that lock!!! (It persists after the client unmounts the NFS file system.) Cute, eh:-) Btw, I suspect you can get the unpatched code to fail the same way if you did a "chmod 600 " after the write lock, but before the unlock. I'm almost thinking that an unlock shouldn't do a VOP_ACCESS() of any kind, but since that isn't current behaviour??? rick > Thanks, > John > > ----- John's Original Message ----- > > Hi Fellow NFS'ers, > > > > I believe I have found the problem we've been having with read > > locks > > while attaching to a FreeBSD NFS server. > > > > In sys/nlm/nlm_prot_impl.c, function nlm_get_vfs_state(), there > > is a call > > to VOP_ACCESS() as follows: > > > > /* > > * Check cred. > > */ > > NLM_DEBUG(3, "nlm_get_vfs_state(): Calling > > VOP_ACCESS(VWRITE) with cred->cr_uid=%d\n",cred->cr_uid); > > error = VOP_ACCESS(vs->vs_vp, VWRITE, cred, curthread); > > if (error) { > > NLM_DEBUG(3, "nlm_get_vfs_state(): caller_name = %s > > VOP_ACCESS() returns %d\n", > > host->nh_caller_name, error); > > goto out; > > } > > > > The file being accessed is read only to the user, and open()ed > > with > > O_RDONLY. The lock being requested is for a read. > > > > fd = open(filename, O_RDONLY, 0); > > ... > > > > lblk.l_type = F_RDLCK; > > lblk.l_start = 0; > > lblk.l_whence= SEEK_SET; > > lblk.l_len = 0; > > lblk.l_pid = 0; > > rc = fcntl(fd, F_SETLK, &lblk); > > > > Running the above from a remote system, the lock call fails with > > errno set to ENOLCK. Given cred->cr_uid comes in as 227 which is > > my uid on the remote system. Since the file is R/O to me, and the > > VOP_ACCESS() is asking for VWRITE, it fails with errno 13, EACCES, > > Permission denied. > > > > The above operations work correctly to some of our other > > favorite big-name nfs vendors :-) > > > > Opinions on the "correct" way to fix this? > > > > 1. Since we're only asking for a read lock, why do we need to ask > > for VWRITE? I may not understand an underlying requirement for > > the VWRITE so please feel free to educate me if needed. > > > > Something like: request == F_RDLCK ? VREAD : VWRITE > > (need to figure out where to get the request from in this > > context). > > > > 2. Attempt VWRITE, fallback to VREAD... seems off to me though. > > > > 3. Other? > > > > I appreciate any thoughts on this. > > > > Thanks, > > John > > > > While they might not follow style(9) completely, I've uploaded > > my patch to nlm_prot.impl.c with the NLM_DEBUG() calls i've added. > > I'd appreciate it if someone would consider committing them so > > who ever debugs this file next will have them available. > > > > http://people.freebsd.org/~jwd/nlm_prot_impl.c.patch > > > _______________________________________________ > 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 6 10:07:20 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6786F106564A for ; Tue, 6 Dec 2011 10:07:20 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EBDD78FC18 for ; Tue, 6 Dec 2011 10:07:19 +0000 (UTC) Received: by bkat2 with SMTP id t2so10020006bka.13 for ; Tue, 06 Dec 2011 02:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ayJBAeMVKcsnj/tGDS0vNB0jA7i7QPIit9swZd81NdQ=; b=xBkCKZtN5rNY0a3dg0+JhJWd8TN9sdjmIt/AAqYVApcc2nqczG7QqzcMoQYXn67OFl 6k25fpZM8z9WriIF4VMBUCWIGEELcmfKfO0SwrzImKGSjCaH4g1AoSzhQiUP6dj+MYM3 atYeoSDE7i0C2lwJ3qKRwYUfmDCnWimFW7E+Q= Received: by 10.180.75.204 with SMTP id e12mr16303341wiw.61.1323166038849; Tue, 06 Dec 2011 02:07:18 -0800 (PST) Received: from green.tandem.local (utwig.xim.bz. [91.216.237.46]) by mx.google.com with ESMTPS id eo4sm10274674wib.19.2011.12.06.02.07.17 (version=SSLv3 cipher=OTHER); Tue, 06 Dec 2011 02:07:18 -0800 (PST) Message-ID: <4EDDE954.9020709@gmail.com> Date: Tue, 06 Dec 2011 12:07:16 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111111 Thunderbird/8.0 MIME-Version: 1.0 To: Adam Stylinski References: <20111205220715.GA36072@freebsdbox.adamsnet> In-Reply-To: <20111205220715.GA36072@freebsdbox.adamsnet> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: weird bug with ZFS and SLOG X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 10:07:20 -0000 06.12.2011 00:07, Adam Stylinski wrote: > The worst case scenario happened to me where my dedicated SLOG decided to drop off the controller and thus prevent me from importing my pool. I quickly upgrade to FreeBSD 9.0-RC2 after testing this scenario in a VM. It has worked successfully in a VM, but it is not working on my hardware for whatever reason. I rollback the pool with zpool import -F share, seems ok, files are there, finishes scrub, very little corruption. I upgrade the pool to V28, and the fs's to v5. I then do a: > zpool remove share 15752248745115926170 > > It returns no errors and pretends like the operation worked, it even appends it to my zpool history. However, when I do a zpool status, this is what I get: Just a +1 from me, I have such pool also: pool: utwig state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scan: resilvered 73,6M in 0h0m with 0 errors on Fri Oct 28 14:37:10 2011 config: NAME STATE READ WRITE CKSUM utwig DEGRADED 0 0 0 mirror-0 ONLINE 0 0 0 gptid/ecb17af1-9119-11df-bb0b-00304f4e6d80 ONLINE 0 0 0 gptid/03aed1f5-95a3-11df-bb0b-00304f4e6d80 ONLINE 0 0 0 logs gptid/231b9002-a4a5-11e0-a114-3f386a87752c OFFLINE 0 0 0 As you see I just 'offline'd that device. Common points: 1. Pool was created on 8.x. 2. Machine runs 8_STABLE now, pool was upgraded after log device fails to detach. Other hints: The log device can be substituted with other device yet it cannot be deleted anyway. If you have some spare place on the disk to create some small partition for log and replace missed device with such partition. > What is going on here and how do I fix it? Dunno why but the pool now _requires_ log device. While log device is not present pool should use an on-disk log and everything-should-work-fine TM. -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Tue Dec 6 12:19:42 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F957106564A for ; Tue, 6 Dec 2011 12:19:42 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 288F78FC0C for ; Tue, 6 Dec 2011 12:19:42 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MgI6w-1RALUp0KCU-00NgHA; Tue, 06 Dec 2011 13:19:41 +0100 Message-ID: <4EDE085C.4020406@brockmann-consult.de> Date: Tue, 06 Dec 2011 13:19:40 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20111205220715.GA36072@freebsdbox.adamsnet> In-Reply-To: <20111205220715.GA36072@freebsdbox.adamsnet> X-Enigmail-Version: 1.1.2 X-Provags-ID: V02:K0:BiaY45e/P7jP7wXpbYt+A2PhSrcBOQibHY1I8Ct45t7 3PRiEAeRUtmrkeaWszq1FAlY5IX28/1FEFvkYUqMP3LsBwgUfd Y9kfYHNoc2Gm6zpdicLPy3YwZlnnCOGAL0JBAQu0P61+npU2tA 9BBW+7FMH4QqWM71FzfyQV9rBAeNOZH2fpl4vNlcQ+/edjIUf7 A4MBU4aF07Qe6SdTFeuTq0/wQpDoiXFHxRHDCO4wExMRXpu/ls vLh7gSJdqerfieB8UsX4aQsO1bAZbdGpVEj5RftQ2vXOTmhN9b D/tDsQQ1ctmhJFBYVpINZCzwUqYIjlNulhh6lpw66hQm/KFnHx skSnlsFWzldQvPdmF8oBsiB+cLGWeOGn9PIyrYAkd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: weird bug with ZFS and SLOG X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 12:19:42 -0000 On 12/05/2011 11:07 PM, Adam Stylinski wrote: > The worst case scenario happened to me where my dedicated SLOG decided to drop off the controller and thus prevent me from importing my pool. I quickly upgrade to FreeBSD 9.0-RC2 after testing this scenario in a VM. It has worked successfully in a VM, but it is not working on my hardware for whatever reason. I rollback the pool with zpool import -F share, seems ok, files are there, finishes scrub, very little corruption. I upgrade the pool to V28, and the fs's to v5. I then do a: > zpool remove share 15752248745115926170 > > It returns no errors and pretends like the operation worked, it even appends it to my zpool history. However, when I do a zpool status, this is what I get: > > [adam@nasbox ~]$ zpool status > pool: share > state: DEGRADED > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scan: scrub repaired 0 in 8h57m with 0 errors on Mon Dec 5 12:48:28 2011 > config: > > NAME STATE READ WRITE CKSUM > share DEGRADED 0 0 0 > raidz1-0 ONLINE 0 0 0 > ada4 ONLINE 0 0 0 > ada1 ONLINE 0 0 0 > *ada2* ONLINE 0 0 0 > ada3 ONLINE 0 0 0 > raidz1-1 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > da0 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > raidz1-2 ONLINE 0 0 0 > aacd0 ONLINE 0 0 0 > aacd1 ONLINE 0 0 0 > aacd2 ONLINE 0 0 0 > aacd3 ONLINE 0 0 0 > raidz1-4 ONLINE 0 0 0 > aacd4 ONLINE 0 0 0 > aacd5 ONLINE 0 0 0 > aacd6 ONLINE 0 0 0 > aacd7 ONLINE 0 0 0 > logs > 15752248745115926170 UNAVAIL 0 0 0 was /dev/*ada2* This looks like another case of not using labels. (see that share has ada2 in the list, but the log "was /dev/ada2"; they must have switched... maybe they also resilvered and your log is overwritten) I did the same thing when I started on FreeBSD and ZFS... nobody warned me either. When you reboot, sometimes the disks move around and change numbers. Maybe they are reliable with onboard SATA ports (from my experience), but with more io cards, removable media, expanders, etc. they don't seem to ever stay put for me. For me, only the first disk on the back expander and the first disk on the front expander ever seem to be the same, and if I add a new disk in the back, the front ones go up by 1. When a data disk from my pool would switch places with another data disk from the same pool, zfs would automatically handle it. But when a hotspare or something else switched places, it would look the same as you see in your zpool status. "some big number .... UNAVAIL 0 0 0 was /dev/da#" Here, I wrote you a howto, to explain how to convert to labels: http://forums.freebsd.org/showthread.php?p=157004 > errors: 3 data errors, use '-v' for a list > > Here is the ending output of zpool history: > > 2011-12-05.03:38:50 zpool upgrade -V 28 -a > 2011-12-05.03:39:09 zpool export share > 2011-12-05.03:39:33 zpool import -m share > 2011-12-05.03:40:05 zpool remove share 15752248745115926170 > 2011-12-05.03:41:04 zpool remove share 15752248745115926170 > 2011-12-05.03:41:18 zpool export share > 2011-12-05.03:41:56 zpool import -m share > 2011-12-05.03:43:47 zpool remove share 15752248745115926170 > 2011-12-05.03:47:54 zpool remove share 15752248745115926170 > 2011-12-05.03:51:20 zpool scrub share > 2011-12-05.16:33:01 zfs create share/vardb2 > 2011-12-05.16:33:32 zfs set compression=gzip-9 share/vardb2 > 2011-12-05.16:33:38 zfs set atime=off share/vardb2 > 2011-12-05.16:39:37 zfs destroy share/vardb > 2011-12-05.16:39:47 zfs rename share/vardb2 share/vardb > 2011-12-05.16:39:53 zfs set mountpoint=/var/db share/vardb > 2011-12-05.16:47:24 zpool clear share > 2011-12-05.16:48:41 zpool remove share 15752248745115926170 > 2011-12-05.16:53:15 zpool export -f share > 2011-12-05.16:55:21 zpool import -m share > 2011-12-05.16:55:52 zpool remove share 15752248745115926170 > 2011-12-05.16:56:56 zpool remove share -f 15752248745115926170 > 2011-12-05.17:04:07 zpool remove share 15752248745115926170 > > What is going on here and how do I fix it? > -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 6 12:20:00 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45582106566C for ; Tue, 6 Dec 2011 12:20:00 +0000 (UTC) (envelope-from wmn@siberianet.ru) Received: from mail.siberianet.ru (mail.siberianet.ru [89.105.136.7]) by mx1.freebsd.org (Postfix) with ESMTP id AB3168FC18 for ; Tue, 6 Dec 2011 12:19:59 +0000 (UTC) Received: from wmn.localnet (wmn.siberianet.ru [89.105.137.12]) by mail.siberianet.ru (Postfix) with ESMTPA id BF19EBBAF4 for ; Tue, 6 Dec 2011 20:04:04 +0800 (KRAT) From: Sergey Lobanov To: freebsd-fs@freebsd.org Date: Tue, 6 Dec 2011 20:04:03 +0800 User-Agent: KMail/1.13.7 (Linux/2.6.38-ARCH; KDE/4.6.2; i686; ; ) References: In-Reply-To: Organization: ISP "SiberiaNet" MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112062004.03759.wmn@siberianet.ru> Subject: Re: ZFS v28: mount dataset hangs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 12:20:00 -0000 On Thursday 06 October 2011 at 16:04:30 Sergey Gavrilov wrote: > Hello, all. > > After "chown -R" hanging and reboot I cannot mount one of the > datasets, while other pools work well. > CTRL-T shows state [tx->tx_sync_done_cv)] > > Hardware: 3ware 9690SA-8I, 8 SEAGATE ST32000445SS in raidz2, 48 Gb > RAM, 2 E5520 CPU > Software: FreeBSD 8.2-STABLE #3: Wed Oct 5 18:04:50 MSD 2011 > /usr/obj/usr/src/sys/GENERIC amd64, ZFS V28 compression=on > > I can clone and mount any snapshot of the dataset, but not itself. > No errors in zpool status or system messages. Scrub has finished clear. > > Let me know if I could provide any additional information to solve the > issue. Hello. Same problem here. raidz2 using 4 disks (made with fake 4k sector size using gnop for possible future replacement by native 4k disks) with dedup, lzjb and NTFSv4 ACL which is shared over samba3.6 for windows clients. System freezed (even local log-in via ipmi didn't work) during flush of recycle (trash) over smb from windows station on one of datasets (a lot of files were being removed). After hard reset via ipmi, zfs hangs on mount of that dataset under 8.2 and 9.0-RC2 (but "zfs set mountpoint" works well). Scrubs under 8.2 and 9.0-RC2 did not help and found nothing, other datasets can be mounted without problems. Storage consists of 2 seagate disks (ST3160318AS CC38) with ufs for system, 4 WD (WD10EALX-009BA0 15.01H15) for zfs share and Qlogic 2432 FC adapter which is connected to HP tape library via FC-switch for bacula backups. All WD disks were checked with smart long self-test, went without errors, also no reallocated sectors (and events) in smart output. here is example for one of the disks: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 177 175 021 Pre-fail Always - 4108 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 60 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 6183 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 58 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 47 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 12 194 Temperature_Celsius 0x0022 122 110 000 Old_age Always - 25 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 85 Here is some other output: --- # zfs mount data/storage/public load: 0.15 cmd: zfs 1352 [tx->tx_sync_done_cv)] 348.58r 0.00u 0.92s 0% 2296k # procstat -kk 1352 PID TID COMM TDNAME KSTACK 1352 100081 zfs initial thread mi_switch+0x176 sleepq_wait+0x42 _cv_wait+0x129 txg_wait_synced+0x85 zil_replay+0x10a zfsvfs_setup+0x117 zfs_mount+0x52f vfs_donmount+0xdc5 nmount+0x63 amd64_syscall+0x1f4 Xfast_syscall+0xfc --- # zfs snapshot data/storage/public@test load: 0.02 cmd: zfs 1382 [tx->tx_sync_done_cv)] 4.34r 0.00u 0.00s 0% 2280k load: 0.09 cmd: zfs 1382 [tx->tx_sync_done_cv)] 19.13r 0.00u 0.00s 0% 2280k load: 0.01 cmd: zfs 1352 [tx->tx_sync_done_cv)] 611.74r 0.00u 0.92s 0% 2296k # procstat -kk 1382 PID TID COMM TDNAME KSTACK 1382 100295 zfs initial thread mi_switch+0x176 sleepq_wait+0x42 _cv_wait+0x129 txg_wait_synced+0x85 dsl_sync_task_group_wait+0x128 dmu_objset_snapshot+0x302 zfs_ioc_snapshot+0x1a8 zfsdev_ioctl+0xe6 devfs_ioctl_f+0x7b kern_ioctl+0x102 ioctl+0xfd amd64_syscall+0x1f4 Xfast_syscall+0xfc --- # procstat -kk 6 PID TID COMM TDNAME KSTACK 6 100058 zfskern arc_reclaim_thre mi_switch+0x176 sleepq_timedwait+0x42 _cv_timedwait+0x134 arc_reclaim_thread+0x29d fork_exit+0x11f fork_trampoline+0xe 6 100059 zfskern l2arc_feed_threa mi_switch+0x176 sleepq_timedwait+0x42 _cv_timedwait+0x134 l2arc_feed_thread+0x1a8 fork_exit+0x11f fork_trampoline+0xe 6 100279 zfskern txg_thread_enter mi_switch+0x176 sleepq_wait+0x42 _cv_wait+0x129 txg_thread_wait+0x79 txg_quiesce_thread+0xb5 fork_exit+0x11f fork_trampoline+0xe 6 100280 zfskern txg_thread_enter mi_switch+0x176 sleepq_wait+0x42 _cv_wait+0x129 zio_wait+0x61 dbuf_read+0x5e5 dmu_buf_hold+0xe0 zap_idx_to_blk+0xa3 zap_deref_leaf+0x4f fzap_remove+0x33 zap_remove_uint64+0x85 ddt_sync+0x267 spa_sync+0x383 txg_sync_thread+0x139 fork_exit+0x11f fork_trampoline+0xe --- And here is some interesting screenshot of output from 9.0-RC2 livecd shell, which leads to beleive that there was swap exhaustion while zfs mount were freezed: http://imageshack.us/photo/my-images/64/90rc2zfsmounthangswap.gif/ (didn't get this on 8.2 and 9.0-RC1 though didn't specially try to let system be in freeze for a long time). Hardware is supermicro X8SIA-F, core i3, 4Gb of memory. releng8 r226341 amd64 (with e1000 from 8.2-release for another reason), custom kernel with config: include GENERIC ident IPFW_FWD options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD ZFS-related tuning in loader.conf is only following line: vfs.zfs.arc_max="1073741824" I have couple of days for debugging (i plan to try releng9 today or tomorrow because i can see some zfs commits there after RC2), after which i'll have to move this machine to production with zfs or without it. If you need something else, let me know, i've subscribed to the list, so there is no need to CC me. -- ISP SiberiaNet System and Network Administrator From owner-freebsd-fs@FreeBSD.ORG Tue Dec 6 14:22:43 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 663A71065673 for ; Tue, 6 Dec 2011 14:22:43 +0000 (UTC) (envelope-from kungfujesus06@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id EDE448FC13 for ; Tue, 6 Dec 2011 14:22:42 +0000 (UTC) Received: by faak28 with SMTP id k28so5902310faa.13 for ; Tue, 06 Dec 2011 06:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lI/aHPVd74zzMm8dOkobiDEBqk2a+UiXcRinnANcTnU=; b=Rm1UNQLMkkWARt9kCWhPc+ixtuPCQVlu5G8oEDsrkxLVws7upMaapNH554viZESMsI 69xPmcm9+oRO7wna7QktB9/FRL3HaNXqDtnhI3mJbpHL7J1dlQBqrez5tX9cp0q3Lmsk 97qQ6pEanURJwyNJSfiq96yrVHx3zis4C8Y44= MIME-Version: 1.0 Received: by 10.180.107.229 with SMTP id hf5mr17649962wib.35.1323181361750; Tue, 06 Dec 2011 06:22:41 -0800 (PST) Received: by 10.216.55.137 with HTTP; Tue, 6 Dec 2011 06:22:41 -0800 (PST) In-Reply-To: References: <20111205220715.GA36072@freebsdbox.adamsnet> <4EDDE954.9020709@gmail.com> Date: Tue, 6 Dec 2011 09:22:41 -0500 Message-ID: From: Adam Stylinski To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: weird bug with ZFS and SLOG X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 14:22:43 -0000 On Tue, Dec 6, 2011 at 5:07 AM, Volodymyr Kostyrko wrote: > 06.12.2011 00:07, Adam Stylinski wrote: > >> The worst case scenario happened to me where my dedicated SLOG decided to >> drop off the controller and thus prevent me from importing my pool. I >> quickly upgrade to FreeBSD 9.0-RC2 after testing this scenario in a VM. It >> has worked successfully in a VM, but it is not working on my hardware for >> whatever reason. I rollback the pool with zpool import -F share, seems ok, >> files are there, finishes scrub, very little corruption. I upgrade the >> pool to V28, and the fs's to v5. I then do a: >> zpool remove share 15752248745115926170 >> >> It returns no errors and pretends like the operation worked, it >> even appends it to my zpool history. However, when I do a zpool status, >> this is what I get: >> > > Just a +1 from me, I have such pool also: > > pool: utwig > state: DEGRADED > status: One or more devices has been taken offline by the administrator. > Sufficient replicas exist for the pool to continue functioning in a > degraded state. > action: Online the device using 'zpool online' or replace the device with > 'zpool replace'. > scan: resilvered 73,6M in 0h0m with 0 errors on Fri Oct 28 14:37:10 2011 > > config: > > NAME STATE READ > WRITE CKSUM > utwig DEGRADED 0 > 0 0 > mirror-0 ONLINE 0 > 0 0 > gptid/ecb17af1-9119-11df-bb0b-**00304f4e6d80 ONLINE 0 > 0 0 > gptid/03aed1f5-95a3-11df-bb0b-**00304f4e6d80 ONLINE 0 > 0 0 > logs > gptid/231b9002-a4a5-11e0-a114-**3f386a87752c OFFLINE 0 > 0 0 > > As you see I just 'offline'd that device. > > Common points: > 1. Pool was created on 8.x. > 2. Machine runs 8_STABLE now, pool was upgraded after log device fails to > detach. > > Other hints: > The log device can be substituted with other device yet it cannot be > deleted anyway. If you have some spare place on the disk to create some > small partition for log and replace missed device with such partition. > > > What is going on here and how do I fix it? >> > > Dunno why but the pool now _requires_ log device. While log device is not > present pool should use an on-disk log and everything-should-work-fine TM. > > -- > Sphinx of black quartz judge my vow. > Actually my pool was created on 7.2 and has been updated every release, is that a factor? I did manage to do this in a VM, so in any case we'll probably have to do something that involves zdb. From owner-freebsd-fs@FreeBSD.ORG Wed Dec 7 16:50:39 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C3FE106564A; Wed, 7 Dec 2011 16:50:38 +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 586478FC13; Wed, 7 Dec 2011 16:50:36 +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 SAA00766; Wed, 07 Dec 2011 18:50:35 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EDF995B.9000407@FreeBSD.org> Date: Wed, 07 Dec 2011 18:50:35 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: zfs-related(?) panic in cache_enter: wrong vnode type X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 16:50:39 -0000 (kgdb) bt #0 doadump (textdump=1) at pcpu.h:224 #1 0xffffffff804f6d3b in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff804f63e9 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:635 #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 #4 0xffffffff81a90900 in zfs_lookup (dvp=0xfffffe003d4763c0, nm=0xffffff82393b3140 "..", vpp=0xffffff82393b36e0, cnp=0xffffff82393b3708, nameiop=0, cr=0xfffffe0042e88100, td=0xfffffe000fdfa480, flags=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1470 #5 0xffffffff81a91570 in zfs_freebsd_lookup (ap=0xffffff82393b32c0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5858 #6 0xffffffff8073f054 in VOP_CACHEDLOOKUP_APV (vop=0xffffffff81b05a20, a=0xffffff82393b32c0) at vnode_if.c:187 #7 0xffffffff80586bf4 in vfs_cache_lookup (ap=Variable "ap" is not available. ) at vnode_if.h:80 #8 0xffffffff80740a5c in VOP_LOOKUP_APV (vop=0xffffffff81b05a20, a=0xffffff82393b33a0) at vnode_if.c:123 #9 0xffffffff8058e42c in lookup (ndp=0xffffff82393b36a0) at vnode_if.h:54 #10 0xffffffff8058f17e in namei (ndp=0xffffff82393b36a0) at /usr/src/sys/kern/vfs_lookup.c:312 #11 0xffffffff805a890d in vn_open_cred (ndp=0xffffff82393b36a0, flagp=0xffffff82393b3918, cmode=0, vn_open_flags=Variable "vn_open_flags" is not available. ) at /usr/src/sys/kern/vfs_vnops.c:195 #12 0xffffffff80589e7e in vop_stdvptocnp (ap=Variable "ap" is not available. ) at /usr/src/sys/kern/vfs_default.c:774 #13 0xffffffff8073b012 in VOP_VPTOCNP_APV (vop=0xffffffff80a99140, a=0xffffff82393b39b0) at vnode_if.c:3479 #14 0xffffffff80584665 in vn_vptocnp_locked (vp=0xffffff82393b3a50, cred=0xfffffe0042e88100, buf=0xfffffe000ca06000 "������������������������������������������������������������������������������������������������������������������������������������������������������"..., buflen=0xffffff82393b3a4c) at vnode_if.h:1564 #15 0xffffffff80584bab in vn_fullpath1 (td=0xfffffe000fdfa480, vp=0xfffffe003d4763c0, rdir=0xfffffe000cd4d000, buf=0xfffffe000ca06000 "������������������������������������������������������������������������������������������������������������������������������������������������������"..., retbuf=0xffffff82393b3ab0, buflen=1023) at /usr/src/sys/kern/vfs_cache.c:1218 #16 0xffffffff8058526a in kern___getcwd (td=0xfffffe000fdfa480, buf=0x80880a000
, bufseg=UIO_USERSPACE, buflen=1024) at /usr/src/sys/kern/vfs_cache.c:960 #17 0xffffffff805853f4 in sys___getcwd (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_cache.c:934 #18 0xffffffff806d2069 in amd64_syscall (td=0xfffffe000fdfa480, traced=0) at subr_syscall.c:131 #19 0xffffffff806bb4e7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #20 0x00000008031adb2c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 3 #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 726 KASSERT(vp == NULL || vp->v_type == VDIR, (kgdb) list 721 if (dvp->v_cache_dd != NULL) { 722 CACHE_WUNLOCK(); 723 cache_free(ncp); 724 return; 725 } 726 KASSERT(vp == NULL || vp->v_type == VDIR, 727 ("wrong vnode type %p", vp)); 728 dvp->v_cache_dd = ncp; 729 } 730 (kgdb) p *vp $1 = {v_type = VREG, v_tag = 0xffffffff81afe449 "zfs", v_op = 0xffffffff81b05a20, v_data = 0xfffffe020d9a8320, v_mount = 0xfffffe001a283600, v_nmntvnodes = {tqe_next = 0xfffffe00347c6d20, tqe_prev = 0xfffffe013b0575c8}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = { lh_first = 0x0}, v_cache_dst = {tqh_first = 0xfffffe003dfcf690, tqh_last = 0xfffffe003dfcf6b0}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = { lo_name = 0xffffffff81afe449 "zfs", lo_flags = 91947008, lo_data = 0, lo_witness = 0xffffff800066e380}, lk_lock = 18446741874952610944, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96}, v_interlock = {lock_object = {lo_name = 0xffffffff807e610a "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff8000665600}, mtx_lock = 4}, v_vnlock = 0xfffffe0142517098, v_holdcnt = 2, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0xfffffe00347c6d20, tqe_prev = 0xfffffe02110d3e30}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0xffffffff807efdfa "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff800066c300}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe0142517140}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe0142517160}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff80a95ec0, bo_bsize = 131072, bo_object = 0xfffffe01fccb5620, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xfffffe0142517000, __bo_vnode = 0xfffffe0142517000}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} (kgdb) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Dec 7 17:33:12 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B948106564A; Wed, 7 Dec 2011 17:33:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6907A8FC14; Wed, 7 Dec 2011 17:33:10 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA01373; Wed, 07 Dec 2011 19:33:09 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EDFA354.60909@FreeBSD.org> Date: Wed, 07 Dec 2011 19:33:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org References: <4EDF995B.9000407@FreeBSD.org> In-Reply-To: <4EDF995B.9000407@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: zfs-related(?) panic in cache_enter: wrong vnode type X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 17:33:12 -0000 A detail that may or may not be useful. It seems that the panic happened when tried to resume a vim process. The process was suspended, its current directory and a file being edited/viewed may have been already removed. on 07/12/2011 18:50 Andriy Gapon said the following: > > (kgdb) bt > #0 doadump (textdump=1) at pcpu.h:224 > #1 0xffffffff804f6d3b in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff804f63e9 in panic (fmt=0x104
) at > /usr/src/sys/kern/kern_shutdown.c:635 > #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, > vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 > #4 0xffffffff81a90900 in zfs_lookup (dvp=0xfffffe003d4763c0, > nm=0xffffff82393b3140 "..", vpp=0xffffff82393b36e0, cnp=0xffffff82393b3708, > nameiop=0, cr=0xfffffe0042e88100, td=0xfffffe000fdfa480, > flags=0) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1470 > #5 0xffffffff81a91570 in zfs_freebsd_lookup (ap=0xffffff82393b32c0) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5858 > #6 0xffffffff8073f054 in VOP_CACHEDLOOKUP_APV (vop=0xffffffff81b05a20, > a=0xffffff82393b32c0) at vnode_if.c:187 > #7 0xffffffff80586bf4 in vfs_cache_lookup (ap=Variable "ap" is not available. > ) at vnode_if.h:80 > #8 0xffffffff80740a5c in VOP_LOOKUP_APV (vop=0xffffffff81b05a20, > a=0xffffff82393b33a0) at vnode_if.c:123 > #9 0xffffffff8058e42c in lookup (ndp=0xffffff82393b36a0) at vnode_if.h:54 > #10 0xffffffff8058f17e in namei (ndp=0xffffff82393b36a0) at > /usr/src/sys/kern/vfs_lookup.c:312 > #11 0xffffffff805a890d in vn_open_cred (ndp=0xffffff82393b36a0, > flagp=0xffffff82393b3918, cmode=0, vn_open_flags=Variable "vn_open_flags" is not > available. > ) at /usr/src/sys/kern/vfs_vnops.c:195 > #12 0xffffffff80589e7e in vop_stdvptocnp (ap=Variable "ap" is not available. > ) at /usr/src/sys/kern/vfs_default.c:774 > #13 0xffffffff8073b012 in VOP_VPTOCNP_APV (vop=0xffffffff80a99140, > a=0xffffff82393b39b0) at vnode_if.c:3479 > #14 0xffffffff80584665 in vn_vptocnp_locked (vp=0xffffff82393b3a50, > cred=0xfffffe0042e88100, > buf=0xfffffe000ca06000 > "������������������������������������������������������������������������������������������������������������������������������������������������������"..., > buflen=0xffffff82393b3a4c) at vnode_if.h:1564 > #15 0xffffffff80584bab in vn_fullpath1 (td=0xfffffe000fdfa480, > vp=0xfffffe003d4763c0, rdir=0xfffffe000cd4d000, > buf=0xfffffe000ca06000 > "������������������������������������������������������������������������������������������������������������������������������������������������������"..., > retbuf=0xffffff82393b3ab0, buflen=1023) at /usr/src/sys/kern/vfs_cache.c:1218 > #16 0xffffffff8058526a in kern___getcwd (td=0xfffffe000fdfa480, buf=0x80880a000 >
, bufseg=UIO_USERSPACE, buflen=1024) at > /usr/src/sys/kern/vfs_cache.c:960 > #17 0xffffffff805853f4 in sys___getcwd (td=Variable "td" is not available. > ) at /usr/src/sys/kern/vfs_cache.c:934 > #18 0xffffffff806d2069 in amd64_syscall (td=0xfffffe000fdfa480, traced=0) at > subr_syscall.c:131 > #19 0xffffffff806bb4e7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 > #20 0x00000008031adb2c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) fr 3 > #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, > vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 > 726 KASSERT(vp == NULL || vp->v_type == VDIR, > (kgdb) list > 721 if (dvp->v_cache_dd != NULL) { > 722 CACHE_WUNLOCK(); > 723 cache_free(ncp); > 724 return; > 725 } > 726 KASSERT(vp == NULL || vp->v_type == VDIR, > 727 ("wrong vnode type %p", vp)); > 728 dvp->v_cache_dd = ncp; > 729 } > 730 > (kgdb) p *vp > $1 = {v_type = VREG, v_tag = 0xffffffff81afe449 "zfs", v_op = 0xffffffff81b05a20, > v_data = 0xfffffe020d9a8320, v_mount = 0xfffffe001a283600, v_nmntvnodes = > {tqe_next = 0xfffffe00347c6d20, > tqe_prev = 0xfffffe013b0575c8}, v_un = {vu_mount = 0x0, vu_socket = 0x0, > vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, > v_hash = 0, v_cache_src = { > lh_first = 0x0}, v_cache_dst = {tqh_first = 0xfffffe003dfcf690, tqh_last = > 0xfffffe003dfcf6b0}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, > v_clen = 0, v_lock = {lock_object = { > lo_name = 0xffffffff81afe449 "zfs", lo_flags = 91947008, lo_data = 0, > lo_witness = 0xffffff800066e380}, lk_lock = 18446741874952610944, lk_exslpfail = > 0, lk_timo = 51, lk_pri = 96}, > v_interlock = {lock_object = {lo_name = 0xffffffff807e610a "vnode interlock", > lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff8000665600}, mtx_lock = 4}, > v_vnlock = 0xfffffe0142517098, > v_holdcnt = 2, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0, > v_freelist = {tqe_next = 0xfffffe00347c6d20, tqe_prev = 0xfffffe02110d3e30}, > v_bufobj = {bo_mtx = {lock_object = { > lo_name = 0xffffffff807efdfa "bufobj interlock", lo_flags = 16973824, > lo_data = 0, lo_witness = 0xffffff800066c300}, mtx_lock = 4}, bo_clean = {bv_hd = > {tqh_first = 0x0, > tqh_last = 0xfffffe0142517140}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = > {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe0142517160}, bv_root = 0x0, bv_cnt = > 0}, bo_numoutput = 0, bo_flag = 0, > bo_ops = 0xffffffff80a95ec0, bo_bsize = 131072, bo_object = > 0xfffffe01fccb5620, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = > 0xfffffe0142517000, __bo_vnode = 0xfffffe0142517000}, > v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} > (kgdb) > -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Dec 7 18:09:30 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD3701065672; Wed, 7 Dec 2011 18:09:30 +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 036378FC08; Wed, 7 Dec 2011 18:09:29 +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 UAA01823; Wed, 07 Dec 2011 20:09:28 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EDFABD7.20301@FreeBSD.org> Date: Wed, 07 Dec 2011 20:09:27 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-fs@FreeBSD.org References: <4EDF995B.9000407@FreeBSD.org> <4EDFA354.60909@FreeBSD.org> In-Reply-To: <4EDFA354.60909@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: zfs-related(?) panic in cache_enter: wrong vnode type X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 18:09:30 -0000 on 07/12/2011 19:33 Andriy Gapon said the following: > > A detail that may or may not be useful. > It seems that the panic happened when tried to resume a vim process. The process > was suspended, its current directory and a file being edited/viewed may have been > already removed. And another data point: (kgdb) p ((znode_t *)dvp->v_data)->z_unlinked Perhaps lookup in unlinked directories should just fail? I am not sufficiently familiar with VFS, so just guessing. > on 07/12/2011 18:50 Andriy Gapon said the following: >> >> (kgdb) bt >> #0 doadump (textdump=1) at pcpu.h:224 >> #1 0xffffffff804f6d3b in kern_reboot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:447 >> #2 0xffffffff804f63e9 in panic (fmt=0x104
) at >> /usr/src/sys/kern/kern_shutdown.c:635 >> #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, >> vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 >> #4 0xffffffff81a90900 in zfs_lookup (dvp=0xfffffe003d4763c0, >> nm=0xffffff82393b3140 "..", vpp=0xffffff82393b36e0, cnp=0xffffff82393b3708, >> nameiop=0, cr=0xfffffe0042e88100, td=0xfffffe000fdfa480, >> flags=0) at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1470 >> #5 0xffffffff81a91570 in zfs_freebsd_lookup (ap=0xffffff82393b32c0) at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5858 >> #6 0xffffffff8073f054 in VOP_CACHEDLOOKUP_APV (vop=0xffffffff81b05a20, >> a=0xffffff82393b32c0) at vnode_if.c:187 >> #7 0xffffffff80586bf4 in vfs_cache_lookup (ap=Variable "ap" is not available. >> ) at vnode_if.h:80 >> #8 0xffffffff80740a5c in VOP_LOOKUP_APV (vop=0xffffffff81b05a20, >> a=0xffffff82393b33a0) at vnode_if.c:123 >> #9 0xffffffff8058e42c in lookup (ndp=0xffffff82393b36a0) at vnode_if.h:54 >> #10 0xffffffff8058f17e in namei (ndp=0xffffff82393b36a0) at >> /usr/src/sys/kern/vfs_lookup.c:312 >> #11 0xffffffff805a890d in vn_open_cred (ndp=0xffffff82393b36a0, >> flagp=0xffffff82393b3918, cmode=0, vn_open_flags=Variable "vn_open_flags" is not >> available. >> ) at /usr/src/sys/kern/vfs_vnops.c:195 >> #12 0xffffffff80589e7e in vop_stdvptocnp (ap=Variable "ap" is not available. >> ) at /usr/src/sys/kern/vfs_default.c:774 >> #13 0xffffffff8073b012 in VOP_VPTOCNP_APV (vop=0xffffffff80a99140, >> a=0xffffff82393b39b0) at vnode_if.c:3479 >> #14 0xffffffff80584665 in vn_vptocnp_locked (vp=0xffffff82393b3a50, >> cred=0xfffffe0042e88100, >> buf=0xfffffe000ca06000 >> "������������������������������������������������������������������������������������������������������������������������������������������������������"..., >> buflen=0xffffff82393b3a4c) at vnode_if.h:1564 >> #15 0xffffffff80584bab in vn_fullpath1 (td=0xfffffe000fdfa480, >> vp=0xfffffe003d4763c0, rdir=0xfffffe000cd4d000, >> buf=0xfffffe000ca06000 >> "������������������������������������������������������������������������������������������������������������������������������������������������������"..., >> retbuf=0xffffff82393b3ab0, buflen=1023) at /usr/src/sys/kern/vfs_cache.c:1218 >> #16 0xffffffff8058526a in kern___getcwd (td=0xfffffe000fdfa480, buf=0x80880a000 >>
, bufseg=UIO_USERSPACE, buflen=1024) at >> /usr/src/sys/kern/vfs_cache.c:960 >> #17 0xffffffff805853f4 in sys___getcwd (td=Variable "td" is not available. >> ) at /usr/src/sys/kern/vfs_cache.c:934 >> #18 0xffffffff806d2069 in amd64_syscall (td=0xfffffe000fdfa480, traced=0) at >> subr_syscall.c:131 >> #19 0xffffffff806bb4e7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 >> #20 0x00000008031adb2c in ?? () >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) fr 3 >> #3 0xffffffff80585f46 in cache_enter (dvp=0xfffffe003d4763c0, >> vp=0xfffffe0142517000, cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 >> 726 KASSERT(vp == NULL || vp->v_type == VDIR, >> (kgdb) list >> 721 if (dvp->v_cache_dd != NULL) { >> 722 CACHE_WUNLOCK(); >> 723 cache_free(ncp); >> 724 return; >> 725 } >> 726 KASSERT(vp == NULL || vp->v_type == VDIR, >> 727 ("wrong vnode type %p", vp)); >> 728 dvp->v_cache_dd = ncp; >> 729 } >> 730 >> (kgdb) p *vp >> $1 = {v_type = VREG, v_tag = 0xffffffff81afe449 "zfs", v_op = 0xffffffff81b05a20, >> v_data = 0xfffffe020d9a8320, v_mount = 0xfffffe001a283600, v_nmntvnodes = >> {tqe_next = 0xfffffe00347c6d20, >> tqe_prev = 0xfffffe013b0575c8}, v_un = {vu_mount = 0x0, vu_socket = 0x0, >> vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, >> v_hash = 0, v_cache_src = { >> lh_first = 0x0}, v_cache_dst = {tqh_first = 0xfffffe003dfcf690, tqh_last = >> 0xfffffe003dfcf6b0}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, >> v_clen = 0, v_lock = {lock_object = { >> lo_name = 0xffffffff81afe449 "zfs", lo_flags = 91947008, lo_data = 0, >> lo_witness = 0xffffff800066e380}, lk_lock = 18446741874952610944, lk_exslpfail = >> 0, lk_timo = 51, lk_pri = 96}, >> v_interlock = {lock_object = {lo_name = 0xffffffff807e610a "vnode interlock", >> lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff8000665600}, mtx_lock = 4}, >> v_vnlock = 0xfffffe0142517098, >> v_holdcnt = 2, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0, >> v_freelist = {tqe_next = 0xfffffe00347c6d20, tqe_prev = 0xfffffe02110d3e30}, >> v_bufobj = {bo_mtx = {lock_object = { >> lo_name = 0xffffffff807efdfa "bufobj interlock", lo_flags = 16973824, >> lo_data = 0, lo_witness = 0xffffff800066c300}, mtx_lock = 4}, bo_clean = {bv_hd = >> {tqh_first = 0x0, >> tqh_last = 0xfffffe0142517140}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = >> {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe0142517160}, bv_root = 0x0, bv_cnt = >> 0}, bo_numoutput = 0, bo_flag = 0, >> bo_ops = 0xffffffff80a95ec0, bo_bsize = 131072, bo_object = >> 0xfffffe01fccb5620, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = >> 0xfffffe0142517000, __bo_vnode = 0xfffffe0142517000}, >> v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} >> (kgdb) >> > > -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Dec 8 08:14:05 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DBD71065673; Thu, 8 Dec 2011 08:14:05 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id D6B508FC14; Thu, 8 Dec 2011 08:14:04 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 064DA784; Thu, 8 Dec 2011 09:14:04 +0100 (CET) Date: Thu, 8 Dec 2011 09:13:04 +0100 From: Pawel Jakub Dawidek To: Andriy Gapon Message-ID: <20111208081304.GE1678@garage.freebsd.pl> References: <4EDF995B.9000407@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k3qmt+ucFURmlhDS" Content-Disposition: inline In-Reply-To: <4EDF995B.9000407@FreeBSD.org> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: zfs-related(?) panic in cache_enter: wrong vnode type X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 08:14:05 -0000 --k3qmt+ucFURmlhDS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 07, 2011 at 06:50:35PM +0200, Andriy Gapon wrote: > (kgdb) bt > #0 doadump (textdump=3D1) at pcpu.h:224 > #1 0xffffffff804f6d3b in kern_reboot (howto=3D260) at > /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff804f63e9 in panic (fmt=3D0x104
) at > /usr/src/sys/kern/kern_shutdown.c:635 > #3 0xffffffff80585f46 in cache_enter (dvp=3D0xfffffe003d4763c0, > vp=3D0xfffffe0142517000, cnp=3D0xffffff82393b3708) at /usr/src/sys/kern/v= fs_cache.c:726 > #4 0xffffffff81a90900 in zfs_lookup (dvp=3D0xfffffe003d4763c0, > nm=3D0xffffff82393b3140 "..", vpp=3D0xffffff82393b36e0, cnp=3D0xffffff823= 93b3708, > nameiop=3D0, cr=3D0xfffffe0042e88100, td=3D0xfffffe000fdfa480, > flags=3D0) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /zfs_vnops.c:1470 Which FreeBSD version is it? Because lines doesn't seem to match neither to HEAD nor to stable/8. It would be best of you could send me few lines around zfs_vnops.c:1470 and vfs_cache.c:726. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --k3qmt+ucFURmlhDS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk7gcZAACgkQForvXbEpPzT2BwCdHa1bkovzE8qspjSQPQtLtSJr tMQAoLC5VMIG5qMZSB7cWY8fLucu30j/ =Svjs -----END PGP SIGNATURE----- --k3qmt+ucFURmlhDS-- From owner-freebsd-fs@FreeBSD.ORG Thu Dec 8 09:23:51 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44C5B106566B; Thu, 8 Dec 2011 09:23: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 2D0138FC1D; Thu, 8 Dec 2011 09:23:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA15187; Thu, 08 Dec 2011 11:23:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RYaCh-0004cJ-Di; Thu, 08 Dec 2011 11:23:47 +0200 Message-ID: <4EE08220.3010908@FreeBSD.org> Date: Thu, 08 Dec 2011 11:23:44 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4EDF995B.9000407@FreeBSD.org> <20111208081304.GE1678@garage.freebsd.pl> In-Reply-To: <20111208081304.GE1678@garage.freebsd.pl> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: zfs-related(?) panic in cache_enter: wrong vnode type X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 09:23:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 08/12/2011 10:13 Pawel Jakub Dawidek said the following: > On Wed, Dec 07, 2011 at 06:50:35PM +0200, Andriy Gapon wrote: >> (kgdb) bt #0 doadump (textdump=1) at pcpu.h:224 #1 0xffffffff804f6d3b >> in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 >> 0xffffffff804f63e9 in panic (fmt=0x104
) at >> /usr/src/sys/kern/kern_shutdown.c:635 #3 0xffffffff80585f46 in >> cache_enter (dvp=0xfffffe003d4763c0, vp=0xfffffe0142517000, >> cnp=0xffffff82393b3708) at /usr/src/sys/kern/vfs_cache.c:726 #4 >> 0xffffffff81a90900 in zfs_lookup (dvp=0xfffffe003d4763c0, >> nm=0xffffff82393b3140 "..", vpp=0xffffff82393b36e0, >> cnp=0xffffff82393b3708, nameiop=0, cr=0xfffffe0042e88100, >> td=0xfffffe000fdfa480, flags=0) at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1470 > >> > Which FreeBSD version is it? Because lines doesn't seem to match neither to > HEAD nor to stable/8. It would be best of you could send me few lines > around zfs_vnops.c:1470 and vfs_cache.c:726. > It's recent svn head, r228017, just with some local unrelated modifications. 1458 #ifdef FREEBSD_NAMECACHE 1459 /* 1460 * Insert name into cache (as non-existent) if appropriate. 1461 */ 1462 if (error == ENOENT && (cnp->cn_flags & MAKEENTRY) && nameiop != CREATE) 1463 cache_enter(dvp, *vpp, cnp); 1464 /* 1465 * Insert name into cache if appropriate. 1466 */ 1467 if (error == 0 && (cnp->cn_flags & MAKEENTRY)) { 1468 if (!(cnp->cn_flags & ISLASTCN) || 1469 (nameiop != DELETE && nameiop != RENAME)) { 1470 cache_enter(dvp, *vpp, cnp); 1471 } 1472 } 1473 #endif ================ 716 if (flag == NCF_ISDOTDOT) { 717 /* 718 * See if we are trying to add .. entry, but some other lookup 719 * has populated v_cache_dd pointer already. 720 */ 721 if (dvp->v_cache_dd != NULL) { 722 CACHE_WUNLOCK(); 723 cache_free(ncp); 724 return; 725 } 726 KASSERT(vp == NULL || vp->v_type == VDIR, 727 ("wrong vnode type %p", vp)); 728 dvp->v_cache_dd = ncp; 729 } - -- Andriy Gapon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO4IIgAAoJEHSlLSemUf4v5v0H/RqN3RagBBleHYZTY+39gxj3 I2urnYxB+1vi2b9o/B4KRQXi5gByAY3sukDnKrABxXK3ycOOJjQ5o8Xz0NMqcwHY r6oMnh/4NLpZi+Cwx0LQKycRZuPMsKzYJpMrofE/Q9Nl1EgUjz6Er2fOaEiu1xUO DAWKrJdgFNE3Kwjy64oqftcC9Aw9g0+lcyVp+Pzw9HRHzw1h8wokH+EvslfFqtJ0 YFCabxTxNQrqpCgv8PEEAAyNiqB7S9X43f5RKNuMFOiwGp8GsP7O6j9AFDUoM9os +KkkN0hE28jB4daQ0HJpPr9Kz3Mkr91yMT+nxMv1lPH9BmGYWwbx3Jck0c7o+OY= =8Y/W -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Thu Dec 8 14:05:54 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 698E3106566B; Thu, 8 Dec 2011 14:05:54 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B5E0A8FC08; Thu, 8 Dec 2011 14:05:53 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so3438966wgb.31 for ; Thu, 08 Dec 2011 06:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=qrJOUiJRGylHrthn0eoqGR0BtnWhbkl9jc+/8tbIuX4=; b=vSQiGEPy45SaN7qHewiWjNa5Xs/5yGEnBJtxzaH9R7QXOecmZee1NMMtT2n0N2zaEH hptD4UkmZtMY2YU5a2oxoCovH+dimgIGvRd4H4EVH43NXL4+rND4yFVSgFEy09aBz+7F apxIBxyYa10YKjZmvjyRvFdvO1BPc39xsW940= Received: by 10.180.104.2 with SMTP id ga2mr5870328wib.33.1323351790300; Thu, 08 Dec 2011 05:43:10 -0800 (PST) Received: from thorin (52.Red-95-122-67.staticIP.rima-tde.net. [95.122.67.52]) by mx.google.com with ESMTPS id ei9sm1473666wid.0.2011.12.08.05.43.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Dec 2011 05:43:09 -0800 (PST) Sender: Robert Millan Received: from rmh by thorin with local (Exim 4.72) (envelope-from ) id 1RYeFf-0001NJ-5y; Thu, 08 Dec 2011 14:43:07 +0100 Date: Thu, 8 Dec 2011 14:43:07 +0100 From: Robert Millan To: freebsd-fs@freebsd.org, dougb@freebsd.org Message-ID: <20111208134307.GA5266@thorin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Adrian Chadd Subject: [PATCH] Wipe other file systems when creating new UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 14:05:54 -0000 --pvezYHf7grwyp3Bc Content-Type: multipart/mixed; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, This patch resolves a problem reported to Debian BTS [1] which also affects FreeBSD. The problem is that if you create a ZFS file system in a partition and later decide you'd rather use UFS and overwrite it, remnants of ZFS uberblocks are left at the beginning and end of the partition. This can lead to disaster (data loss) if "zpool import" is attempted, as it would destroy UFS data structures. newfs(8) currently erases remnants of UFS if they exist. I think it should go further and erase first and last 512 kiB of the partition. [1] http://bugs.debian.org/635272 --=20 Robert Millan --UugvWAfsgieZRqgk Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="wipe_other_fs.diff" Content-Transfer-Encoding: quoted-printable Index: sbin/newfs/mkfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sbin/newfs/mkfs.c (revision 228348) +++ sbin/newfs/mkfs.c (working copy) @@ -113,6 +113,7 @@ mkfs(struct partition *pp, char *fsys) { int fragsperinode, optimalfpg, origdensity, minfpg, lastminfpg; + off_t mediasize; long i, j, csfrags; uint cg; time_t utime; @@ -505,24 +506,23 @@ sblock.fs_size * sblock.fs_fsize - sblock.fs_sblockloc); } /* - * Wipe out old UFS1 superblock(s) if necessary. + * Wipe out other file systems. For now we erase first and last 512 kiB + * (this works for at least UFS1 and ZFS). */ - if (!Nflag && Oflag !=3D 1) { - i =3D bread(&disk, part_ofs + SBLOCK_UFS1 / disk.d_bsize, chdummy, SBLOC= KSIZE); - if (i =3D=3D -1) - err(1, "can't read old UFS1 superblock: %s", disk.d_error); + if (!Eflag && !Nflag) { + mediasize =3D get_block_device_size(disk.d_fd); =20 - if (fsdummy.fs_magic =3D=3D FS_UFS1_MAGIC) { - fsdummy.fs_magic =3D 0; - bwrite(&disk, part_ofs + SBLOCK_UFS1 / disk.d_bsize, - chdummy, SBLOCKSIZE); - for (cg =3D 0; cg < fsdummy.fs_ncg; cg++) { - if (fsbtodb(&fsdummy, cgsblock(&fsdummy, cg)) > fssize) - break; - bwrite(&disk, part_ofs + fsbtodb(&fsdummy, - cgsblock(&fsdummy, cg)), chdummy, SBLOCKSIZE); - } - } + printf("Erasing sectors [%jd...%jd]\n", + sblock.fs_sblockloc / disk.d_bsize, + fsbtodb(&sblock, sblock.fs_size) - 1); + berase(&disk, sblock.fs_sblockloc / disk.d_bsize, + 1024 * disk.d_bsize - sblock.fs_sblockloc); + + printf("Erasing sectors [%jd...%jd]\n", + (mediasize - 1024 * 512) / disk.d_bsize, + (mediasize / disk.d_bsize) - 1); + berase(&disk, (mediasize - 1024 * 512) / disk.d_bsize, + 1024 * 512); } if (!Nflag) do_sbwrite(&disk); --UugvWAfsgieZRqgk-- --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/kFreeBSD) iQIcBAEBCAAGBQJO4L7pAAoJELd1onhloKnOSckP/2naJNqSpTOE84U+Ng/HcgW7 OtrYHlcTGVaeb+dV/MsFPiTW3g+w8A3+r1UsU8E9hrJGjZ27OQfI5dPZa9xgtRow GAWLpmc0Hh5tvEGcCSEPhJX/03DzejzkYEPE9hIorp2ovoviaR+UpROi+RaH3ode 37OorAMp47xDXBHHe5BC2oOooRHCRrZMHaJFtoHXesykK0ehUmYZEYzeWIyKdtnd piZ54+veQvnTBROYrUNlY0DrDH9zuROLF7Pzhh5sx/8YSvrzjnJrqozO0pP2+hbs 1176skKzAGG5HOl5xxSS5Q5zf3y0Zdvi/+N5bdM918jhB2UH6d9UfrOSKNjNQzpH RdJ0ACA/7CW7kdgSa6yYjKlpkLpp3gAIJ8VicLoJF7RYV1MhZK4YDsfx3NcDHF2k pa5qCMAjQwPmO0iQHjA6oRnuy6/KNJj+quI0e+G+XAtq/pOHb+RwChDLJYjq6tw0 nGSGgRKWveOTbN94t2AxrPlh1IRLcO7po/p+T2d4RojqEt8/U8yEO/J2An1gETEx 8Mtyt0BtyDx1d3v/U6Ko8Gp8Qly4WiJ9KaO0fnTN+DTFXgAplJ0oXGxAAjZw0nfY 4BQPCEfejMpGMsNwTARh+w9usDxrdZ0FPK3c1Jf01gsDaMnNHB2cWZaDHCti0iia CEYYqBB3aNWfPx1KobHN =SO4B -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From owner-freebsd-fs@FreeBSD.ORG Thu Dec 8 20:24:22 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 096841065670 for ; Thu, 8 Dec 2011 20:24:22 +0000 (UTC) (envelope-from danno@internet2.edu) Received: from int-proxy01.merit.edu (int-proxy01.merit.edu [207.75.116.230]) by mx1.freebsd.org (Postfix) with ESMTP id C482E8FC08 for ; Thu, 8 Dec 2011 20:24:21 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy01.merit.edu (Postfix) with ESMTP id 45A15100058 for ; Thu, 8 Dec 2011 15:06:34 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy01.merit.edu Received: from int-proxy01.merit.edu ([127.0.0.1]) by localhost (int-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv89+Cb+N3Ws for ; Thu, 8 Dec 2011 15:06:33 -0500 (EST) Received: from shrubbery.internet2.edu (eduroam-wlan-116.internet2.edu [198.108.5.116]) by int-proxy01.merit.edu (Postfix) with ESMTPSA id D631C100056 for ; Thu, 8 Dec 2011 15:06:32 -0500 (EST) Message-ID: <4EE118C7.8030803@internet2.edu> Date: Thu, 08 Dec 2011 15:06:31 -0500 From: Dan Pritts User-Agent: Postbox 3.0.2 (Macintosh/20111203) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 20:24:22 -0000 Hi all, I've got a data archive on several ZFS filesystems on a single 8.2-release system. When scrubbing, or sometimes even when copying data between ZFS filesystems, the system frequently hangs. System info: Sun x4200, 16GB RAM. FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Dual Core AMD Opteron(tm) Processor 285 SE (2592.62-MHz K8-class CPU) real memory = 17179869184 (16384 MB) avail memory = 16439779328 (15678 MB) internal LSI mpt-driver hardware raid for boot. 3x LSI parallel-scsi cards for primary storage. 48 SATA disks attached. Using Infortrend RAIDs as JBODs. 5 9-disk RAIDz2 zpools each independent of one another. 3 of them now have 2TB disks; the others still have 500GB disks. The pools were originally created under Solaris/amd64. The system ran on that for several years with no apparent issues, including doing weekly scrubs. I switched the system to FreeBSD when my contract came up for renewal at the new Oracle rates. I've posted some system information (zpool status output, loader.conf, some screenshots from system hangs) at: http://people.internet2.edu/~danno/zfs/ I've adjusted some values in loader.conf. based on stuff I found in the ZFS tuning wiki (see site above) With the defaults, a single zpool scrub of one of the pools would reliably crash the system within a couple minutes. Now, it's less crashy; it will stay up for many hours, but still hangs every 6-24 hours when the filesystems are being actively used (copy from one to the other, or a single scrub). So: 1) suggestions for fixing this with the current system? 2) is it expected that Freebsd 9 will be improved in the solaris compatibility layer (which i assume is what's crashing)? I have been unable to obtain crash dumps, apparently due to a bug in the mpt driver, or my hardware, or something. Filed a bug in the tracker about that. thanks danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224 From owner-freebsd-fs@FreeBSD.ORG Thu Dec 8 20:29:15 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EEF41065673 for ; Thu, 8 Dec 2011 20:29:15 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id EC3DA8FC14 for ; Thu, 8 Dec 2011 20:29:14 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so3010284vbb.13 for ; Thu, 08 Dec 2011 12:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FdnPEYUdBT+Y4GX1ahL/djEqO9GPKNx4NzLgAm3m06c=; b=P7audMeqH0e1UB4S1afuw6UPbTkrbuvov3EosZrZfKV/ZUz8UHnUGVZW0fqgdB6b80 z6MqZ1aV6nPh0giHPPZcSU9lvAi9y4OhCmmy3duvmdHdtb1OeJyWpzQdVi7uXo2OF3Ur LSQYnYeheCvYxiZdm/r5aSdIdEpm/5jrCxHGI= MIME-Version: 1.0 Received: by 10.52.20.209 with SMTP id p17mr2796088vde.60.1323376154319; Thu, 08 Dec 2011 12:29:14 -0800 (PST) Received: by 10.220.231.10 with HTTP; Thu, 8 Dec 2011 12:29:14 -0800 (PST) In-Reply-To: <4EE118C7.8030803@internet2.edu> References: <4EE118C7.8030803@internet2.edu> Date: Thu, 8 Dec 2011 12:29:14 -0800 Message-ID: From: Freddie Cash To: Dan Pritts Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 20:29:15 -0000 On Thu, Dec 8, 2011 at 12:06 PM, Dan Pritts wrote: > FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 > root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > CPU: Dual Core AMD Opteron(tm) Processor 285 SE (2592.62-MHz K8-class CPU= ) > real memory =C2=A0=3D 17179869184 (16384 MB) > avail memory =3D 16439779328 (15678 MB) With a pool that big, you really should upgrade to 8-STABLE or 9-STABLE. Both of those support ZFSv28. You don't need to upgrade the pool/filesystems to ZFSv28, but the new code is much more stable and speedy. Plus, there are a lot of nice extra features in ZFSv28 compared to ZFSv15. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Thu Dec 8 21:03:48 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFFE31065672 for ; Thu, 8 Dec 2011 21:03:48 +0000 (UTC) (envelope-from danno@internet2.edu) Received: from int-proxy01.merit.edu (int-proxy01.merit.edu [207.75.116.230]) by mx1.freebsd.org (Postfix) with ESMTP id 7277D8FC0A for ; Thu, 8 Dec 2011 21:03:48 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy01.merit.edu (Postfix) with ESMTP id 09DDF10002D; Thu, 8 Dec 2011 16:03:48 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy01.merit.edu Received: from int-proxy01.merit.edu ([127.0.0.1]) by localhost (int-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtLMSRo0JPkO; Thu, 8 Dec 2011 16:03:47 -0500 (EST) Received: from shrubbery.internet2.edu (eduroam-wlan-116.internet2.edu [198.108.5.116]) by int-proxy01.merit.edu (Postfix) with ESMTPSA id 508ED10001F; Thu, 8 Dec 2011 16:03:47 -0500 (EST) Message-ID: <4EE12632.4070309@internet2.edu> Date: Thu, 08 Dec 2011 16:03:46 -0500 From: Dan Pritts User-Agent: Postbox 3.0.2 (Macintosh/20111203) MIME-Version: 1.0 To: Freddie Cash References: <4EE118C7.8030803@internet2.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 21:03:48 -0000 Upgrading is our intent...IF we stay with FreeBSD. Thus my question about stability improvements in freebsd 9. Which I guess you've answered; we'll give it a go. thanks danno > Freddie Cash > December 8, 2011 3:29 PM > > With a pool that big, you really should upgrade to 8-STABLE or > 9-STABLE. Both of those support ZFSv28. You don't need to upgrade > the pool/filesystems to ZFSv28, but the new code is much more stable > and speedy. Plus, there are a lot of nice extra features in ZFSv28 > compared to ZFSv15. > -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224 From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 00:33:25 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B739106567A for ; Fri, 9 Dec 2011 00:33:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 13D8B8FC14 for ; Fri, 9 Dec 2011 00:33:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKRW4U6DaFvO/2dsb2JhbAA7CBaEcKZpgXkjgQsCDRkCWYgomC6OApEjgTSGUxyCAoEWBIgujD2JFoku X-IronPort-AV: E=Sophos;i="4.71,322,1320642000"; d="scan'208";a="149586520" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 08 Dec 2011 19:33:24 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0DD47B3F50 for ; Thu, 8 Dec 2011 19:33:24 -0500 (EST) Date: Thu, 8 Dec 2011 19:33:24 -0500 (EST) From: Rick Macklem To: freebsd-fs@freebsd.org Message-ID: <1606267322.1154407.1323390804038.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <476FC2247D6C7843A4814ED64344560C052A32AD@seaxch10.desktop.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Subject: RFC: NLM patch that is more permissive w.r.t. F_RDLCK and F_UNLCK X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 00:33:25 -0000 I have been working on getting a patch for the NLM, originally submitted by John De (jwd@) ready to commit to -current/head. The original patch fixes the case where a client attempts a read lock, but the uid on the client only has read access for the file. (This is allowed by POSIX and local file locking, from what I can see.) I did make one change to his patch, which is to fall back to a test for write access when read access doesn't exist. This is a little weird, but since the unpatched code always checked for write access, this ensures that it will still work if it did without the patch. While testing I also spotted a problem where, if file permissions are changed between a lock and an unlock, the unlock could fail, resulting in the file being left locked "forever". When discussing this off-list, Zack responded with the following, which I have added to the patch. (ie. Being permissive w.r.t. unlock and blocking lock cancellation, so that a lock doesn't get left "forever".) Zack Kirsch wrote (re-posted with his permission): > Hey Rick, Doug, > > I completely agree. I've already implemented this change at Isilon, > where unlock passes a flag into nlm_get_vfs_state(). If the flag > is 0, then it causes the following to be skipped: > * VFS_CHECKEXP (because you still want to allow unlocking even > though exports have changed) > * read-only checks > * svc_getcred (because the cred isn't needed) > * Any cred checks > * VOP_ACCESS call Does anyone see a problem with this? (There could be a security argument against it, but I will simply note that there is really no security against faulty clients in NFSv3 using AUTH_SYS and, since clients normally check that an open of the appropriate type exists in the client before attempting the locking operation against the server, if the client is "trusted" then this shouldn't be an issue.) The patch is at: http://people.freebsd.org/~rmacklem/nlmrlock.patch Please comment on the above or the patch. Thanks, rick From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 00:59:36 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 118ED1065672; Fri, 9 Dec 2011 00:59:36 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id BC4DA8FC14; Fri, 9 Dec 2011 00:59:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Message-Id:References:In-Reply-To:Subject:To:From:Date:Content-Type:Mime-Version; bh=gEUvcysFavXLfmhWaue+juKdwbyhssRoJWgWTUq0WCw=; b=JSFf+ecIq0PdIMC95Aj5ysgfE4n9qUS7XrjKbaBh/stZmDmSVq5E+CiUlIRvNDaf+T9mcpKNufw4KPrqcZ96n+eSJVcYq7hnCSva+9pdFJsAun+C7xaNXP/yKqNKoCkO; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RYooH-0002su-JL; Thu, 08 Dec 2011 18:59:34 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1323392367-1863-1862/5/11; Fri, 9 Dec 2011 00:59:27 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Thu, 8 Dec 2011 18:59:27 -0600 From: Mark Felder To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <20111126104840.GA8794@garage.freebsd.pl> References: <95d00c1b714837aa32e7da72bc4afd03@feld.me> <20111126104840.GA8794@garage.freebsd.pl> Message-Id: X-Sender: feld@feld.me User-Agent: Roundcube Webmail/0.6 X-SA-Score: -1.0 Cc: Subject: Re: zfs i/o hangs on 9-PRERELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 00:59:36 -0000 Hi all, Just wanted to report back that I found time to do more diagnostics. ZFS/FreeBSD/etc are not to blame. ZFS / FreeBSD never reported any I/O errors and scrubs always came up clean because one of the disks was failing and had issues reading the disk but would eventually return accurate data. It was sort of like having a RAIDZ with one disk that had 30s latency sometimes! Seatools confirmed this disk was failing and after replacing the disk all issues went away. From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 03:20:28 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C714B106564A for ; Fri, 9 Dec 2011 03:20:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id AE7FF8FC15 for ; Fri, 9 Dec 2011 03:20:28 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta10.emeryville.ca.mail.comcast.net with comcast id 6r8d1i0070FhH24AArLM2X; Fri, 09 Dec 2011 03:20:21 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta08.emeryville.ca.mail.comcast.net with comcast id 6rKQ1i00H1t3BNj8UrKQhY; Fri, 09 Dec 2011 03:19:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D6A02102C1D; Thu, 8 Dec 2011 19:20:26 -0800 (PST) Date: Thu, 8 Dec 2011 19:20:26 -0800 From: Jeremy Chadwick To: Dan Pritts Message-ID: <20111209032026.GA93676@icarus.home.lan> References: <4EE118C7.8030803@internet2.edu> <4EE12632.4070309@internet2.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EE12632.4070309@internet2.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 03:20:28 -0000 On Thu, Dec 08, 2011 at 04:03:46PM -0500, Dan Pritts wrote: > Upgrading is our intent...IF we stay with FreeBSD. Thus my question > about stability improvements in freebsd 9. > > Which I guess you've answered; we'll give it a go. > > thanks > danno > >Freddie Cash > >December 8, 2011 3:29 PM > > > >With a pool that big, you really should upgrade to 8-STABLE or > >9-STABLE. Both of those support ZFSv28. You don't need to upgrade > >the pool/filesystems to ZFSv28, but the new code is much more stable > >and speedy. Plus, there are a lot of nice extra features in ZFSv28 > >compared to ZFSv15. You don't have to go with FreeBSD 9.x to try and solve this problem. You can simply upgrade to FreeBSD 8.2-STABLE (you are running 8.2-RELEASE right now). ZFS has improved/changed between those 8.2 "versions". -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 04:22:30 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 130ED1065672; Fri, 9 Dec 2011 04:22:30 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id B3BB88FC13; Fri, 9 Dec 2011 04:22:29 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id C1E57B806B; Fri, 9 Dec 2011 08:05:22 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id BC309B806A; Fri, 9 Dec 2011 08:05:22 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 9F189B8F69; Fri, 9 Dec 2011 08:05:22 +0400 (MSK) Received: from [127.0.0.1] (elsukov.kirov.oduur.so [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id C6E36B8F63; Fri, 9 Dec 2011 08:05:21 +0400 (MSK) Message-ID: <4EE18901.7060800@FreeBSD.org> Date: Fri, 09 Dec 2011 08:05:21 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Robert Millan References: <20111208134307.GA5266@thorin> In-Reply-To: <20111208134307.GA5266@thorin> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: freebsd-fs@freebsd.org, Adrian Chadd Subject: Re: [PATCH] Wipe other file systems when creating new UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 04:22:30 -0000 On 08.12.2011 17:43, Robert Millan wrote: > newfs(8) currently erases remnants of UFS if they exist. I think it should > go further and erase first and last 512 kiB of the partition. Hi, i think before erasing 512 kib you should at least check actual available mediasize and don't use hardcoded 512 sector size. -- WBR, Andrey V. Elsukov From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 05:00:24 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 686621065675 for ; Fri, 9 Dec 2011 05:00:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6408FC0C for ; Fri, 9 Dec 2011 05:00:24 +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 pB950NHD028544 for ; Fri, 9 Dec 2011 05:00:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pB950Nv8028541; Fri, 9 Dec 2011 05:00:23 GMT (envelope-from gnats) Date: Fri, 9 Dec 2011 05:00:23 GMT Message-Id: <201112090500.pB950Nv8028541@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= Cc: Subject: Re: kern/149208: mksnap_ffs(8) hang/deadlock X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 05:00:24 -0000 The following reply was made to PR kern/149208; it has been noted by GNATS. From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= To: bug-followup@FreeBSD.org, karl@denninger.net Cc: Subject: Re: kern/149208: mksnap_ffs(8) hang/deadlock Date: Fri, 9 Dec 2011 06:58:51 +0200 Hi as adviced here http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-11/msg00210.html I think you need to add > + if (cg % 10 == 0) > + ffs_syncvnode(vp, MNT_WAIT); in any loop, because of depend on size of disk look can take long time. so: --- ffs_snapshot.c.orig 2011-12-09 06:45:11.000000000 +0000 +++ ffs_snapshot.c 2011-12-09 06:49:43.000000000 +0000 @@ -305,7 +305,7 @@ ip->i_flag |= IN_CHANGE | IN_UPDATE; error = readblock(vp, bp, numblks - 1); bawrite(bp); - if (error != 0) + if (error != 0) // why not just if( error ) ??? goto out; /* * Preallocate critical data structures so that we can copy @@ -324,6 +324,10 @@ if (error) goto out; bawrite(ibp); + if (blkno % 10 == 0) + ffs_syncvnode(vp, MNT_WAIT); + if (error) // to be same as line 385 + goto out; } /* * Allocate copies for the superblock and its summary information. @@ -341,6 +345,10 @@ if (error) goto out; bawrite(nbp); + if (loc % 10 == 0) + ffs_syncvnode(vp, MNT_WAIT); + if (error) //to be same as line 385 + goto out; } /* * Allocate all cylinder group blocks. @@ -353,6 +361,8 @@ bawrite(nbp); if (cg % 10 == 0) ffs_syncvnode(vp, MNT_WAIT); + if (error) //to be same as line 385 + goto out;. } /* * Copy all the cylinder group maps. Although the but I not shure. Please confirm -- Ñ óâàæåíèåì, Êîíüêîâ mailto:kes-kes@yandex.ru From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 14:20:40 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65AF81065675 for ; Fri, 9 Dec 2011 14:20:40 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (gribble.egr.msu.edu [35.9.37.169]) by mx1.freebsd.org (Postfix) with ESMTP id 268A58FC15 for ; Fri, 9 Dec 2011 14:20:39 +0000 (UTC) Received: from gribble (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 046EA735E6 for ; Fri, 9 Dec 2011 09:20:39 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by gribble (gribble.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZtdYQPu3F2f for ; Fri, 9 Dec 2011 09:20:38 -0500 (EST) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mail.egr.msu.edu (Postfix) with ESMTPSA id A5959735DC for ; Fri, 9 Dec 2011 09:20:38 -0500 (EST) Message-ID: <4EE21936.6020502@egr.msu.edu> Date: Fri, 09 Dec 2011 09:20:38 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4EE118C7.8030803@internet2.edu> <4EE12632.4070309@internet2.edu> In-Reply-To: <4EE12632.4070309@internet2.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 14:20:40 -0000 On 12/08/11 16:03, Dan Pritts wrote: > Upgrading is our intent...IF we stay with FreeBSD. Thus my question > about stability improvements in freebsd 9. > > Which I guess you've answered; we'll give it a go. > > thanks > danno >> Freddie Cash >> December 8, 2011 3:29 PM >> >> With a pool that big, you really should upgrade to 8-STABLE or >> 9-STABLE. Both of those support ZFSv28. You don't need to upgrade >> the pool/filesystems to ZFSv28, but the new code is much more stable >> and speedy. Plus, there are a lot of nice extra features in ZFSv28 >> compared to ZFSv15. >> > Some comments on your loader.conf based on experience for stability on my ZFS servers (I have not used zfs send/rec in years and generally don't use snapshots): - Ever since near the timeframe of ZFS v13 and some memory code improvements, I've been able to get ZFS to run in a stable manner if I make sure ZFS has enough ARC in a non-fragmented kmem space. Frequent ARC allocations can cause the ARC to become fragmented inside the virtual kmem space leading to slowness or stalls/panics in extreme cases. Additionally there is a bug in the code that adjusts the kmem_size based on the vm.kmem_size loader variable that you are setting; chances are if you inspect 'sysctl vm.kmem_size' you will find it considerably smaller than the 8G you set it to. I suggest: - set vm.kmem_size to double your ram to give the ARC plenty of elbow room against becoming fragmented within kmem (its a virtual address space, it is not constrained to your ram size). - to fix the bug in the kmem_size setting, edit /usr/src/sys/kern/kern_malloc.c and change cnt.v_page_count to mem_size in this code (it was recently committed to HEAD and is scheduled to be merged into other branches): vm_kmem_size = 2 * cnt.v_page_count * PAGE_SIZE; - I would still recommend setting vfs.zfs.arc_max to 2-4G if you can spare the ram unless it causes the system to starve other necessary functions or cause it to swap. I have seen ZFS speed CRAWL if the ARC is pushed too small, say 600m or under. - I wouldn't bother setting the arc_min unless you are trying to nudge it to use more ram than whatever it has chosen to use. - I wouldn't bother setting vm.kmem_size_max, it is HUGE by default - In my experience running with prefetch disabled is a significant impact to speed, once you are comfortable with doing some performance testing I would evaluate that and decide for yourself about "some discussion suggests that the prefetch sucks" - Be wary of using dedupe in v28, it seems to have a huge performance drag when working with files that were written while dedupe was enabled; I won't comment more on that except to suggest not adding that variable to your issue - These comments mostly relate to speed, but I had to give the ARC enough room to work without deadlocking the system so they may help you there. From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 14:58:08 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80A04106566B; Fri, 9 Dec 2011 14:58:08 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB1B8FC0A; Fri, 9 Dec 2011 14:58:07 +0000 (UTC) Received: by eekc50 with SMTP id c50so1892827eek.13 for ; Fri, 09 Dec 2011 06:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0SzOnNxRh2bPDx5zgCpWMqu8CsH6mr29PEh2WBm4zPo=; b=uEx/foUXywj+5f5oxlwWFqAlvMTD6d5YlFRXBbg75XshdbvT8hXVF+yhWGLvzbFASf BnDRTDkFAc/FE8gvmonVz4CUWd9rWG7pmUXMK2Mmgs9RTA09lwgY5Z4JaFYQHhl9WZfg xtnz1JzKvtxC1sza7ANqzSocDiVn4kQc60quo= Received: by 10.14.2.136 with SMTP id 8mr459065eef.132.1323442686248; Fri, 09 Dec 2011 06:58:06 -0800 (PST) Received: from green.tandem.local (utwig.xim.bz. [91.216.237.46]) by mx.google.com with ESMTPS id d6sm31992392eec.10.2011.12.09.06.58.02 (version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 06:58:03 -0800 (PST) Message-ID: <4EE221F9.9010505@gmail.com> Date: Fri, 09 Dec 2011 16:58:01 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111111 Thunderbird/8.0 MIME-Version: 1.0 To: Robert Millan References: <20111208134307.GA5266@thorin> In-Reply-To: <20111208134307.GA5266@thorin> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Adrian Chadd Subject: Re: [PATCH] Wipe other file systems when creating new UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 14:58:08 -0000 08.12.2011 15:43, Robert Millan wrote: > This patch resolves a problem reported to Debian BTS [1] which also affects > FreeBSD. The problem is that if you create a ZFS file system in a partition > and later decide you'd rather use UFS and overwrite it, remnants of ZFS > uberblocks are left at the beginning and end of the partition. This can > lead to disaster (data loss) if "zpool import" is attempted, as it would > destroy UFS data structures. > > newfs(8) currently erases remnants of UFS if they exist. I think it should > go further and erase first and last 512 kiB of the partition. > > [1] http://bugs.debian.org/635272 Shouldn't it make us a coffee then? Making precautions against shooting-the-foot is a wrong choice for me. This way we need to extend it to support any other file system that can repair thyself upon mount in case user mistakenly mounted the wrong one. What about drives that support SSD? Isn't it convenient to use TRIM in such cases? You messing up ZFS terminology a bit. Uberblock size is 1k and what you refer is ZFS vdev label. Size of vdev label is 256k. There are four vdev labels for each vdev - two at the beginning of the vdev and two at the end. All vdev labels are _aligned_ to 256k. So technically this is not just last 512k. -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 15:29:24 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60D761065670 for ; Fri, 9 Dec 2011 15:29:24 +0000 (UTC) (envelope-from jwd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 339798FC0C; Fri, 9 Dec 2011 15:29:24 +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 pB9FTOsN047283; Fri, 9 Dec 2011 15:29:24 GMT (envelope-from jwd@freefall.freebsd.org) Received: (from jwd@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pB9FTNtN047282; Fri, 9 Dec 2011 15:29:23 GMT (envelope-from jwd) Date: Fri, 9 Dec 2011 15:29:23 +0000 From: John De To: Rick Macklem Message-ID: <20111209152923.GA47235@FreeBSD.org> References: <476FC2247D6C7843A4814ED64344560C052A32AD@seaxch10.desktop.isilon.com> <1606267322.1154407.1323390804038.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1606267322.1154407.1323390804038.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org Subject: Re: RFC: NLM patch that is more permissive w.r.t. F_RDLCK and F_UNLCK X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 15:29:24 -0000 Hi Rick, We have the patch installed and will start running some tests against it today. I appreciate the time you & others have invested in this patch. Thanks, John ----- Rick Macklem's Original Message ----- > I have been working on getting a patch for the NLM, originally > submitted by John De (jwd@) ready to commit to -current/head. > The original patch fixes the case where a client attempts a read > lock, but the uid on the client only has read access for the file. > (This is allowed by POSIX and local file locking, from what I can see.) > > I did make one change to his patch, which is to fall back to a test > for write access when read access doesn't exist. This is a little > weird, but since the unpatched code always checked for write access, > this ensures that it will still work if it did without the patch. > > While testing I also spotted a problem where, if file permissions are > changed between a lock and an unlock, the unlock could fail, resulting > in the file being left locked "forever". > > When discussing this off-list, Zack responded with the following, which > I have added to the patch. (ie. Being permissive w.r.t. unlock and blocking > lock cancellation, so that a lock doesn't get left "forever".) > Zack Kirsch wrote (re-posted with his permission): > > Hey Rick, Doug, > > > > I completely agree. I've already implemented this change at Isilon, > > where unlock passes a flag into nlm_get_vfs_state(). If the flag > > is 0, then it causes the following to be skipped: > > * VFS_CHECKEXP (because you still want to allow unlocking even > > though exports have changed) > > * read-only checks > > * svc_getcred (because the cred isn't needed) > > * Any cred checks > > * VOP_ACCESS call > > Does anyone see a problem with this? > (There could be a security argument against it, but I will simply note that > there is really no security against faulty clients in NFSv3 using AUTH_SYS > and, since clients normally check that an open of the appropriate type exists > in the client before attempting the locking operation against the server, > if the client is "trusted" then this shouldn't be an issue.) > > The patch is at: > http://people.freebsd.org/~rmacklem/nlmrlock.patch > > Please comment on the above or the patch. > > Thanks, rick > From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 18:38:51 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F1D0106566B; Fri, 9 Dec 2011 18:38:51 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) by mx1.freebsd.org (Postfix) with ESMTP id 7E17B8FC13; Fri, 9 Dec 2011 18:38:51 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id pB9IcpUe038205; Fri, 9 Dec 2011 10:38:51 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201112091838.pB9IcpUe038205@chez.mckusick.com> To: Robert Millan In-reply-to: <20111208134307.GA5266@thorin> Date: Fri, 09 Dec 2011 10:38:51 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@freebsd.org, Adrian Chadd Subject: Re: [PATCH] Wipe other file systems when creating new UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 18:38:51 -0000 Generally speaking, I am in agreement with what you are trying to do. However, you should not get rid of the check for (and the erasing of) the UFS1 superblock. By default, UFS2 puts its superblock at an offset of 64K from the beginning of the partition. You then eraseup to 512K after that point which is reasonable since on a UFS2 filesystem the first 64K can be used for the bootstrap. However, UFS1 places its superblock at 8K from the beginning of the partition. You will not wipe it out if it exists and its existence (if it has not been overwritten by a bootstrap) can be quite problematic. Hence the current code that checks for its existence, and only if found its being wiped out. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 20:35:28 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B32011065670 for ; Fri, 9 Dec 2011 20:35:28 +0000 (UTC) (envelope-from danno@internet2.edu) Received: from int-proxy02.merit.edu (int-proxy02.merit.edu [207.75.116.231]) by mx1.freebsd.org (Postfix) with ESMTP id 737C38FC18 for ; Fri, 9 Dec 2011 20:35:28 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy02.merit.edu (Postfix) with ESMTP id 9E0E7120053; Fri, 9 Dec 2011 15:35:27 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy02.merit.edu Received: from int-proxy02.merit.edu ([127.0.0.1]) by localhost (int-proxy02.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98le7+HH-LmV; Fri, 9 Dec 2011 15:35:25 -0500 (EST) Received: from shrubbery.internet2.edu (desk174.internet2.edu [207.75.165.174]) by int-proxy02.merit.edu (Postfix) with ESMTPSA id 4686B12001E; Fri, 9 Dec 2011 15:35:25 -0500 (EST) Message-ID: <4EE2710C.5030009@internet2.edu> Date: Fri, 09 Dec 2011 15:35:24 -0500 From: Dan Pritts User-Agent: Postbox 3.0.2 (Macintosh/20111203) MIME-Version: 1.0 To: Jeremy Chadwick References: <4EE118C7.8030803@internet2.edu> <4EE12632.4070309@internet2.edu> <20111209032026.GA93676@icarus.home.lan> In-Reply-To: <20111209032026.GA93676@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 20:35:28 -0000 You don't have to go with FreeBSD 9.x to try and solve this problem. You can simply upgrade to FreeBSD 8.2-STABLE (you are running 8.2-RELEASE right now). ZFS has improved/changed between those 8.2 "versions". I upgraded to 8.2-STABLE last night. (8.2-RELEASE-p3 it calls itself) using freebsd-update. Unfortunately, things are worse. Scrubbed a pool; the system crashed 17 minutes in. Rebooted, let it continue the scrub, crashed 34 minutes in . screenshot from the first crash: http://people.internet2.edu/~danno/zfs/screenshot-8.2-stable-crash.png Still can't dumpon to my mpt device so no crash dump. If it would be useful I can hook up a USB drive to get a dump. Does FreeBSD 9 have further ZFS improvements vs 8.2-STABLE? thanks danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224 From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 20:39:27 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 243D2106564A for ; Fri, 9 Dec 2011 20:39:27 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D7E788FC08 for ; Fri, 9 Dec 2011 20:39:26 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so4438548vbb.13 for ; Fri, 09 Dec 2011 12:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VpqUC8ZqPuq75vrD25788c8UWGg6PSvda8CucaHoi0A=; b=Kcc9F8wn/EsNy6sGCeOKqxpPw0MocVPgJXVUQQG9WnHkNpZ1kbqNXBga6frk7Yi7qb 8rbuOhgIjW/JftUjXwzICs/CQEhbr4uh18I+h1qgeTivV1ncwt85NRhrkqzmAPaLUxRk Q7zrSMeH8erGU68cvjzertlVLRRX1l1U6jv9Q= MIME-Version: 1.0 Received: by 10.52.117.162 with SMTP id kf2mr5558527vdb.43.1323463166179; Fri, 09 Dec 2011 12:39:26 -0800 (PST) Received: by 10.220.231.10 with HTTP; Fri, 9 Dec 2011 12:39:26 -0800 (PST) In-Reply-To: <4EE2710C.5030009@internet2.edu> References: <4EE118C7.8030803@internet2.edu> <4EE12632.4070309@internet2.edu> <20111209032026.GA93676@icarus.home.lan> <4EE2710C.5030009@internet2.edu> Date: Fri, 9 Dec 2011 12:39:26 -0800 Message-ID: From: Freddie Cash To: Dan Pritts Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 20:39:27 -0000 On Fri, Dec 9, 2011 at 12:35 PM, Dan Pritts wrote: > You don't have to go with FreeBSD 9.x to try and solve this problem. > You can simply upgrade to FreeBSD 8.2-STABLE (you are running > 8.2-RELEASE right now). ZFS has improved/changed between those 8.2 > "versions". > > I upgraded to 8.2-STABLE last night. =C2=A0 (8.2-RELEASE-p3 it calls itse= lf) > using freebsd-update. 8.2-RELEASE-p3 is still 8.2-RELEASE. In SVN terms, this is releng/8.2. In CVS terms, this is tag=3DRELENG_8_2. aka "the security branch for 8.2". This is not 8-STABLE (or 8.2-STABLE). In SVN terms, you need to update to stable/8 In CVS terms, you need to update to tag=3DRELENG_8 The version number shown by "uname -a" will then show either 8-STABLE or 8.2-STABLE. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 22:20:40 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B1C11065676 for ; Fri, 9 Dec 2011 22:20:40 +0000 (UTC) (envelope-from danno@internet2.edu) Received: from int-proxy01.merit.edu (int-proxy01.merit.edu [207.75.116.230]) by mx1.freebsd.org (Postfix) with ESMTP id EE04C8FC16 for ; Fri, 9 Dec 2011 22:20:39 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy01.merit.edu (Postfix) with ESMTP id 0370510002F; Fri, 9 Dec 2011 17:20:39 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy01.merit.edu Received: from int-proxy01.merit.edu ([127.0.0.1]) by localhost (int-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36shxz-d8BYn; Fri, 9 Dec 2011 17:20:38 -0500 (EST) Received: from shrubbery.internet2.edu (desk174.internet2.edu [207.75.165.174]) by int-proxy01.merit.edu (Postfix) with ESMTPSA id 4104010001F; Fri, 9 Dec 2011 17:20:38 -0500 (EST) Message-ID: <4EE289B4.9090909@internet2.edu> Date: Fri, 09 Dec 2011 17:20:36 -0500 From: Dan Pritts User-Agent: Postbox 3.0.2 (Macintosh/20111203) MIME-Version: 1.0 To: Freddie Cash References: <4EE118C7.8030803@internet2.edu> <4EE12632.4070309@internet2.edu> <20111209032026.GA93676@icarus.home.lan> <4EE2710C.5030009@internet2.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 22:20:40 -0000 >> 8.2-RELEASE-p3 is still 8.2-RELEASE. In SVN terms, this is >> releng/8.2. In CVS terms, this is tag=RELENG_8_2. aka "the security >> branch for 8.2". ah, freebsd-update seems confused then. Also, confused between -p3 and -p4, odd. > # uname -a > FreeBSD foo.internet2.edu 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: > Tue Sep 27 18:45:57 UTC 2011 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > # freebsd-update -r 8-STABLE fetch > Looking up update.FreeBSD.org mirrors... 4 mirrors found. > Fetching metadata signature for 8.2-RELEASE from > update5.FreeBSD.org... done. > Fetching metadata index... done. > Inspecting system... done. > Preparing to download files... done. > > No updates needed to update system to 8.2-RELEASE-p4. I've found the section in the handbook regarding moving -STABLE, we'll give that a shot. Thanks for helping with all the bsd-newbie questions. danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224 From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 23:11:59 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FB561065673 for ; Fri, 9 Dec 2011 23:11:59 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6398FC15 for ; Fri, 9 Dec 2011 23:11:58 +0000 (UTC) Received: by ggnp1 with SMTP id p1so5361309ggn.13 for ; Fri, 09 Dec 2011 15:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mIIyYCeuq8jbZXWYzU/YP1MMERD10rgLwVDbyKSeroY=; b=XVH9CH7dT83qR0rPv8IIXOeAVtUU88XKWRIU5EozLpWXq0KWkRtjGlxl8frESfP186 KtKHHLHsx+nCDWdJO+AyfisqiSqI5HeaZxyiWPkNhoHFpSUuoO3onYHBNuErkIC6Sn9a bQ/EJJi7QZMXvTjSzHyUSnUc4LhbaBN/89etE= MIME-Version: 1.0 Received: by 10.100.24.34 with SMTP id 34mr744225anx.79.1323470938759; Fri, 09 Dec 2011 14:48:58 -0800 (PST) Sender: artemb@gmail.com Received: by 10.236.109.17 with HTTP; Fri, 9 Dec 2011 14:48:58 -0800 (PST) In-Reply-To: <4EE2710C.5030009@internet2.edu> References: <4EE118C7.8030803@internet2.edu> <4EE12632.4070309@internet2.edu> <20111209032026.GA93676@icarus.home.lan> <4EE2710C.5030009@internet2.edu> Date: Fri, 9 Dec 2011 14:48:58 -0800 X-Google-Sender-Auth: FmJJZb0l4pCPozyFUSlCjo4crMI Message-ID: From: Artem Belevich To: Dan Pritts Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 23:11:59 -0000 On Fri, Dec 9, 2011 at 12:35 PM, Dan Pritts wrote: ... > I upgraded to 8.2-STABLE last night. =A0 (8.2-RELEASE-p3 it calls itself) > using freebsd-update. > > Unfortunately, things are worse. > > Scrubbed a pool; the system crashed 17 minutes in. > > Rebooted, let it continue the scrub, crashed 34 minutes in . > > screenshot from the first crash: > http://people.internet2.edu/~danno/zfs/screenshot-8.2-stable-crash.png It may be very good idea to thoroughly test your RAM before you continue. ZFS is pretty good at exposing bad hardware and your crash looks very suspicious. --Artem From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 00:00:57 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE5F0106564A; Sat, 10 Dec 2011 00:00:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 749BD8FC0C; Sat, 10 Dec 2011 00:00:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAKmf4k6DaFvO/2dsb2JhbAA7CBaEcKZ6gXIBAQQBI1YFFg4KAgINGQJZBogaCKQvkSiBNIcIgiCBFgSIMIxAiReJLg X-IronPort-AV: E=Sophos;i="4.71,329,1320642000"; d="scan'208";a="149742549" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 09 Dec 2011 19:00:56 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 69EF8B4045; Fri, 9 Dec 2011 19:00:56 -0500 (EST) Date: Fri, 9 Dec 2011 19:00:56 -0500 (EST) From: Rick Macklem To: John De Message-ID: <1926966674.1448.1323475256413.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20111209152923.GA47235@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: NLM patch that is more permissive w.r.t. F_RDLCK and F_UNLCK X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 00:00:57 -0000 John De wrote: > Hi Rick, > > We have the patch installed and will start running some tests > against it today. > > I appreciate the time you & others have invested in this patch. > Don't thank me. You did all the real work on this. I'm just stickhandling it into head...rick > Thanks, > John > > > ----- Rick Macklem's Original Message ----- > > I have been working on getting a patch for the NLM, originally > > submitted by John De (jwd@) ready to commit to -current/head. > > The original patch fixes the case where a client attempts a read > > lock, but the uid on the client only has read access for the file. > > (This is allowed by POSIX and local file locking, from what I can > > see.) > > > > I did make one change to his patch, which is to fall back to a test > > for write access when read access doesn't exist. This is a little > > weird, but since the unpatched code always checked for write access, > > this ensures that it will still work if it did without the patch. > > > > While testing I also spotted a problem where, if file permissions > > are > > changed between a lock and an unlock, the unlock could fail, > > resulting > > in the file being left locked "forever". > > > > When discussing this off-list, Zack responded with the following, > > which > > I have added to the patch. (ie. Being permissive w.r.t. unlock and > > blocking > > lock cancellation, so that a lock doesn't get left "forever".) > > Zack Kirsch wrote (re-posted with his permission): > > > Hey Rick, Doug, > > > > > > I completely agree. I've already implemented this change at > > > Isilon, > > > where unlock passes a flag into nlm_get_vfs_state(). If the flag > > > is 0, then it causes the following to be skipped: > > > * VFS_CHECKEXP (because you still want to allow unlocking even > > > though exports have changed) > > > * read-only checks > > > * svc_getcred (because the cred isn't needed) > > > * Any cred checks > > > * VOP_ACCESS call > > > > Does anyone see a problem with this? > > (There could be a security argument against it, but I will simply > > note that > > there is really no security against faulty clients in NFSv3 using > > AUTH_SYS > > and, since clients normally check that an open of the appropriate > > type exists > > in the client before attempting the locking operation against the > > server, > > if the client is "trusted" then this shouldn't be an issue.) > > > > The patch is at: > > http://people.freebsd.org/~rmacklem/nlmrlock.patch > > > > Please comment on the above or the patch. > > > > Thanks, rick > > From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 02:04:37 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A97E51065678 for ; Sat, 10 Dec 2011 02:04:37 +0000 (UTC) (envelope-from danno@internet2.edu) Received: from mail.deathstar.org (maniac.deathstar.org [204.42.254.2]) by mx1.freebsd.org (Postfix) with ESMTP id 86B3A8FC08 for ; Sat, 10 Dec 2011 02:04:37 +0000 (UTC) Received: from [192.168.1.149] (c-69-244-180-112.hsd1.mi.comcast.net [69.244.180.112]) by mail.deathstar.org (Mail Transport) with ESMTP id 30655317C33D; Fri, 9 Dec 2011 20:45:07 -0500 (EST) Message-ID: <4EE2B9A0.8030802@internet2.edu> Date: Fri, 09 Dec 2011 20:45:04 -0500 From: Dan Pritts User-Agent: Postbox 3.0.2 (Macintosh/20111203) MIME-Version: 1.0 To: Artem Belevich References: <4EE118C7.8030803@internet2.edu> <4EE12632.4070309@internet2.edu> <20111209032026.GA93676@icarus.home.lan> <4EE2710C.5030009@internet2.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS hangs with 8.2-release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 02:04:37 -0000 > It may be very good idea to thoroughly test your RAM before you > continue. ZFS is pretty good at exposing bad hardware and your crash > looks very suspicious. The system was running Solaris with ZFS for several years before I switched it to FreeBSD. It did scheduled scrubs of the zpools and was up for over a year between power incidents. However, a memory test surely won't hurt. thanks for the reminder. thanks, danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224 From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 14:39:56 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18BE91065672 for ; Sat, 10 Dec 2011 14:39:56 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id C77AF8FC12 for ; Sat, 10 Dec 2011 14:39:55 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RZO5i-0008QT-FH for freebsd-fs@freebsd.org; Sat, 10 Dec 2011 15:39:54 +0100 Received: from dyn1247-198.vpn.ic.ac.uk ([129.31.247.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Dec 2011 15:39:54 +0100 Received: from johannes by dyn1247-198.vpn.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Dec 2011 15:39:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Sat, 10 Dec 2011 14:39:41 +0000 Lines: 18 Message-ID: References: <20111208134307.GA5266@thorin> <201112091838.pB9IcpUe038205@chez.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dyn1247-198.vpn.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <201112091838.pB9IcpUe038205@chez.mckusick.com> Subject: Re: [PATCH] Wipe other file systems when creating new UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 14:39:56 -0000 On 09/12/2011 18:38, Kirk McKusick wrote: > Generally speaking, I am in agreement with what you are trying to do. > However, you should not get rid of the check for (and the erasing of) > the UFS1 superblock. By default, UFS2 puts its superblock at an offset > of 64K from the beginning of the partition. You then eraseup to 512K > after that point which is reasonable since on a UFS2 filesystem the > first 64K can be used for the bootstrap. However, UFS1 places its > superblock at 8K from the beginning of the partition. You will not > wipe it out if it exists and its existence (if it has not been > overwritten by a bootstrap) can be quite problematic. Hence the > current code that checks for its existence, and only if found its > being wiped out. Naive question here: why not wipe the first and last few megabytes? Better safe than sorry... Also would be good to document the cases this is supposed to catch *in the code*. So that is does not get forgotten. From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 16:15:21 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3617F1065677 for ; Sat, 10 Dec 2011 16:15:21 +0000 (UTC) (envelope-from kamil.choudhury@anserinae.net) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id 0BBDE8FC16 for ; Sat, 10 Dec 2011 16:15:20 +0000 (UTC) Received: from homiemail-a91.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by hapkido.dreamhost.com (Postfix) with ESMTP id 153A917EEBF for ; Sat, 10 Dec 2011 07:50:08 -0800 (PST) Received: from homiemail-a91.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a91.g.dreamhost.com (Postfix) with ESMTP id 8069A36A06D for ; Sat, 10 Dec 2011 07:50:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=anserinae.net; h=message-id:date :subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=anserinae.net; b=kM9mHxNvfAs qUDLkXf91VaPbQjXT2dIGoKxk9PHlMTGA1s4JNbuas2ouHHAeKCMylxceDip7cGd VJFVRtoGv9lDI/o77E6pLfFiPGF/GO5XzeuMICUsZGFkxbWQB4JJQNmnc4e8A30c 1sqYV3bG0vEIOmb8SwschmaLaHDxUiNc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=anserinae.net; h= message-id:date:subject:from:to:reply-to:mime-version :content-type:content-transfer-encoding; s=anserinae.net; bh=5z0 VX2UJDs19JvnZzwXmqM6OfMQ=; b=TaJKs4PiUtuX8exFmQ4kQqbiONicrX4r4o1 P+4nVEbWbnJbER2rHYLJByywQV5bgHq9/v2SXd7Et2KigtuxQCQUmbxXWcIdcQpC TVIoG3LKZlylEAplOIaTNGQwH+tf4CO9p78LhU9E7TP3wncnmCX9FELYEYRjCduW 9Wf2kvyY= Received: from webmail.anserinae.net (ahfbbjcaiaae.dreamhost.com [75.119.208.4]) (Authenticated sender: kamil.choudhury@anserinae.net) by homiemail-a91.g.dreamhost.com (Postfix) with ESMTPA id 7D10A36A06B for ; Sat, 10 Dec 2011 07:50:07 -0800 (PST) Received: from 68.173.236.44 (proxying for 68.173.236.44) (SquirrelMail authenticated user kamil.choudhury@anserinae.net) by webmail.anserinae.net with HTTP; Sat, 10 Dec 2011 10:50:07 -0500 Message-ID: Date: Sat, 10 Dec 2011 10:50:07 -0500 From: "Kamil Choudhury" To: freebsd-fs@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: mysterious sysctl failure on nullfs mount X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kamil.choudhury@anserinae.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 16:15:21 -0000 Hi all: I've been trying to figure out what's going on with this bug for a few da= ys now: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D899628+0+current/freebsd-p= orts-bugs Summary: you mount the virtualbox binaries to /usr/local/ via nullfs, and execution fails with a syctl error. I've figured out the bit of code that's causing the error, and I've encapsulated it in the following (small) program: #include #include #include #include #include int main( void ) { char g_szSupLibHardenedExePath[5000]; int aiName[4]; aiName[0] =3D CTL_KERN; aiName[1] =3D KERN_PROC; aiName[2] =3D KERN_PROC_PATHNAME; aiName[3] =3D getpid(); size_t cbPath =3D sizeof( g_szSupLibHardenedExePath ); printf( "%d\n", cbPath ); if(sysctl(aiName, 4, g_szSupLibHardenedExePath, &cbPath, NULL, 0)= < 0) printf( "sysctl failed" ); else printf( "sysctl succeeded" ); return( 0 ); } Here's where it gets weird: if the code is executed in in /usr/local/lib/virtualbox, it fails with the sysctl error. If the code is executed in another location on the *same* nullfs mount (say, /usr/local/bin/), it executes fine. There seems to be a something at a filesystem level that's preventing execution -- does anyone on the list know what that something may be? Thanks, Kamil From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 16:36:41 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 073301065678 for ; Sat, 10 Dec 2011 16:36:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D2BC88FC1F for ; Sat, 10 Dec 2011 16:36:39 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBAGaRsK087216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Dec 2011 18:36:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBAGaQG6027539; Sat, 10 Dec 2011 18:36:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBAGaPqb027538; Sat, 10 Dec 2011 18:36:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 10 Dec 2011 18:36:25 +0200 From: Kostik Belousov To: Kamil Choudhury Message-ID: <20111210163625.GY50300@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kcC1fNEgTMCB/ozP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: mysterious sysctl failure on nullfs mount X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 16:36:41 -0000 --kcC1fNEgTMCB/ozP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 10, 2011 at 10:50:07AM -0500, Kamil Choudhury wrote: > Hi all: >=20 > I've been trying to figure out what's going on with this bug for a few da= ys now: >=20 > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D899628+0+current/freebsd-p= orts-bugs >=20 > Summary: you mount the virtualbox binaries to /usr/local/ via nullfs, and > execution fails with a syctl error. >=20 > I've figured out the bit of code that's causing the error, and I've > encapsulated it in the following (small) program: >=20 > #include > #include > #include > #include > #include >=20 > int main( void ) > { > char g_szSupLibHardenedExePath[5000]; > int aiName[4]; > aiName[0] =3D CTL_KERN; > aiName[1] =3D KERN_PROC; > aiName[2] =3D KERN_PROC_PATHNAME; > aiName[3] =3D getpid(); >=20 > size_t cbPath =3D sizeof( g_szSupLibHardenedExePath ); > printf( "%d\n", cbPath ); > if(sysctl(aiName, 4, g_szSupLibHardenedExePath, &cbPath, NULL, 0)= < 0) > printf( "sysctl failed" ); > else > printf( "sysctl succeeded" ); >=20 > return( 0 ); > } >=20 > Here's where it gets weird: if the code is executed in in > /usr/local/lib/virtualbox, it fails with the sysctl error. If the code is > executed in another location on the *same* nullfs mount (say, > /usr/local/bin/), it executes fine. >=20 > There seems to be a something at a filesystem level that's preventing > execution -- does anyone on the list know what that something may be? You did not specified which version of the OS you are running. --kcC1fNEgTMCB/ozP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7jiokACgkQC3+MBN1Mb4hxsQCglmZH0/Urn1edNnWHpY0+P1qt 7qYAn2x0RJOavl+5kSayi++M6Kww7Brd =RCq9 -----END PGP SIGNATURE----- --kcC1fNEgTMCB/ozP-- From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 16:46:13 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1714106564A; Sat, 10 Dec 2011 16:46:13 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 730978FC0A; Sat, 10 Dec 2011 16:46:13 +0000 (UTC) Received: by iakl21 with SMTP id l21so146276iak.13 for ; Sat, 10 Dec 2011 08:46:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0yZKbFJ92Oy3u+uqCIsv9BED/4a8h0H6pNMVGVbg+sY=; b=VyXzdNKYGFvcmCg9zmdslLEu4T2bGVPbBnGD76/gaWs+osxg3jErlWQuuq/KUSJZOg MIIOb0GJN2ADc/OaSx0zWdWXnnDPdPRLUOadYbyTXwQmV1RGKve+gZykFU+08C4NQRTD F3/pSN0dOOLnDCm2fNoUdmZgUVISQUfWEzPg0= MIME-Version: 1.0 Received: by 10.50.154.228 with SMTP id vr4mr8187765igb.65.1323535572841; Sat, 10 Dec 2011 08:46:12 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.200 with HTTP; Sat, 10 Dec 2011 08:46:12 -0800 (PST) In-Reply-To: <4EE221F9.9010505@gmail.com> References: <20111208134307.GA5266@thorin> <4EE221F9.9010505@gmail.com> Date: Sat, 10 Dec 2011 17:46:12 +0100 X-Google-Sender-Auth: 3qI0G0KZlExgUqohb9Zxcz3ikPs Message-ID: From: Robert Millan To: Volodymyr Kostyrko Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org, Adrian Chadd Subject: Re: [PATCH] Wipe other file systems when creating new UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 16:46:13 -0000 2011/12/9 Volodymyr Kostyrko : > > Shouldn't it make us a coffee then? Making precautions against > shooting-the-foot is a wrong choice for me. This way we need to extend it to > support any other file system that can repair thyself upon mount in case > user mistakenly mounted the wrong one. > This suggests you don't agree with the premise that file systems need to be identifiable. We could argue about this, but note that existing behaviour is entirely consistent with this premise: - newfs stores an UFSv2 signature on disk - fsck checks for this signature and refuses to operate - newfs checks for UFSv1 signature and makes sure it is cleared out before creating a new UFSv2 - the kernel checks for UFS signature before attempting to mount a file system > What about drives that support SSD? Isn't it convenient to use TRIM in such > cases? As I'm quite unfamiliar with SSD, I'd rather have someone else answer that. My impression, however, is that this improvement would most likely belong in berase() and be completely orthogonal to my patch. > You messing up ZFS terminology a bit. Uberblock size is 1k and what you > refer is ZFS vdev label. Size of vdev label is 256k. There are four vdev > labels for each vdev - two at the beginning of the vdev and two at the end. Ah yes, I probably confused the concepts, I was working from memory and it's been a while since I read the spec. > All vdev labels are _aligned_ to 256k. So technically this is not just last > 512k. I see that you mean. I guess just aligning down "mediasize" to 256 kiB before using it would suffice? From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 16:49:47 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AC6E106566B; Sat, 10 Dec 2011 16:49:47 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1058FC08; Sat, 10 Dec 2011 16:49:42 +0000 (UTC) Received: by iakl21 with SMTP id l21so151228iak.13 for ; Sat, 10 Dec 2011 08:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=E9BjOd1Q07Dpi4MYw9Mt1t/zjuwFEgO9yOT5QlW5/vo=; b=B001R+6uqycajbRn9YMrinGKVe9zNgmp6m5M6xkBSLXsUQ/9//IGxpfboLQf2jBviB dbFWeXIDzkihlUeAtslktrcNxynPy+mDKo1OS9eqSh4N6ctcy1T3yPjg3AUTJvcmsNVk DcAI0/AM4hO8pcoi3V3fhO/CKCuwslQnktAxM= MIME-Version: 1.0 Received: by 10.42.151.68 with SMTP id d4mr6476483icw.36.1323535782748; Sat, 10 Dec 2011 08:49:42 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.200 with HTTP; Sat, 10 Dec 2011 08:49:42 -0800 (PST) In-Reply-To: <4EE18901.7060800@FreeBSD.org> References: <20111208134307.GA5266@thorin> <4EE18901.7060800@FreeBSD.org> Date: Sat, 10 Dec 2011 17:49:42 +0100 X-Google-Sender-Auth: apY6p-o2-Cn2D9XIdV9W2ofnmzc Message-ID: From: Robert Millan To: "Andrey V. Elsukov" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org, Adrian Chadd Subject: Re: [PATCH] Wipe other file systems when creating new UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 16:49:47 -0000 2011/12/9 Andrey V. Elsukov : > i think before erasing 512 kib you should at least check actual available > mediasize and don't use hardcoded 512 sector size. 2011/12/9 Andrey V. Elsukov : > sorry, now i see that you have used disk.d_bsize, not hardcoded. > But the check for mediasize is still needed. :) I think I'm actually checking for physical media size, in: mediasize = get_block_device_size(disk.d_fd); which is based on output from ioctl rather than file system data structures. Is that what you meant? From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 16:51:22 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DF84106564A; Sat, 10 Dec 2011 16:51:22 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C63C38FC0C; Sat, 10 Dec 2011 16:51:21 +0000 (UTC) Received: by iakl21 with SMTP id l21so153779iak.13 for ; Sat, 10 Dec 2011 08:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8CKelPdMIGo55nKkD5EMw41PXsw21yYGEHowU1YCoqU=; b=iJcVrK3FG356rg5vRw9HO3sJzNFbQQoILZEvGXHBbsW70AgdqXSz+anNcJLpaVnSjS k7pXnE7YgPf8LmzU3O8kBmNJHu6QVWsNSE888T4dI9P4oXFVFXsZTVWxGLDejv5iAKUj N7nJ4AcnNCEPCr29S4u+fc3U6CIa1n37uzd6A= MIME-Version: 1.0 Received: by 10.50.196.163 with SMTP id in3mr8062552igc.53.1323535881426; Sat, 10 Dec 2011 08:51:21 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.200 with HTTP; Sat, 10 Dec 2011 08:51:21 -0800 (PST) In-Reply-To: <201112091838.pB9IcpUe038205@chez.mckusick.com> References: <20111208134307.GA5266@thorin> <201112091838.pB9IcpUe038205@chez.mckusick.com> Date: Sat, 10 Dec 2011 17:51:21 +0100 X-Google-Sender-Auth: V86IfmCD7Pe7N6YzhHmt0PsZHbE Message-ID: From: Robert Millan To: Kirk McKusick Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org, Adrian Chadd Subject: Re: [PATCH] Wipe other file systems when creating new UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 16:51:22 -0000 2011/12/9 Kirk McKusick : > Generally speaking, I am in agreement with what you are trying to do. > However, you should not get rid of the check for (and the erasing of) > the UFS1 superblock. By default, UFS2 puts its superblock at an offset > of 64K from the beginning of the partition. You then eraseup to 512K > after that point which is reasonable since on a UFS2 filesystem the > first 64K can be used for the bootstrap. However, UFS1 places its > superblock at 8K from the beginning of the partition. You will not > wipe it out if it exists and its existence (if it has not been > overwritten by a bootstrap) can be quite problematic. Hence the > current code that checks for its existence, and only if found its > being wiped out. Thanks for the tip, I'll prepare a new patch that includes this. From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 16:55:26 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 569F41065673 for ; Sat, 10 Dec 2011 16:55:26 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 238868FC08 for ; Sat, 10 Dec 2011 16:55:25 +0000 (UTC) Received: by iakl21 with SMTP id l21so159689iak.13 for ; Sat, 10 Dec 2011 08:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=i0eZLXpX0CCupLoiNeCFBe6Di2lCX2gtvgpyQAAKCqM=; b=CRKezHiXu7gazvESE7D85lPhNEo0Gnd/Ve0BCmU8MbZSCENqI8LW7VdiE4jXB99cqo ZwD2ti71WRy38oWgFIvF1cO9lVY3lF7QFoUyJW0mMt5O6WZtZA+4zsTb8sTkQqy7oAsg 8sFiHsMk/F6pedzPp78tE7B7y9CkEVshpBThM= MIME-Version: 1.0 Received: by 10.50.159.199 with SMTP id xe7mr8127673igb.77.1323536125591; Sat, 10 Dec 2011 08:55:25 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.222.200 with HTTP; Sat, 10 Dec 2011 08:55:25 -0800 (PST) In-Reply-To: References: <20111208134307.GA5266@thorin> <201112091838.pB9IcpUe038205@chez.mckusick.com> Date: Sat, 10 Dec 2011 17:55:25 +0100 X-Google-Sender-Auth: Z4dYCl5pECivjmsYjbMhNjeyAag Message-ID: From: Robert Millan To: Johannes Totz Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: [PATCH] Wipe other file systems when creating new UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 16:55:26 -0000 2011/12/10 Johannes Totz : > Naive question here: why not wipe the first and last few megabytes? Better > safe than sorry... I'm not exactly against wiping the first and last few megabytes, but before doing that I'd rather know what other file systems which are not already covered are we trying to erase (in part so we can document them). > Also would be good to document the cases this is supposed to catch *in the > code*. So that is does not get forgotten. UFSv1 was already documented in the code, my patch adds a note about ZFS. From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 17:06:12 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46FBF106564A for ; Sat, 10 Dec 2011 17:06:12 +0000 (UTC) (envelope-from kamil.choudhury@anserinae.net) Received: from homiemail-a91.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by mx1.freebsd.org (Postfix) with ESMTP id 1EBED8FC16 for ; Sat, 10 Dec 2011 17:06:11 +0000 (UTC) Received: from homiemail-a91.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a91.g.dreamhost.com (Postfix) with ESMTP id 9FC5036A06D; Sat, 10 Dec 2011 09:06:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=anserinae.net; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= anserinae.net; b=KdepLyUKAfwfx8RBkKAPHAsc2OcX+9tXbw/ybH2NcXRK7gu hA7mxNwyPkYlxkmLgN7uHDMEbobMtocP66jjAxdEFvrm1uZ99023HHxyvj5vim/J 1WSrzHSeePpgyHCxoCwiFp2Pm5y/0j2ZJyEQEb+lgbOO4DhIpOm4Bt2hBkdI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=anserinae.net; h= message-id:in-reply-to:references:date:subject:from:to:cc :reply-to:mime-version:content-type:content-transfer-encoding; s=anserinae.net; bh=ZeKQIWrWk+yQjTPujKVDf8wpQbQ=; b=Kdrq29xYNye IlL8P62VVaaNE16VvsqTcqRYbiFaIhZVeGoy+jj6esLJeY57ZfTwtqM5lS9/jJ5z LgWr/NtIbLsgvPa1p/HCe5t2WRE4cEA/TR6M5XXggM9bwL3HxHVdOMNwuNdzFKtN E328BQjV/J2oIC4iB9YcnG4++jI7ZWsw= Received: from webmail.anserinae.net (ahfbbjcaiaae.dreamhost.com [75.119.208.4]) (Authenticated sender: kamil.choudhury@anserinae.net) by homiemail-a91.g.dreamhost.com (Postfix) with ESMTPA id 49E1E36A064; Sat, 10 Dec 2011 09:06:11 -0800 (PST) Received: from 68.173.236.44 (proxying for 68.173.236.44) (SquirrelMail authenticated user kamil.choudhury@anserinae.net) by webmail.anserinae.net with HTTP; Sat, 10 Dec 2011 12:06:11 -0500 Message-ID: In-Reply-To: <20111210163625.GY50300@deviant.kiev.zoral.com.ua> References: <20111210163625.GY50300@deviant.kiev.zoral.com.ua> Date: Sat, 10 Dec 2011 12:06:11 -0500 From: "Kamil Choudhury" To: "Kostik Belousov" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: mysterious sysctl failure on nullfs mount X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kamil.choudhury@anserinae.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 17:06:12 -0000 On Sat, December 10, 2011 11:36, Kostik Belousov wrote: > You did not specified which version of the OS you are running. > My apologies. I'm running 8.1-RELEASE, GENERIC kernel on amd64. From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 17:15:44 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 866181065672 for ; Sat, 10 Dec 2011 17:15:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 044368FC0A for ; Sat, 10 Dec 2011 17:15:43 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBAHFQBm007421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Dec 2011 19:15:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBAHFQ0J027665; Sat, 10 Dec 2011 19:15:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBAHFQ9X027664; Sat, 10 Dec 2011 19:15:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 10 Dec 2011 19:15:26 +0200 From: Kostik Belousov To: Kamil Choudhury Message-ID: <20111210171526.GZ50300@deviant.kiev.zoral.com.ua> References: <20111210163625.GY50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nUidbeHqhaATBdxo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: mysterious sysctl failure on nullfs mount X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 17:15:44 -0000 --nUidbeHqhaATBdxo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 10, 2011 at 12:06:11PM -0500, Kamil Choudhury wrote: > On Sat, December 10, 2011 11:36, Kostik Belousov wrote: > > You did not specified which version of the OS you are running. > > >=20 > My apologies. I'm running 8.1-RELEASE, GENERIC kernel on amd64. >=20 Yes, known issue. The supposed fix was committed to HEAD as r227697 and might be. subject to re@ approval, be merged into stable/9 after 9.0 is released. --nUidbeHqhaATBdxo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7jk64ACgkQC3+MBN1Mb4ggoQCgwU14J7AhqdJ9f+2LZS/cGVX2 gCkAn0UG1JKivi2XKkfS6/ZzxidpmdAG =gJJg -----END PGP SIGNATURE----- --nUidbeHqhaATBdxo--