From owner-freebsd-fs@FreeBSD.ORG Sun Apr 25 11:17:28 2010 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 2FEAA106566B; Sun, 25 Apr 2010 11:17:28 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 457948FC24; Sun, 25 Apr 2010 11:17:27 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so1069442fge.13 for ; Sun, 25 Apr 2010 04:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=jA3Sp4gStuqNeEA7JSxysUAv4TUfYZ2Vgt8BPoRPp7I=; b=gUabzGLxvNGBvH19c3JR54C0JXbTgF7476y3HVeEzlDgtkksAFjBVNOnP2sIUyuaJS fo2WBGIJloEMaEAPM4AOU2jlaq+sfTMwtuF5vyF/sUQH4BNdSucuGX4lMB4qcff3h0QM QCl/9G08JH38mzP3izi2w8+aE6sF+gqoC8n78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=JYtAS0Eyu72lMOq3DUYgcGvDkIxYK0TD1gfMAroOveAK24qhFmGZHSuji1AgsB4hoc ahiqoEmcmK8R7yIEnlyJHk8TK0Nc/j6HqeVV5lTnFH5dZ0UgGTpHuUdPZQsXju7ox+d4 g7GqARf1teTOkDtRPPp1B5o+9OfoLj2KwsyWY= Received: by 10.87.61.22 with SMTP id o22mr4366251fgk.50.1272194238812; Sun, 25 Apr 2010 04:17:18 -0700 (PDT) Received: from localhost (vpn-195-69-247-65.customer.onet.com.ua [195.69.247.65]) by mx.google.com with ESMTPS id 12sm2536390fgg.9.2010.04.25.04.17.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 25 Apr 2010 04:17:17 -0700 (PDT) To: Mikolaj Golub References: <86r5m9dvqf.fsf@zhuzha.ua1> <20100423062950.GD1670@garage.freebsd.pl> <86k4rye33e.fsf@zhuzha.ua1> <20100424073031.GD3067@garage.freebsd.pl> <868w8dgk4e.fsf@kopusha.onet> Organization: Home From: Mikolaj Golub Date: Sun, 25 Apr 2010 14:17:15 +0300 In-Reply-To: <868w8dgk4e.fsf@kopusha.onet> (Mikolaj Golub's message of "Sat\, 24 Apr 2010 14\:33\:53 +0300") Message-ID: <86tyqzeq84.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: freebsd-fs , Pawel Jakub Dawidek Subject: Re: HAST: primary might get stuck when there are connectivity problems with secondary 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, 25 Apr 2010 11:17:28 -0000 --=-=-= On Sat, 24 Apr 2010 14:33:53 +0300 Mikolaj Golub wrote: > From the code I don't see how hast_proto_recv_hdr() may timeout if the > connection is alive, have I missed something? I did some experiments adding the code that sets SO_RCVTIMEO socket option (see the attached patch). It fixes this issue. After timeout the worker on the secondary is restarted with the error: Apr 25 13:06:45 hastb hastd: [storage] (secondary) Unable to receive request header: Resource temporarily unavailable. Apr 25 13:06:45 hastb hastd: [storage] (secondary) Worker process (pid=1243) exited ungracefully: status=19200. On the other hand when the FS is idle (there is no I/O at all) we have the worker restart too and the primary is not being connected to the secondary until some I/O appears. So it might look not very nicely :-) Also note, I had to modify proto_common_recv() to have timeout working. After timeout recv() sets errno to EWOULDBLOCK, which has the same number as EAGAIN in FreeBSD. The current proto_common_recv() restarts recv() if EAGAIN is returned. -- Mikolaj Golub --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=hastd.proto_tcp4.c.SO_RCVTIMEO.patch Index: sbin/hastd/proto_common.c =================================================================== --- sbin/hastd/proto_common.c (revision 207185) +++ sbin/hastd/proto_common.c (working copy) @@ -76,7 +76,7 @@ proto_common_recv(int fd, unsigned char *data, siz do { done = recv(fd, data, size, MSG_WAITALL); - } while (done == -1 && errno == EAGAIN); + } while (done == -1 && errno == EINTR); if (done == 0) return (ENOTCONN); else if (done < 0) Index: sbin/hastd/proto_tcp4.c =================================================================== --- sbin/hastd/proto_tcp4.c (revision 207185) +++ sbin/hastd/proto_tcp4.c (working copy) @@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$"); #include /* MAXHOSTNAMELEN */ +#include #include #include @@ -203,7 +204,7 @@ tcp4_common_setup(const char *addr, void **ctxp, i sizeof(val)) == -1) { pjdlog_warning("Unable to set receive buffer size on %s", addr); } - + tctx->tc_side = side; tctx->tc_magic = TCP4_CTX_MAGIC; *ctxp = tctx; @@ -214,8 +215,23 @@ tcp4_common_setup(const char *addr, void **ctxp, i static int tcp4_client(const char *addr, void **ctxp) { + struct tcp4_ctx *tctx; + struct timeval tv; + int ret; - return (tcp4_common_setup(addr, ctxp, TCP4_SIDE_CLIENT)); + if ((ret = tcp4_common_setup(addr, ctxp, TCP4_SIDE_CLIENT)) != 0) + return (ret); + + tctx = *ctxp; + + tv.tv_sec = 300; + tv.tv_usec = 0; + if (setsockopt(tctx->tc_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, + sizeof(tv)) == -1) { + pjdlog_warning("Unable to set receive timeout %s", addr); + } + + return (0); } static int @@ -273,6 +289,7 @@ tcp4_accept(void *ctx, void **newctxp) { struct tcp4_ctx *tctx = ctx; struct tcp4_ctx *newtctx; + struct timeval tv; socklen_t fromlen; int ret; @@ -294,6 +311,13 @@ tcp4_accept(void *ctx, void **newctxp) return (ret); } + tv.tv_sec = 300; + tv.tv_usec = 0; + if (setsockopt(newtctx->tc_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, + sizeof(tv)) == -1) { + pjdlog_debug(2, "Unable to set receive timeout"); + } + newtctx->tc_side = TCP4_SIDE_SERVER_WORK; newtctx->tc_magic = TCP4_CTX_MAGIC; *newctxp = newtctx; --=-=-=-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 26 11:07:00 2010 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 368AD1065674 for ; Mon, 26 Apr 2010 11:07:00 +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 014A28FC1D for ; Mon, 26 Apr 2010 11:07:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3QB6xpO004141 for ; Mon, 26 Apr 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3QB6xD9004139 for freebsd-fs@FreeBSD.org; Mon, 26 Apr 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Apr 2010 11:06:59 GMT Message-Id: <201004261106.o3QB6xD9004139@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, 26 Apr 2010 11:07:00 -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/145802 fs [zfs] page fault under load o kern/145778 fs [zfs] [panic] panic in zfs_fuid_map_id (known issue fi o kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145424 fs [zfs] [patch] move source closer to v15 o kern/145423 fs [zfs] ZFS/zpool status shows deleted/not present pools o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an o kern/145339 fs [zfs] deadlock after detaching block device from raidz o kern/145309 fs [disklabel]: Editing disk label invalidates the whole 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 o kern/144458 fs [nfs] [patch] nfsd fails as a kld 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/144330 fs [nfs] mbuf leakage in nfsd with zfs o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o bin/144214 fs zfsboot fails on gang block after upgrade to zfs v14 o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o kern/143345 fs [ext2fs] [patch] extfs minor header cleanups to better o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142924 fs [ext2fs] [patch] Small cleanup for the inode struct in o kern/142914 fs [zfs] ZFS performance degradation over time 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/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD 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/140433 fs [zfs] [panic] panic while replaying ZIL after crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity 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 o 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/139363 fs [nfs] diskless root nfs mount from non FreeBSD server o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr 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 o 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/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w 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/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv 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/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour 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 p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B 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 mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N 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/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex 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] mount_msdosfs: msdosfs_iconv: Operation not 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/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk 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 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic 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 f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in 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/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi 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 kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi 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 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/53137 fs [ffs] [panic] background fscking causing ffs_valloc pa 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 kern/33464 fs [ufs] soft update inconsistencies after system crash o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 174 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 26 14:33:32 2010 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 1CBBD1065674; Mon, 26 Apr 2010 14:33:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E28538FC14; Mon, 26 Apr 2010 14:33:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 95A5746B52; Mon, 26 Apr 2010 10:33:31 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AF7438A021; Mon, 26 Apr 2010 10:33:27 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Mon, 26 Apr 2010 09:59:00 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <201004230844.58047.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201004260959.00287.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 26 Apr 2010 10:33:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Ivan Voras Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 26 Apr 2010 14:33:32 -0000 On Friday 23 April 2010 11:18:58 am Ivan Voras wrote: > On 04/23/10 14:44, John Baldwin wrote: > > On Friday 23 April 2010 8:25:51 am Andriy Gapon wrote: > >> on 23/04/2010 13:34 Peter Schuller said the following: > >>>> It's easy. > >>> > >>> Thank you for posting the example. I never really understood that > >>> gpart was to be the generic tool; I thought it was gpt specific. > >>> Obviously I should have read up better. > >>> > >>> Is gpart to be considered "tested", "stable", "production quality" > >>> and/or "default" now then, or is it still cutting edge/experimental? > >> > >> Yes, it's "tested", "stable", "production quality" and/or "default". > >> All other tools are slowly rotting now, but can be fixed to correctly works via > >> GEOM interface the same way gpart does now. > >> E.g. see Andrey's work on sade(8). > > > > Actually, the other tools were already fixed to work properly with GEOM, but > > they used the older set of GEOM classes (GEOM_BSD, GEOM_MBR, etc.) instead > > of the GEOM_PART classes. > > It also depends on the meaning of "fixed" :) They mostly wrote to disk > drives directly from userland and relied on GEOM to pick up the changes > via the "spoil" mechanism - which is why they couldn't write to > partition tables if a file system on one of the partition was mounted, > etc., requiring hacks like kern.geom.debugflags=16 to drop the > permission (actually reference counting) checks. Not true. They sent verb actions to the modules to write updated sectors. Look at the write_disk() method in fdisk.c for example. It uses a verb for the GEOM_MBR class to update the MBR and only falls back to raw disk access if that fails. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Apr 26 20:07:38 2010 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 2AFCE106564A for ; Mon, 26 Apr 2010 20:07:38 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id AA6C28FC17 for ; Mon, 26 Apr 2010 20:07:37 +0000 (UTC) Received: by bwz8 with SMTP id 8so11589465bwz.3 for ; Mon, 26 Apr 2010 13:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:organization:from :date:message-id:user-agent:mime-version:content-type; bh=9J4aMy7DNUAtfuVdgPw6Md7CkEfbuaCfIZjJzNHDixM=; b=Fbh7EYhcIaCz3LsdYyDO4jA8AEFwyj+aSn6Pn/wubfE+F2OupUMGfl/ypFKoZOA7g8 DWoNH0H0+XEMwDFUztKzcUkiMY4LdfhKHAFKoUCoyePOV47uXdmesHiglcFXmOOJNYNF PU/Ar5NJasz3wixJ+smC1xMKnKXlmdK5iDcdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:organization:from:date:message-id:user-agent :mime-version:content-type; b=mqXGe/6Wcr81L9bSBPRfCPoqAIzPaIRxoJD7s46DyaKtvY2f8dG+lEoWBzxTzn3vXZ e2oed3ctL0+w/1HuJ2LpFpdfRLqj+1lxXLckjupG60D9sMlk3cG6WryIs1QjOx+XPKlL jAV5nU5folQS97wEQCrz1WGszrOOcF94OEWiE= Received: by 10.204.22.16 with SMTP id l16mr2978493bkb.186.1272312453641; Mon, 26 Apr 2010 13:07:33 -0700 (PDT) Received: from localhost ([95.69.163.27]) by mx.google.com with ESMTPS id 16sm1609951bwz.13.2010.04.26.13.07.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 13:07:32 -0700 (PDT) To: freebsd-fs Organization: Home From: Mikolaj Golub Date: Mon, 26 Apr 2010 23:07:31 +0300 Message-ID: <86iq7ex9j0.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: hastd segfaults reading metadata from not initialized provider 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, 26 Apr 2010 20:07:38 -0000 --=-=-= Hi, When configuring a new provider if one forgets to do hastctl create tank before hastctl role primary tank the worker core dumps on reading metadata: (gdb) bt #0 strcmp () at /usr/src/lib/libc/i386/string/strcmp.S:61 #1 0x0804fa18 in metadata_read (res=0x284cb600, openrw=true) at /usr/src/sbin/hastd/metadata.c:120 #2 0x080570ac in init_local (res=0x284cb600) at /usr/src/sbin/hastd/primary.c:425 #3 0x08057f88 in hastd_primary (res=0x284cb600) at /usr/src/sbin/hastd/primary.c:754 #4 0x0804e270 in child_exit () at /usr/src/sbin/hastd/hastd.c:145 #5 0x0804edd1 in main_loop () at /usr/src/sbin/hastd/hastd.c:389 #6 0x0804f3d8 in main (argc=0, argv=0xbfbfed84) at /usr/src/sbin/hastd/hastd.c:520 Current language: auto; currently asm (gdb) fr 1 #1 0x0804fa18 in metadata_read (res=0x284cb600, openrw=true) at /usr/src/sbin/hastd/metadata.c:120 120 if (strcmp(str, res->hr_name) != 0) { Current language: auto; currently c (gdb) list 115 ebuf_free(eb); 116 goto fail; 117 } 118 119 str = nv_get_string(nv, "resource"); 120 if (strcmp(str, res->hr_name) != 0) { 121 pjdlog_error("Provider %s is not part of resource %s.", 122 res->hr_localpath, res->hr_name); 123 nv_free(nv); 124 goto fail; (gdb) p str $1 = 0x0 In the attached patch the check for str is added so we would have a termination with the error message instead of a core dump: Apr 26 22:46:06 hasta hastd: [tank] (primary) Metadata read from /dev/ad6 is invalid. Apr 26 22:46:06 hasta hastd: [tank] (primary) Worker process failed (pid=6196, status=66). -- Mikolaj Golub --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=hastd.metadata.c.patch Index: sbin/hastd/metadata.c =================================================================== --- sbin/hastd/metadata.c (revision 207245) +++ sbin/hastd/metadata.c (working copy) @@ -117,6 +117,12 @@ metadata_read(struct hast_resource *res, bool open } str = nv_get_string(nv, "resource"); + if (str == NULL) { + pjdlog_error("Metadata read from %s is invalid.", + res->hr_localpath); + nv_free(nv); + goto fail; + } if (strcmp(str, res->hr_name) != 0) { pjdlog_error("Provider %s is not part of resource %s.", res->hr_localpath, res->hr_name); --=-=-=-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 27 17:40:06 2010 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 CDDFA1065670 for ; Tue, 27 Apr 2010 17:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A02918FC0C for ; Tue, 27 Apr 2010 17:40:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3RHe6Ml064236 for ; Tue, 27 Apr 2010 17:40:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3RHe6TM064233; Tue, 27 Apr 2010 17:40:06 GMT (envelope-from gnats) Date: Tue, 27 Apr 2010 17:40:06 GMT Message-Id: <201004271740.o3RHe6TM064233@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Gunnar Hinriksson Cc: Subject: Re: kern/118107: [ntfs] [panic] Kernel panic when accessing a file at NTFS file system [regression] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gunnar Hinriksson List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 17:40:06 -0000 The following reply was made to PR kern/118107; it has been noted by GNATS. From: Gunnar Hinriksson To: bug-followup@FreeBSD.org, minotaur@crete.org.ua Cc: Subject: Re: kern/118107: [ntfs] [panic] Kernel panic when accessing a file at NTFS file system [regression] Date: Tue, 27 Apr 2010 17:01:32 +0000 Hello Im experiencing the exact same issue on my Freebsd-8-p2 box FreeBSD knut 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Apr 27 04:36:16 UTC 2010 gunnar@knut:/usr/obj/usr/src/sys/GENERIC amd64 Apr 27 16:19:09 knut kernel: pid 7944 (try), uid 0: exited on signal 10 (core dumped) Some notes about my system. Im using zfs as my root filesystem so no UFS. Computer reboots when I try to copy a file from an ntfs filesystem. The ntfs filesystem has been successfully used by windows and ntfs-3g on a linux box. Afraid I don't have more info than this at the moment. With Regards Gunnar Apr 27 16:37:18 syslogd: kernel boot file is /boot/kernel/kernel Apr 27 16:37:18 kernel: Copyright (c) 1992-2009 The FreeBSD Project. Apr 27 16:37:18 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Apr 27 16:37:18 kernel: The Regents of the University of California. All rights reserved. Apr 27 16:37:18 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Apr 27 16:37:18 kernel: FreeBSD 8.0-RELEASE-p2 #0: Tue Apr 27 04:36:16 UTC 2010 Apr 27 16:37:18 kernel: gunnar@knut:/usr/obj/usr/src/sys/GENERIC Apr 27 16:37:18 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Apr 27 16:37:18 kernel: CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2211.34-MHz K8-class CPU) Apr 27 16:37:18 kernel: Origin = "AuthenticAMD" Id = 0x20fb1 Stepping = 1 Apr 27 16:37:18 kernel: Features=0x178bfbff Apr 27 16:37:18 kernel: Features2=0x1 Apr 27 16:37:18 kernel: AMD Features=0xe2500800 Apr 27 16:37:18 kernel: AMD Features2=0x3 Apr 27 16:37:18 kernel: real memory = 2147483648 (2048 MB) Apr 27 16:37:18 kernel: avail memory = 2054156288 (1958 MB) Apr 27 16:37:18 kernel: ACPI APIC Table: Apr 27 16:37:18 kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Apr 27 16:37:18 kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) Apr 27 16:37:18 kernel: cpu0 (BSP): APIC ID: 0 Apr 27 16:37:18 kernel: cpu1 (AP): APIC ID: 1 Apr 27 16:37:18 kernel: ioapic0: Changing APIC ID to 2 Apr 27 16:37:18 kernel: ioapic0 irqs 0-23 on motherboard Apr 27 16:37:18 kernel: kbd1 at kbdmux0 Apr 27 16:37:18 kernel: acpi0: on motherboard Apr 27 16:37:18 kernel: acpi0: [ITHREAD] Apr 27 16:37:18 kernel: acpi0: Power Button (fixed) Apr 27 16:37:18 kernel: acpi0: reservation of 0, a0000 (3) failed Apr 27 16:37:18 kernel: acpi0: reservation of 100000, 7fef0000 (3) failed Apr 27 16:37:18 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Apr 27 16:37:18 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 Apr 27 16:37:18 kernel: acpi_button0: on acpi0 Apr 27 16:37:18 kernel: pcib0: port 0xcf8-0xcff on acpi0 Apr 27 16:37:18 kernel: pci0: on pcib0 Apr 27 16:37:18 kernel: pci0: at device 0.0 (no driver attached) Apr 27 16:37:18 kernel: isab0: at device 1.0 on pci0 Apr 27 16:37:18 kernel: isa0: on isab0 Apr 27 16:37:18 kernel: pci0: at device 1.1 (no driver attached) Apr 27 16:37:18 kernel: ohci0: mem 0xc5102000-0xc5102fff at device 2.0 on pci0 Apr 27 16:37:18 kernel: ohci0: [ITHREAD] Apr 27 16:37:18 kernel: usbus0: on ohci0 Apr 27 16:37:18 kernel: ehci0: mem 0xfeb00000-0xfeb000ff at device 2.1 on pci0 Apr 27 16:37:18 kernel: ehci0: [ITHREAD] Apr 27 16:37:18 kernel: usbus1: EHCI version 1.0 Apr 27 16:37:18 kernel: usbus1: on ehci0 Apr 27 16:37:18 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 Apr 27 16:37:18 kernel: ata0: on atapci0 Apr 27 16:37:18 kernel: ata0: [ITHREAD] Apr 27 16:37:18 kernel: ata1: on atapci0 Apr 27 16:37:18 kernel: ata1: [ITHREAD] Apr 27 16:37:18 kernel: atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd400-0xd40f mem 0xc5101000-0xc5101fff irq 20 at device 7.0 on pci0 Apr 27 16:37:18 kernel: atapci1: [ITHREAD] Apr 27 16:37:18 kernel: ata2: on atapci1 Apr 27 16:37:18 kernel: ata2: [ITHREAD] Apr 27 16:37:18 kernel: ata3: on atapci1 Apr 27 16:37:18 kernel: ata3: [ITHREAD] Apr 27 16:37:18 kernel: atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc000-0xc00f mem 0xc5100000-0xc5100fff irq 21 at device 8.0 on pci0 Apr 27 16:37:18 kernel: atapci2: [ITHREAD] Apr 27 16:37:18 kernel: ata4: on atapci2 Apr 27 16:37:18 kernel: ata4: [ITHREAD] Apr 27 16:37:18 kernel: ata5: on atapci2 Apr 27 16:37:18 kernel: ata5: [ITHREAD] Apr 27 16:37:18 kernel: pcib1: at device 9.0 on pci0 Apr 27 16:37:18 kernel: pci5: on pcib1 Apr 27 16:37:18 kernel: emu10kx0: port 0xa000-0xa01f irq 16 at device 6.0 on pci5 Apr 27 16:37:18 kernel: emu10kx0: [ITHREAD] Apr 27 16:37:18 kernel: pcm0: on emu10kx0 Apr 27 16:37:18 kernel: pcm0: Apr 27 16:37:18 kernel: pcm1: on emu10kx0 Apr 27 16:37:18 kernel: pcm2: on emu10kx0 Apr 27 16:37:18 kernel: pcm3: on emu10kx0 Apr 27 16:37:18 kernel: pci5: at device 6.1 (no driver attached) Apr 27 16:37:18 kernel: fwohci0: <1394 Open Host Controller Interface> mem 0xc400d000-0xc400d7ff,0xc4008000-0xc400bfff at device 6.2 on pci5 Apr 27 16:37:18 kernel: fwohci0: [ITHREAD] Apr 27 16:37:18 kernel: fwohci0: OHCI version 1.10 (ROM=0) Apr 27 16:37:18 kernel: fwohci0: No. of Isochronous channels is 4. Apr 27 16:37:18 kernel: fwohci0: EUI64 00:02:3c:00:20:02:e5:98 Apr 27 16:37:18 kernel: fwohci0: Phy 1394a available S400, 2 ports. Apr 27 16:37:18 kernel: fwohci0: Link S400, max_rec 2048 bytes. Apr 27 16:37:18 kernel: firewire0: on fwohci0 Apr 27 16:37:18 kernel: dcons_crom0: on firewire0 Apr 27 16:37:18 kernel: dcons_crom0: bus_addr 0x109c000 Apr 27 16:37:18 kernel: fwe0: on firewire0 Apr 27 16:37:18 kernel: if_fwe0: Fake Ethernet address: 02:02:3c:02:e5:98 Apr 27 16:37:18 kernel: fwe0: Ethernet address: 02:02:3c:02:e5:98 Apr 27 16:37:18 kernel: fwip0: on firewire0 Apr 27 16:37:18 kernel: fwip0: Firewire address: 00:02:3c:00:20:02:e5:98 @ 0xfffe00000000, S400, maxrec 2048 Apr 27 16:37:18 kernel: fwohci0: Initiate bus reset Apr 27 16:37:18 kernel: fwohci0: fwohci_intr_core: BUS reset Apr 27 16:37:18 kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Apr 27 16:37:18 kernel: pci5: at device 8.0 (no driver attached) Apr 27 16:37:18 kernel: pci5: at device 8.1 (no driver attached) Apr 27 16:37:18 kernel: fwohci1: mem 0xc400c000-0xc400c7ff,0xc4000000-0xc4003fff at device 11.0 on pci5 Apr 27 16:37:18 kernel: fwohci1: [ITHREAD] Apr 27 16:37:18 kernel: fwohci1: OHCI version 1.10 (ROM=1) Apr 27 16:37:18 kernel: fwohci1: No. of Isochronous channels is 4. Apr 27 16:37:18 kernel: fwohci1: EUI64 00:11:d8:00:00:00:48:86 Apr 27 16:37:18 kernel: fwohci1: Phy 1394a available S400, 2 ports. Apr 27 16:37:18 kernel: fwohci1: Link S400, max_rec 2048 bytes. Apr 27 16:37:18 kernel: firewire1: on fwohci1 Apr 27 16:37:18 kernel: dcons_crom1: on firewire1 Apr 27 16:37:18 kernel: dcons_crom1: bus_addr 0x109c000 Apr 27 16:37:18 kernel: dcons_crom1: dcons_paddr is already set Apr 27 16:37:18 kernel: fwe1: on firewire1 Apr 27 16:37:18 kernel: if_fwe1: Fake Ethernet address: 02:11:d8:00:48:86 Apr 27 16:37:18 kernel: fwe1: Ethernet address: 02:11:d8:00:48:86 Apr 27 16:37:18 kernel: fwip1: on firewire1 Apr 27 16:37:18 kernel: fwip1: Firewire address: 00:11:d8:00:00:00:48:86 @ 0xfffe00000000, S400, maxrec 2048 Apr 27 16:37:18 kernel: fwohci1: Initiate bus reset Apr 27 16:37:18 kernel: fwohci1: fwohci_intr_core: BUS reset Apr 27 16:37:18 kernel: fwohci1: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Apr 27 16:37:18 kernel: skc0: port 0xa800-0xa8ff mem 0xc4004000-0xc4007fff irq 17 at device 12.0 on pci5 Apr 27 16:37:18 kernel: skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) Apr 27 16:37:18 kernel: sk0: on skc0 Apr 27 16:37:18 kernel: sk0: Ethernet address: 00:11:d8:30:39:4e Apr 27 16:37:18 kernel: miibus0: on sk0 Apr 27 16:37:18 kernel: e1000phy0: PHY 0 on miibus0 Apr 27 16:37:18 kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Apr 27 16:37:18 kernel: skc0: [ITHREAD] Apr 27 16:37:18 kernel: pcib2: at device 11.0 on pci0 Apr 27 16:37:18 kernel: pci4: on pcib2 Apr 27 16:37:18 kernel: pcib3: at device 12.0 on pci0 Apr 27 16:37:18 kernel: pci3: on pcib3 Apr 27 16:37:18 kernel: pcib4: at device 13.0 on pci0 Apr 27 16:37:18 kernel: pci2: on pcib4 Apr 27 16:37:18 kernel: pcib5: at device 14.0 on pci0 Apr 27 16:37:18 kernel: pci1: on pcib5 Apr 27 16:37:18 kernel: vgapci0: port 0x9000-0x907f mem 0xc0000000-0xc0ffffff,0xb0000000-0xbfffffff,0xc1000000-0xc1ffffff irq 18 at device 0.0 on pci1 Apr 27 16:37:18 kernel: acpi_tz0: on acpi0 Apr 27 16:37:18 kernel: atrtc0: port 0x70-0x73 irq 8 on acpi0 Apr 27 16:37:18 kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Apr 27 16:37:18 kernel: uart0: [FILTER] Apr 27 16:37:18 kernel: ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 Apr 27 16:37:18 kernel: ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Apr 27 16:37:18 kernel: ppc0: FIFO with 16/16/16 bytes threshold Apr 27 16:37:18 kernel: ppc0: [ITHREAD] Apr 27 16:37:18 kernel: ppbus0: on ppc0 Apr 27 16:37:18 kernel: plip0: on ppbus0 Apr 27 16:37:18 kernel: plip0: [ITHREAD] Apr 27 16:37:18 kernel: lpt0: on ppbus0 Apr 27 16:37:18 kernel: lpt0: [ITHREAD] Apr 27 16:37:18 kernel: lpt0: Interrupt-driven port Apr 27 16:37:18 kernel: ppi0: on ppbus0 Apr 27 16:37:18 kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Apr 27 16:37:18 kernel: atkbd0: irq 1 on atkbdc0 Apr 27 16:37:18 kernel: kbd0 at atkbd0 Apr 27 16:37:18 kernel: atkbd0: [GIANT-LOCKED] Apr 27 16:37:18 kernel: atkbd0: [ITHREAD] Apr 27 16:37:18 kernel: cpu0: on acpi0 Apr 27 16:37:18 kernel: powernow0: on cpu0 Apr 27 16:37:18 kernel: device_attach: powernow0 attach returned 6 Apr 27 16:37:18 kernel: cpu1: on acpi0 Apr 27 16:37:18 kernel: powernow1: on cpu1 Apr 27 16:37:18 kernel: device_attach: powernow1 attach returned 6 Apr 27 16:37:18 kernel: orm0: at iomem 0xd0000-0xd3fff,0xd4000-0xd4fff on isa0 Apr 27 16:37:18 kernel: sc0: at flags 0x100 on isa0 Apr 27 16:37:18 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Apr 27 16:37:18 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Apr 27 16:37:18 kernel: ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; Apr 27 16:37:18 kernel: to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. Apr 27 16:37:18 kernel: ZFS filesystem version 13 Apr 27 16:37:18 kernel: ZFS storage pool version 13 Apr 27 16:37:18 kernel: Timecounters tick every 1.000 msec Apr 27 16:37:18 kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Apr 27 16:37:18 kernel: firewire0: bus manager 0 Apr 27 16:37:18 kernel: firewire1: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Apr 27 16:37:18 kernel: firewire1: bus manager 0 Apr 27 16:37:18 kernel: usbus0: 12Mbps Full Speed USB v1.0 Apr 27 16:37:18 kernel: usbus1: 480Mbps High Speed USB v2.0 Apr 27 16:37:18 kernel: ugen0.1: at usbus0 Apr 27 16:37:18 kernel: uhub0: on usbus0 Apr 27 16:37:18 kernel: ugen1.1: at usbus1 Apr 27 16:37:18 kernel: uhub1: on usbus1 Apr 27 16:37:18 kernel: acd0: DVDROM at ata0-master PIO4 Apr 27 16:37:18 kernel: ad8: 476940MB at ata4-master SATA300 Apr 27 16:37:18 kernel: ad10: 114473MB at ata5-master SATA150 Apr 27 16:37:18 kernel: SMP: AP CPU #1 Launched! Apr 27 16:37:18 kernel: Root mount waiting for: usbus1 usbus0 Apr 27 16:37:18 kernel: uhub0: 10 ports with 10 removable, self powered Apr 27 16:37:18 kernel: Root mount waiting for: usbus1 Apr 27 16:37:18 last message repeated 2 times Apr 27 16:37:18 kernel: uhub1: 10 ports with 10 removable, self powered Apr 27 16:37:18 kernel: Root mount waiting for: usbus1 Apr 27 16:37:18 kernel: ugen1.2: at usbus1 Apr 27 16:37:18 kernel: Trying to mount root from zfs:tank/root From owner-freebsd-fs@FreeBSD.ORG Tue Apr 27 21:19:02 2010 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 837E0106564A; Tue, 27 Apr 2010 21:19:02 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id BEFCF8FC1A; Tue, 27 Apr 2010 21:19:01 +0000 (UTC) Received: by wwb17 with SMTP id 17so20911wwb.13 for ; Tue, 27 Apr 2010 14:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=s7wj17FtDmJotQf7KyCCUfq9FVGERP0cmUxfM3vh4SA=; b=SZmuPS3A4vmzyxcHXQyVTvbBH2ro1bqjWkar/azKiiLhHZTx/e54/XrFkB5eFavwSu 2to16VSIEpA732JEtYGMugGp0Rzj7LoRaRJkVQLRv1pn6as/Vvl/+8ii9cuDV8dxwpJ8 DHZzckK9tOK/6/z5XEYHeuQSrtkmZXVO4DDQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qA2TGJLTHNeIHnNvFLTyG7G56aBCQNQst6DirboeKIPf1dtITEMaJahxcSQbPUjN8R lrjsQBa6TbKGtTLpOD7CPbvK8OlBW01qPyAdNhOPE8XqK9evt1LuEb6Yy3GVu12o2zao wUoU8nmrzXe10XmQYqhXllnADt/1McSdhSHQA= MIME-Version: 1.0 Received: by 10.216.87.140 with SMTP id y12mr1734811wee.36.1272403136994; Tue, 27 Apr 2010 14:18:56 -0700 (PDT) Received: by 10.216.49.76 with HTTP; Tue, 27 Apr 2010 14:18:56 -0700 (PDT) In-Reply-To: References: <4BC9E254.9070300@freebsd.org> Date: Tue, 27 Apr 2010 21:18:56 +0000 Message-ID: From: Paul B Mahol To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Tim Kientzle , current@freebsd.org, fs@freebsd.org Subject: Re: ISO9660 4GB directory structures boundary limit and growisofs 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, 27 Apr 2010 21:19:02 -0000 On 4/19/10, Paul B Mahol wrote: > On 4/19/10, Tom Evans wrote: >> On Mon, Apr 19, 2010 at 1:48 PM, Paul B Mahol wrote: >>> On 4/17/10, Paul B Mahol wrote: >>>> On Sat, Apr 17, 2010 at 4:31 PM, Tim Kientzle >>>> wrote: >>>>> Paul B Mahol wrote: >>>>>> >>>>>> It is apparently not possible to make use of -use-the-force-luke=4gms >>>>>> on FreeBSD when appending new session after 4GB. Mounted disk >>>>>> afterwards show nothing. >>>>>> >>>>>> Should we allow it like linux does? >>>>> >>>>> Are you claiming there is a problem when FreeBSD reads such >>>>> images or a problem with creating such images? What >>>>> programs are you using? >>>> >>>> I burn flac files in multiple sessions, each session have separate >>>> directory, on DVD+R DL MKM/003 >>>> After I used 4gms switch mounted fs shows nothing. (but there is >5GB >>>> of >>>> data) >>>> >>>> According to growisofs source BD (bluray) dont need this switch at all >>>> ... >>>> >>>>> This sounds like a pretty unsurprising 32-bit truncation >>>>> bug: the filesystem structures in ISO9660 are all sector >>>>> numbers so 8TB should be the natural limit (4G sectors >>>>> times 2k bytes/sector). >>>> >>>> I did not tested this on FreeBSD amd64 yet. >>> >>> Update: Linux shows all sessions and Windows 7 shows only first one. >> >> >> From the source code of groisofs.c: >> >> * - DVD+R Double Layer support; >> * - -use-the-force-luke=4gms to allow ISO9660 directory structures >> * to cross 4GB boundary, the option is effective only with DVD+R DL >> * and for data to be accessible under Linux isofs a kernel patch is >> * required; >> >> So I'm guessing it does something non standard, particularly if >> windows also refuses to see the data. > > That is pretty old, from 2.4 era, it was added after it was found that > isofs had bug. Windows at least "try" to show something - only one > session, but fourth and not second session crossed 4GB limit. > > The source also claims that in BD case there is no need for _force_ > switch at all. > Mounting with -norrip shows all sessions. Kernel displays "RRIP without PX field?" if I try to mount "normal" way. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 27 22:59:39 2010 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BD9D106564A; Tue, 27 Apr 2010 22:59:39 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id E4A7E8FC1B; Tue, 27 Apr 2010 22:59:38 +0000 (UTC) Received: from park.js.berklix.net (p549A68DA.dip.t-dialin.net [84.154.104.218]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o3RMLWbH093135; Tue, 27 Apr 2010 22:21:32 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o3RMLL66052967; Wed, 28 Apr 2010 00:21:21 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o3RMKhqZ017168; Wed, 28 Apr 2010 00:21:00 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201004272221.o3RMKhqZ017168@fire.js.berklix.net> To: Paul B Mahol From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 27 Apr 2010 21:18:56 -0000." Date: Wed, 28 Apr 2010 00:20:43 +0200 Sender: jhs@berklix.com Cc: Tom Evans , Tim Kientzle , current@freebsd.org, fs@freebsd.org Subject: Re: ISO9660 4GB directory structures boundary limit and growisofs 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, 27 Apr 2010 22:59:39 -0000 Hi, Paul B Mahol wrote: > On 4/19/10, Paul B Mahol wrote: > > On 4/19/10, Tom Evans wrote: > >> On Mon, Apr 19, 2010 at 1:48 PM, Paul B Mahol wrote: > >>> On 4/17/10, Paul B Mahol wrote: > >>>> On Sat, Apr 17, 2010 at 4:31 PM, Tim Kientzle > >>>> wrote: > >>>>> Paul B Mahol wrote: > >>>>>> > >>>>>> It is apparently not possible to make use of -use-the-force-luke=4gms > >>>>>> on FreeBSD when appending new session after 4GB. Mounted disk > >>>>>> afterwards show nothing. > >>>>>> > >>>>>> Should we allow it like linux does? > >>>>> > >>>>> Are you claiming there is a problem when FreeBSD reads such > >>>>> images or a problem with creating such images? What > >>>>> programs are you using? > >>>> > >>>> I burn flac files in multiple sessions, each session have separate > >>>> directory, on DVD+R DL MKM/003 > >>>> After I used 4gms switch mounted fs shows nothing. (but there is >5GB > >>>> of > >>>> data) > >>>> > >>>> According to growisofs source BD (bluray) dont need this switch at all > >>>> ... > >>>> > >>>>> This sounds like a pretty unsurprising 32-bit truncation > >>>>> bug: the filesystem structures in ISO9660 are all sector > >>>>> numbers so 8TB should be the natural limit (4G sectors > >>>>> times 2k bytes/sector). > >>>> > >>>> I did not tested this on FreeBSD amd64 yet. > >>> > >>> Update: Linux shows all sessions and Windows 7 shows only first one. > >> > >> > >> From the source code of groisofs.c: > >> > >> * - DVD+R Double Layer support; > >> * - -use-the-force-luke=4gms to allow ISO9660 directory structures > >> * to cross 4GB boundary, the option is effective only with DVD+R DL > >> * and for data to be accessible under Linux isofs a kernel patch is > >> * required; > >> > >> So I'm guessing it does something non standard, particularly if > >> windows also refuses to see the data. > > > > That is pretty old, from 2.4 era, it was added after it was found that > > isofs had bug. Windows at least "try" to show something - only one > > session, but fourth and not second session crossed 4GB limit. > > > > The source also claims that in BD case there is no need for _force_ > > switch at all. > > > > Mounting with -norrip shows all sessions. > Kernel displays "RRIP without PX field?" if I try to mount "normal" way. Might this help ? Kernel config /sys/conf/NOTES options UDF #Universal Disk Format My config notes /* Allows DVDs with files > 2 Gig, to avoid: * "ls: file_about_2.5gig.ts: * Value too large to be stored in data type" * ports/sysutils/k3b can use it to write eg 4G+ files. */ Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-fs@FreeBSD.ORG Tue Apr 27 23:01:44 2010 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 9C26D1065672 for ; Tue, 27 Apr 2010 23:01:44 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 4D94B8FC08 for ; Tue, 27 Apr 2010 23:01:43 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id o3RN1gZ1035029 for ; Tue, 27 Apr 2010 18:01:42 -0500 (CDT) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=jUAbme63PbGhvwUV0Nl8h45sQQciwYbHS7KKPw3LQAY2P9Scpii4ZUmGGi9QuuieO MuxaMznd855j0CwuUgDhlY7uE7QdkEPsycIYMw1qAI7elmQun3qZ3ASabhtc1X1Fupn AxL0ByZkHGeF7xPGR0GzQk17qmRd9y6wFemSztQ= Message-ID: <4BD76CD5.3070500@jrv.org> Date: Tue, 27 Apr 2010 18:01:41 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: "dying znode detected"? 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, 27 Apr 2010 23:01:44 -0000 FreeBSD bigback.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206111: Mon Apr 26 01:13:00 CDT 2010 root@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 (April 2 svn) Is anyone interested in this kernel message? I'm not aware of any problem associated with it. The system is in a $ while true; do make -j8 buildworld; done loop for qualification testing, using a ZFS boot disk (mirror). The message appeared during build #88 (out of 117 so far). bigback:/usr/src# cat /var/log/messages Apr 26 02:00:00 bigback newsyslog[71751]: logfile turned over due to size>100K Apr 27 07:08:47 bigback kernel: zfs_zget:916[1]: dying znode detected (zp=0xffffff0065042758) bigback:/usr/src# From owner-freebsd-fs@FreeBSD.ORG Tue Apr 27 23:14:45 2010 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 52A641065673 for ; Tue, 27 Apr 2010 23:14:45 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 971418FC14 for ; Tue, 27 Apr 2010 23:14:44 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 64F8645CBA; Wed, 28 Apr 2010 01:14:42 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 49F0945C9F; Wed, 28 Apr 2010 01:14:36 +0200 (CEST) Date: Wed, 28 Apr 2010 01:14:33 +0200 From: Pawel Jakub Dawidek To: "James R. Van Artsdalen" Message-ID: <20100427231433.GA3598@garage.freebsd.pl> References: <4BD76CD5.3070500@jrv.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <4BD76CD5.3070500@jrv.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs Subject: Re: "dying znode detected"? 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, 27 Apr 2010 23:14:45 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 27, 2010 at 06:01:41PM -0500, James R. Van Artsdalen wrote: > FreeBSD bigback.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206111: > Mon Apr 26 01:13:00 CDT 2010 =20 > root@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 > (April 2 svn) >=20 > Is anyone interested in this kernel message? I'm not aware of any > problem associated with it. >=20 > The system is in a >=20 > $ while true; do make -j8 buildworld; done >=20 > loop for qualification testing, using a ZFS boot disk (mirror). The > message appeared during build #88 (out of 117 so far). >=20 > bigback:/usr/src# cat /var/log/messages > Apr 26 02:00:00 bigback newsyslog[71751]: logfile turned over due to > size>100K > Apr 27 07:08:47 bigback kernel: zfs_zget:916[1]: dying znode detected > (zp=3D0xffffff0065042758) We handle such case, so don't worry. You have debug enabled (vfs.zfs.debug > 0) so expect some debug messages:) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvXb9kACgkQForvXbEpPzSQvQCgkozg2N5Fuu2419yR2IO2cOic F0oAn3vXRcpDWOHCAxnNIJ1QpujaAYR3 =tB45 -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 28 11:29:16 2010 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 68AC7106566C for ; Wed, 28 Apr 2010 11:29:16 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 043118FC0C for ; Wed, 28 Apr 2010 11:29:15 +0000 (UTC) Received: by wyb34 with SMTP id 34so990841wyb.13 for ; Wed, 28 Apr 2010 04:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ihqilMZ/csvUAJJNNyeLU2PJC1R7jcYyu+4T/gA0dIs=; b=MH6rzif5PeR9Z4JOoqo3LaB1vmfd4iNnTcYADOB/l1V7BeseIpgvsSyqwPkHMcKsiI d/GOnUAZg6UbxNmAaanS4oFBxkhpYbX+9/0J5b4zhtheh/nFM/JWlcRsVaipSgHNHLu6 45GW8Xa28ULmuNuKW2rGPEXDqQ/XwbdngT30k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sBxCVvmgE27+ZDHK2aT0xUEwrBJuOWN6uOAwF3I+lUPyjvVH2B8QB2kz8Kq1sOTiAN i3aTbq8DQqLYBQMcxZx6oaUcSI7lAuKzejElDaYmlYP7ItNHDfqx5tSPGeoRuvt6V6i2 YJeayktVXZuQBI/rN9NsCSRV1D1S4R5kmushM= MIME-Version: 1.0 Received: by 10.216.90.201 with SMTP id e51mr1114309wef.72.1272452367627; Wed, 28 Apr 2010 03:59:27 -0700 (PDT) Received: by 10.216.180.10 with HTTP; Wed, 28 Apr 2010 03:59:27 -0700 (PDT) Date: Wed, 28 Apr 2010 12:59:27 +0200 Message-ID: From: Lucius Windschuh To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Meaning of: handle_workitem_freeblocks: block count 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, 28 Apr 2010 11:29:16 -0000 Hi. I was using UFS2 with gjournal and now testing UFS2 with SUJ enabled, on -CURRENT rr207195 (i386). During some simple linear write tests with dd if=/dev/zero of=/some/fs/file bs=1M, this message appeared in the kernel log: Apr 28 12:24:15 current kernel: handle_workitem_freeblocks: block count Some times, this messages also comes after the dd stopped and if I remember right, in some cases also after running a background fsck on an UFS2 with SU enabled: Apr 25 22:51:31 t400 fsck: /dev/ada0s1d.eli: UNREF FILE I=4638583 OWNER=lw MODE=100644 Apr 25 22:51:31 t400 fsck: /dev/ada0s1d.eli: SIZE=56013 MTIME=Apr 25 22:39 2010 (CLEARED) Apr 25 22:51:31 t400 fsck: /dev/ada0s1d.eli: UNREF FILE I=4638606 OWNER=lw MODE=100644 Apr 25 22:51:31 t400 fsck: /dev/ada0s1d.eli: SIZE=56013 MTIME=Apr 25 22:37 2010 (CLEARED) Apr 25 22:51:31 t400 fsck: /dev/ada0s1d.eli: Reclaimed: 0 directories, 2 files, 54 fragments Apr 25 22:51:31 t400 fsck: /dev/ada0s1d.eli: 254348 files, 10156202 used, 9195354 free (48682 frags, 2286668 blocks, 0.3% fragmentation) Apr 25 22:51:43 t400 kernel: handle_workitem_freeblocks: block count My kernel config is: http://sites.google.com/site/lwfreebsd/Home/files/kernelconfig-T400.txt?attredirects=0&d=1 Can somebody explain the meaning of this message? I saw that it was converted from a panic() to a diagnostic notification in r68715 by Kirk McKusick. A quick search showed that only a few people did encounter this message over the years (perhaps because it is only visible with INVARIANTS/DIAGNOSTIC enabled?). Could indicate an hardware fault, even if my system runs stable? Lucius From owner-freebsd-fs@FreeBSD.ORG Wed Apr 28 15:47:18 2010 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 7C27D106564A for ; Wed, 28 Apr 2010 15:47:18 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 538C88FC08 for ; Wed, 28 Apr 2010 15:47:18 +0000 (UTC) Received: by pwi9 with SMTP id 9so10603754pwi.13 for ; Wed, 28 Apr 2010 08:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Nb/QNTs4LFzG/bXJ+BeLHankxFZM+UB9zMc/PYejpns=; b=iqUhWuZhJLrAXou3P8TEZTgb6W6H1feO9FWah3KlBhYSxRznPY3kCheyV9YYHnd3nU jA4YmNjZ5g3dsJgrW3IHJzenNnOGRy61/BH3X9OqF+6F6tQBXb90ugG7Hr3k1LEzJuuG 4AC5guz54EZMSudhrFa3j+DQYzX80lvrU21Zc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nnMjrGcsR+Jo9200xHAbdN2GNMnYXSjHb2xdLUCfxlszT83JbOYo8iNZMfArLAGFHn XQnQknSFS7k6xUb5SljNpc1fW2mudgrOkbdneBU+p/TCtA/QcSuA1JR0KWzDAAfAU7d8 qSF/bFueHjyKXeSPGaZE1T4mKL9X8xGP4uQ4Y= MIME-Version: 1.0 Received: by 10.114.23.15 with SMTP id 15mr9205918waw.45.1272469621111; Wed, 28 Apr 2010 08:47:01 -0700 (PDT) Received: by 10.231.18.74 with HTTP; Wed, 28 Apr 2010 08:47:00 -0700 (PDT) Date: Wed, 28 Apr 2010 08:47:00 -0700 Message-ID: From: Freddie Cash To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ZFS: "Cannot replace a replacing drive" 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, 28 Apr 2010 15:47:18 -0000 Going through the archives, I see that others have run into this issue, and managed to solve it via "zpool detach". However, looking closely at the archived messages, all the successful tests had one thing in common: 1 drive ONLINE, 1 drive FAULTED. If a drive is online, obviously it can be detached. In all the cases where people have been unsuccessful at fixing this situation, 1 drive is OFFLINE, and 1 drive is FAULTED. As is our case: [fcash@thehive ~]$ zpool status -v pool: storage state: DEGRADED status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM storage DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 label/disk01 ONLINE 0 0 0 label/disk02 ONLINE 0 0 0 label/disk03 ONLINE 0 0 0 replacing UNAVAIL 0 534 0 insufficient replicas label/disk04/old OFFLINE 0 544 0 label/disk04 FAULTED 0 544 0 corrupted data label/disk13 ONLINE 0 0 0 label/disk14 ONLINE 0 0 0 label/disk15 ONLINE 0 0 0 label/disk16 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/disk05 ONLINE 0 0 0 label/disk06 ONLINE 0 0 0 label/disk07 ONLINE 0 0 0 label/disk08 ONLINE 0 0 0 label/disk17 ONLINE 0 0 0 label/disk18 ONLINE 0 0 0 label/disk19 ONLINE 0 0 0 label/disk20 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/disk09 ONLINE 0 0 0 label/disk10 ONLINE 0 0 0 label/disk11 ONLINE 0 0 0 label/disk12 ONLINE 0 0 0 label/disk21 ONLINE 0 0 0 label/disk22 ONLINE 0 0 0 label/disk23 ONLINE 0 0 0 label/disk24 ONLINE 0 0 0 cache label/cache ONLINE 0 0 0 errors: No known data errors [fcash@thehive ~]$ sudo zpool replace storage label/disk04 cannot replace label/disk04 with label/disk04: cannot replace a replacing device Note the OFFLINE status for label/disk04/old. I cannot get either drive to detach, or to replace, or to online, or to offline. "zpool online" on the old device changes the status to UNAVAIL. "zpool detach" and "zpool offline" give the same error: no valid replicas. I've tried removing the underlying device, booting with the drive in the system and without the drive in the system, all kinds of zpool commands, all without success. Is there any way to recover from this error? Or am I doomed to destroy a 10 TB pool? FreeBSD thehive.sd73.bc.ca 8.0-STABLE FreeBSD 8.0-STABLE #3: Fri Jan 15 11:08:47 PST 2010 root@thehive.sd73.bc.ca:/usr/obj/usr/src-8/sys/ZFSHOST amd64 ZFSv13 -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Wed Apr 28 21:46:54 2010 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 68A4A1065670 for ; Wed, 28 Apr 2010 21:46:54 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id A9D528FC19 for ; Wed, 28 Apr 2010 21:46:46 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 1D88945E8E; Wed, 28 Apr 2010 23:46:45 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8770145CDD; Wed, 28 Apr 2010 23:46:39 +0200 (CEST) Date: Wed, 28 Apr 2010 23:46:36 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20100428214636.GD1677@garage.freebsd.pl> References: <86r5m9dvqf.fsf@zhuzha.ua1> <20100423062950.GD1670@garage.freebsd.pl> <86k4rye33e.fsf@zhuzha.ua1> <20100424073031.GD3067@garage.freebsd.pl> <868w8dgk4e.fsf@kopusha.onet> <86tyqzeq84.fsf@kopusha.onet> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zS7rBR6csb6tI2e1" Content-Disposition: inline In-Reply-To: <86tyqzeq84.fsf@kopusha.onet> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs Subject: Re: HAST: primary might get stuck when there are connectivity problems with secondary 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, 28 Apr 2010 21:46:54 -0000 --zS7rBR6csb6tI2e1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 25, 2010 at 02:17:15PM +0300, Mikolaj Golub wrote: > On Sat, 24 Apr 2010 14:33:53 +0300 Mikolaj Golub wrote: >=20 > > From the code I don't see how hast_proto_recv_hdr() may timeout if the > > connection is alive, have I missed something? >=20 > I did some experiments adding the code that sets SO_RCVTIMEO socket option > (see the attached patch). It fixes this issue. After timeout the worker o= n the > secondary is restarted with the error: >=20 > Apr 25 13:06:45 hastb hastd: [storage] (secondary) Unable to receive requ= est header: Resource temporarily unavailable. > Apr 25 13:06:45 hastb hastd: [storage] (secondary) Worker process (pid=3D= 1243) exited ungracefully: status=3D19200. >=20 > On the other hand when the FS is idle (there is no I/O at all) we have the > worker restart too and the primary is not being connected to the secondary > until some I/O appears. So it might look not very nicely :-) >=20 > Also note, I had to modify proto_common_recv() to have timeout working. A= fter > timeout recv() sets errno to EWOULDBLOCK, which has the same number as EA= GAIN > in FreeBSD. The current proto_common_recv() restarts recv() if EAGAIN is > returned. Could you see if the following patch fixes the problem for you: http://people.freebsd.org/~pjd/patches/hastd_timeout.patch The patch sets timeout on both incoming and outgoing sockets on primary and on outgoing socket on secondary. Incoming socket on secondary is left with no timeout to avoid problem you described above. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --zS7rBR6csb6tI2e1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvYrLwACgkQForvXbEpPzRkMACeMd+9AKiccA5DguLCLmL9YN59 q28Anj2eo1PDEFxf+xjqeU9fpv+yHmBn =wUGw -----END PGP SIGNATURE----- --zS7rBR6csb6tI2e1-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 28 22:43:36 2010 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 A00B1106566C for ; Wed, 28 Apr 2010 22:43:36 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id E6FF08FC20 for ; Wed, 28 Apr 2010 22:43:35 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 2C23645CD8; Thu, 29 Apr 2010 00:43:34 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0C75E45685; Thu, 29 Apr 2010 00:43:28 +0200 (CEST) Date: Thu, 29 Apr 2010 00:43:26 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20100428224326.GE1677@garage.freebsd.pl> References: <86iq7ex9j0.fsf@kopusha.onet> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C94crkcyjafcjHxo" Content-Disposition: inline In-Reply-To: <86iq7ex9j0.fsf@kopusha.onet> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs Subject: Re: hastd segfaults reading metadata from not initialized provider 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, 28 Apr 2010 22:43:36 -0000 --C94crkcyjafcjHxo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2010 at 11:07:31PM +0300, Mikolaj Golub wrote: > Hi, >=20 > When configuring a new provider if one forgets to do=20 >=20 > hastctl create tank >=20 > before=20 >=20 > hastctl role primary tank In my tests I cannot reproduce it. If metadata is empty hastd should notice that, but check for NULL was missing anyway. > the worker core dumps on reading metadata: >=20 > (gdb) bt > #0 strcmp () at /usr/src/lib/libc/i386/string/strcmp.S:61 > #1 0x0804fa18 in metadata_read (res=3D0x284cb600, openrw=3Dtrue) at /usr= /src/sbin/hastd/metadata.c:120 > #2 0x080570ac in init_local (res=3D0x284cb600) at /usr/src/sbin/hastd/pr= imary.c:425 > #3 0x08057f88 in hastd_primary (res=3D0x284cb600) at /usr/src/sbin/hastd= /primary.c:754 > #4 0x0804e270 in child_exit () at /usr/src/sbin/hastd/hastd.c:145 > #5 0x0804edd1 in main_loop () at /usr/src/sbin/hastd/hastd.c:389 > #6 0x0804f3d8 in main (argc=3D0, argv=3D0xbfbfed84) at /usr/src/sbin/has= td/hastd.c:520 > Current language: auto; currently asm > (gdb) fr 1 > #1 0x0804fa18 in metadata_read (res=3D0x284cb600, openrw=3Dtrue) at /usr= /src/sbin/hastd/metadata.c:120 > 120 if (strcmp(str, res->hr_name) !=3D 0) { > Current language: auto; currently c > (gdb) list > 115 ebuf_free(eb); > 116 goto fail; > 117 } > 118 > 119 str =3D nv_get_string(nv, "resource"); > 120 if (strcmp(str, res->hr_name) !=3D 0) { > 121 pjdlog_error("Provider %s is not part of resource= %s.", > 122 res->hr_localpath, res->hr_name); > 123 nv_free(nv); > 124 goto fail; > (gdb) p str > $1 =3D 0x0 >=20 > In the attached patch the check for str is added so we would have a > termination with the error message instead of a core dump: >=20 > Apr 26 22:46:06 hasta hastd: [tank] (primary) Metadata read from /dev/ad6= is invalid. > Apr 26 22:46:06 hasta hastd: [tank] (primary) Worker process failed (pid= =3D6196, status=3D66). I fixed it a bit different. In general nv API is constructued in a way that the consumer might execute various calls and check for error at the end. This is what we do there already, only (str !=3D NULL) check was missing. Thanks for the report, I committed fix to HEAD. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --C94crkcyjafcjHxo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvYug4ACgkQForvXbEpPzQF+QCglCAj4IMHWZR5KPQqIS9itw5m lSYAoNNSQHuEsekxz7zrQdJtFbMQLWgT =M1ca -----END PGP SIGNATURE----- --C94crkcyjafcjHxo-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 00:20:03 2010 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 DDDC41065672 for ; Thu, 29 Apr 2010 00:20:03 +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 B30A48FC15 for ; Thu, 29 Apr 2010 00:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3T0K3Q3075336 for ; Thu, 29 Apr 2010 00:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3T0K3oZ075335; Thu, 29 Apr 2010 00:20:03 GMT (envelope-from gnats) Date: Thu, 29 Apr 2010 00:20:03 GMT Message-Id: <201004290020.o3T0K3oZ075335@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Matuska Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 00:20:04 -0000 The following reply was made to PR bin/144214; it has been noted by GNATS. From: Martin Matuska To: bug-followup@FreeBSD.org, c.kworr@gmail.com Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 Date: Thu, 29 Apr 2010 02:16:24 +0200 This bug is still actual. We had to forcibly reboot a server with a 97% full zpool (~2GB free space) and we came to a ZFS: gang block detected The workaround with re-creating and re-populating /boot worked. From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 00:30:05 2010 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 CCB76106564A for ; Thu, 29 Apr 2010 00:30:05 +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 A40FD8FC0A for ; Thu, 29 Apr 2010 00:30:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3T0U5Y3083643 for ; Thu, 29 Apr 2010 00:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3T0U56u083640; Thu, 29 Apr 2010 00:30:05 GMT (envelope-from gnats) Date: Thu, 29 Apr 2010 00:30:05 GMT Message-Id: <201004290030.o3T0U56u083640@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Daniel Gerzo Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 00:30:05 -0000 The following reply was made to PR bin/144214; it has been noted by GNATS. From: Daniel Gerzo To: bug-followup@FreeBSD.org, c.kworr@gmail.com Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 Date: Thu, 29 Apr 2010 02:11:16 +0200 Hello, this bug seems to be still present in stable/8. The proposed workaround seems to work. You may find the console screenshot at http://danger.rulez.sk/dockdrop/144214.png -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 00:40:05 2010 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 63443106566B for ; Thu, 29 Apr 2010 00:40:05 +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 3A1708FC17 for ; Thu, 29 Apr 2010 00:40:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3T0e4sO093405 for ; Thu, 29 Apr 2010 00:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3T0e44Q093404; Thu, 29 Apr 2010 00:40:04 GMT (envelope-from gnats) Date: Thu, 29 Apr 2010 00:40:04 GMT Message-Id: <201004290040.o3T0e44Q093404@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: =?windows-1252?Q?Daniel_Ger=9Eo?= Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1252?Q?Daniel_Ger=9Eo?= List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 00:40:05 -0000 The following reply was made to PR bin/144214; it has been noted by GNATS. From: =?windows-1252?Q?Daniel_Ger=9Eo?= To: bug-followup@FreeBSD.org, c.kworr@gmail.com Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 Date: Thu, 29 Apr 2010 02:13:42 +0200 Hi, note that the HDD has been almost full (97%) when the box died (ca. 2GB free). -- S pozdravom / Best regards Daniel Gerzo From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 06:56:56 2010 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 9FFF9106564A; Thu, 29 Apr 2010 06:56:56 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id C4E758FC0C; Thu, 29 Apr 2010 06:56:55 +0000 (UTC) Received: by bwz8 with SMTP id 8so14013798bwz.3 for ; Wed, 28 Apr 2010 23:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :organization:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=r22CazZ7us2IYtb97UdZrHyxMp1IBwHoqLg2o8Ha1Kg=; b=MVuIByxbNM3x59Ei9CX159enYgUqDbHIok+30sPIo737I10Zcu0hpNToDRr7RwWeCO F8HhyxW+rfRibRC0s0iQIgU4L1PLj906ca8MXxDyfvp7yAdhZOHqkb5MRKqbJqIDuFAM 8M5z2Vop9FRsd7kNuL1q3gCgbfbx42eTuP46c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=cmWSpYm2N+WuGbarrjkGSo/VDvH74kLsPXaNYzMQ9qyeyy+tahMa67DcL9Yx/wFK0v jFkEKsdmAShRwotqurVpyxjfdUjdW8rb66mxgi3AH6oQEXZL0SHy+sQ/zCddCKH+8XGH U91SMhAa71rWcJmz6DDK5hcpkhLZBDTK/cp6Y= Received: by 10.204.74.98 with SMTP id t34mr1074443bkj.154.1272524207743; Wed, 28 Apr 2010 23:56:47 -0700 (PDT) Received: from localhost (ua1.etadirect.net [91.198.140.16]) by mx.google.com with ESMTPS id 16sm193725bwz.5.2010.04.28.23.56.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Apr 2010 23:56:46 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek Organization: TOA Ukraine References: <86iq7ex9j0.fsf@kopusha.onet> <20100428224326.GE1677@garage.freebsd.pl> Date: Thu, 29 Apr 2010 09:56:44 +0300 In-Reply-To: <20100428224326.GE1677@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Thu, 29 Apr 2010 00:43:26 +0200") Message-ID: <86r5lykaqb.fsf@zhuzha.ua1> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs Subject: Re: hastd segfaults reading metadata from not initialized provider 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, 29 Apr 2010 06:56:56 -0000 On Thu, 29 Apr 2010 00:43:26 +0200 Pawel Jakub Dawidek wrote: PJD> On Mon, Apr 26, 2010 at 11:07:31PM +0300, Mikolaj Golub wrote: >> Hi, >> >> When configuring a new provider if one forgets to do >> >> hastctl create tank >> >> before >> >> hastctl role primary tank PJD> In my tests I cannot reproduce it. If metadata is empty hastd should PJD> notice that, but check for NULL was missing anyway. I observe this on VirtualBox hosts with virtual disks (dynamically expanding storage). PJD> I fixed it a bit different. In general nv API is constructued in a way PJD> that the consumer might execute various calls and check for error at the PJD> end. This is what we do there already, only (str != NULL) check was PJD> missing. Thanks for the report, I committed fix to HEAD. Thank you :-) -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 08:03:46 2010 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 7D9321065670; Thu, 29 Apr 2010 08:03:46 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id AF0268FC17; Thu, 29 Apr 2010 08:03:45 +0000 (UTC) Received: by bwz8 with SMTP id 8so14048003bwz.3 for ; Thu, 29 Apr 2010 01:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :organization:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=BCgNIQJkOyov7QzXVGTaFHswAEqjMn8EZ4BicZTfMn8=; b=QXnVwMpZAIh89467qRu7rDv6f6T5xZvoxEcSa83zbuEaxWiunrk2Jv8eXN0Pjne58Y PsHdPjsukcy2kK25hROGT5Wbh4ERhnDlAS43jCIft2FpcqKNQoTr/+KgusUeuTPOAX6K 4Djkm3Fzq3jO9xZsAw2p8f1c0u8xGkEvSW/KI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=EXboj9NeZaGptmUpMm3In2pMjOB+QN3jXXwKGiuvazDVrmTzjbJY4jzLlADARe0coG 0afYg9v07/aIla1JnpJIWdCY9zMx7hTbUTtIkYGlKbVh2O/t+F+ABP2jc+xv3fq5Ecwg Ou057xA2mxKAZGy5W1SN7+Y7CpTdePa6sFb00= Received: by 10.204.141.133 with SMTP id m5mr5535795bku.91.1272528217254; Thu, 29 Apr 2010 01:03:37 -0700 (PDT) Received: from localhost (ua1.etadirect.net [91.198.140.16]) by mx.google.com with ESMTPS id 15sm217641bwz.4.2010.04.29.01.03.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Apr 2010 01:03:35 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek Organization: TOA Ukraine References: <86r5m9dvqf.fsf@zhuzha.ua1> <20100423062950.GD1670@garage.freebsd.pl> <86k4rye33e.fsf@zhuzha.ua1> <20100424073031.GD3067@garage.freebsd.pl> <868w8dgk4e.fsf@kopusha.onet> <86tyqzeq84.fsf@kopusha.onet> <20100428214636.GD1677@garage.freebsd.pl> Date: Thu, 29 Apr 2010 11:03:33 +0300 In-Reply-To: <20100428214636.GD1677@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Wed, 28 Apr 2010 23:46:36 +0200") Message-ID: <86mxwmk7my.fsf@zhuzha.ua1> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs Subject: Re: HAST: primary might get stuck when there are connectivity problems with secondary 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, 29 Apr 2010 08:03:46 -0000 On Wed, 28 Apr 2010 23:46:36 +0200 Pawel Jakub Dawidek wrote: PJD> Could you see if the following patch fixes the problem for you: PJD> http://people.freebsd.org/~pjd/patches/hastd_timeout.patch PJD> The patch sets timeout on both incoming and outgoing sockets on primary PJD> and on outgoing socket on secondary. Incoming socket on secondary is PJD> left with no timeout to avoid problem you described above. The patch works for me. After disabling the network connection between the primary and the secondary FS operations on the primary do not get stuck and the following messages are observed: Apr 29 10:37:41 hasta hastd: [storage] (primary) Unable to receive reply header: Resource temporarily unavailable. Apr 29 10:37:57 hasta hastd: [tank] (primary) Unable to receive reply header: Resource temporarily unavailable. Apr 29 10:37:57 hasta hastd: [tank] (primary) Unable to send request (Resource temporarily unavailable): WRITE(972292096, 14336). Apr 29 10:38:56 hasta hastd: [storage] (primary) Unable to connect to 172.20.66.202: Operation timed out. Apr 29 10:39:12 hasta hastd: [tank] (primary) Unable to connect to 172.20.66.202: Operation timed out. After restoring the network connection the primary reconnects to the secondary and the status changes back from "degraded" to "complete". Thank you. -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 08:12:11 2010 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 7DF2F106566B for ; Thu, 29 Apr 2010 08:12:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id A0BA58FC12 for ; Thu, 29 Apr 2010 08:12:10 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id BCA8845CD9; Thu, 29 Apr 2010 10:12:07 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id CD81A45C9B; Thu, 29 Apr 2010 10:12:02 +0200 (CEST) Date: Thu, 29 Apr 2010 10:12:00 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20100429081200.GB1697@garage.freebsd.pl> References: <86r5m9dvqf.fsf@zhuzha.ua1> <20100423062950.GD1670@garage.freebsd.pl> <86k4rye33e.fsf@zhuzha.ua1> <20100424073031.GD3067@garage.freebsd.pl> <868w8dgk4e.fsf@kopusha.onet> <86tyqzeq84.fsf@kopusha.onet> <20100428214636.GD1677@garage.freebsd.pl> <86mxwmk7my.fsf@zhuzha.ua1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E13BgyNx05feLLmH" Content-Disposition: inline In-Reply-To: <86mxwmk7my.fsf@zhuzha.ua1> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs Subject: Re: HAST: primary might get stuck when there are connectivity problems with secondary 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, 29 Apr 2010 08:12:11 -0000 --E13BgyNx05feLLmH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 29, 2010 at 11:03:33AM +0300, Mikolaj Golub wrote: >=20 > On Wed, 28 Apr 2010 23:46:36 +0200 Pawel Jakub Dawidek wrote: >=20 > PJD> Could you see if the following patch fixes the problem for you: >=20 > PJD> http://people.freebsd.org/~pjd/patches/hastd_timeout.patch >=20 > PJD> The patch sets timeout on both incoming and outgoing sockets on pri= mary > PJD> and on outgoing socket on secondary. Incoming socket on secondary is > PJD> left with no timeout to avoid problem you described above. >=20 > The patch works for me. >=20 > After disabling the network connection between the primary and the second= ary > FS operations on the primary do not get stuck and the following messages = are > observed: >=20 > Apr 29 10:37:41 hasta hastd: [storage] (primary) Unable to receive reply = header: Resource temporarily unavailable. > Apr 29 10:37:57 hasta hastd: [tank] (primary) Unable to receive reply hea= der: Resource temporarily unavailable. > Apr 29 10:37:57 hasta hastd: [tank] (primary) Unable to send request (Res= ource temporarily unavailable): WRITE(972292096, 14336). > Apr 29 10:38:56 hasta hastd: [storage] (primary) Unable to connect to 172= .20.66.202: Operation timed out. > Apr 29 10:39:12 hasta hastd: [tank] (primary) Unable to connect to 172.20= .66.202: Operation timed out. >=20 > After restoring the network connection the primary reconnects to the seco= ndary > and the status changes back from "degraded" to "complete". Good. And I assume you don't observe problems on secondary? Eg. recv(2) on secondary doesn't timeout? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --E13BgyNx05feLLmH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvZP1AACgkQForvXbEpPzQFQwCgiD1RGHI73+QgfVJ+kxGCXT2/ MZ4An2CG/Dlvk7zDa0IlfvhdCoJOHzst =iuSN -----END PGP SIGNATURE----- --E13BgyNx05feLLmH-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 10:12:46 2010 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 271FA106566C; Thu, 29 Apr 2010 10:12:46 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 319E38FC1A; Thu, 29 Apr 2010 10:12:44 +0000 (UTC) Received: from porto.topspin.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 NAA03040; Thu, 29 Apr 2010 13:12:43 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O7Qja-0008be-7h; Thu, 29 Apr 2010 13:12:42 +0300 Message-ID: <4BD95B99.8040600@freebsd.org> Date: Thu, 29 Apr 2010 13:12:41 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: bug-followup@freebsd.org, piotr.matuszczyk@expro.pl, freebsd-fs@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: kern/141050: fstab(5): Problem with userquota, groupquota parameters in /etc/fstab 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, 29 Apr 2010 10:12:46 -0000 http://www.freebsd.org/cgi/query-pr.cgi?pr=141050 I'd like to fix the issue with the following patch. Could you please review and/or test it? Thanks! Index: sys/ufs/ffs/ffs_vfsops.c =================================================================== --- sys/ufs/ffs/ffs_vfsops.c (revision 207366) +++ sys/ufs/ffs/ffs_vfsops.c (working copy) @@ -124,10 +124,16 @@ #endif }; +/* + * Note that userquota and groupquota options are not currently used + * by UFS/FFS code and generally mount(8) does not pass those options + * from userland, but they can be passed by loader(8) via + * vfs.root.mountfrom.options. + */ static const char *ffs_opts[] = { "acls", "async", "noatime", "noclusterr", - "noclusterw", "noexec", "export", "force", "from", "multilabel", - "nfsv4acls", "snapshot", "nosuid", "suiddir", "nosymfollow", "sync", - "union", NULL }; + "noclusterw", "noexec", "export", "force", "from", "groupquota", + "multilabel", "nfsv4acls", "snapshot", "nosuid", "suiddir", "nosymfollow", + "sync", "union", "userquota", NULL }; static int ffs_mount(struct mount *mp) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 11:23:13 2010 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 18F27106564A; Thu, 29 Apr 2010 11:23:13 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC088FC08; Thu, 29 Apr 2010 11:23:12 +0000 (UTC) Received: by bwz8 with SMTP id 8so14161372bwz.3 for ; Thu, 29 Apr 2010 04:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :organization:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=1ViKzBRhvomm4yR089Saq8OlhnAwLCFtFofFI7dOsBU=; b=XK2JQIBGXf7gEYBHMvdoSfM+B0ZHKn0fzuJ9Omb6CvTcvW5FK/+NDOkQws+crAx5JQ 9g06rpW36mgmssEap2A3kib5F20/FfDnEa5QCydfgBoXRK5IUyuNaxoj32OH+iaBOt0c DaS2/hE98Y0Q6klpIDNhVSK+dZlpm/IaPgEew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=sLWRfu0i5+4dVyFEGDjkgvNNElk/cWGr6cUQG8RJcuR5NdLWO5CZa0zoMc2HPIPSaq JG/cYvo2gG1srbRlCZWdgCPSV+uL4afnxHpncrjtdUxtnmHMFHD5KlIHHwfwurTcnC1z D83U0tMm7eCvUAnMBsoeFAGACLb7KNh1CrdKQ= Received: by 10.204.16.73 with SMTP id n9mr5790253bka.21.1272540184214; Thu, 29 Apr 2010 04:23:04 -0700 (PDT) Received: from localhost (ua1.etadirect.net [91.198.140.16]) by mx.google.com with ESMTPS id 14sm290773bwz.6.2010.04.29.04.23.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Apr 2010 04:23:02 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek Organization: TOA Ukraine References: <86r5m9dvqf.fsf@zhuzha.ua1> <20100423062950.GD1670@garage.freebsd.pl> <86k4rye33e.fsf@zhuzha.ua1> <20100424073031.GD3067@garage.freebsd.pl> <868w8dgk4e.fsf@kopusha.onet> <86tyqzeq84.fsf@kopusha.onet> <20100428214636.GD1677@garage.freebsd.pl> <86mxwmk7my.fsf@zhuzha.ua1> <20100429081200.GB1697@garage.freebsd.pl> Date: Thu, 29 Apr 2010 14:22:59 +0300 In-Reply-To: <20100429081200.GB1697@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Thu, 29 Apr 2010 10:12:00 +0200") Message-ID: <86iq7ajyek.fsf@zhuzha.ua1> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs Subject: Re: HAST: primary might get stuck when there are connectivity problems with secondary 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, 29 Apr 2010 11:23:13 -0000 On Thu, 29 Apr 2010 10:12:00 +0200 Pawel Jakub Dawidek wrote: PJD> On Thu, Apr 29, 2010 at 11:03:33AM +0300, Mikolaj Golub wrote: >> >> On Wed, 28 Apr 2010 23:46:36 +0200 Pawel Jakub Dawidek wrote: >> >> PJD> Could you see if the following patch fixes the problem for you: >> >> PJD> http://people.freebsd.org/~pjd/patches/hastd_timeout.patch >> >> PJD> The patch sets timeout on both incoming and outgoing sockets on primary >> PJD> and on outgoing socket on secondary. Incoming socket on secondary is >> PJD> left with no timeout to avoid problem you described above. >> >> The patch works for me. >> >> After disabling the network connection between the primary and the secondary >> FS operations on the primary do not get stuck and the following messages are >> observed: >> >> Apr 29 10:37:41 hasta hastd: [storage] (primary) Unable to receive reply header: Resource temporarily unavailable. >> Apr 29 10:37:57 hasta hastd: [tank] (primary) Unable to receive reply header: Resource temporarily unavailable. >> Apr 29 10:37:57 hasta hastd: [tank] (primary) Unable to send request (Resource temporarily unavailable): WRITE(972292096, 14336). >> Apr 29 10:38:56 hasta hastd: [storage] (primary) Unable to connect to 172.20.66.202: Operation timed out. >> Apr 29 10:39:12 hasta hastd: [tank] (primary) Unable to connect to 172.20.66.202: Operation timed out. >> >> After restoring the network connection the primary reconnects to the secondary >> and the status changes back from "degraded" to "complete". PJD> Good. And I assume you don't observe problems on secondary? Eg. recv(2) PJD> on secondary doesn't timeout? No problems on secondary. When emulating a network outage, after connectivity restoring the worker is restarted when new connections comes from primary: Apr 29 14:12:39 hastb hastd: Accepting connection to tcp4://0.0.0.0:8457. Apr 29 14:12:39 hastb hastd: Connection from tcp4://172.20.66.202:8457 to tcp4://172.20.66.201:44508. Apr 29 14:12:39 hastb hastd: tcp4://172.20.66.201:44508: resource=tank Apr 29 14:12:39 hastb hastd: [tank] (secondary) Initial connection from tcp4://172.20.66.201:44508. Apr 29 14:12:39 hastb hastd: [tank] (secondary) Worker process exists (pid=1729), stopping it. Apr 29 14:12:39 hastb hastd: [tank] (secondary) Worker process (pid=1729) exited gracefully. Apr 29 14:12:39 hastb hastd: [tank] (secondary) Incoming connection from tcp4://172.20.66.201:44508 configured. If the FS is idle (there is no I/O) secondary is waiting in receive, does not timeout and does not stop workers (as it was with my timeout patch). -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 12:20:04 2010 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 F113B106566C for ; Thu, 29 Apr 2010 12:20:04 +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 5BA7A8FC0C for ; Thu, 29 Apr 2010 12:20:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3TCK326029646 for ; Thu, 29 Apr 2010 12:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3TCK3Bo029643; Thu, 29 Apr 2010 12:20:03 GMT (envelope-from gnats) Date: Thu, 29 Apr 2010 12:20:03 GMT Message-Id: <201004291220.o3TCK3Bo029643@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 12:20:05 -0000 The following reply was made to PR bin/144214; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14 Date: Thu, 29 Apr 2010 15:10:28 +0300 Just to be on the sure side: have you guys actually updated bootblocks on your system? I.e. the code that runs before loader and that resides beyond filesystems. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 15:45:33 2010 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 91810106566C for ; Thu, 29 Apr 2010 15:45:33 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id D760F8FC12 for ; Thu, 29 Apr 2010 15:45:32 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C73B145CD9; Thu, 29 Apr 2010 17:45:30 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0BA4B45CA0; Thu, 29 Apr 2010 17:45:26 +0200 (CEST) Date: Thu, 29 Apr 2010 17:45:23 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20100429154523.GH1697@garage.freebsd.pl> References: <86r5m9dvqf.fsf@zhuzha.ua1> <20100423062950.GD1670@garage.freebsd.pl> <86k4rye33e.fsf@zhuzha.ua1> <20100424073031.GD3067@garage.freebsd.pl> <868w8dgk4e.fsf@kopusha.onet> <86tyqzeq84.fsf@kopusha.onet> <20100428214636.GD1677@garage.freebsd.pl> <86mxwmk7my.fsf@zhuzha.ua1> <20100429081200.GB1697@garage.freebsd.pl> <86iq7ajyek.fsf@zhuzha.ua1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dwWFXG4JqVa0wfCP" Content-Disposition: inline In-Reply-To: <86iq7ajyek.fsf@zhuzha.ua1> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs Subject: Re: HAST: primary might get stuck when there are connectivity problems with secondary 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, 29 Apr 2010 15:45:33 -0000 --dwWFXG4JqVa0wfCP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 29, 2010 at 02:22:59PM +0300, Mikolaj Golub wrote: > On Thu, 29 Apr 2010 10:12:00 +0200 Pawel Jakub Dawidek wrote: > PJD> Good. And I assume you don't observe problems on secondary? Eg. rec= v(2) > PJD> on secondary doesn't timeout? >=20 > No problems on secondary. When emulating a network outage, after connecti= vity > restoring the worker is restarted when new connections comes from primary: >=20 > Apr 29 14:12:39 hastb hastd: Accepting connection to tcp4://0.0.0.0:8457. > Apr 29 14:12:39 hastb hastd: Connection from tcp4://172.20.66.202:8457 to= tcp4://172.20.66.201:44508. > Apr 29 14:12:39 hastb hastd: tcp4://172.20.66.201:44508: resource=3Dtank > Apr 29 14:12:39 hastb hastd: [tank] (secondary) Initial connection from t= cp4://172.20.66.201:44508. > Apr 29 14:12:39 hastb hastd: [tank] (secondary) Worker process exists (pi= d=3D1729), stopping it. > Apr 29 14:12:39 hastb hastd: [tank] (secondary) Worker process (pid=3D172= 9) exited gracefully. > Apr 29 14:12:39 hastb hastd: [tank] (secondary) Incoming connection from = tcp4://172.20.66.201:44508 configured. >=20 > If the FS is idle (there is no I/O) secondary is waiting in receive, does= not > timeout and does not stop workers (as it was with my timeout patch). Thanks for reporting and testing. I committed the patch to HEAD. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --dwWFXG4JqVa0wfCP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvZqZIACgkQForvXbEpPzThlQCeNyMDteysX00LN9CbtkMWdeTL 0uQAn3mem/elULuaQSuU0RZw0ZI4P3As =FCrh -----END PGP SIGNATURE----- --dwWFXG4JqVa0wfCP-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 16:18:54 2010 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 387AE106577C for ; Thu, 29 Apr 2010 16:18:54 +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 E93F58FC20 for ; Thu, 29 Apr 2010 16:18:52 +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 TAA13213 for ; Thu, 29 Apr 2010 19:18:51 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BD9B16A.10606@freebsd.org> Date: Thu, 29 Apr 2010 19:18:50 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4B9FD6E0.5000303@icyb.net.ua> In-Reply-To: <4B9FD6E0.5000303@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: few ideas for zfsloader 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, 29 Apr 2010 16:18:54 -0000 on 16/03/2010 21:07 Andriy Gapon said the following: > 2. Currently nextboot functionality doesn't work properly with ZFS because there > is no RW support in zfsloader. Adding that support seems to be quite hard given > the transactional nature of ZFS, checksums, compression and what not. > Here's an alternative idea: honor nextboot.conf only if boot filesystem has a a > special property set on it, for example org.freebsd:nextboot. > Then all we need is to flip the property off. > Although doing this is still not trivial it should be simpler than filesystem RW > support. ZFS properties do, in fact, have the same nature as regular file data. So, changing a property value (whether filesystem or pool) requires practically the same level of write support as modification of a file. And this seems to be quite complex to do in loader; updating all necessary vdevs, doing checksums, transactions, etc. So, right now, I do not see a way to properly support nextboot with ZFS. We probably should emit some warning when nextboot.conf is created on ZFS that there will not be automatic recovery if kernel boot fails. Some really weird alternative ideas: 1. Write nextboot flag in some other place (NVRAM, special sectors of HDD) 2. Use time-limited nextboot - e.g. there is a timestamp in nextboot.conf and it is honored until the timestamp expires. But I won't seriously consider these. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 16:30:03 2010 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 AC027106566B for ; Thu, 29 Apr 2010 16:30:03 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1146D8FC12 for ; Thu, 29 Apr 2010 16:30:00 +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 TAA13378; Thu, 29 Apr 2010 19:29:59 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BD9B406.5070009@icyb.net.ua> Date: Thu, 29 Apr 2010 19:29:58 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org References: <4B9FD6E0.5000303@icyb.net.ua> In-Reply-To: <4B9FD6E0.5000303@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Navdeep Parhar Subject: Re: few ideas for zfsloader (boot environments) 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, 29 Apr 2010 16:30:03 -0000 on 16/03/2010 21:07 Andriy Gapon said the following: > 3. Currently ZFS boot chain lacks an ability to switch bootfs property of a pool. > So, if a (new) boot environment is not quite bootable and bootfs points to it, > then an alternative boot media (e.g. livecd) is needed to correct the situation. > Implementing selection of a boot filesystem in ZFS boot chain seems like a hard task. > Alternative idea: a new FreeBSD-specific pool property, nextbootfs. This property > would designate a boot filesystem for the next boot and would be automatically > reset by a boot loader at sufficiently early stage. If the next boot doesn't > succeed, then we are back to the regular bootfs property, if it does succeed, then > bootfs can be safely changed to the new value. I've git it all backwards. It is hard to implement nextbootfs property, see my other post about nextboot. It is possible to implement boot environment selection in zfs boot code. We could use the same approach as in OpenSolaris version of GRUB. E.g. have a file in root filesystem of a pool (the filesystem that has the same name as the pool) named, say, boot/boot.list that would have a one-per-line list of supposedly bootable filesystems in a pool. zfsboot would read that file and present the list to a user. Entry selected by bootfs would be a default one. If user chooses a different filesystem, then the boot code would try it for boot (find loader, etc). BTW, it's already possible to use FreeBSD+ZFS+GRUB and have this ability (in some form). But it would great to have that "natively". Couple of useful links: http://grub.enbug.org/GRUB2FreeBSDZFS http://www.mail-archive.com/grub-devel@gnu.org/msg15161.html Thanks to Navdeep for the GRUB work! BTW, Navdeep, was there any progress on your grub+zfsloader patch? Or GRUB folks plainly refused it? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 16:37:40 2010 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 4279F106566C for ; Thu, 29 Apr 2010 16:37:40 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id 0E07A8FC18 for ; Thu, 29 Apr 2010 16:37:39 +0000 (UTC) Received: by pzk39 with SMTP id 39so3056283pzk.7 for ; Thu, 29 Apr 2010 09:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=85gPCZJeTuNTvbDwMaHwAuwy4EK8CR2UCnP0S/jM1EQ=; b=Iz4tXHBXRyoxaMllP7iYNlO3wew84+fykTzv9izgynzlss590pO/VjlxfAYY3EKlbG 98TH5ayGoPwr2YUXcr943vOLNo64csV1+2xAMRRoOeRua13YMwAM3R6v9g+MgkO6rdV8 1thJJDaoANTtL/jVdgR/LfQ4CmwHmv6QCfjzk= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=x091mtr2aYTuF07i/S2XX4uTzkGuTG8DoLkKPLiS7f6S49Ya5G6zfjF3VB12kOW01Z TKdRrzmjVBn0JRLn5pIJsBSt8XpVEaG74BffY/SbeaNn9PPSuqHc9F4eFg1JixQnzV0h sO10uL/gQE068voWvTawx/pZ4En4fSQ4dqaHs= MIME-Version: 1.0 Received: by 10.141.14.21 with SMTP id r21mr9526228rvi.144.1272559053121; Thu, 29 Apr 2010 09:37:33 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.29.10 with HTTP; Thu, 29 Apr 2010 09:37:32 -0700 (PDT) In-Reply-To: <4BD9B16A.10606@freebsd.org> References: <4B9FD6E0.5000303@icyb.net.ua> <4BD9B16A.10606@freebsd.org> Date: Thu, 29 Apr 2010 09:37:32 -0700 X-Google-Sender-Auth: 73091c54068b807b Message-ID: From: Artem Belevich To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: few ideas for zfsloader 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, 29 Apr 2010 16:37:40 -0000 Perhaps we can hijack vdev's boot block header and/or boot block itself for these purposes. It's currently unused, according to ZFS spec. See chapters 1.3.2 and 1.4 in ZFS on-disk format: http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskform= at0822.pdf --Artem On Thu, Apr 29, 2010 at 9:18 AM, Andriy Gapon wrote: > on 16/03/2010 21:07 Andriy Gapon said the following: >> 2. Currently nextboot functionality doesn't work properly with ZFS becau= se there >> is no RW support in zfsloader. =A0Adding that support seems to be quite = hard given >> the transactional nature of ZFS, checksums, compression and what not. >> Here's an alternative idea: honor nextboot.conf only if boot filesystem = has a a >> special property set on it, for example org.freebsd:nextboot. >> Then all we need is to flip the property off. >> Although doing this is still not trivial it should be simpler than files= ystem RW >> support. > > ZFS properties do, in fact, have the same nature as regular file data. > So, changing a property value (whether filesystem or pool) requires pract= ically > the same level of write support as modification of a file. > > And this seems to be quite complex to do in loader; updating all necessar= y vdevs, > doing checksums, transactions, etc. > > So, right now, I do not see a way to properly support nextboot with ZFS. > We probably should emit some warning when nextboot.conf is created on ZFS= that > there will not be automatic recovery if kernel boot fails. > > Some really weird alternative ideas: > 1. Write nextboot flag in some other place (NVRAM, special sectors of HDD= ) > 2. Use time-limited nextboot - e.g. there is a timestamp in nextboot.conf= and it > is honored until the timestamp expires. > But I won't seriously consider these. > > -- > Andriy Gapon > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 16:47:19 2010 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 0FB081065670 for ; Thu, 29 Apr 2010 16:47:19 +0000 (UTC) (envelope-from julianelischer@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 9053E8FC0A for ; Thu, 29 Apr 2010 16:47:18 +0000 (UTC) Received: by fxm15 with SMTP id 15so1244638fxm.13 for ; Thu, 29 Apr 2010 09:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Eri90GVffxXbKuSdFRI425bI78ZJ0MpWVMI5w5EBw4E=; b=WkA6EJXlAB25LHsisFSWDLcaQwtujjHtdCzekCou0tIpq7hRbIsZsW7FMN3Ytct/jM fmg3LzAo48Dj8j/eb+trxVZEhlKG2AVdkgGxoMRIyfbVQ69QdHgsYmOP0fb6NeFrUhw2 W4RsgDTggNbv0HCFK948rJG6ByBHi64y3sZeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=j2B9rRXkqlJprEARdojKedHXGBBOxajUtngEoE9/WC/8MJh7VL4/6qmoC40D3G95Mu FKyc84wRQojxEiQIP4KftjNjo8P+bPwOQIIgAcdHPIUyxeCPjJ4Z+xAJVf6+DErRXLLb JWE9Z2a28Dc/fHVoAPM3HRBIWeMkVn7VmmkBQ= Received: by 10.87.48.34 with SMTP id a34mr1941721fgk.2.1272559627666; Thu, 29 Apr 2010 09:47:07 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id e11sm12641578fga.13.2010.04.29.09.47.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Apr 2010 09:47:03 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BD9B7FD.1010409@elischer.org> Date: Thu, 29 Apr 2010 09:46:53 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andriy Gapon , freebsd-fs@FreeBSD.org References: <4B9FD6E0.5000303@icyb.net.ua> <4BD9B16A.10606@freebsd.org> In-Reply-To: <4BD9B16A.10606@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: few ideas for zfsloader 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, 29 Apr 2010 16:47:19 -0000 On 4/29/10 9:18 AM, Andriy Gapon wrote: > > So, right now, I do not see a way to properly support nextboot with ZFS. > We probably should emit some warning when nextboot.conf is created on ZFS that > there will not be automatic recovery if kernel boot fails. > > Some really weird alternative ideas: > 1. Write nextboot flag in some other place (NVRAM, special sectors of HDD) this is what nextboot originally did before it was broken^H^H^H^H^H^H rewritten. I stored the information in sector 1 (not 0) of the drive. One version I never finished stored it in a special 'nextboot' partition. > 2. Use time-limited nextboot - e.g. there is a timestamp in nextboot.conf > and it is honored until the timestamp expires. > But I won't seriously consider these. the timestamp idea good. I considered doing it. myself for the original nextboot. It may be annoying having to wait 10 minutes before recovering from a bad upgrade, but it would be simple, and better than not recovering. From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 16:52:34 2010 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 62BE41065675 for ; Thu, 29 Apr 2010 16:52:34 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 83C638FC1F for ; Thu, 29 Apr 2010 16:52:33 +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 TAA13708 for ; Thu, 29 Apr 2010 19:52:32 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BD9B94F.7090709@icyb.net.ua> Date: Thu, 29 Apr 2010 19:52:31 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org References: <4B9FD6E0.5000303@icyb.net.ua> In-Reply-To: <4B9FD6E0.5000303@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: multipart/mixed; boundary="------------070300090607070101030101" Cc: Subject: Re: few ideas for zfsloader ( bootfs -> vfs.root.mountfrom) 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, 29 Apr 2010 16:52:34 -0000 This is a multi-part message in MIME format. --------------070300090607070101030101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit on 16/03/2010 21:07 Andriy Gapon said the following: > I have three crazy-ish ideas for zfsloader. > Unfortunately, right now I am short on time and I am very short on ZFS knowledge > to go for implementing them myself. > > 1. If vfs.root.mountfrom is not already set and there is no root mount entry in > fstab then set vfs.root.mountfrom to "zfs:". > This obviously requires being able to get properties of the current dataset > (filesystem) and get the name from them. I've made some progress on this, see the attached patch. The patch is not complete. What it can do right now: 1. set vfs.zfs.bootfs to something like "zfs:tank:1111" where 'tank' is a pool name and '1111' is object id of dataset selected as boot filesystem (e.g. via bootfs). 2. set vfs.root.mountfrom to value of vfs.zfs.bootfs iff it was not set explicietly and '/' entry was not found in fstab. But right now ZFS can not be mounted using a filesystem specification in the above format. I see two ways forward: 1. Enhance ZFS mount kernel code, so that it accepts dataset id instead of its name. This doesn't seem to be very hard. 2. Enhance zfs boot code (zfsloader) to map boot dataset id to its name. I have prototype code (unfinished, non-working) for this that navigates from a dataset up the hierarchy (via dir_obj, parent_dir_obj) and does a reverse lookup in directory child map to find a name component. While #2 seems nicer it also seems to be a waste, since the name will ultimately be mapped to object id by ZFS kernel code anyways. Also, I am not sure if we should care about multiple pools under the same name. Maybe I should use pool guid instead of pool name in vfs.zfs.bootfs? Thanks a lot for any comments and help with this. -- Andriy Gapon --------------070300090607070101030101 Content-Type: text/plain; name="zfsboot.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="zfsboot.diff" ZGlmZiAtLWdpdCBhL3N5cy9ib290L2NvbW1vbi9ib290LmMgYi9zeXMvYm9vdC9jb21tb24v Ym9vdC5jCmluZGV4IGM2YWI2ODEuLjAyZWNiNjMgMTAwNjQ0Ci0tLSBhL3N5cy9ib290L2Nv bW1vbi9ib290LmMKKysrIGIvc3lzL2Jvb3QvY29tbW9uL2Jvb3QuYwpAQCAtMzExLDEyICsz MTEsMTIgQEAgZ2V0cm9vdG1vdW50KGNoYXIgKnJvb3RkZXYpCiAgICAgaWYgKGdldGVudigi dmZzLnJvb3QubW91bnRmcm9tIikgIT0gTlVMTCkKIAlyZXR1cm4oMCk7CiAKKyAgICBlcnJv ciA9IDE7CiAgICAgc3ByaW50ZihsYnVmLCAiJXMvZXRjL2ZzdGFiIiwgcm9vdGRldik7CiAg ICAgaWYgKChmZCA9IG9wZW4obGJ1ZiwgT19SRE9OTFkpKSA8IDApCi0JcmV0dXJuKDEpOwor CWdvdG8gZW5kOwogCiAgICAgLyogbG9vcCByZWFkaW5nIGxpbmVzIGZyb20gL2V0Yy9mc3Rh YiAgICBXaGF0IHdhcyB0aGF0IGFib3V0IHNzY2FuZiBhZ2Fpbj8gKi8KLSAgICBlcnJvciA9 IDE7CiAgICAgd2hpbGUgKGZnZXRzdHIobGJ1Ziwgc2l6ZW9mKGxidWYpLCBmZCkgPj0gMCkg ewogCWlmICgobGJ1ZlswXSA9PSAwKSB8fCAobGJ1ZlswXSA9PSAnIycpKQogCSAgICBjb250 aW51ZTsKQEAgLTM3Nyw2ICszNzcsMTggQEAgZ2V0cm9vdG1vdW50KGNoYXIgKnJvb3RkZXYp CiAJYnJlYWs7CiAgICAgfQogICAgIGNsb3NlKGZkKTsKKworZW5kOgorICAgIGlmIChlcnJv ciAhPSAwKSB7CisJY29uc3QgY2hhciAqemZzX2Jvb3RmczsKKworCXpmc19ib290ZnMgPSBn ZXRlbnYoInZmcy56ZnMuYm9vdGZzIik7CisJaWYgKHpmc19ib290ZnMgIT0gTlVMTCkgewor CSAgICBzZXRlbnYoInZmcy5yb290Lm1vdW50ZnJvbSIsIHpmc19ib290ZnMsIDApOworCSAg ICBlcnJvciA9IDA7CisJfQorICAgIH0KKwogICAgIHJldHVybihlcnJvcik7CiB9CiAKZGlm ZiAtLWdpdCBhL3N5cy9ib290L2kzODYvbG9hZGVyL21haW4uYyBiL3N5cy9ib290L2kzODYv bG9hZGVyL21haW4uYwppbmRleCAwNzM4ODgyLi40NzY4ZTY0IDEwMDY0NAotLS0gYS9zeXMv Ym9vdC9pMzg2L2xvYWRlci9tYWluLmMKKysrIGIvc3lzL2Jvb3QvaTM4Ni9sb2FkZXIvbWFp bi5jCkBAIC03OSw2ICs3OSwxNCBAQCBleHRlcm4JY2hhciBib290cHJvZ19uYW1lW10sIGJv b3Rwcm9nX3JldltdLCBib290cHJvZ19kYXRlW10sIGJvb3Rwcm9nX21ha2VyW107CiAvKiBY WFggZGVidWdnaW5nICovCiBleHRlcm4gY2hhciBlbmRbXTsKIAorI2lmZGVmIExPQURFUl9a RlNfU1VQUE9SVAorZXh0ZXJuIHN0cnVjdCBkZXZzdyB6ZnNfZGV2OworCitleHRlcm4gdWlu dDY0X3QJCXpmc19ndWlkX3RvX2Jvb3RvYmoodWludDY0X3QpOworZXh0ZXJuIGNvbnN0IGNo YXIgKgl6ZnNfZ3VpZF90b19uYW1lKHVpbnQ2NF90KTsKK2V4dGVybiBpbnQJCXpmc19ndWlk X3RvX3VuaXQodWludDY0X3QpOworI2VuZGlmCisKIHN0YXRpYyB2b2lkICpoZWFwX3RvcDsK IHN0YXRpYyB2b2lkICpoZWFwX2JvdHRvbTsKIApAQCAtMjY2LDIwICsyNzQsMjIgQEAgZXh0 cmFjdF9jdXJyZGV2KHZvaWQpCiAgICAgICogd2hpY2ggWkZTIHBvb2wgd2UgYXJlIGJvb3Rp bmcgZnJvbS4KICAgICAgKi8KICAgICBpZiAoa2FyZ3MtPmJvb3RmbGFncyAmIEtBUkdTX0ZM QUdTX1pGUykgewotCS8qCi0JICogRGlnIG91dCB0aGUgcG9vbCBndWlkIGFuZCBjb252ZXJ0 IGl0IHRvIGEgJ3VuaXQgbnVtYmVyJwotCSAqLwotCXVpbnQ2NF90IGd1aWQ7Ci0JaW50IHVu aXQ7Ci0JY2hhciBkZXZuYW1lWzMyXTsKLQlleHRlcm4gaW50IHpmc19ndWlkX3RvX3VuaXQo dWludDY0X3QpOworICAgIAljaGFyIGJ1ZlsyNTZdOworICAgICAgICB1aW50NjRfdCBib290 X29iajsKKyAgICAJY29uc3QgY2hhciAqcG9vbG5hbWU7CisgICAgCWludCB1bml0OwogCi0J Z3VpZCA9IGthcmdzLT56ZnNwb29sOwotCXVuaXQgPSB6ZnNfZ3VpZF90b191bml0KGd1aWQp OworCXVuaXQgPSB6ZnNfZ3VpZF90b191bml0KGthcmdzLT56ZnNwb29sKTsKIAlpZiAodW5p dCA+PSAwKSB7CiAJICAgIG5ld19jdXJyZGV2LmRfZGV2ID0gJnpmc19kZXY7CiAJICAgIG5l d19jdXJyZGV2LmRfdHlwZSA9IG5ld19jdXJyZGV2LmRfZGV2LT5kdl90eXBlOwogCSAgICBu ZXdfY3VycmRldi5kX3VuaXQgPSB1bml0OworCSAgICBuZXdfY3VycmRldi5kX2tpbmQuemZz LnBvb2xfZ3VpZCA9IGthcmdzLT56ZnNwb29sOyAvKiBYWFggdW51c2VkICovCisKKwkgICAg cG9vbG5hbWUgPSB6ZnNfZ3VpZF90b19uYW1lKGthcmdzLT56ZnNwb29sKTsKKwkgICAgYm9v dF9vYmogPSB6ZnNfZ3VpZF90b19ib290b2JqKGthcmdzLT56ZnNwb29sKTsKKwkgICAgc3By aW50ZihidWYsICJ6ZnM6JXM6JWxsdSIsIHBvb2xuYW1lLCBib290X29iaik7IC8qIFhYWCBz bnByaW50Zj8gKi8KKwkgICAgc2V0ZW52KCJ2ZnMuemZzLmJvb3RmcyIsIGJ1ZiwgMSk7CiAJ fQogICAgIH0KICNlbmRpZgpkaWZmIC0tZ2l0IGEvc3lzL2Jvb3QvemZzL3pmcy5jIGIvc3lz L2Jvb3QvemZzL3pmcy5jCmluZGV4IDk5YmI2MGEuLjhlYThhZDAgMTAwNjQ0Ci0tLSBhL3N5 cy9ib290L3pmcy96ZnMuYworKysgYi9zeXMvYm9vdC96ZnMvemZzLmMKQEAgLTM4Nyw2ICsz ODcsMzIgQEAgemZzX2d1aWRfdG9fdW5pdCh1aW50NjRfdCBndWlkKQogCXJldHVybiAoLTEp OwogfQogCitjb25zdCBjaGFyICoKK3pmc19ndWlkX3RvX25hbWUodWludDY0X3QgZ3VpZCkK K3sKKwlzcGFfdCAqc3BhOworCisJU1RBSUxRX0ZPUkVBQ0goc3BhLCAmemZzX3Bvb2xzLCBz cGFfbGluaykKKwkJaWYgKHNwYS0+c3BhX2d1aWQgPT0gZ3VpZCkKKwkJCXJldHVybiAoc3Bh LT5zcGFfbmFtZSk7CisKKwlyZXR1cm4gKE5VTEwpOworfQorCit1aW50NjRfdAoremZzX2d1 aWRfdG9fYm9vdG9iaih1aW50NjRfdCBndWlkKQoreworCXNwYV90ICpzcGE7CisKKwlTVEFJ TFFfRk9SRUFDSChzcGEsICZ6ZnNfcG9vbHMsIHNwYV9saW5rKQorCQlpZiAoc3BhLT5zcGFf Z3VpZCA9PSBndWlkKSB7CisJCQl6ZnNfbW91bnRfcG9vbChzcGEpOworCQkJcmV0dXJuIChz cGEtPnNwYV9yb290X29iaik7CisJCX0KKworCXJldHVybiAoMCk7Cit9CisKIHN0YXRpYyBp bnQKIHpmc19kZXZfaW5pdCh2b2lkKSAKIHsKZGlmZiAtLWdpdCBhL3N5cy9ib290L3pmcy96 ZnNpbXBsLmMgYi9zeXMvYm9vdC96ZnMvemZzaW1wbC5jCmluZGV4IDE0MDdlYjUuLjY3ZDNh MjMgMTAwNjQ0Ci0tLSBhL3N5cy9ib290L3pmcy96ZnNpbXBsLmMKKysrIGIvc3lzL2Jvb3Qv emZzL3pmc2ltcGwuYwpAQCAtMTQyMSw2ICsxNDIxLDcgQEAgemZzX21vdW50X2RhdGFzZXQo c3BhX3QgKnNwYSwgdWludDY0X3Qgb2JqbnVtLCBvYmpzZXRfcGh5c190ICpvYmpzZXQpCiAJ CXJldHVybiAoRUlPKTsKIAl9CiAKKwlzcGEtPnNwYV9yb290X29iaiA9IG9iam51bTsKIAly ZXR1cm4gKDApOwogfQogCmRpZmYgLS1naXQgYS9zeXMvY2RkbC9ib290L3pmcy96ZnNpbXBs LmggYi9zeXMvY2RkbC9ib290L3pmcy96ZnNpbXBsLmgKaW5kZXggZWYxMzQ4Ny4uNDY0NzAx NiAxMDA2NDQKLS0tIGEvc3lzL2NkZGwvYm9vdC96ZnMvemZzaW1wbC5oCisrKyBiL3N5cy9j ZGRsL2Jvb3QvemZzL3pmc2ltcGwuaApAQCAtMTIwNSw0ICsxMjA1LDUgQEAgdHlwZWRlZiBz dHJ1Y3Qgc3BhIHsKIAl2ZGV2X2xpc3RfdAlzcGFfdmRldnM7CS8qIGxpc3Qgb2YgYWxsIHRv cGxldmVsIHZkZXZzICovCiAJb2Jqc2V0X3BoeXNfdAlzcGFfbW9zOwkvKiBNT1MgZm9yIHRo aXMgcG9vbCAqLwogCW9ianNldF9waHlzX3QJc3BhX3Jvb3Rfb2Jqc2V0OyAvKiBjdXJyZW50 IG1vdW50ZWQgWlBMIG9ianNldCAqLworCXVpbnQ2NF90CXNwYV9yb290X29iajsJLyogY3Vy cmVudCBtb3VudGVkIFpQTCBvYmplY3QgaWQgKi8KIH0gc3BhX3Q7Cg== --------------070300090607070101030101-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 17:07:00 2010 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 924B2106566C; Thu, 29 Apr 2010 17:07:00 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id 536AA8FC15; Thu, 29 Apr 2010 17:07:00 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id C4009139591; Thu, 29 Apr 2010 20:06:56 +0300 (EEST) Date: Thu, 29 Apr 2010 20:06:56 +0300 From: Jaakko Heinonen To: Andriy Gapon Message-ID: <20100429170656.GA3617@a91-153-117-195.elisa-laajakaista.fi> References: <4BD95B99.8040600@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD95B99.8040600@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: kern/141050: fstab(5): Problem with userquota, groupquota parameters in /etc/fstab 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, 29 Apr 2010 17:07:00 -0000 On 2010-04-29, Andriy Gapon wrote: > I'd like to fix the issue with the following patch. > Could you please review and/or test it? The kernel groupquota and userquota options may not be sync with the user space viewpoint. This is not a problem as long as the kernel options are not used but it might be better to not store them permanently to mnt_opt list. Possibly you can remove the options with vfs_deleteopt() in ffs_mount(). Thank you for looking at this bug. -- Jaakko From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 17:20:38 2010 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 A62551065675 for ; Thu, 29 Apr 2010 17:20: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 D0A3A8FC15 for ; Thu, 29 Apr 2010 17:20:37 +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 UAA14232; Thu, 29 Apr 2010 20:20:33 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BD9BFE0.90707@freebsd.org> Date: Thu, 29 Apr 2010 20:20:32 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Artem Belevich References: <4B9FD6E0.5000303@icyb.net.ua> <4BD9B16A.10606@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: few ideas for zfsloader 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, 29 Apr 2010 17:20:38 -0000 on 29/04/2010 19:37 Artem Belevich said the following: > Perhaps we can hijack vdev's boot block header and/or boot block > itself for these purposes. It's currently unused, according to ZFS > spec. I think that boot block is (can be) partially used by our zfsboot when a whole disk is dedicated to ZFS (i.e. no partitioning). E.g. see: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg103774.html The idea is fine in general. It's having to deal with multiple vdevs for a pool with complex topology is what can get messy. But I haven' given any real thought to this yet. If you come up with a design please share. Thanks! > See chapters 1.3.2 and 1.4 in ZFS on-disk format: > http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskformat0822.pdf Yep, have it on my (virtual) desk :-) > > On Thu, Apr 29, 2010 at 9:18 AM, Andriy Gapon wrote: >> on 16/03/2010 21:07 Andriy Gapon said the following: >>> 2. Currently nextboot functionality doesn't work properly with ZFS because there >>> is no RW support in zfsloader. Adding that support seems to be quite hard given >>> the transactional nature of ZFS, checksums, compression and what not. >>> Here's an alternative idea: honor nextboot.conf only if boot filesystem has a a >>> special property set on it, for example org.freebsd:nextboot. >>> Then all we need is to flip the property off. >>> Although doing this is still not trivial it should be simpler than filesystem RW >>> support. >> ZFS properties do, in fact, have the same nature as regular file data. >> So, changing a property value (whether filesystem or pool) requires practically >> the same level of write support as modification of a file. >> >> And this seems to be quite complex to do in loader; updating all necessary vdevs, >> doing checksums, transactions, etc. >> >> So, right now, I do not see a way to properly support nextboot with ZFS. >> We probably should emit some warning when nextboot.conf is created on ZFS that >> there will not be automatic recovery if kernel boot fails. >> >> Some really weird alternative ideas: >> 1. Write nextboot flag in some other place (NVRAM, special sectors of HDD) >> 2. Use time-limited nextboot - e.g. there is a timestamp in nextboot.conf and it >> is honored until the timestamp expires. >> But I won't seriously consider these. >> >> -- >> Andriy Gapon >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 18:22:51 2010 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 8CF081065670; Thu, 29 Apr 2010 18:22:51 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 639338FC15; Thu, 29 Apr 2010 18:22:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3TIMpjS046596; Thu, 29 Apr 2010 18:22:51 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3TIMoYa046592; Thu, 29 Apr 2010 18:22:50 GMT (envelope-from jh) Date: Thu, 29 Apr 2010 18:22:50 GMT Message-Id: <201004291822.o3TIMoYa046592@freefall.freebsd.org> To: gerrit@pmp.uni-hannover.de, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/144330: [nfs] mbuf leakage in nfsd with 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: Thu, 29 Apr 2010 18:22:51 -0000 Synopsis: [nfs] mbuf leakage in nfsd with zfs State-Changed-From-To: open->closed State-Changed-By: jh State-Changed-When: Thu Apr 29 18:22:50 UTC 2010 State-Changed-Why: Fixed in head and stable/8. http://www.freebsd.org/cgi/query-pr.cgi?pr=144330 From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 20:56:53 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1205) id 6318D1065676; Thu, 29 Apr 2010 20:56:53 +0000 (UTC) Date: Thu, 29 Apr 2010 20:56:53 +0000 From: Navdeep Parhar To: Andriy Gapon Message-ID: <20100429205653.GA86011@hub.freebsd.org> References: <4B9FD6E0.5000303@icyb.net.ua> <4BD9B406.5070009@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD9B406.5070009@icyb.net.ua> User-Agent: Mutt/1.4.2.1i Cc: freebsd-fs@FreeBSD.org Subject: Re: few ideas for zfsloader (boot environments) 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, 29 Apr 2010 20:56:53 -0000 On Thu, Apr 29, 2010 at 07:29:58PM +0300, Andriy Gapon wrote: > BTW, it's already possible to use FreeBSD+ZFS+GRUB and have this ability (in some > form). But it would great to have that "natively". > > Couple of useful links: > http://grub.enbug.org/GRUB2FreeBSDZFS > http://www.mail-archive.com/grub-devel@gnu.org/msg15161.html > Thanks to Navdeep for the GRUB work! > > BTW, Navdeep, was there any progress on your grub+zfsloader patch? > Or GRUB folks plainly refused it? It's all in the email thread that you pointed out. I got the impression from the reply that they don't have chainloading high in their priority list. But the patch has not been explicitly refused either. Those interested in this functionality should consider asking the GRUB folks to include it. Regards, Navdeep From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 21:05:52 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 939EF1065678 for ; Thu, 29 Apr 2010 21:05:52 +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 9E4CA8FC16 for ; Thu, 29 Apr 2010 21:05:50 +0000 (UTC) Received: from porto.topspin.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 AAA18155; Fri, 30 Apr 2010 00:05:49 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O7avd-0009iX-LI; Fri, 30 Apr 2010 00:05:49 +0300 Message-ID: <4BD9F4AD.4080904@freebsd.org> Date: Fri, 30 Apr 2010 00:05:49 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Navdeep Parhar References: <4B9FD6E0.5000303@icyb.net.ua> <4BD9B406.5070009@icyb.net.ua> <20100429205653.GA86011@hub.freebsd.org> In-Reply-To: <20100429205653.GA86011@hub.freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Sergey Matveychuk Subject: Re: few ideas for zfsloader (boot environments) 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, 29 Apr 2010 21:05:52 -0000 on 29/04/2010 23:56 Navdeep Parhar said the following: > On Thu, Apr 29, 2010 at 07:29:58PM +0300, Andriy Gapon wrote: >> BTW, it's already possible to use FreeBSD+ZFS+GRUB and have this ability (in some >> form). But it would great to have that "natively". >> >> Couple of useful links: >> http://grub.enbug.org/GRUB2FreeBSDZFS >> http://www.mail-archive.com/grub-devel@gnu.org/msg15161.html >> Thanks to Navdeep for the GRUB work! >> >> BTW, Navdeep, was there any progress on your grub+zfsloader patch? >> Or GRUB folks plainly refused it? > > It's all in the email thread that you pointed out. I got the impression > from the reply that they don't have chainloading high in their priority > list. But the patch has not been explicitly refused either. Those > interested in this functionality should consider asking the GRUB folks > to include it. I see. Perhaps, we could use your patch in FreeBSD port of GRUB for time being. Oh, hey, we don't have a port for GRUB2 yet? :-) I think we should create it. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 21:15:25 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1205) id CB8151065672; Thu, 29 Apr 2010 21:15:25 +0000 (UTC) Date: Thu, 29 Apr 2010 21:15:25 +0000 From: Navdeep Parhar To: Andriy Gapon Message-ID: <20100429211525.GA91893@hub.freebsd.org> References: <4B9FD6E0.5000303@icyb.net.ua> <4BD9B406.5070009@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD9B406.5070009@icyb.net.ua> User-Agent: Mutt/1.4.2.1i Cc: freebsd-fs@FreeBSD.org Subject: Re: few ideas for zfsloader (boot environments) 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, 29 Apr 2010 21:15:25 -0000 On Thu, Apr 29, 2010 at 07:29:58PM +0300, Andriy Gapon wrote: > on 16/03/2010 21:07 Andriy Gapon said the following: > > 3. Currently ZFS boot chain lacks an ability to switch bootfs property of a pool. > > So, if a (new) boot environment is not quite bootable and bootfs points to it, > > then an alternative boot media (e.g. livecd) is needed to correct the situation. > > Implementing selection of a boot filesystem in ZFS boot chain seems like a hard task. > > Alternative idea: a new FreeBSD-specific pool property, nextbootfs. This property > > would designate a boot filesystem for the next boot and would be automatically > > reset by a boot loader at sufficiently early stage. If the next boot doesn't > > succeed, then we are back to the regular bootfs property, if it does succeed, then > > bootfs can be safely changed to the new value. > > I've git it all backwards. > It is hard to implement nextbootfs property, see my other post about nextboot. > It is possible to implement boot environment selection in zfs boot code. > > We could use the same approach as in OpenSolaris version of GRUB. > E.g. have a file in root filesystem of a pool (the filesystem that has the same > name as the pool) named, say, boot/boot.list that would have a one-per-line list > of supposedly bootable filesystems in a pool. > zfsboot would read that file and present the list to a user. Entry selected by > bootfs would be a default one. If user chooses a different filesystem, then the > boot code would try it for boot (find loader, etc). > > BTW, it's already possible to use FreeBSD+ZFS+GRUB and have this ability (in some > form). But it would great to have that "natively". > > Couple of useful links: > http://grub.enbug.org/GRUB2FreeBSDZFS ^^^^ Oh, and I hope you weren't crediting me for any of the functionality explained at the link above..? I have nothing to do with it - it's all someone else's work. In fact, I'm not too fond of the kfreebsd, kfreebsd_module, ... style of booting FreeBSD from GRUB2 personally. > http://www.mail-archive.com/grub-devel@gnu.org/msg15161.html The patch in this email is the only functionality I've ever offered to the GRUB project. Regards, Navdeep > Thanks to Navdeep for the GRUB work! > > BTW, Navdeep, was there any progress on your grub+zfsloader patch? > Or GRUB folks plainly refused it? > > -- > Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 29 21:56:06 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADB25106566B for ; Thu, 29 Apr 2010 21:56:06 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 420FE8FC16 for ; Thu, 29 Apr 2010 21:56:06 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 128FB45CDC; Thu, 29 Apr 2010 23:56:04 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1455E45684; Thu, 29 Apr 2010 23:55:59 +0200 (CEST) Date: Thu, 29 Apr 2010 23:55:56 +0200 From: Pawel Jakub Dawidek To: "hiroshi@soupacific.com" Message-ID: <20100429215556.GD2240@garage.freebsd.pl> References: <4BCD5AD7.8070502@soupacific.com> <4BCFA4C2.6000109@soupacific.com> <4BCFB1C5.5000908@soupacific.com> <4BD01800.9040901@soupacific.com> <4BD0438B.5080308@soupacific.com> <4BD0E432.1000108@soupacific.com> <20100423061521.GC1670@garage.freebsd.pl> <4BD24E16.8000302@soupacific.com> <20100424070737.GC3067@garage.freebsd.pl> <4BD2A0E5.7020506@soupacific.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6Vw0j8UKbyX0bfpA" Content-Disposition: inline In-Reply-To: <4BD2A0E5.7020506@soupacific.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: HAST configuration? 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, 29 Apr 2010 21:56:06 -0000 --6Vw0j8UKbyX0bfpA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 24, 2010 at 04:42:29PM +0900, hiroshi@soupacific.com wrote: > Thanks a lot ! >=20 > Hope to hear good news soon ! >=20 > And I am waiting for 8.0 support too. I do not push you ! I committed fix to HEAD (r207390). Could you verify if it fixes your problem? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --6Vw0j8UKbyX0bfpA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvaAGsACgkQForvXbEpPzTFTgCglDsOMe4LV6Mne5WEIf3Lo2uc oWEAoMub4rcnmN4YhHMEq+bsY7OVAcJd =lVRT -----END PGP SIGNATURE----- --6Vw0j8UKbyX0bfpA-- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 30 01:06:31 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87746106566B for ; Fri, 30 Apr 2010 01:06:31 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (warped.bluecherry.net [66.138.159.247]) by mx1.freebsd.org (Postfix) with ESMTP id 5CAD48FC0A for ; Fri, 30 Apr 2010 01:06:31 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-123-77.shv.bellsouth.net [98.67.123.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id 0688D87DC615; Thu, 29 Apr 2010 20:06:29 -0500 (CDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.4/8.14.4) with ESMTP id o3U16P39071566; Thu, 29 Apr 2010 20:06:25 -0500 (CDT) (envelope-from morganw@chemikals.org) Date: Thu, 29 Apr 2010 20:06:25 -0500 (CDT) From: Wes Morgan X-X-Sender: morganw@volatile To: Freddie Cash In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95.3 at warped X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: "Cannot replace a replacing drive" 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, 30 Apr 2010 01:06:31 -0000 On Wed, 28 Apr 2010, Freddie Cash wrote: > Going through the archives, I see that others have run into this issue, and > managed to solve it via "zpool detach". However, looking closely at the > archived messages, all the successful tests had one thing in common: 1 > drive ONLINE, 1 drive FAULTED. If a drive is online, obviously it can be > detached. In all the cases where people have been unsuccessful at fixing > this situation, 1 drive is OFFLINE, and 1 drive is FAULTED. As is our case: > What happened to the drive to fault it? From owner-freebsd-fs@FreeBSD.ORG Fri Apr 30 01:40:44 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECF6D106564A for ; Fri, 30 Apr 2010 01:40:44 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id B0D438FC19 for ; Fri, 30 Apr 2010 01:40:43 +0000 (UTC) Received: by iwn42 with SMTP id 42so11981425iwn.14 for ; Thu, 29 Apr 2010 18:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=gfN/4mUyjSk9jDmo/f4YW3Rb7Ky+MVsN3Hi85efBBsQ=; b=mU5KjmSbWyf9efrGmJU8qZsWXn5NkYt4sxi68yOPwPXRZ4O5BYoMpxREUzOZVZuE+2 w7ZdeVYmnVsyeuKMZcSdOUw0u9v9HzL9MWvyVyMFW7y3OE/77kSCDKuskBLjuWz3Nyuu yhP9RcrVewkqtkyJScy/dc6cZ8Kr/VqlmSqEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=B4JUOA+nCqtN9CRrB/NwwgVpDW/9q6h5dHzS4+ttx38nFHdmcK6TqHnULc45kXKjKS ieTtkKSm4j1eV6lnIt0OhlxqHPqyXG3JWrdXxWQtCVXQdx1m+xe/Inwt4oKaVdeHeXRW pNBH7i7pK+St9Z+0uxxQEksuq+rBI8+XJ/nUI= MIME-Version: 1.0 Received: by 10.231.176.7 with SMTP id bc7mr2066341ibb.2.1272591636176; Thu, 29 Apr 2010 18:40:36 -0700 (PDT) Received: by 10.231.18.74 with HTTP; Thu, 29 Apr 2010 18:40:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Apr 2010 18:40:36 -0700 Message-ID: From: Freddie Cash To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS: "Cannot replace a replacing drive" 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, 30 Apr 2010 01:40:45 -0000 On Thu, Apr 29, 2010 at 6:06 PM, Wes Morgan wrote: > On Wed, 28 Apr 2010, Freddie Cash wrote: > > > Going through the archives, I see that others have run into this issue, > and > > managed to solve it via "zpool detach". However, looking closely at the > > archived messages, all the successful tests had one thing in common: 1 > > drive ONLINE, 1 drive FAULTED. If a drive is online, obviously it can be > > detached. In all the cases where people have been unsuccessful at fixing > > this situation, 1 drive is OFFLINE, and 1 drive is FAULTED. As is our > case: > > > > What happened to the drive to fault it? > > Am in the process of replacing 500 GB drives with 1.5 TB drives, to increase the available storage space in the pool (process went flawlessly on the other storage server). First 3 disks in the vdev replaced without issues. 4th disk turned out to be a dud. Nothing but timeouts and read/write errors during the replace. So I popped it out, put in a different 1.5 TB drive, glabel'd it with the same name ... and the pool went "boom". Now I'm stuck with a "label/disk04" device that can't be replaced, can't be offlined, can't be detached. Tried exporting the pool, importing the pool, with and without the disk in the system. All kinds of variations on detach, online, offline, replace on the old device, the new device, the UUIDs. Nothing. [Now I know, for the future, to stress-test a drive before putting it into the pool.] I'm really hoping there's a way to recover from this, but it doesn't look like it. Will probably have to destroy/recreate the pool next week, using the 1.5 TB drives from the get-go. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Apr 30 20:51:30 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 197931065670 for ; Fri, 30 Apr 2010 20:51:30 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (warped.bluecherry.net [66.138.159.247]) by mx1.freebsd.org (Postfix) with ESMTP id D2CED8FC18 for ; Fri, 30 Apr 2010 20:51:29 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-123-77.shv.bellsouth.net [98.67.123.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id E597487DCB3A; Fri, 30 Apr 2010 15:51:26 -0500 (CDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.4/8.14.4) with ESMTP id o3UKpAtq086568; Fri, 30 Apr 2010 15:51:10 -0500 (CDT) (envelope-from morganw@chemikals.org) Date: Fri, 30 Apr 2010 15:51:10 -0500 (CDT) From: Wes Morgan X-X-Sender: morganw@volatile To: Freddie Cash In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95.3 at warped X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: "Cannot replace a replacing drive" 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, 30 Apr 2010 20:51:30 -0000 On Thu, 29 Apr 2010, Freddie Cash wrote: > On Thu, Apr 29, 2010 at 6:06 PM, Wes Morgan wrote: > > > On Wed, 28 Apr 2010, Freddie Cash wrote: > > > > > Going through the archives, I see that others have run into this issue, > > and > > > managed to solve it via "zpool detach". However, looking closely at the > > > archived messages, all the successful tests had one thing in common: 1 > > > drive ONLINE, 1 drive FAULTED. If a drive is online, obviously it can be > > > detached. In all the cases where people have been unsuccessful at fixing > > > this situation, 1 drive is OFFLINE, and 1 drive is FAULTED. As is our > > case: > > > > > > > What happened to the drive to fault it? > > > > Am in the process of replacing 500 GB drives with 1.5 TB drives, to > increase the available storage space in the pool (process went flawlessly on > the other storage server). First 3 disks in the vdev replaced without > issues. > > 4th disk turned out to be a dud. Nothing but timeouts and read/write errors > during the replace. So I popped it out, put in a different 1.5 TB drive, > glabel'd it with the same name ... and the pool went "boom". > > Now I'm stuck with a "label/disk04" device that can't be replaced, can't be > offlined, can't be detached. > > Tried exporting the pool, importing the pool, with and without the disk in > the system. All kinds of variations on detach, online, offline, replace on > the old device, the new device, the UUIDs. Can you send the output of zpool history? > I'm really hoping there's a way to recover from this, but it doesn't look > like it. Will probably have to destroy/recreate the pool next week, using > the 1.5 TB drives from the get-go. I'm sure you can still recover it. Just have some patience. From owner-freebsd-fs@FreeBSD.ORG Fri Apr 30 21:00:09 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A164B106564A for ; Fri, 30 Apr 2010 21:00:09 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (warped.bluecherry.net [66.138.159.247]) by mx1.freebsd.org (Postfix) with ESMTP id 6D2598FC13 for ; Fri, 30 Apr 2010 21:00:09 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-123-77.shv.bellsouth.net [98.67.123.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id 10E1187DC608; Fri, 30 Apr 2010 16:00:07 -0500 (CDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.4/8.14.4) with ESMTP id o3UKxwL3089114; Fri, 30 Apr 2010 15:59:58 -0500 (CDT) (envelope-from morganw@chemikals.org) Date: Fri, 30 Apr 2010 15:59:58 -0500 (CDT) From: Wes Morgan X-X-Sender: morganw@volatile To: Freddie Cash In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95.3 at warped X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: "Cannot replace a replacing drive" 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, 30 Apr 2010 21:00:09 -0000 On Fri, 30 Apr 2010, Wes Morgan wrote: > On Thu, 29 Apr 2010, Freddie Cash wrote: > > > On Thu, Apr 29, 2010 at 6:06 PM, Wes Morgan wrote: > > > > > On Wed, 28 Apr 2010, Freddie Cash wrote: > > > > > > > Going through the archives, I see that others have run into this issue, > > > and > > > > managed to solve it via "zpool detach". However, looking closely at the > > > > archived messages, all the successful tests had one thing in common: 1 > > > > drive ONLINE, 1 drive FAULTED. If a drive is online, obviously it can be > > > > detached. In all the cases where people have been unsuccessful at fixing > > > > this situation, 1 drive is OFFLINE, and 1 drive is FAULTED. As is our > > > case: > > > > > > > > > > What happened to the drive to fault it? > > > > > > Am in the process of replacing 500 GB drives with 1.5 TB drives, to > > increase the available storage space in the pool (process went flawlessly on > > the other storage server). First 3 disks in the vdev replaced without > > issues. Also, where is the original 500gb drive (#4) that you replaced? You should be able to put that drive back in and let it resilver itself to catch back up to the other devices, then cancel the replacement. From owner-freebsd-fs@FreeBSD.ORG Fri Apr 30 21:01:34 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE7A4106564A for ; Fri, 30 Apr 2010 21:01:34 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id AF9D38FC16 for ; Fri, 30 Apr 2010 21:01:33 +0000 (UTC) Received: by iwn42 with SMTP id 42so742499iwn.14 for ; Fri, 30 Apr 2010 14:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=A6pXwWj0bfgoizlsHhOYJr3TppC853nGYC9E9FvFojs=; b=UzOvZPQ6FlW++lXOAyi7ZjT6uhsqrzMfgwKOygYTH74U7rB5EPIBAZ4KqK/CZ2GiHG mLPvK2k3v8yjDC+7/JFnQWSY0VVUibBMB2B4ue+DRhdX/t2YucXu6sLJVp6B20eVDy+Z 94giQifCsXt8Ibg7/l5tz3JrwWOi7qk1ECt6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=VurkgIhJ3sFLbPHlJO9lzYQCuB1XhWKit5wqx54N270dmF3/HSxf8yTJT30LOAPjOg fL9AYpQilWCNpAV50Qhqm5UKqtAt2q29lSRwCSioX62QHEgx1JzLA0vjCx4eSy8QnWuS qHi8Dt9wkGAvhZ3BfdwIohBDTaNYfAalsmPUM= MIME-Version: 1.0 Received: by 10.231.182.211 with SMTP id cd19mr1572668ibb.55.1272661287176; Fri, 30 Apr 2010 14:01:27 -0700 (PDT) Received: by 10.231.18.74 with HTTP; Fri, 30 Apr 2010 14:01:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Apr 2010 14:01:27 -0700 Message-ID: From: Freddie Cash To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS: "Cannot replace a replacing drive" 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, 30 Apr 2010 21:01:35 -0000 On Fri, Apr 30, 2010 at 1:59 PM, Wes Morgan wrote: > On Fri, 30 Apr 2010, Wes Morgan wrote: > > > On Thu, 29 Apr 2010, Freddie Cash wrote: > > > > > On Thu, Apr 29, 2010 at 6:06 PM, Wes Morgan > wrote: > > > > > > > On Wed, 28 Apr 2010, Freddie Cash wrote: > > > > > > > > > Going through the archives, I see that others have run into this > issue, > > > > and > > > > > managed to solve it via "zpool detach". However, looking closely > at the > > > > > archived messages, all the successful tests had one thing in > common: 1 > > > > > drive ONLINE, 1 drive FAULTED. If a drive is online, obviously it > can be > > > > > detached. In all the cases where people have been unsuccessful at > fixing > > > > > this situation, 1 drive is OFFLINE, and 1 drive is FAULTED. As is > our > > > > case: > > > > > > > > > > > > > What happened to the drive to fault it? > > > > > > > > Am in the process of replacing 500 GB drives with 1.5 TB drives, to > > > increase the available storage space in the pool (process went > flawlessly on > > > the other storage server). First 3 disks in the vdev replaced without > > > issues. > > Also, where is the original 500gb drive (#4) that you replaced? You should > be able to put that drive back in and let it resilver itself to catch back > up to the other devices, then cancel the replacement. > Oooh, never thought of trying that. Makes sense. I'll see if I can do that this weekend. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Apr 30 21:03:44 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00B721065672 for ; Fri, 30 Apr 2010 21:03:44 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id B82918FC13 for ; Fri, 30 Apr 2010 21:03:43 +0000 (UTC) Received: by iwn42 with SMTP id 42so745179iwn.14 for ; Fri, 30 Apr 2010 14:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=0AIAsJObAq5W6jTo7Lk7JSZpeO1ncrQMrip8IUya5Ag=; b=U5y6AnXY8LUaWZzJGwkeOJi6XBiK26RlR7QCH0sMyRLBVY1V7xsx3w5PIveKcTKmXZ yf6VcwDHrHSR78eSlfIZAxXRaj3+TRuXbVMOY0FTd4QdAykHRoK4TgjYv8uRV94W18la Hh1O8GpRDyl/INxO3Ju+lM0aMsM9D5sQVuAtM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=pTl/q/VmmN7PDVZfRpCVpIZ9aLPrAdho0QfBQ9YY8XIeBEAI+0/3upl/g7GZ4eR7EV 8MX8QKZV+0G0k88Ti1KDbLTbk3Z1xmmEu0dbh8X4lZ0Pzj5UJtWp6HIE60U6fXFHM5hx DXJfb2hUkehhrbIe1+o5zL0V2hkuXLmlLh+po= MIME-Version: 1.0 Received: by 10.231.59.149 with SMTP id l21mr2386429ibh.80.1272661418346; Fri, 30 Apr 2010 14:03:38 -0700 (PDT) Received: by 10.231.18.74 with HTTP; Fri, 30 Apr 2010 14:03:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Apr 2010 14:03:37 -0700 Message-ID: From: Freddie Cash To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS: "Cannot replace a replacing drive" 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, 30 Apr 2010 21:03:44 -0000 On Fri, Apr 30, 2010 at 1:51 PM, Wes Morgan wrote: > On Thu, 29 Apr 2010, Freddie Cash wrote: > > On Thu, Apr 29, 2010 at 6:06 PM, Wes Morgan > wrote: > > > What happened to the drive to fault it? > > > > > > Am in the process of replacing 500 GB drives with 1.5 TB drives, to > > increase the available storage space in the pool (process went flawlessly > on > > the other storage server). First 3 disks in the vdev replaced without > > issues. > > > > 4th disk turned out to be a dud. Nothing but timeouts and read/write > errors > > during the replace. So I popped it out, put in a different 1.5 TB drive, > > glabel'd it with the same name ... and the pool went "boom". > > > > Now I'm stuck with a "label/disk04" device that can't be replaced, can't > be > > offlined, can't be detached. > > > > Tried exporting the pool, importing the pool, with and without the disk > in > > the system. All kinds of variations on detach, online, offline, replace > on > > the old device, the new device, the UUIDs. > > Can you send the output of zpool history? 2010-04-07.12:21:25 zfs destroy storage/backup@2009-11-12 2010-04-07.12:21:32 zfs destroy storage/backup@2009-11-24 2010-04-07.12:21:39 zfs destroy storage/backup@2009-11-25 2010-04-07.12:21:46 zfs destroy storage/backup@2009-11-26 2010-04-07.12:21:57 zfs destroy storage/backup@2009-11-30 2010-04-13.16:56:35 zpool replace storage label/disk01 label/disk01 2010-04-15.11:53:08 zpool offline storage label/disk02 2010-04-15.12:05:29 zpool replace storage label/disk02 label/disk02 2010-04-17.12:14:11 zpool offline storage label/disk03 2010-04-17.12:19:56 zpool replace storage label/disk03 label/disk03 2010-04-21.16:00:36 zpool offline storage label/disk04 2010-04-21.16:05:07 zpool replace storage label/disk04 label/disk04 2010-04-26.18:40:17 zpool scrub storage 2010-04-26.18:41:27 zpool clear storage 2010-04-26.18:49:58 zpool clear storage label/disk04/old 2010-04-26.18:50:05 zpool clear storage label/disk04 2010-04-26.18:50:33 zpool scrub -s storage 2010-04-26.18:50:45 zpool scrub storage 2010-04-28.08:41:58 zpool online storage label/disk04 2010-04-28.08:42:33 zpool online storage label/disk04/old 2010-04-28.08:49:27 zpool clear storage 2010-04-28.08:49:37 zpool online storage label/disk04 2010-04-28.08:54:49 zpool online storage label/disk04 2010-04-28.14:20:32 zpool export storage 2010-04-28.14:21:27 zpool import storage 2010-04-28.14:30:29 zpool export storage 2010-04-28.14:32:47 zpool import storage 2010-04-28.14:33:26 zpool export storage 2010-04-28.14:38:07 zpool import storage 2010-04-28.15:15:48 zpool upgrade storage -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Apr 30 23:43:59 2010 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD1E71065670 for ; Fri, 30 Apr 2010 23:43:59 +0000 (UTC) (envelope-from 20080111.freebsd.org@ab.ote.we.lv) Received: from mx2.nttmcl.com (MX2.nttmcl.com [216.69.68.200]) by mx1.freebsd.org (Postfix) with ESMTP id AF11F8FC1E for ; Fri, 30 Apr 2010 23:43:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx2.nttmcl.com (Postfix) with ESMTP id 672204DD9E for ; Fri, 30 Apr 2010 16:28:40 -0700 (PDT) X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.8, AWL=-2.159, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_DATE_PAST_20XX=3.188, FROM_STARTS_WITH_NUMS=1.499] autolearn=no Received: from mx2.nttmcl.com ([127.0.0.1]) by localhost (mx2.nttmcl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoxJnwm5zofb for ; Fri, 30 Apr 2010 16:28:40 -0700 (PDT) Received: from [216.69.70.67] (v6dhcp67.nttmcl.com [216.69.70.67]) by mx2.nttmcl.com (Postfix) with ESMTPS id F2C8D4DD89 for ; Fri, 30 Apr 2010 16:28:39 -0700 (PDT) Message-ID: <4BDB677B.5020205@ab.ote.we.lv> Date: Fri, 30 Apr 2010 16:27:55 -0700 From: "Eugene M. Kim" <20080111.freebsd.org@ab.ote.we.lv> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: fs@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: 8-stable ZFS ACL (NFSv4): Access disallowed when it should be by inheritance 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, 30 Apr 2010 23:43:59 -0000 Greetings, I am experimenting with NFSv4 ACLs on ZFS, and am baffled by the following behavior: --- BEGIN TRANSCRIPT --- purple# uname -a FreeBSD purple.the-7.net 8.0-STABLE FreeBSD 8.0-STABLE #1: Mon Mar 29 19:22:00 PDT 2010 ab@purple.the-7.net:/home/FreeBSD/build/RELENG_8/obj/home/FreeBSD/build/RELENG_8/src/sys/PURPLE i386 purple# id uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) purple# ls -ld . drwxr-xr-x 2 root wheel 2 Apr 30 16:15 . purple# getfacl . # file: . # owner: root # group: wheel owner@:--------------:------:deny owner@:rwxp---A-W-Co-:------:allow group@:-w-p----------:------:deny group@:r-x-----------:------:allow everyone@:-w-p---A-W-Co-:------:deny everyone@:r-x---a-R-c--s:------:allow purple# setfacl -a0 user:ab:rwxpRWcs:fi:allow . purple# getfacl . # file: . # owner: root # group: wheel user:ab:rwxp----RWc--s:f-i---:allow owner@:--------------:------:deny owner@:rwxp---A-W-Co-:------:allow group@:-w-p----------:------:deny group@:r-x-----------:------:allow everyone@:-w-p---A-W-Co-:------:deny everyone@:r-x---a-R-c--s:------:allow purple# touch root-f purple# ls -ld root-f -rw-r--r--+ 1 root wheel 0 Apr 30 16:16 root-f purple# getfacl root-f # file: root-f # owner: root # group: wheel user:ab:-wxp----------:------:deny user:ab:rwxp----RWc--s:------:allow owner@:--x-----------:------:deny owner@:rw-p---A-W-Co-:------:allow group@:-wxp----------:------:deny group@:r-------------:------:allow everyone@:-wxp---A-W-Co-:------:deny everyone@:r-----a-R-c--s:------:allow purple# sudo -u ab cat root-f purple# sudo -u ab touch root-f touch: root-f: Permission denied purple# sudo -u ab ./root-f sudo: ./root-f: command not found purple# --- END TRANSCRIPT --- The intention here is to allow read/write/append/execution of files created under the current directory (root:wheel 0755). However, as seen in the third getfacl output, the ACL of the created file (root-f) contains not just the inherited ACE (user:ab:rwxpRWcs::allow) but also another ACE (user:ab:wxp::deny) before the inherited ACE, which causes the touch(1) and execution of the created file to fail. Why does this happen? Regards, Eugene