From owner-freebsd-fs@FreeBSD.ORG Mon Feb 1 00:25:25 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 BFD841065670 for ; Mon, 1 Feb 2010 00:25:25 +0000 (UTC) (envelope-from scott@bqinternet.com) Received: from mail.bqinternet.com (mail.bqinternet.com [69.9.32.203]) by mx1.freebsd.org (Postfix) with ESMTP id 977098FC12 for ; Mon, 1 Feb 2010 00:25:25 +0000 (UTC) Received: from localhost (mail [69.9.32.203]) by mail.bqinternet.com (Postfix) with ESMTP id 0D8568405F6 for ; Mon, 1 Feb 2010 00:07:24 +0000 (GMT) Received: from mail.bqinternet.com ([69.9.32.203]) by localhost (mail.bqinternet.com [69.9.32.203]) (amavisd-new, port 10024) with ESMTP id X1I+VEAuGs6w for ; Mon, 1 Feb 2010 00:07:23 +0000 (GMT) Received: from scott-burnss-macbook-air.local (mail [69.9.32.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bqinternet.com (Postfix) with ESMTP id 6CB9E8405D7 for ; Mon, 1 Feb 2010 00:07:23 +0000 (GMT) Message-ID: <4B661B35.7050501@bqinternet.com> Date: Sun, 31 Jan 2010 19:07:17 -0500 From: Scott Burns User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Inode number treated as signed int in ffs_nodealloccg 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, 01 Feb 2010 00:25:25 -0000 Hi guys, While working with a 17TB UFS2 filesystem, g_vfs_done() was reporting write errors with negative offsets. I modified bufwrite() to have it panic on a negative bp->b_blkno so that I could trace the source of the write. The traces showed ffs_nodealloccg() as the source of the problem. The negative number is coming from the ino_to_fsba(fs, x) macro used in ffs_nodealloccg(). In this case, the x is "cg * fs->fs_ipg + cgp->cg_initediblk". The problem goes away if I cast cg as (unsigned int)cg. I imagine that this hasn't been noticed up to now since most people are not exceeding the range of a signed int, even with multi-TB filesystems. Is this issue likely to exist in other FFS code? Should I just recreate the filesystem with less inodes for now? I made a crude example program to easily demonstrate the problem: #include #include #include #include #include int main() { struct fs *fs; struct cg *cgp; int cg; fs = malloc(sizeof(struct fs)); cgp = malloc(sizeof(struct cg)); fs->fs_magic = 424935705; fs->fs_fsbtodb = 2; fs->fs_inopb = 64; fs->fs_fragshift = 3; fs->fs_ipg = 23552; fs->fs_iblkno = 56; fs->fs_fpg = 94064; cg = 96868; cgp->cg_initediblk = 21696; printf("ino_to_fsba #1: %lld\n", ino_to_fsba(fs, cg * fs->fs_ipg + cgp->cg_initediblk)); printf("ino_to_fsba #2: %lld\n", ino_to_fsba(fs, (unsigned int)cg * fs->fs_ipg + cgp->cg_initediblk)); return 0; } /* Observed output: ino_to_fsba #1: -8041719792 ino_to_fsba #2: 9111794320 */ -- Scott Burns System Administrator BQ Internet Corporation From owner-freebsd-fs@FreeBSD.ORG Mon Feb 1 04:49: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 CDC381065670 for ; Mon, 1 Feb 2010 04:49:34 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4C35C8FC15 for ; Mon, 1 Feb 2010 04:49:33 +0000 (UTC) Received: by fxm27 with SMTP id 27so114689fxm.3 for ; Sun, 31 Jan 2010 20:49:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=22A5P1934M+tofEks8jClyYYoP2yFAFjfhNWbQlGmd0=; b=JoiGrWBKKEWwCWwjT7xFVX7LKt/0RbAfgkBBPmdFu3fi/Meha1v8I1/yheNFglKwI/ +sJzcIKHafjGeoEaWWiZ2kCPNcDY9KH8a6mu8YJFc67QUt08ir/shpMo3ZN86onsK4ej Waduf3WcGVkWkuRvWNccXnTfwk4RCHC+9Mjus= 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=OtL4Lp2lIYfBkBZZ4Su7vvRbmKUkYiPzQwyO4zUl8YZLO7rpWlw2bBV9zVYWD2I+Z6 Q+NoWTkCvJlT0mwAH4zx3LSMHWfhU0erTZ22Vm0IqhqSweyt+Lie3gvV2rdlzWdWNf6N NmEwM/itE53mcxUB8tT0IVhhN46Uab8//F4Zg= MIME-Version: 1.0 Received: by 10.239.189.7 with SMTP id r7mr624607hbh.116.1264999770438; Sun, 31 Jan 2010 20:49:30 -0800 (PST) In-Reply-To: <5da0588e1001240544q61e3bebbka7ad1248343be26d@mail.gmail.com> References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> <5da0588e1001232017m6c67731fwaa1d71cd86800017@mail.gmail.com> <5da0588e1001232128w5a551674od0805c2ff0b884ad@mail.gmail.com> <5da0588e1001240544q61e3bebbka7ad1248343be26d@mail.gmail.com> Date: Sun, 31 Jan 2010 23:49:30 -0500 Message-ID: <5da0588e1001312049p36b5facam478052cc6aeb4f1d@mail.gmail.com> From: Rich To: Wes Morgan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? 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, 01 Feb 2010 04:49:35 -0000 Well, that's frustrating. I moved all the data off of that FS on the pool, onto a newly-created FS on the pool. It took a few days. I just attempted to zfs destroy the old filesystem. The command hung for 30 minutes, at which point I decided that this was likely not doing anything useful, especially since operations to all but the latest-created filesystem on the pool now hung, as well as zfs list. I got this fun thing out of /var/log/messages, too: Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni path=/dev/da5 offset=446136819712 size=8192 Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni path=/dev/da2 offset=320393101312 size=8192 Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni path=/dev/da4 offset=1231402180608 size=8192 Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni path=/dev/da5 offset=446136819712 size=8192 Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni path=/dev/da2 offset=320393101312 size=8192 Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni path=/dev/da4 offset=1231402180608 size=8192 Jan 31 23:12:05 manticore root: ZFS: zpool I/O failure, zpool=rigatoni error=86 Jan 31 23:12:05 manticore root: ZFS: vdev I/O failure, zpool=rigatoni path= offset= size= error= The last one, of course, being fascinating. Okay, how annoying. I try sysctl debug.kdb.panic=1, and it hangs. Uh-oh. I reboot physically, and the system hangs on "Mounting local filesystems..." for a long time. I power the machine off, unplug all 5 devices in that pool, and boot the machine again. It boots rapidly and fine. I export the pool (now reporting that all 5 devices were missing, unsurprisingly), power the machine off, plug the 5 devices back in, and power on. Machine boots. zpool import rigatoni succeeds. zfs list now hangs. df output shows no filesystems from that pool, and /var/log/messages got another copy of what I just pasted above. Thoughts? - Rich From owner-freebsd-fs@FreeBSD.ORG Mon Feb 1 09:04:14 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 545501065670 for ; Mon, 1 Feb 2010 09:04:14 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id EEFCF8FC0C for ; Mon, 1 Feb 2010 09:04:13 +0000 (UTC) Received: by fxm27 with SMTP id 27so232648fxm.3 for ; Mon, 01 Feb 2010 01:04:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.143.70 with SMTP id t6mr3919213fau.101.1265013696102; Mon, 01 Feb 2010 00:41:36 -0800 (PST) From: Vlad Galu Date: Mon, 1 Feb 2010 10:41:16 +0200 Message-ID: To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: What's the status of unionfs in RELENG_8 these days? 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, 01 Feb 2010 09:04:14 -0000 Hello, About a year or so ago, I'd deployed unionfs mounts for the ports directory of each jail on a server I used to nurse. However, once a week, the host system locked up. Turned out it was one of the weekly cron jobs that triggered it. Unfortunately I never got around investigating that deeper, we simply switched to nullfs. Now I've a similar scenario ahead, so I'm wondering if I could try unionfs once more. Unfortunately, the server is on a different time zone, remote debugging would be difficult, if not impossible. So, is anybody successfully using unionfs with jails? Thanks, Vlad -- Good, fast & cheap. Pick any two. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 1 10:29:23 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 09AC5106566C for ; Mon, 1 Feb 2010 10:29:23 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id BFA7B8FC14 for ; Mon, 1 Feb 2010 10:29:22 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id 616812168F4; Mon, 1 Feb 2010 12:29:19 +0200 (EET) Date: Mon, 1 Feb 2010 12:29:18 +0200 From: Jaakko Heinonen To: Scott Burns Message-ID: <20100201102918.GA2505@a91-153-117-195.elisa-laajakaista.fi> References: <4B661B35.7050501@bqinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B661B35.7050501@bqinternet.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: Inode number treated as signed int in ffs_nodealloccg 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, 01 Feb 2010 10:29:23 -0000 On 2010-01-31, Scott Burns wrote: > I imagine that this hasn't been noticed up to now since most people are > not exceeding the range of a signed int, even with multi-TB filesystems. This PR may be related to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133980 http://docs.freebsd.org/cgi/mid.cgi?20090508120355.S1497 -- Jaakko From owner-freebsd-fs@FreeBSD.ORG Mon Feb 1 11:06: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 E20CF106566C for ; Mon, 1 Feb 2010 11:06:54 +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 B60018FC17 for ; Mon, 1 Feb 2010 11:06:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o11B6sKd062778 for ; Mon, 1 Feb 2010 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o11B6rKD062776 for freebsd-fs@FreeBSD.org; Mon, 1 Feb 2010 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Feb 2010 11:06:53 GMT Message-Id: <201002011106.o11B6rKD062776@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, 01 Feb 2010 11:06:55 -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/143345 fs [ext2fs] [patch] extfs minor header cleanups to better o kern/143343 fs [zfs] bug in sunlink flag on directories 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/142872 fs [zfs] ZFS ZVOL Lockmgr Deadlock o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142594 fs [zfs] Modification time reset to 1 Jan 1970 after fsyn o kern/142558 fs [msdosfs] patch] Minor updates to fs/msdosfs headers ( 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/142271 fs [zfs] [patch] race condition on zpool create o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs(/ufs) o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141718 fs [zfs] [panic] kernel panic when 'zfs rename' is used o o kern/141685 fs [zfs] zfs corruption on adaptec 5805 raid controller 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/141257 fs [gvinum] No puedo crear RAID5 por SW con gvinum o kern/141235 fs [disklabel] 8.0 no longer provides /dev entries for al o kern/141177 fs [zfs] fsync() on FIFO causes panic() on zfs 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/140682 fs [netgraph] [panic] random panic in netgraph o kern/140661 fs [zfs] /boot/loader fails to work on a GPT/ZFS-only sys 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/138524 fs [msdosfs] disks and usb flashes/cards with Russian lab 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/135594 fs [zfs] Single dataset unresponsive with Samba 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/133980 fs [panic] [ffs] panic: ffs_valloc: dup alloc 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/131995 fs [nfs] Failure to mount NFSv4 server 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 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 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/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/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/18874 fs [2TB] 32bit NFS servers export wrong negative values t 164 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 1 12:50: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 3DAF8106566B for ; Mon, 1 Feb 2010 12:50:38 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id D6C928FC0A for ; Mon, 1 Feb 2010 12:50:37 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o11CoU69027201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Feb 2010 13:50:30 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id o11CoNvF032797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2010 13:50:23 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o11CoNWW031515; Mon, 1 Feb 2010 13:50:23 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o11CoLQP031514; Mon, 1 Feb 2010 13:50:21 +0100 (CET) (envelope-from ticso) Date: Mon, 1 Feb 2010 13:50:21 +0100 From: Bernd Walter To: Rich Message-ID: <20100201125020.GU21848@cicely7.cicely.de> References: <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> <5da0588e1001232017m6c67731fwaa1d71cd86800017@mail.gmail.com> <5da0588e1001232128w5a551674od0805c2ff0b884ad@mail.gmail.com> <5da0588e1001240544q61e3bebbka7ad1248343be26d@mail.gmail.com> <5da0588e1001312049p36b5facam478052cc6aeb4f1d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5da0588e1001312049p36b5facam478052cc6aeb4f1d@mail.gmail.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.020, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 12:50:38 -0000 On Sun, Jan 31, 2010 at 11:49:30PM -0500, Rich wrote: > Well, that's frustrating. > > I moved all the data off of that FS on the pool, onto a newly-created > FS on the pool. It took a few days. > > I just attempted to zfs destroy the old filesystem. > > The command hung for 30 minutes, at which point I decided that this > was likely not doing anything useful, especially since operations to > all but the latest-created filesystem on the pool now hung, as well as > zfs list. > > I got this fun thing out of /var/log/messages, too: > Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni > path=/dev/da5 offset=446136819712 size=8192 > Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni > path=/dev/da2 offset=320393101312 size=8192 > Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni > path=/dev/da4 offset=1231402180608 size=8192 > Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni > path=/dev/da5 offset=446136819712 size=8192 > Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni > path=/dev/da2 offset=320393101312 size=8192 > Jan 31 23:12:05 manticore root: ZFS: checksum mismatch, zpool=rigatoni > path=/dev/da4 offset=1231402180608 size=8192 > Jan 31 23:12:05 manticore root: ZFS: zpool I/O failure, zpool=rigatoni error=86 > Jan 31 23:12:05 manticore root: ZFS: vdev I/O failure, zpool=rigatoni > path= offset= size= error= > > The last one, of course, being fascinating. > > Okay, how annoying. I try sysctl debug.kdb.panic=1, and it hangs. Uh-oh. > > I reboot physically, and the system hangs on "Mounting local > filesystems..." for a long time. > > I power the machine off, unplug all 5 devices in that pool, and boot > the machine again. It boots rapidly and fine. > > I export the pool (now reporting that all 5 devices were missing, > unsurprisingly), power the machine off, plug the 5 devices back in, > and power on. > > Machine boots. zpool import rigatoni succeeds. zfs list now hangs. df > output shows no filesystems from that pool, and /var/log/messages got > another copy of what I just pasted above. I have had a strange corruption with an older FreeBSD version after a panic one day. On boot it excercised the harddisks for more than 20 hours before I finally gave up. The "solution" was to import the pool and manually mount the unbroken volumes. Disk excercise startet only when mounting the broken FS. It was possible to clone the most recent snapshot of the broken filesystem and use this, which was good because it was a few hours more recent than the last backup. I never deleted the broken FS, because the machine was already in transition to be replaced. At least you might be able to read the correct filesystems by hand mounting and have the pool available, which might allow trying a delete again. But I'm not sure if zfs import allows importing without mounting. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 1 16:07:24 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 8AE0F1065672 for ; Mon, 1 Feb 2010 16:07:24 +0000 (UTC) (envelope-from pathiaki2@yahoo.com) Received: from web110511.mail.gq1.yahoo.com (web110511.mail.gq1.yahoo.com [67.195.8.116]) by mx1.freebsd.org (Postfix) with SMTP id 5618C8FC12 for ; Mon, 1 Feb 2010 16:07:24 +0000 (UTC) Received: (qmail 32750 invoked by uid 60001); 1 Feb 2010 16:07:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1265040443; bh=UqEGqiw0cy8xoELf80IvCL8dnVJmNJE6OP72ugDezJQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1sdAscpeW7PpXvWGf8dwFCrU79W/f8eE+ikWfyvR2LpTD4NuHuJmkgfh212t0ZoqW3JgdyJ8Na6cILqCbVIzHjBvy0WuoVKVH1S5GOOainWQJKqv/gZolLQ+dhq4khpGal6UuOxP3/o03HYoTh2blNQQvONaBUxfPE7muc7GQlk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LwkZheRtkOtepacC27Tqf76VA2oAmcRB1yFFU52JV8ydHLCSG6NBwwyL3dzgKzdBvgTGf7MegbIla0TE3W6ByMvRrxzSuWfOnY8vu69rQRC3jiqm8M8/Y5pf4L0rVn6yvIUMaYRXRu4I/WvVGTIpiknKeEQgxg1U9iC92nuafWc=; Message-ID: <845421.32713.qm@web110511.mail.gq1.yahoo.com> X-YMail-OSG: z8Q.JVIVM1mgTaRy6P16LN1mjWbk49kU.MgrX7iDU64qAw7TaOmaPUhkdAu_465J3EYMQkIAe80AdbGBQTVEZzcNA1QriFP5TrxOzfmkV0cFzMa92gm6IllbzN1GdnHQYx0cM4ilCC.9hCSI1g6xH5LJk36xYnchv5vWhTPglaMZPP4e7IipumsfzG4MM5jOjkMbS4j3aVdD5BUoIrrjUVoVO5hRzq.EDbRXQpoRK9k1vXCege02K1Ju6tride6QyHnIFTGIvjox84M6luX1FpFNhsNaK1CSW_gdfewh4h6HU3aLhwuOQvMA.5.eWU.w6f1wS0ZHQDiW5PITTNN1K.WNroNzBYnKm6sWpzm0oEceUDXtpB55KFTE1wTXZZVSHQudJszyTEmB.rzaWQ-- Received: from [71.174.61.120] by web110511.mail.gq1.yahoo.com via HTTP; Mon, 01 Feb 2010 08:07:23 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <419976.64363.qm@web110515.mail.gq1.yahoo.com> <422431.76479.qm@web110504.mail.gq1.yahoo.com> <529238.22926.qm@web110513.mail.gq1.yahoo.com> <377667.81874.qm@web110504.mail.gq1.yahoo.com> <4B61D668.3020703@bellanet.org> <539498.51342.qm@web110502.mail.gq1.yahoo.com> Date: Mon, 1 Feb 2010 08:07:23 -0800 (PST) From: Paul Pathiakis To: Paul Pathiakis , Graham Todd In-Reply-To: <539498.51342.qm@web110502.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS - scrub lead to corruption? 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, 01 Feb 2010 16:07:24 -0000 **************************************************************************** Graham, Thanks for the info. I've realized something that is... disconcerting. (I had found that article but I don't think the FreeBSD zdb is as robust with features.) So, I did a quick install of a base OS. I've backed up everything in /usr that doesn't cause a crash (it's only /usr/bin, /usr/share, and /usr/obj files) onto the new pool. Many various files in directories and sub-sub-sub-sub... dirs in /usr have files in them that if you touch them *CRASH* I'm going to zfs destroy the /usr partition and all the subpartitions and recreate it. I'll restore everything from the new OS /usr. From there, I'll change my pool mountpoints back to the norm and I will see if I can make the world and install it. (I'm also going to upgrade the firmware on the drives as well. I'm going to see if Seagate release a version later than the one I have for the 1500 GB drives) I'll give the list an update after this. Paul ######################################################### Hi all! Well, I got it to work. I went back to my reference link from the wiki.freebsd.org/ZFS site. I installed the pmbr and gptzfsboot onto partition 'p1' on both disks of the mirror. (don't know if that's necessary, done as a CYA) I used zfs set mountpoint=/{pool mount} pool/mount for all the subdirs that were necessary. I cvsup'd from the booted system to the / //{usr, var,} I then cd into /{pool}/usr/src. I set DESTDIR to be /{pool}/usr/src make buildworld make buildkernel make installkernel make installworld (scary but had to be) THIS IS IMPORTANT!!! You need a zfspool.cache file in //boot/zfs dir. So, move it to a .old file in the booted filesystem and perform a: zpool export && zpool import Move this file to //boot/zfs. Move the old one back. Use zfs set mountpoint= commands to put all the pools back to the correct hierarchy so ZFS can mount them properly on reboot. I believe this is everything. I'm up and running and now understand a lot more about the new zfs boot process and zfs requirements. After all this, everything seems to be working fine. I'm going to cvsup STABLE and ports and rebuild the machine. P. PS - Anybody know how to remove some permanent errors I have? Once I zpool status, it showed 10 corrupt files, I copied stuff from back up and now says everything's fine but the errors exist (no longer paths) on the disk at 10 separate addresses. _______________________________________________ freebsd-fs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Feb 1 20:36: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 3EECF106566C; Mon, 1 Feb 2010 20:36:36 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [64.81.247.49]) by mx1.freebsd.org (Postfix) with ESMTP id 20F3C8FC08; Mon, 1 Feb 2010 20:36:35 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id o11KaXLE038927; Mon, 1 Feb 2010 12:36:33 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201002012036.o11KaXLE038927@chez.mckusick.com> To: Jaakko Heinonen In-reply-to: <20100201102918.GA2505@a91-153-117-195.elisa-laajakaista.fi> Date: Mon, 01 Feb 2010 12:36:33 -0800 From: Kirk McKusick Cc: freebsd-fs@freebsd.org Subject: Re: Inode number treated as signed int in ffs_nodealloccg 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, 01 Feb 2010 20:36:36 -0000 > Date: Mon, 1 Feb 2010 12:29:18 +0200 > From: Jaakko Heinonen > To: Scott Burns > Cc: freebsd-fs@freebsd.org > Subject: Re: Inode number treated as signed int in ffs_nodealloccg > > On 2010-01-31, Scott Burns wrote: > > I imagine that this hasn't been noticed up to now since most people are > > not exceeding the range of a signed int, even with multi-TB filesystems. > > This PR may be related to this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133980 > http://docs.freebsd.org/cgi/mid.cgi?20090508120355.S1497 > > -- > Jaakko Thanks for that pointer. I will look into getting Scott Burns fix into the tree which should correct it. I will also ensure that newfs scales back the number of inodes per cylinder group to keep the total number under 2^32. The long-term solution is to go to 64-bit inode numbers, but that will have to wait for a major filesystem revision. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Tue Feb 2 13:51:27 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 7B393106566B for ; Tue, 2 Feb 2010 13:51:27 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id CAE948FC21 for ; Tue, 2 Feb 2010 13:51:26 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id B5E4E175F; Tue, 2 Feb 2010 14:32:31 +0100 (CET) Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vOcPNwNtdnm; Tue, 2 Feb 2010 14:32:29 +0100 (CET) Received: from [192.168.3.42] (archer.yomi.darkbsd.org [192.168.3.42]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id 9310C1758; Tue, 2 Feb 2010 14:32:27 +0100 (CET) Message-ID: <4B682972.6030604@darkbsd.org> Date: Tue, 02 Feb 2010 22:32:34 +0900 From: Stephane LAPIE User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-hardware@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig30EC70D03E772944CD83A3F7" Cc: Subject: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE 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, 02 Feb 2010 13:51:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig30EC70D03E772944CD83A3F7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello lists, I have a case of kernel panic that can be consistently reproduced, and=20 which I guess is related to the hardware I'm using (Marvell controllers, = check my pciconf -lv output below). The kernel panic message is always, consistently, the following : Sleeping thread (tid 100021, pid 0) owns a non-sleepable lock in the following cases (both on Marvell PCI-X SATA controllers) : - Bad disk failing one too much DMA read/flush/write and getting=20 disconnected by the system (it has SMART indicators reporting at least=20 200 bad sectors, and still rising weekly); This is how I noticed it. - When I simply unplug one disk, to replace it. It should also be noted=20 my system freezes upon atacontrol reinit'ing the concerned ata channel. Unplugging for instance an USB drive that belongs to the pool doesn't=20 provoke this effect. Just sharing in case there is anyone here who could provide pointers or=20 insight. Thanks for your time, --> ZFS pool structure : NAME STATE READ WRITE CKSUM prana DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 spare DEGRADED 0 0 0 ad16 ONLINE 0 0 0 ad16 ONLINE 0 0 0 ad30 ONLINE 0 0 0 ad28 ONLINE 0 0 0 ad18 ONLINE 0 0 0 ad14 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad26 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad20 ONLINE 0 0 0 ad22 ONLINE 0 0 0 ad24 ONLINE 0 0 0 ad32 ONLINE 0 0 0 ad34 ONLINE 0 0 0 cache ad12 ONLINE 0 0 0 ad37 ONLINE 0 0 0 spares da0 AVAIL da1 AVAIL --> pciconf -lv output : hostb0@pci0:0:0:0: class=3D0x060000 card=3D0xd98015d9 chip=3D0x29e08086=20 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'X38/X48 (Bearlake) Processor to I/O Controller' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:6:0: class=3D0x060400 card=3D0xd98015d9 chip=3D0x29e98086=20 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'X38/X48 (Bearlake) PCIe Root Port 2' class =3D bridge subclass =3D PCI-PCI em2@pci0:0:25:0: class=3D0x020000 card=3D0x10bd15d9 chip=3D0x10bd8086 rev= =3D0x02=20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class =3D network subclass =3D ethernet uhci0@pci0:0:26:0: class=3D0x0c0300 card=3D0xd98015d9 chip=3D0x29378086=20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host=20 Controller' class =3D serial bus subclass =3D USB uhci1@pci0:0:26:1: class=3D0x0c0300 card=3D0xd98015d9 chip=3D0x29388086=20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host=20 Controller' class =3D serial bus subclass =3D USB uhci2@pci0:0:26:2: class=3D0x0c0300 card=3D0xd98015d9 chip=3D0x29398086=20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host=20 Controller' class =3D serial bus subclass =3D USB ehci0@pci0:0:26:7: class=3D0x0c0320 card=3D0xd98015d9 chip=3D0x293c8086=20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host=20 Controller' class =3D serial bus subclass =3D USB pcib4@pci0:0:28:0: class=3D0x060400 card=3D0xd98015d9 chip=3D0x29408086=20 rev=3D0x02 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) PCIe Root Port 1' class =3D bridge subclass =3D PCI-PCI uhci3@pci0:0:29:0: class=3D0x0c0300 card=3D0xd98015d9 chip=3D0x29348086=20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host=20 Controller' class =3D serial bus subclass =3D USB uhci4@pci0:0:29:1: class=3D0x0c0300 card=3D0xd98015d9 chip=3D0x29358086=20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host=20 Controller' class =3D serial bus subclass =3D USB uhci5@pci0:0:29:2: class=3D0x0c0300 card=3D0xd98015d9 chip=3D0x29368086=20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB Universal Host=20 Controller' class =3D serial bus subclass =3D USB ehci1@pci0:0:29:7: class=3D0x0c0320 card=3D0xd98015d9 chip=3D0x293a8086=20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) USB2 Enhanced Host=20 Controller' class =3D serial bus subclass =3D USB pcib6@pci0:0:30:0: class=3D0x060401 card=3D0xd98015d9 chip=3D0x244e8086=20 rev=3D0x92 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub=20 Interface to PCI Bridge' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:31:0: class=3D0x060100 card=3D0xd98015d9 chip=3D0x29168086=20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IR (ICH9R) LPC Interface Controller' class =3D bridge subclass =3D PCI-ISA ahci0@pci0:0:31:2: class=3D0x010601 card=3D0xd98015d9 chip=3D0x29228086=20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) 6 port SATA AHCI Control= ler' class =3D mass storage subclass =3D SATA ichsmb0@pci0:0:31:3: class=3D0x0c0500 card=3D0xd98015d9 chip=3D0x29308086= =20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) SMBus Controller' class =3D serial bus subclass =3D SMBus none0@pci0:0:31:6: class=3D0x118000 card=3D0x000015d9 chip=3D0x29328086=20 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801IB/IR/IH (ICH9 Family) Thermal Subsystem' class =3D dasp pcib2@pci0:3:0:0: class=3D0x060400 card=3D0x00000000 chip=3D0x03408086=20 rev=3D0x09 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '41210 [Lanai] Serial to Parallel PCI Bridge A-segmen= t=20 Bridge' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:3:0:2: class=3D0x060400 card=3D0x00000000 chip=3D0x03418086=20 rev=3D0x09 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '41210 [Lanai] Serial to Parallel PCI Bridge B-segmen= t=20 Bridge' class =3D bridge subclass =3D PCI-PCI em0@pci0:4:4:0: class=3D0x020000 card=3D0x108a8086 chip=3D0x108a8086 rev=3D= 0x03=20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'PRO/1000 P' class =3D network subclass =3D ethernet em1@pci0:4:4:1: class=3D0x020000 card=3D0x108a8086 chip=3D0x108a8086 rev=3D= 0x03=20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'PRO/1000 P' class =3D network subclass =3D ethernet pcib5@pci0:6:0:0: class=3D0x060400 card=3D0x00000000 chip=3D0x032c8086=20 rev=3D0x09 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'PCI Express-to-PCI Express Bridge (6702PXH)' class =3D bridge subclass =3D PCI-PCI ioapic0@pci0:6:0:1: class=3D0x080020 card=3D0xd98015d9 chip=3D0x03268086 = rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '6700/6702PXH I/OxAPIC Interrupt Controller A' class =3D base peripheral subclass =3D interrupt controller atapci0@pci0:7:1:0: class=3D0x010000 card=3D0x11ab11ab chip=3D0x608111ab = rev=3D0x09 hdr=3D0x00 vendor =3D 'Marvell Semiconductor (Was: Galileo Technology Ltd)'= device =3D 'MV88SX6081 8-port SATA II PCI-X Controller' class =3D mass storage subclass =3D SCSI atapci1@pci0:7:7:0: class=3D0x010000 card=3D0x11ab11ab chip=3D0x608111ab = rev=3D0x09 hdr=3D0x00 vendor =3D 'Marvell Semiconductor (Was: Galileo Technology Ltd)'= device =3D 'MV88SX6081 8-port SATA II PCI-X Controller' class =3D mass storage subclass =3D SCSI em3@pci0:17:0:0: class=3D0x020000 card=3D0x10128086 chip=3D0x10128086 rev= =3D0x01=20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Dual Port Gigabit Ethernet Controller (Fiber) (82546= EB)' class =3D network subclass =3D ethernet em4@pci0:17:0:1: class=3D0x020000 card=3D0x10128086 chip=3D0x10128086 rev= =3D0x01=20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Dual Port Gigabit Ethernet Controller (Fiber) (82546= EB)' class =3D network subclass =3D ethernet vgapci0@pci0:17:1:0: class=3D0x030000 card=3D0x63261039 chip=3D0x63261039= =20 rev=3D0x0b hdr=3D0x00 vendor =3D 'Silicon Integrated Systems (SiS)' device =3D 'SiS6326 GUI Accelerator' class =3D display subclass =3D VGA fwohci0@pci0:17:3:0: class=3D0x0c0010 card=3D0xba8015d9 chip=3D0x8023104c= =20 rev=3D0x00 hdr=3D0x00 vendor =3D 'Texas Instruments (TI)' device =3D 'IEEE1394a-2000 OHCI PHY/Link-Layer Ctrlr (TSB43AB21/= A)' class =3D serial bus subclass =3D FireWire atapci2@pci0:17:4:0: class=3D0x010185 card=3D0x82131283 chip=3D0x82131283= =20 rev=3D0x00 hdr=3D0x00 vendor =3D 'Integrated Technology Express (ITE) Inc' device =3D 'IDE Controller (IT8213F)' class =3D mass storage subclass =3D ATA --> dmesg output : Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #11: Thu Jan 14 21:05:32 JST 2010 =20 darksoul@eirei-no-za.yomi.darkbsd.org:/usr/storage/tech/eirei-no-za.yomi.= darkbsd.org/usr/obj/usr/storage/tech/eirei-no-za.yomi.darkbsd.org/usr/src= /sys/DARK-2009KERN=20 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz (2666.68-MHz=20 K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x1067a Stepping =3D 10 =20 Features=3D0xbfebfbff =20 Features2=3D0x408e3fd AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 8589934592 (8192 MB) avail memory =3D 8257941504 (7875 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ichwd module loaded iscsi: version 2.1.0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 6.0 on pci0 pci3: on pcib1 pcib2: at device 0.0 on pci3 pci4: on pcib2 em0: port 0x2000-0x203f=20 mem 0xdfd80000-0xdfd9ffff,0xdfd00000-0xdfd3ffff irq 16 at device 4.0 on p= ci4 em0: [FILTER] em0: Ethernet address: 00:0e:0c:70:7d:1e em1: port 0x2040-0x207f=20 mem 0xdfda0000-0xdfdbffff,0xdfd40000-0xdfd7ffff irq 17 at device 4.1 on p= ci4 em1: [FILTER] em1: Ethernet address: 00:0e:0c:70:7d:1f pcib3: at device 0.2 on pci3 pci5: on pcib3 em2: port 0x1820-0x183f=20 mem 0xdff00000-0xdff1ffff,0xdff20000-0xdff20fff irq 16 at device 25.0 on = pci0 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:30:48:de:84:88 uhci0: port 0x1840-0x185f irq 16 at = device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1860-0x187f irq 17 at = device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1880-0x189f irq 18 at = device 26.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem=20 0xdff22800-0xdff22bff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib4: irq 16 at device 28.0 on pci0 pci6: on pcib4 pcib5: at device 0.0 on pci6 pci7: on pcib5 atapci0: port 0x3000-0x30ff mem=20 0xdf200000-0xdf2fffff irq 24 at device 1.0 on pci7 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] ata8: on atapci0 ata8: [ITHREAD] ata9: on atapci0 ata9: [ITHREAD] atapci1: port 0x3400-0x34ff mem=20 0xdf300000-0xdf3fffff irq 28 at device 7.0 on pci7 atapci1: [ITHREAD] ata10: on atapci1 ata10: [ITHREAD] ata11: on atapci1 ata11: [ITHREAD] ata12: on atapci1 ata12: [ITHREAD] ata13: on atapci1 ata13: [ITHREAD] ata14: on atapci1 ata14: [ITHREAD] ata15: on atapci1 ata15: [ITHREAD] ata16: on atapci1 ata16: [ITHREAD] ata17: on atapci1 ata17: [ITHREAD] uhci3: port 0x18a0-0x18bf irq 23 at = device 29.0 on pci0 uhci3: [ITHREAD] usbus4: on uhci3 uhci4: port 0x18c0-0x18df irq 22 at = device 29.1 on pci0 uhci4: [ITHREAD] usbus5: on uhci4 uhci5: port 0x18e0-0x18ff irq 18 at = device 29.2 on pci0 uhci5: [ITHREAD] usbus6: on uhci5 ehci1: mem=20 0xdff22c00-0xdff22fff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib6: at device 30.0 on pci0 pci17: on pcib6 em3: port 0x4080-0x40bf=20 mem 0xdfe00000-0xdfe1ffff irq 20 at device 0.0 on pci17 em3: [FILTER] em3: Ethernet address: 00:07:e9:0f:a3:80 em4: port 0x40c0-0x40ff=20 mem 0xdfe20000-0xdfe3ffff irq 21 at device 0.1 on pci17 em4: [FILTER] em4: Ethernet address: 00:07:e9:0f:a3:81 vgapci0: port 0x4000-0x407f mem=20 0xde800000-0xdeffffff,0xdfe40000-0xdfe4ffff at device 1.0 on pci17 fwohci0: mem=20 0xdfe54000-0xdfe547ff,0xdfe50000-0xdfe53fff irq 22 at device 3.0 on pci17= fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:30:48:00:00:20:42:f6 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:30:48:20:42:f6 fwe0: Ethernet address: 02:30:48:20:42:f6 fwip0: on firewire0 fwip0: Firewire address: 00:30:48:00:00:20:42:f6 @ 0xfffe00000000, S400, = maxrec 2048 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x799820 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D1,=20 CYCLEMASTER mode atapci2: port=20 0x4420-0x4427,0x4414-0x4417,0x4418-0x441f,0x4410-0x4413,0x4400-0x440f=20 irq 23 at device 4.0 on pci17 atapci2: [ITHREAD] ata18: on atapci2 ata18: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port=20 0x1c70-0x1c77,0x1c64-0x1c67,0x1c68-0x1c6f,0x1c60-0x1c63,0x1c00-0x1c1f=20 mem 0xdff22000-0xdff227ff irq 17 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] ichsmb0: port 0x1100-0x111f mem=20 0xdff23000-0xdff230ff irq 17 at device 31.3 on pci0 ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (115200,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 ichwd0: on isa0 ichwd0: Intel ICH9R watchdog timer (ICH9 or equivalent) orm0: at iomem=20 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xcf7ff,0xcf800-0xd5fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0= ZFS filesystem version 14 ZFS storage pool version 14 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle firewire0: 1 nodes, maxhop <=3D 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ad4: 1430799MB at ata2-master UDMA100 SATA 3G= b/s ad6: 1430799MB at ata3-master UDMA100 SATA 3G= b/s ad8: 1430799MB at ata4-master UDMA100 SATA 3G= b/s ad10: 1430799MB at ata5-master UDMA100 SATA=20 3Gb/s ad12: 61136MB at ata6-master UDMA100 SATA 3Gb/s uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered ad14: 1430799MB at ata7-master UDMA100 SATA=20 3Gb/s ad16: 1430799MB at ata8-master UDMA100 SATA=20 3Gb/s ad18: 1430799MB at ata9-master UDMA100 SATA=20 3Gb/s ad20: 1430799MB at ata10-master UDMA100 SATA = 3Gb/s ad22: 1430799MB at ata11-master UDMA100 SATA = 3Gb/s ad24: 1430799MB at ata12-master UDMA100 SATA = 3Gb/s ad26: 1430799MB at ata13-master UDMA100 SATA = 3Gb/s ad28: 1430799MB at ata14-master UDMA100 SATA = 3Gb/s ad30: 1430799MB at ata15-master UDMA100 SATA = 3Gb/s ad32: 1430799MB at ata16-master UDMA100 SATA = 3Gb/s ad34: 1430799MB at ata17-master UDMA100 SATA = 3Gb/s ata18: DMA limited to UDMA33, controller found non-ATA66 cable ad36: 3823MB at ata18-master UDMA33 ad37: 61136MB at ata18-slave UDMA133 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen0.2: at usbus0 uhub8: on usb= us0 SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from zfs:prana uhub8: 3 ports with 2 removable, bus powered ugen0.3: at usbus0 ukbd0: =20 on usbus0 kbd2 at ukbd0 em1: link state changed to UP em0: link state changed to UP ad36: FAILURE - SMART status=3D51 error=3D4 ugen7.2: at usbus7 uhub9: on=20 usbus7 uhub9: 4 ports with 4 removable, self powered ugen7.3: at usbus7 uhub10: on=20 usbus7 uhub10: 4 ports with 4 removable, self powered ugen7.4: at usbus7 umass0: on usbus7 umass0: SCSI over Bulk-Only; quirks =3D 0x0000 umass0:6:0:-1: Attached to scbus6 da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 da0: Fixed Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enig30EC70D03E772944CD83A3F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktoKXYACgkQ24Ql8u6TF2MnggCg4yC6QL/HesQUk9VreOfbBd8g XXMAnivUDonClpkmbv1dxbWB8NAw674v =Jp8W -----END PGP SIGNATURE----- --------------enig30EC70D03E772944CD83A3F7-- From owner-freebsd-fs@FreeBSD.ORG Tue Feb 2 13:57:02 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 AF4CB1065698; Tue, 2 Feb 2010 13:57:02 +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 A679D8FC13; Tue, 2 Feb 2010 13:57:01 +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 PAA16976; Tue, 02 Feb 2010 15:56:57 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B682F29.90505@icyb.net.ua> Date: Tue, 02 Feb 2010 15:56:57 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Stephane LAPIE References: <4B682972.6030604@darkbsd.org> In-Reply-To: <4B682972.6030604@darkbsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE 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, 02 Feb 2010 13:57:02 -0000 on 02/02/2010 15:32 Stephane LAPIE said the following: > I have a case of kernel panic that can be consistently reproduced, and > which I guess is related to the hardware I'm using (Marvell controllers, > check my pciconf -lv output below). > > The kernel panic message is always, consistently, the following : > > Sleeping thread (tid 100021, pid 0) owns a non-sleepable lock I probably won't be able to help you, but to kickstart debugging could you please run 'procstat -t 0' and determine what kernel thread has tid 100021 on your system? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Feb 2 14:04:08 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 20B42106566B; Tue, 2 Feb 2010 14:04:08 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7BDB8FC29; Tue, 2 Feb 2010 14:04:07 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id 50C141797; Tue, 2 Feb 2010 15:04:01 +0100 (CET) Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y+82KTzNtJr; Tue, 2 Feb 2010 15:03:59 +0100 (CET) Received: from [192.168.3.42] (archer.yomi.darkbsd.org [192.168.3.42]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id E885F178F; Tue, 2 Feb 2010 15:03:57 +0100 (CET) Message-ID: <4B6830CF.9070102@darkbsd.org> Date: Tue, 02 Feb 2010 23:03:59 +0900 From: Stephane LAPIE User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andriy Gapon References: <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua> In-Reply-To: <4B682F29.90505@icyb.net.ua> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB7914B7431170113956FAFAA" Cc: freebsd-fs@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE 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, 02 Feb 2010 14:04:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB7914B7431170113956FAFAA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 02/02/2010 15:32 Stephane LAPIE said the following: >> I have a case of kernel panic that can be consistently reproduced, and= >> which I guess is related to the hardware I'm using (Marvell controller= s, >> check my pciconf -lv output below). >> >> The kernel panic message is always, consistently, the following : >> >> Sleeping thread (tid 100021, pid 0) owns a non-sleepable lock >=20 > I probably won't be able to help you, but to kickstart debugging could = you please > run 'procstat -t 0' and determine what kernel thread has tid 100021 on = your system? Thanks for the tip. I will keep that one in mind, as I was wondering how = you looked up individual threads. # procstat -t 0 | grep 100021 0 100021 kernel thread taskq 1 92 sleep - Is that the "kernel task queue" handler ? --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enigB7914B7431170113956FAFAA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktoMNgACgkQ24Ql8u6TF2PRWwCfW0dbLdl/RD5Jw1qMRZ6Ys064 Zd0AnjTX6k5k1XERp0WZuHJBYjDzKuiw =SCJh -----END PGP SIGNATURE----- --------------enigB7914B7431170113956FAFAA-- From owner-freebsd-fs@FreeBSD.ORG Tue Feb 2 15:50:55 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 7DBAE1065670; Tue, 2 Feb 2010 15:50:55 +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 901278FC16; Tue, 2 Feb 2010 15:50:54 +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 RAA19204; Tue, 02 Feb 2010 17:50:50 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B6849DA.5080303@icyb.net.ua> Date: Tue, 02 Feb 2010 17:50:50 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Stephane LAPIE References: <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua> <4B6830CF.9070102@darkbsd.org> In-Reply-To: <4B6830CF.9070102@darkbsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE 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, 02 Feb 2010 15:50:55 -0000 on 02/02/2010 16:03 Stephane LAPIE said the following: > Andriy Gapon wrote: >> on 02/02/2010 15:32 Stephane LAPIE said the following: >>> I have a case of kernel panic that can be consistently reproduced, and >>> which I guess is related to the hardware I'm using (Marvell controllers, >>> check my pciconf -lv output below). >>> >>> The kernel panic message is always, consistently, the following : >>> >>> Sleeping thread (tid 100021, pid 0) owns a non-sleepable lock >> >> I probably won't be able to help you, but to kickstart debugging could >> you please >> run 'procstat -t 0' and determine what kernel thread has tid 100021 on >> your system? > > Thanks for the tip. I will keep that one in mind, as I was wondering how > you looked up individual threads. > > # procstat -t 0 | grep 100021 > 0 100021 kernel thread taskq 1 92 sleep - > > Is that the "kernel task queue" handler ? This taskqueue "taskqueue_thread" which is used to schedule tasks in many places. I would guess that one of those tasks leaked a lock. Probably it's best to configure system for crashdumps to a reliable storage and then try to examine a dump with kgdb to see what lock we have here. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Feb 2 16:12:42 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 A46ED106566C for ; Tue, 2 Feb 2010 16:12:42 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 2C10A8FC13 for ; Tue, 2 Feb 2010 16:12:41 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o12GCcZE003944; Tue, 2 Feb 2010 17:12:40 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 8D5BB24; Tue, 2 Feb 2010 17:12:38 +0100 (CET) Date: Tue, 2 Feb 2010 17:12:38 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Gerrit =?ISO-8859-1?Q?K=FChn?= Message-Id: <20100202171238.7694c19e.gerrit@pmp.uni-hannover.de> In-Reply-To: <20091112092630.e7cd6836.gerrit@pmp.uni-hannover.de> References: <20091106094734.4b056899.gerrit@pmp.uni-hannover.de> <4AF4123A.4080301@andric.com> <20091106231440.4f0f2cbb.gerrit@pmp.uni-hannover.de> <4AF4AAFF.2080104@jrv.org> <20091109101255.e81774e4.gerrit@pmp.uni-hannover.de> <4AF98032.9050808@bellanet.org> <20091110164622.6bc7aca1.gerrit@pmp.uni-hannover.de> <20091112092630.e7cd6836.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.2.160320 Cc: freebsd-fs@freebsd.org Subject: Re: trace for zfs panic mounting fs after crash with RC2 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, 02 Feb 2010 16:12:42 -0000 On Thu, 12 Nov 2009 09:26:30 +0100 Gerrit K=FChn wrote about Re: trace for zfs panic mounting fs after crash with RC2: AB> Perhaps some of the links on the following post on zfs-discuss may AB> help: AB> http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg26704.html GK> Interesting stuff, thanks. GK> At a first glance I do not see an easy way to roll back my pool to a GK> slightly previous (consistent) state, but all the posts state that it GK> is possible. I guess I have to dive into this a bit deeper. "zpool GK> clear -F" definitely would be the easier-to-use solution. AB> Another option would be to boot from OpenSolaris LiveCD that AB> contains latest zfs changes, import your pool there, fix, export AB> and then re-import it on FreeBSD. Make sure you don't upgrade your AB> pool while running OpenSolaris. GK> Uh, yes, not really an option in this case, I guess. Unless I buy an GK> additional external CD drive and stuff. But thanks for the hint, GK> anyway. I will have a look around how difficult it is to get recent GK> OpenSolaris on a USB stick... Just to get this documented: I was not able to get OSL on a USB medium since you need a special tool for putting an image on a stick that rungs under Solaris -> checken-egg-problem. I borrowed an external usb cd drive and downloaded the latest osl (131) from grunix. grub came up fine, selecting Solaris led to some dots on the screen (obviously the kernel being loaded), then there was a block screen with a blinking cursor, after some time the system rebooted. I added -v to boot the kernel and got as far as Sun's Copyright, then it hang again, rebooting some time later. I added -k -d to activate the kernel debugger and managed to follow what it is actually doing... well, after coming up with the cpu, OSL tried to activate hyperthreading, which is not supported by the cpu, and bang... After knowing what is going wrong, it was relatively easy to find the problem on the web. My system has a VIA NANO processor, which supports 64bit, but no HT. OSL obviously supposes that any cpu not being and AMD and having 64bit can support ht, too. The bug is there as long as the nano processor exists (first reports in 2008), but obviously unfixed. :-( I changed grub's boot line to load the 32bit OSL instead. This comes up fine. I could only boot textmode or vesa, otherwise the system does not recognize my onboard graphics. After googleing the default login and default root account (why don't they display this on the login prompt?) I could login, hat my zpool recognized and could import/export it without any hassle. After this the pool worked fine in FreeBSD again. One thing I noted is that the first disk changed its name from label/disk-0 back to da0 in the pool, although there still is a glabel on it. I don't know why this happened nor how to get back do use the glabel on this disk, but it seems to work anyway. The whole issue took me several attempts and at least 4 hours of work altogether (that's why I want to document it here to save other people this time :-). I would really love to see these fixing features imported in FreeBSD as soon as possible. BTW: I did not even have to specify the -F option when importing the pool. So maybe OSL is also more clever about what to do with inconsistent ZIL states... cu Gerrit From owner-freebsd-fs@FreeBSD.ORG Tue Feb 2 16:15: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 685F2106566C for ; Tue, 2 Feb 2010 16:15:18 +0000 (UTC) (envelope-from kickbsd@ya.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [95.108.130.94]) by mx1.freebsd.org (Postfix) with ESMTP id 15C818FC1E for ; Tue, 2 Feb 2010 16:15:17 +0000 (UTC) Received: from webmail89.yandex.ru (webmail89.yandex.ru [77.88.47.163]) by forward12.mail.yandex.net (Yandex) with ESMTP id B101915D12F7; Tue, 2 Feb 2010 19:04:03 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1265126643; bh=QD5dUorGxg/ZINTkCoekdFLYoPW6UwmZhFjew2Q3oLs=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=r8xdMxvn12AdM+8OThBqpZrV/86j9HT4ybkc2uMt6J5z5yPsN9v1EmSR8KmJM1ZeM ZDl5htoz/j0EM1TiAtand97qZNZ1FHg94RVrjMX24CGb5YkQVh1g7GlWZYBD2TInvt vW6CkRVuniown/RnikctQjP/UBwadinTTfVUkc+k= Received: from localhost (localhost.localdomain [127.0.0.1]) by webmail89.yandex.ru (Yandex) with ESMTP id 982B179038B; Tue, 2 Feb 2010 19:04:03 +0300 (MSK) X-Yandex-Spam: 1 X-Yandex-Front: webmail89 X-Yandex-TimeMark: 1265126643 Received: from iphone-charles.as6453.net (iphone-charles.as6453.net [64.86.53.183]) by mail.yandex.ru with HTTP; Tue, 02 Feb 2010 19:04:02 +0300 From: Baginski Darren To: Pawel Jakub Dawidek In-Reply-To: <20100130220221.GC1660@garage.freebsd.pl> References: <20100130220221.GC1660@garage.freebsd.pl> MIME-Version: 1.0 Message-Id: <8231265126643@webmail89.yandex.ru> Date: Tue, 02 Feb 2010 19:04:03 +0300 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-fs@freebsd.org, Michael Reifenberger Subject: Re: Re: zpool create fails on gpart 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: Tue, 02 Feb 2010 16:15:18 -0000 Worked for me too , I've applied aginst todays current. Is that fix or workaround ? Will it hit current soon ? 30.01.10, 23:02, "Pawel Jakub Dawidek" : > On Sat, Jan 30, 2010 at 09:31:45PM +0100, Michael Reifenberger wrote: > > Hi, > > have you got any new information or preliminary patch on this topic? > > Unfortunately I get the same symptom when trying to create a new pool using > > newly attached ada devices: > [...] > > I got no response how the patch works. Maybe you could try it? > > http://people.freebsd.org/~pjd/patches/vdev_geom.c.2.patch > > From owner-freebsd-fs@FreeBSD.ORG Tue Feb 2 17:43:01 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 178DB106566B; Tue, 2 Feb 2010 17:43:01 +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 2801E8FC2A; Tue, 2 Feb 2010 17:42:59 +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 TAA20962; Tue, 02 Feb 2010 19:42:54 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B68641D.9000201@icyb.net.ua> Date: Tue, 02 Feb 2010 19:42:53 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Julian Elischer References: <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua> <4B686324.2090308@elischer.org> In-Reply-To: <4B686324.2090308@elischer.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Stephane LAPIE , freebsd-hardware@freebsd.org Subject: Re: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE 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, 02 Feb 2010 17:43:01 -0000 on 02/02/2010 19:38 Julian Elischer said the following: > Andriy Gapon wrote: >> on 02/02/2010 15:32 Stephane LAPIE said the following: >>> I have a case of kernel panic that can be consistently reproduced, and >>> which I guess is related to the hardware I'm using (Marvell controllers, >>> check my pciconf -lv output below). >>> >>> The kernel panic message is always, consistently, the following : >>> >>> Sleeping thread (tid 100021, pid 0) owns a non-sleepable lock >> >> I probably won't be able to help you, but to kickstart debugging could >> you please >> run 'procstat -t 0' and determine what kernel thread has tid 100021 on >> your system? > > or in the kernel debugger after the panic, do: bt I think that in this case it may not help. I mean the stack trace. Because, I think that this panic happens after the taskqueue thread is done with its tasks and is parked waiting. > you DO have options kdb and ddb right? (I never leave home without them) > -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Feb 2 18:18:48 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 15ACA1065670; Tue, 2 Feb 2010 18:18:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from utility-0.aerioconnect.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id C253B8FC0C; Tue, 2 Feb 2010 18:18:47 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by utility-0.aerioconnect.net (8.13.1/8.13.1) with ESMTP id o12HcCdw019434; Tue, 2 Feb 2010 09:38:12 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id C3A692D601B; Tue, 2 Feb 2010 09:38:11 -0800 (PST) Message-ID: <4B686324.2090308@elischer.org> Date: Tue, 02 Feb 2010 09:38:44 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Andriy Gapon References: <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua> In-Reply-To: <4B682F29.90505@icyb.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Stephane LAPIE , freebsd-hardware@freebsd.org Subject: Re: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE 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, 02 Feb 2010 18:18:48 -0000 Andriy Gapon wrote: > on 02/02/2010 15:32 Stephane LAPIE said the following: >> I have a case of kernel panic that can be consistently reproduced, and >> which I guess is related to the hardware I'm using (Marvell controllers, >> check my pciconf -lv output below). >> >> The kernel panic message is always, consistently, the following : >> >> Sleeping thread (tid 100021, pid 0) owns a non-sleepable lock > > I probably won't be able to help you, but to kickstart debugging could you please > run 'procstat -t 0' and determine what kernel thread has tid 100021 on your system? or in the kernel debugger after the panic, do: bt you DO have options kdb and ddb right? (I never leave home without them) From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 09:49: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 F00E31065692 for ; Wed, 3 Feb 2010 09:49:00 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 91D008FC14 for ; Wed, 3 Feb 2010 09:49:00 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 4C802208FE6; Wed, 3 Feb 2010 10:48:58 +0100 (CET) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 19.1563] X-CRM114-CacheID: sfid-20100203_10485_1A065689 X-CRM114-Status: Good ( pR: 19.1563 ) Message-ID: <4B694689.2030704@fsn.hu> Date: Wed, 03 Feb 2010 10:48:57 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Stationery: 0.4.10 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (people.fsn.hu); Wed, 03 Feb 2010 10:48:57 +0100 (CET) Subject: Machine stops for some seconds 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: Wed, 03 Feb 2010 09:49:01 -0000 Hello, After a long time, I've switched back to ZFS on my desktop. It runs 8-STABLE/amd64 with two SATA disks and an USB pendrive. One-one partition is used from each disk for the zpool, which is encrypted using GELI, and the pendrive is there for L2ARC: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 mirror ONLINE 0 0 0 ad0s1d.eli ONLINE 0 0 0 ad1s1d.eli ONLINE 0 0 0 cache da0 ONLINE 0 0 0 Today, after 12 days of uptime the machine has frozen. I could ping it from a different machine, even could open a telnet to its ssh port, but I couldn't get the ssh banner. Now I'm building a 9-CURRENT kernel and world to see whether the same problem persists with that, and during the make process I've noticed a strange thing. I build with -j4 (the machine has one dual core CPU), so the fans are screaming during the process. But every few minutes (I couldn't recognize any patterns in it) the machine goes completely silent (even more silent than normally), and everything halts. During this, the top running on the machine can refresh itself, and I can type on pass through ssh connections (that is, I use the machine in question to access other machines with ssh), but I can't open new ssh connections to it, and can't start anything new (for example from an open shell). ping is running seamlessly during this, and top shows the following: last pid: 36503; load averages: 1.59, 3.04, 3.01 up 0+00:49:53 10:32:10 97 processes: 1 running, 96 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 218M Active, 24M Inact, 639M Wired, 40M Cache, 6208K Buf, 1022M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1342 root 1 44 0 3204K 620K select 0 0:02 0.00% make 1424 root 1 44 0 3204K 1036K select 0 0:01 0.00% make 1280 root 1 44 0 12540K 1900K select 0 0:01 0.00% hald-addon-storage 1234 haldaemon 1 44 0 24116K 4464K select 0 0:01 0.00% hald 93600 root 1 44 0 3204K 1028K select 0 0:00 0.00% make 1260 root 1 44 0 19704K 2688K select 0 0:00 0.00% hald-addon-mouse-sy 15142 bra 1 44 0 9332K 2864K CPU0 0 0:00 0.00% top 1263 root 1 44 0 12540K 1896K cgticb 0 0:00 0.00% hald-addon-storage 94415 bra 1 44 0 37944K 4992K select 1 0:00 0.00% sshd 35837 root 1 44 0 5252K 2424K select 1 0:00 0.00% make 95361 bra 1 44 0 37944K 4992K select 1 0:00 0.00% sshd 35973 root 1 44 0 3204K 1772K select 0 0:00 0.00% make 608 root 1 44 0 6892K 1436K select 1 0:00 0.00% syslogd 96928 root 1 44 0 3204K 728K select 0 0:00 0.00% make 94369 root 1 51 0 37944K 4584K sbwait 0 0:00 0.00% sshd 82631 root 1 50 0 37944K 4584K sbwait 0 0:00 0.00% sshd 16304 root 1 44 0 37944K 4576K zio->i 1 0:00 0.00% sshd 951 _ntp 1 44 0 6876K 1692K select 0 0:00 0.00% ntpd 1238 root 1 76 0 16768K 2372K select 0 0:00 0.00% hald-runner 4916 root 1 44 0 3204K 728K select 1 0:00 0.00% make 95338 root 1 49 0 37944K 4584K sbwait 1 0:00 0.00% sshd 1259 root 1 44 0 10280K 2712K pause 1 0:00 0.00% csh 33357 bra 1 44 0 21596K 4004K select 0 0:00 0.00% ssh 16405 bra 1 44 0 37944K 5012K zio->i 0 0:00 0.00% sshd 1044 root 1 44 0 9104K 1796K kqread 0 0:00 0.00% master 34765 root 1 76 0 8260K 1764K wait 1 0:00 0.00% sh 82685 bra 1 44 0 37944K 4960K select 1 0:00 0.00% sshd 1065 postfix 1 44 0 9100K 1872K kqread 0 0:00 0.00% qmgr 1237 root 17 44 0 27460K 4124K waitvt 0 0:00 0.00% console-kit-daemon 95362 bra 1 44 0 10216K 2612K ttyin 0 0:00 0.00% bash 34764 root 1 44 0 3204K 852K select 0 0:00 0.00% make 1222 root 1 49 0 21672K 1896K wait 0 0:00 0.00% login 35728 root 1 44 0 3204K 860K select 0 0:00 0.00% make 1064 postfix 1 44 0 9104K 1772K zio->i 1 0:00 0.00% pickup 82696 bra 1 44 0 10216K 2596K wait 0 0:00 0.00% bash 94417 bra 1 44 0 10216K 2596K wait 1 0:00 0.00% bash 35455 root 1 44 0 3204K 744K select 0 0:00 0.00% make 35774 root 1 44 0 3204K 728K select 1 0:00 0.00% make 16409 bra 1 44 0 10216K 2592K ttyin 0 0:00 0.00% bash 1155 root 1 44 0 7948K 1604K nanslp 0 0:00 0.00% cron 1077 messagebus 1 53 0 8092K 2060K select 0 0:00 0.00% dbus-daemon 1149 root 1 44 0 26012K 3960K select 1 0:00 0.00% sshd 35729 root 1 76 0 8260K 1760K wait 0 0:00 0.00% sh 4921 root 1 57 0 8260K 1748K wait 0 0:00 0.00% sh 825 root 1 76 0 39212K 2372K lockf 1 0:00 0.00% saslauthd 35460 root 1 76 0 8260K 1748K wait 0 0:00 0.00% sh 34761 root 1 48 0 8260K 1740K wait 1 0:00 0.00% sh 96923 root 1 50 0 8260K 1740K wait 0 0:00 0.00% sh As you can see, top reports that the machine is 100% idle, while a make -j4 buildworld runs. This lasts for few seconds (10-20), then everything goes back to normal, the fans start to scream, the build continues and I can use the machine. This occasional halt is new to me -but I'm just switched to ZFS on my desktop, in a server it's harder to notice if you don't use it for interactive sessions-, but I could see the final freeze on more than one servers. How could I help to debug this, and the final one? Thanks, From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 10:15:08 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 C040D106566C for ; Wed, 3 Feb 2010 10:15:08 +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 7F2E48FC12 for ; Wed, 3 Feb 2010 10:15:07 +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 o13AF6Y1043770; Wed, 3 Feb 2010 04:15:06 -0600 (CST) (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:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=XbLxPMEfxPhBS8EBaZFYLK1D7a7RoyNOfNtnrPb6a4i3R3pkxd4eb+gZH62IG1mZt sQFVy9lpG3gEo3PSmF4Mwm+pkYNaW7PP6uIvv1OKZdc+jfn1T664Gc/nyIYpQvxdNHp GiY2fYgFB16PK2C5yvHe7/4VRQ5UqS4wK0gD/Rk= Message-ID: <4B694CAA.60703@jrv.org> Date: Wed, 03 Feb 2010 04:15:06 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance 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, 03 Feb 2010 10:15:08 -0000 Dan Naumov wrote: > [jago@atombsd ~]$ dd if=/dev/zero of=/home/jago/test2 bs=1M count=4096 > 4096+0 records in > 4096+0 records out > 4294967296 bytes transferred in 143.878615 secs (29851325 bytes/sec) > > This works out to 1GB in 36,2 seconds / 28,2mb/s in the first test and > 4GB in 143.8 seconds / 28,4mb/s For the record, better results can be seen. In my test I put 3 Seagate Barracuda XT drives in a port multiplier and connected that to one port of a PCIe 3124 card. The MIRROR case is at about the I/O bandwidth limit of those drives. [root@kraken ~]# zpool create tmpx ada{2,3,4} [root@kraken ~]# dd if=/dev/zero of=/tmpx/test2 bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 20.892818 secs (205571470 bytes/sec) [root@kraken ~]# zpool destroy tmpx [root@kraken ~]# zpool create tmpx mirror ada{2,3} [root@kraken ~]# dd if=/dev/zero of=/tmpx/test2 bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 36.432818 secs (117887321 bytes/sec) [root@kraken ~]# From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 10:38:47 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 1A2D41065670 for ; Wed, 3 Feb 2010 10:38:47 +0000 (UTC) (envelope-from wonslung@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4018FC12 for ; Wed, 3 Feb 2010 10:38:46 +0000 (UTC) Received: by mail-ew0-f211.google.com with SMTP id 3so1117429ewy.13 for ; Wed, 03 Feb 2010 02:38:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=msViBLbuDH1T9x2WMCWNIzPljbPuR31qyGao+oGxk54=; b=YF1jd4XwMj2U2fK3UeSWsPt+2+P8u7OyNyOOCkJ21ufzmgujfZnrIlPzITouCBDjts LbtpBWgnFnVs0BAhQx4V3KawcHFdLSOgiYFHF7EthXVlJeDCOvgps6WxFhDXsclskk/s 9HH/BWk/SFJSuZUY/IpXmfWrKBdsedT05uS1A= 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=fbf5z10F6/0+iPoqMu1hfWH/J/Mk2iDNemC0Q0wgaBIl09rAgjMxNPihXSmSGuTN9L Wo3KHBOwBEnMEqGdPNfmbhkX07/65aS0gWilwF6CSLSMIIHsnTVvVJvXziBmZ26WIazJ 8j9wXQsOCfm1EAhLXJORjOamDbBm23oO1YhX4= MIME-Version: 1.0 Received: by 10.216.87.79 with SMTP id x57mr4717711wee.83.1265193526085; Wed, 03 Feb 2010 02:38:46 -0800 (PST) In-Reply-To: <4B694689.2030704@fsn.hu> References: <4B694689.2030704@fsn.hu> Date: Wed, 3 Feb 2010 05:38:45 -0500 Message-ID: From: Thomas Burgess To: Attila Nagy Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Machine stops for some seconds 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: Wed, 03 Feb 2010 10:38:47 -0000 why would you use a usb drive for L2ARC? I would think that would make things slower...have you tried setting up without the usb drive? On Wed, Feb 3, 2010 at 4:48 AM, Attila Nagy wrote: > Hello, > > After a long time, I've switched back to ZFS on my desktop. It runs > 8-STABLE/amd64 with two SATA disks and an USB pendrive. > One-one partition is used from each disk for the zpool, which is encrypted > using GELI, and the pendrive is there for L2ARC: > NAME STATE READ WRITE CKSUM > data ONLINE 0 0 0 > mirror ONLINE 0 0 0 > ad0s1d.eli ONLINE 0 0 0 > ad1s1d.eli ONLINE 0 0 0 > cache > da0 ONLINE 0 0 0 > > Today, after 12 days of uptime the machine has frozen. I could ping it from > a different machine, even could open a telnet to its ssh port, but I > couldn't get the ssh banner. > > Now I'm building a 9-CURRENT kernel and world to see whether the same > problem persists with that, and during the make process I've noticed a > strange thing. > I build with -j4 (the machine has one dual core CPU), so the fans are > screaming during the process. But every few minutes (I couldn't recognize > any patterns in it) the machine goes completely silent (even more silent > than normally), and everything halts. > During this, the top running on the machine can refresh itself, and I can > type on pass through ssh connections (that is, I use the machine in question > to access other machines with ssh), but I can't open new ssh connections to > it, and can't start anything new (for example from an open shell). > ping is running seamlessly during this, and top shows the following: > > last pid: 36503; load averages: 1.59, 3.04, 3.01 up 0+00:49:53 > 10:32:10 > 97 processes: 1 running, 96 sleeping > CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > Mem: 218M Active, 24M Inact, 639M Wired, 40M Cache, 6208K Buf, 1022M Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 1342 root 1 44 0 3204K 620K select 0 0:02 0.00% make > 1424 root 1 44 0 3204K 1036K select 0 0:01 0.00% make > 1280 root 1 44 0 12540K 1900K select 0 0:01 0.00% > hald-addon-storage > 1234 haldaemon 1 44 0 24116K 4464K select 0 0:01 0.00% hald > 93600 root 1 44 0 3204K 1028K select 0 0:00 0.00% make > 1260 root 1 44 0 19704K 2688K select 0 0:00 0.00% > hald-addon-mouse-sy > 15142 bra 1 44 0 9332K 2864K CPU0 0 0:00 0.00% top > 1263 root 1 44 0 12540K 1896K cgticb 0 0:00 0.00% > hald-addon-storage > 94415 bra 1 44 0 37944K 4992K select 1 0:00 0.00% sshd > 35837 root 1 44 0 5252K 2424K select 1 0:00 0.00% make > 95361 bra 1 44 0 37944K 4992K select 1 0:00 0.00% sshd > 35973 root 1 44 0 3204K 1772K select 0 0:00 0.00% make > 608 root 1 44 0 6892K 1436K select 1 0:00 0.00% syslogd > 96928 root 1 44 0 3204K 728K select 0 0:00 0.00% make > 94369 root 1 51 0 37944K 4584K sbwait 0 0:00 0.00% sshd > 82631 root 1 50 0 37944K 4584K sbwait 0 0:00 0.00% sshd > 16304 root 1 44 0 37944K 4576K zio->i 1 0:00 0.00% sshd > 951 _ntp 1 44 0 6876K 1692K select 0 0:00 0.00% ntpd > 1238 root 1 76 0 16768K 2372K select 0 0:00 0.00% > hald-runner > 4916 root 1 44 0 3204K 728K select 1 0:00 0.00% make > 95338 root 1 49 0 37944K 4584K sbwait 1 0:00 0.00% sshd > 1259 root 1 44 0 10280K 2712K pause 1 0:00 0.00% csh > 33357 bra 1 44 0 21596K 4004K select 0 0:00 0.00% ssh > 16405 bra 1 44 0 37944K 5012K zio->i 0 0:00 0.00% sshd > 1044 root 1 44 0 9104K 1796K kqread 0 0:00 0.00% master > 34765 root 1 76 0 8260K 1764K wait 1 0:00 0.00% sh > 82685 bra 1 44 0 37944K 4960K select 1 0:00 0.00% sshd > 1065 postfix 1 44 0 9100K 1872K kqread 0 0:00 0.00% qmgr > 1237 root 17 44 0 27460K 4124K waitvt 0 0:00 0.00% > console-kit-daemon > 95362 bra 1 44 0 10216K 2612K ttyin 0 0:00 0.00% bash > 34764 root 1 44 0 3204K 852K select 0 0:00 0.00% make > 1222 root 1 49 0 21672K 1896K wait 0 0:00 0.00% login > 35728 root 1 44 0 3204K 860K select 0 0:00 0.00% make > 1064 postfix 1 44 0 9104K 1772K zio->i 1 0:00 0.00% pickup > 82696 bra 1 44 0 10216K 2596K wait 0 0:00 0.00% bash > 94417 bra 1 44 0 10216K 2596K wait 1 0:00 0.00% bash > 35455 root 1 44 0 3204K 744K select 0 0:00 0.00% make > 35774 root 1 44 0 3204K 728K select 1 0:00 0.00% make > 16409 bra 1 44 0 10216K 2592K ttyin 0 0:00 0.00% bash > 1155 root 1 44 0 7948K 1604K nanslp 0 0:00 0.00% cron > 1077 messagebus 1 53 0 8092K 2060K select 0 0:00 0.00% > dbus-daemon > 1149 root 1 44 0 26012K 3960K select 1 0:00 0.00% sshd > 35729 root 1 76 0 8260K 1760K wait 0 0:00 0.00% sh > 4921 root 1 57 0 8260K 1748K wait 0 0:00 0.00% sh > 825 root 1 76 0 39212K 2372K lockf 1 0:00 0.00% > saslauthd > 35460 root 1 76 0 8260K 1748K wait 0 0:00 0.00% sh > 34761 root 1 48 0 8260K 1740K wait 1 0:00 0.00% sh > 96923 root 1 50 0 8260K 1740K wait 0 0:00 0.00% sh > > > As you can see, top reports that the machine is 100% idle, while a make -j4 > buildworld runs. This lasts for few seconds (10-20), then everything goes > back to normal, the fans start to scream, the build continues and I can use > the machine. > This occasional halt is new to me -but I'm just switched to ZFS on my > desktop, in a server it's harder to notice if you don't use it for > interactive sessions-, but I could see the final freeze on more than one > servers. > How could I help to debug this, and the final one? > > Thanks, > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 10:39: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 57F45106566C for ; Wed, 3 Feb 2010 10:39:33 +0000 (UTC) (envelope-from mgamsjager@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id D1EB08FC08 for ; Wed, 3 Feb 2010 10:39:32 +0000 (UTC) Received: by bwz3 with SMTP id 3so917803bwz.13 for ; Wed, 03 Feb 2010 02:39:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=5aPaurj8z78sLxcBo5vrMtKyYWHM90RIibdgwynFD3k=; b=Ht+j4XtKXvkb5ch/Q37pfZnvDDXZCZYi80SmVJczwe3e4Dj8vsPAAuLd4/WdK31vA4 RuLR/EstYJ9CDX+iLrk/2psl8Avxl3F4JeP84pujYdiU1FbFK4eVJsNhn5MtLPWqEv8x D4sSFwkVBjOabIIEw5BJryVu9qGjgExTIhvb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=i9keD6Io8rAJDnBtTQUVmlIYHZDTD/BjA3qrao5SzQkZLMiYdRbOFTxeVMRU9F1kQr YB03hkNUPGfl0nIugmg8W8bkNwvd4p8ubXzELG2iPFFqTYu4ZfiHJZgYHTo4Q4Nm65RO czygwgkEqip41ZG6Pzv87fjAk9ftBP0g9LiQQ= MIME-Version: 1.0 Received: by 10.204.8.154 with SMTP id h26mr5236269bkh.113.1265193571497; Wed, 03 Feb 2010 02:39:31 -0800 (PST) In-Reply-To: <4B694689.2030704@fsn.hu> References: <4B694689.2030704@fsn.hu> From: Matthias Gamsjager Date: Wed, 3 Feb 2010 11:39:11 +0100 Message-ID: <585602e11002030239y3da31f7bkbf593a04950c351e@mail.gmail.com> To: Attila Nagy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Machine stops for some seconds 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: Wed, 03 Feb 2010 10:39:33 -0000 What's the point in having a cache device that is slower then the harddisks itself? could you please try the build without the slow cache device? On Wed, Feb 3, 2010 at 10:48 AM, Attila Nagy wrote: > Hello, > > After a long time, I've switched back to ZFS on my desktop. It runs > 8-STABLE/amd64 with two SATA disks and an USB pendrive. > One-one partition is used from each disk for the zpool, which is encrypte= d > using GELI, and the pendrive is there for L2ARC: > =A0 NAME =A0 =A0 =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRITE CKSUM > =A0 data =A0 =A0 =A0 =A0 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 mirror =A0 =A0 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 ad0s1d.eli =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 ad1s1d.eli =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 cache > =A0 =A0 da0 =A0 =A0 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > > Today, after 12 days of uptime the machine has frozen. I could ping it fr= om > a different machine, even could open a telnet to its ssh port, but I > couldn't get the ssh banner. > > Now I'm building a 9-CURRENT kernel and world to see whether the same > problem persists with that, and during the make process I've noticed a > strange thing. > I build with -j4 (the machine has one dual core CPU), so the fans are > screaming during the process. But every few minutes (I couldn't recognize > any patterns in it) the machine goes completely silent (even more silent > than normally), and everything halts. > During this, the top running on the machine can refresh itself, and I can > type on pass through ssh connections (that is, I use the machine in quest= ion > to access other machines with ssh), but I can't open new ssh connections = to > it, and can't start anything new (for example from an open shell). > ping is running seamlessly during this, and top shows the following: > > last pid: 36503; =A0load averages: =A01.59, =A03.04, =A03.01 =A0 =A0up 0+= 00:49:53 > =A010:32:10 > 97 processes: =A01 running, 96 sleeping > CPU: =A00.0% user, =A00.0% nice, =A00.0% system, =A00.0% interrupt, =A010= 0% idle > Mem: 218M Active, 24M Inact, 639M Wired, 40M Cache, 6208K Buf, 1022M Free > Swap: 4096M Total, 4096M Free > > =A0PID USERNAME =A0 =A0THR PRI NICE =A0 SIZE =A0 =A0RES STATE =A0 C =A0 T= IME =A0 WCPU COMMAND > 1342 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A03204K =A0 620K select = =A00 =A0 0:02 =A00.00% make > 1424 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A03204K =A01036K select = =A00 =A0 0:01 =A00.00% make > 1280 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 12540K =A01900K select =A00= =A0 0:01 =A00.00% > hald-addon-storage > 1234 haldaemon =A0 =A0 1 =A044 =A0 =A00 24116K =A04464K select =A00 =A0 0= :01 =A00.00% hald > 93600 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A03204K =A01028K select = =A00 =A0 0:00 =A00.00% make > 1260 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 19704K =A02688K select =A00= =A0 0:00 =A00.00% > hald-addon-mouse-sy > 15142 bra =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 =A09332K =A02864K CPU0 =A0= =A00 =A0 0:00 =A00.00% top > 1263 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 12540K =A01896K cgticb =A00= =A0 0:00 =A00.00% > hald-addon-storage > 94415 bra =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 37944K =A04992K select =A0= 1 =A0 0:00 =A00.00% sshd > 35837 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A05252K =A02424K select = =A01 =A0 0:00 =A00.00% make > 95361 bra =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 37944K =A04992K select =A0= 1 =A0 0:00 =A00.00% sshd > 35973 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A03204K =A01772K select = =A00 =A0 0:00 =A00.00% make > =A0608 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A06892K =A01436K select = =A01 =A0 0:00 =A00.00% syslogd > 96928 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A03204K =A0 728K select = =A00 =A0 0:00 =A00.00% make > 94369 root =A0 =A0 =A0 =A0 =A01 =A051 =A0 =A00 37944K =A04584K sbwait =A0= 0 =A0 0:00 =A00.00% sshd > 82631 root =A0 =A0 =A0 =A0 =A01 =A050 =A0 =A00 37944K =A04584K sbwait =A0= 0 =A0 0:00 =A00.00% sshd > 16304 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 37944K =A04576K zio->i =A0= 1 =A0 0:00 =A00.00% sshd > =A0951 _ntp =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A06876K =A01692K select = =A00 =A0 0:00 =A00.00% ntpd > 1238 root =A0 =A0 =A0 =A0 =A01 =A076 =A0 =A00 16768K =A02372K select =A00= =A0 0:00 =A00.00% > hald-runner > 4916 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A03204K =A0 728K select = =A01 =A0 0:00 =A00.00% make > 95338 root =A0 =A0 =A0 =A0 =A01 =A049 =A0 =A00 37944K =A04584K sbwait =A0= 1 =A0 0:00 =A00.00% sshd > 1259 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 10280K =A02712K pause =A0 1= =A0 0:00 =A00.00% csh > 33357 bra =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 21596K =A04004K select =A0= 0 =A0 0:00 =A00.00% ssh > 16405 bra =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 37944K =A05012K zio->i =A0= 0 =A0 0:00 =A00.00% sshd > 1044 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A09104K =A01796K kqread = =A00 =A0 0:00 =A00.00% master > 34765 root =A0 =A0 =A0 =A0 =A01 =A076 =A0 =A00 =A08260K =A01764K wait =A0= =A01 =A0 0:00 =A00.00% sh > 82685 bra =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 37944K =A04960K select =A0= 1 =A0 0:00 =A00.00% sshd > 1065 postfix =A0 =A0 =A0 1 =A044 =A0 =A00 =A09100K =A01872K kqread =A00 = =A0 0:00 =A00.00% qmgr > 1237 root =A0 =A0 =A0 =A0 17 =A044 =A0 =A00 27460K =A04124K waitvt =A00 = =A0 0:00 =A00.00% > console-kit-daemon > 95362 bra =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 10216K =A02612K ttyin =A0 = 0 =A0 0:00 =A00.00% bash > 34764 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A03204K =A0 852K select = =A00 =A0 0:00 =A00.00% make > 1222 root =A0 =A0 =A0 =A0 =A01 =A049 =A0 =A00 21672K =A01896K wait =A0 = =A00 =A0 0:00 =A00.00% login > 35728 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A03204K =A0 860K select = =A00 =A0 0:00 =A00.00% make > 1064 postfix =A0 =A0 =A0 1 =A044 =A0 =A00 =A09104K =A01772K zio->i =A01 = =A0 0:00 =A00.00% pickup > 82696 bra =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 10216K =A02596K wait =A0 = =A00 =A0 0:00 =A00.00% bash > 94417 bra =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 10216K =A02596K wait =A0 = =A01 =A0 0:00 =A00.00% bash > 35455 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A03204K =A0 744K select = =A00 =A0 0:00 =A00.00% make > 35774 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A03204K =A0 728K select = =A01 =A0 0:00 =A00.00% make > 16409 bra =A0 =A0 =A0 =A0 =A0 1 =A044 =A0 =A00 10216K =A02592K ttyin =A0 = 0 =A0 0:00 =A00.00% bash > 1155 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 =A07948K =A01604K nanslp = =A00 =A0 0:00 =A00.00% cron > 1077 messagebus =A0 =A01 =A053 =A0 =A00 =A08092K =A02060K select =A00 =A0= 0:00 =A00.00% > dbus-daemon > 1149 root =A0 =A0 =A0 =A0 =A01 =A044 =A0 =A00 26012K =A03960K select =A01= =A0 0:00 =A00.00% sshd > 35729 root =A0 =A0 =A0 =A0 =A01 =A076 =A0 =A00 =A08260K =A01760K wait =A0= =A00 =A0 0:00 =A00.00% sh > 4921 root =A0 =A0 =A0 =A0 =A01 =A057 =A0 =A00 =A08260K =A01748K wait =A0 = =A00 =A0 0:00 =A00.00% sh > =A0825 root =A0 =A0 =A0 =A0 =A01 =A076 =A0 =A00 39212K =A02372K lockf =A0= 1 =A0 0:00 =A00.00% > saslauthd > 35460 root =A0 =A0 =A0 =A0 =A01 =A076 =A0 =A00 =A08260K =A01748K wait =A0= =A00 =A0 0:00 =A00.00% sh > 34761 root =A0 =A0 =A0 =A0 =A01 =A048 =A0 =A00 =A08260K =A01740K wait =A0= =A01 =A0 0:00 =A00.00% sh > 96923 root =A0 =A0 =A0 =A0 =A01 =A050 =A0 =A00 =A08260K =A01740K wait =A0= =A00 =A0 0:00 =A00.00% sh > > > As you can see, top reports that the machine is 100% idle, while a make -= j4 > buildworld runs. This lasts for few seconds (10-20), then everything goes > back to normal, the fans start to scream, the build continues and I can u= se > the machine. > This occasional halt is new to me -but I'm just switched to ZFS on my > desktop, in a server it's harder to notice if you don't use it for > interactive sessions-, but I could see the final freeze on more than one > servers. > How could I help to debug this, and the final one? > > Thanks, > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 11:23: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 098FA1065676; Wed, 3 Feb 2010 11:23:19 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id 98F138FC1B; Wed, 3 Feb 2010 11:23:18 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id 840151CFF; Wed, 3 Feb 2010 12:23:11 +0100 (CET) Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6qkRDKXiBJV; Wed, 3 Feb 2010 12:23:09 +0100 (CET) Received: from [192.168.3.42] (archer.yomi.darkbsd.org [192.168.3.42]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id 9E9211CF8; Wed, 3 Feb 2010 12:23:07 +0100 (CET) Message-ID: <4B695CA3.50008@darkbsd.org> Date: Wed, 03 Feb 2010 20:23:15 +0900 From: Stephane LAPIE User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andriy Gapon References: <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua> <4B686324.2090308@elischer.org> <4B68641D.9000201@icyb.net.ua> In-Reply-To: <4B68641D.9000201@icyb.net.ua> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9026C478EB31D9AA9953CE13" Cc: freebsd-fs@freebsd.org, Julian Elischer , freebsd-hardware@freebsd.org Subject: Re: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE 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, 03 Feb 2010 11:23:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9026C478EB31D9AA9953CE13 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 02/02/2010 19:38 Julian Elischer said the following: >> Andriy Gapon wrote: >>> on 02/02/2010 15:32 Stephane LAPIE said the following: >>>> I have a case of kernel panic that can be consistently reproduced, a= nd >>>> which I guess is related to the hardware I'm using (Marvell controll= ers, >>>> check my pciconf -lv output below). >>>> >>>> The kernel panic message is always, consistently, the following : >>>> >>>> Sleeping thread (tid 100021, pid 0) owns a non-sleepable lock >>> I probably won't be able to help you, but to kickstart debugging coul= d >>> you please >>> run 'procstat -t 0' and determine what kernel thread has tid 100021 o= n >>> your system? >> or in the kernel debugger after the panic, do: bt >=20 > I think that in this case it may not help. I mean the stack trace. > Because, I think that this panic happens after the taskqueue thread is = done with > its tasks and is parked waiting. >=20 >> you DO have options kdb and ddb right? (I never leave home without th= em) >> >=20 >=20 I just rebuilt a kernel with debugger options, and obtained the=20 following output upon pulling out one disk : Sleeping thread (tid 100024, pid 0) owns a non-sleepable lock sched_switch() at sched_switch+0xf8 mi_switch() at mi_switch+0x16f sleepq_timedwait() at sleepq_timedwait+0x42 _cv_timedwait() at _cv_timedwait+0x129 _sema_timedwait() at _sema_timedwait+0x55 ata_queue_request() at ata_queue_request+0x526 ata_controlcmd() at ata_controlcmd+0xa1 ata_setmode() at ata_setmode+0xdc ad_init() at ad_init+0x27 ad_reinit() at ad_reinit+0x48 ata_reinit() at ata_reinit+0x268 ata_conn_event() at ata_conn_event+0x49 taskqueue_run() at taskqueue_run+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff80000aad30, rbp =3D 0 --- panic: sleeping thread cpuid =3D 2 KDB: enter: panic [thread pid 12 tid 100008 ] Stopped at kdb_enter+0x3d: movq $0,0x4943d0(%rip) I think the output below is not really relevant though. db> bt Tracing pid 12 tid 100008 td 0xffffff000187e000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b turnstile_adjust() at turnstile_adjust turnstile_wait() at turnstile_wait+0x1aa _mtx_lock_sleep() at _mtx_lock_sleep+0xb0 softclock() at softclock+0x2a9 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff800005ad30, rbp =3D 0 --- If there is anything else I can run to obtain further information, all=20 hints are welcome, though this clearly seems to point to a problem with=20 my controller event handling as I initially thought. I am also very suspicious of that controller because it tends to drop=20 two disks at exactly the same time, which alas belong to the same raidz1 = block (BIOS level can't reset properly the port or redetect them after=20 this, I have to go through a cold boot; The disks themselves could be=20 damaged but I don't catch any weird readings via SMART and Reallocated=20 Sectors or such). I am seriously thinking of moving some of these disks=20 to the AHCI controller on my motherboard, and will resort to using my=20 spares at the very least in the meantime. Thanks for your time, --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enig9026C478EB31D9AA9953CE13 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktpXKkACgkQ24Ql8u6TF2PafgCg0KHN21iTsRKK5bicKqrVo4Rv E68AoKFECb7szXCvNUWvk7k40dKfMI5r =URPh -----END PGP SIGNATURE----- --------------enig9026C478EB31D9AA9953CE13-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 11:26:49 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 4F5791065670 for ; Wed, 3 Feb 2010 11:26:49 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id A04F68FC18 for ; Wed, 3 Feb 2010 11:26:48 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id DE4F1208462; Wed, 3 Feb 2010 12:26:46 +0100 (CET) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 25.4422] X-CRM114-CacheID: sfid-20100203_12264_25A24470 X-CRM114-Status: Good ( pR: 25.4422 ) Message-ID: <4B695D74.6040003@fsn.hu> Date: Wed, 03 Feb 2010 12:26:44 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Matthias Gamsjager References: <4B694689.2030704@fsn.hu> <585602e11002030239y3da31f7bkbf593a04950c351e@mail.gmail.com> In-Reply-To: <585602e11002030239y3da31f7bkbf593a04950c351e@mail.gmail.com> X-Stationery: 0.4.10 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (people.fsn.hu); Wed, 03 Feb 2010 12:26:45 +0100 (CET) Cc: freebsd-fs@freebsd.org Subject: Re: Machine stops for some seconds 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: Wed, 03 Feb 2010 11:26:49 -0000 Slower in what regard? In sequential read -which is meaningless-, maybe. But in random read and latency? Absolutely no. Compare these: L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 1 64 64 4071 8.7 0 0 0.0 55.4| ad0s1d.eli 0 44 44 2799 7.1 0 0 0.0 31.0| ad1s1d.eli 1 1208 1208 1908 0.8 0 0 0.0 78.8| da0 An average consumer SATA drive can push about 120 IOPS with 8-10 ms seek time. An average consumer USB pendrive can perform more than 10 times better of that (in both IOPS and latency). SATA drive: (64/55.4)*100=115 IOPS, latency: about 8 ms USB drive: (1208/78.8)*100=1530 IOPS, latency: about 0.8 ms This is the essential of Windows ReadyBoost and ZFS's L2ARC. There is absolutely no IO (no nothing) towards the disks (be is HDD or SSD), so this is not because of the cache. (yes, I've tried without that, and the freeze also comes without an L2ARC device) Matthias Gamsjager wrote: > What's the point in having a cache device that is slower then the > harddisks itself? > could you please try the build without the slow cache device? > > On Wed, Feb 3, 2010 at 10:48 AM, Attila Nagy wrote: > >> Hello, >> >> After a long time, I've switched back to ZFS on my desktop. It runs >> 8-STABLE/amd64 with two SATA disks and an USB pendrive. >> One-one partition is used from each disk for the zpool, which is encrypted >> using GELI, and the pendrive is there for L2ARC: >> NAME STATE READ WRITE CKSUM >> data ONLINE 0 0 0 >> mirror ONLINE 0 0 0 >> ad0s1d.eli ONLINE 0 0 0 >> ad1s1d.eli ONLINE 0 0 0 >> cache >> da0 ONLINE 0 0 0 >> >> Today, after 12 days of uptime the machine has frozen. I could ping it from >> a different machine, even could open a telnet to its ssh port, but I >> couldn't get the ssh banner. >> >> Now I'm building a 9-CURRENT kernel and world to see whether the same >> problem persists with that, and during the make process I've noticed a >> strange thing. >> I build with -j4 (the machine has one dual core CPU), so the fans are >> screaming during the process. But every few minutes (I couldn't recognize >> any patterns in it) the machine goes completely silent (even more silent >> than normally), and everything halts. >> During this, the top running on the machine can refresh itself, and I can >> type on pass through ssh connections (that is, I use the machine in question >> to access other machines with ssh), but I can't open new ssh connections to >> it, and can't start anything new (for example from an open shell). >> ping is running seamlessly during this, and top shows the following: >> >> last pid: 36503; load averages: 1.59, 3.04, 3.01 up 0+00:49:53 >> 10:32:10 >> 97 processes: 1 running, 96 sleeping >> CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle >> Mem: 218M Active, 24M Inact, 639M Wired, 40M Cache, 6208K Buf, 1022M Free >> Swap: 4096M Total, 4096M Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 1342 root 1 44 0 3204K 620K select 0 0:02 0.00% make >> 1424 root 1 44 0 3204K 1036K select 0 0:01 0.00% make >> 1280 root 1 44 0 12540K 1900K select 0 0:01 0.00% >> hald-addon-storage >> 1234 haldaemon 1 44 0 24116K 4464K select 0 0:01 0.00% hald >> 93600 root 1 44 0 3204K 1028K select 0 0:00 0.00% make >> 1260 root 1 44 0 19704K 2688K select 0 0:00 0.00% >> hald-addon-mouse-sy >> 15142 bra 1 44 0 9332K 2864K CPU0 0 0:00 0.00% top >> 1263 root 1 44 0 12540K 1896K cgticb 0 0:00 0.00% >> hald-addon-storage >> 94415 bra 1 44 0 37944K 4992K select 1 0:00 0.00% sshd >> 35837 root 1 44 0 5252K 2424K select 1 0:00 0.00% make >> 95361 bra 1 44 0 37944K 4992K select 1 0:00 0.00% sshd >> 35973 root 1 44 0 3204K 1772K select 0 0:00 0.00% make >> 608 root 1 44 0 6892K 1436K select 1 0:00 0.00% syslogd >> 96928 root 1 44 0 3204K 728K select 0 0:00 0.00% make >> 94369 root 1 51 0 37944K 4584K sbwait 0 0:00 0.00% sshd >> 82631 root 1 50 0 37944K 4584K sbwait 0 0:00 0.00% sshd >> 16304 root 1 44 0 37944K 4576K zio->i 1 0:00 0.00% sshd >> 951 _ntp 1 44 0 6876K 1692K select 0 0:00 0.00% ntpd >> 1238 root 1 76 0 16768K 2372K select 0 0:00 0.00% >> hald-runner >> 4916 root 1 44 0 3204K 728K select 1 0:00 0.00% make >> 95338 root 1 49 0 37944K 4584K sbwait 1 0:00 0.00% sshd >> 1259 root 1 44 0 10280K 2712K pause 1 0:00 0.00% csh >> 33357 bra 1 44 0 21596K 4004K select 0 0:00 0.00% ssh >> 16405 bra 1 44 0 37944K 5012K zio->i 0 0:00 0.00% sshd >> 1044 root 1 44 0 9104K 1796K kqread 0 0:00 0.00% master >> 34765 root 1 76 0 8260K 1764K wait 1 0:00 0.00% sh >> 82685 bra 1 44 0 37944K 4960K select 1 0:00 0.00% sshd >> 1065 postfix 1 44 0 9100K 1872K kqread 0 0:00 0.00% qmgr >> 1237 root 17 44 0 27460K 4124K waitvt 0 0:00 0.00% >> console-kit-daemon >> 95362 bra 1 44 0 10216K 2612K ttyin 0 0:00 0.00% bash >> 34764 root 1 44 0 3204K 852K select 0 0:00 0.00% make >> 1222 root 1 49 0 21672K 1896K wait 0 0:00 0.00% login >> 35728 root 1 44 0 3204K 860K select 0 0:00 0.00% make >> 1064 postfix 1 44 0 9104K 1772K zio->i 1 0:00 0.00% pickup >> 82696 bra 1 44 0 10216K 2596K wait 0 0:00 0.00% bash >> 94417 bra 1 44 0 10216K 2596K wait 1 0:00 0.00% bash >> 35455 root 1 44 0 3204K 744K select 0 0:00 0.00% make >> 35774 root 1 44 0 3204K 728K select 1 0:00 0.00% make >> 16409 bra 1 44 0 10216K 2592K ttyin 0 0:00 0.00% bash >> 1155 root 1 44 0 7948K 1604K nanslp 0 0:00 0.00% cron >> 1077 messagebus 1 53 0 8092K 2060K select 0 0:00 0.00% >> dbus-daemon >> 1149 root 1 44 0 26012K 3960K select 1 0:00 0.00% sshd >> 35729 root 1 76 0 8260K 1760K wait 0 0:00 0.00% sh >> 4921 root 1 57 0 8260K 1748K wait 0 0:00 0.00% sh >> 825 root 1 76 0 39212K 2372K lockf 1 0:00 0.00% >> saslauthd >> 35460 root 1 76 0 8260K 1748K wait 0 0:00 0.00% sh >> 34761 root 1 48 0 8260K 1740K wait 1 0:00 0.00% sh >> 96923 root 1 50 0 8260K 1740K wait 0 0:00 0.00% sh >> >> >> As you can see, top reports that the machine is 100% idle, while a make -j4 >> buildworld runs. This lasts for few seconds (10-20), then everything goes >> back to normal, the fans start to scream, the build continues and I can use >> the machine. >> This occasional halt is new to me -but I'm just switched to ZFS on my >> desktop, in a server it's harder to notice if you don't use it for >> interactive sessions-, but I could see the final freeze on more than one >> servers. >> How could I help to debug this, and the final one? >> >> Thanks, >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> >> From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 12:09: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 6F962106568D for ; Wed, 3 Feb 2010 12:09:28 +0000 (UTC) (envelope-from sty@blosphere.net) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 51F688FC08 for ; Wed, 3 Feb 2010 12:09:28 +0000 (UTC) Received: by pxi13 with SMTP id 13so1297884pxi.3 for ; Wed, 03 Feb 2010 04:09:27 -0800 (PST) MIME-Version: 1.0 Sender: sty@blosphere.net Received: by 10.114.165.4 with SMTP id n4mr5003531wae.81.1265198967728; Wed, 03 Feb 2010 04:09:27 -0800 (PST) In-Reply-To: <4B694689.2030704@fsn.hu> References: <4B694689.2030704@fsn.hu> Date: Wed, 3 Feb 2010 21:09:27 +0900 X-Google-Sender-Auth: 3460c518de9bbab1 Message-ID: From: =?UTF-8?B?VG9tbWkgTMOkdHRp?= To: Attila Nagy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Machine stops for some seconds 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: Wed, 03 Feb 2010 12:09:28 -0000 > After a long time, I've switched back to ZFS on my desktop. It runs > 8-STABLE/amd64 with two SATA disks and an USB pendrive. > One-one partition is used from each disk for the zpool, which is encrypte= d > using GELI, and the pendrive is there for L2ARC: > =C2=A0 NAME =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0STATE =C2=A0 =C2=A0 = READ WRITE CKSUM > =C2=A0 data =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ONLINE =C2=A0 =C2=A0= =C2=A0 0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 0 > =C2=A0 =C2=A0 mirror =C2=A0 =C2=A0 =C2=A0 =C2=A0ONLINE =C2=A0 =C2=A0 =C2= =A0 0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 0 > =C2=A0 =C2=A0 =C2=A0 ad0s1d.eli =C2=A0ONLINE =C2=A0 =C2=A0 =C2=A0 0 =C2= =A0 =C2=A0 0 =C2=A0 =C2=A0 0 > =C2=A0 =C2=A0 =C2=A0 ad1s1d.eli =C2=A0ONLINE =C2=A0 =C2=A0 =C2=A0 0 =C2= =A0 =C2=A0 0 =C2=A0 =C2=A0 0 > =C2=A0 cache > =C2=A0 =C2=A0 da0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ONLINE =C2=A0 =C2=A0= =C2=A0 0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 0 > > Today, after 12 days of uptime the machine has frozen. I could ping it fr= om > a different machine, even could open a telnet to its ssh port, but I > couldn't get the ssh banner. > > Now I'm building a 9-CURRENT kernel and world to see whether the same > problem persists with that, and during the make process I've noticed a > strange thing. > I build with -j4 (the machine has one dual core CPU), so the fans are > screaming during the process. But every few minutes (I couldn't recognize > any patterns in it) the machine goes completely silent (even more silent > than normally), and everything halts. > =C2=A0PID USERNAME =C2=A0 =C2=A0THR PRI NICE =C2=A0 SIZE =C2=A0 =C2=A0RES= STATE =C2=A0 C =C2=A0 TIME =C2=A0 WCPU COMMAND > 16304 root =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01 =C2=A044 =C2=A0 =C2=A00 37= 944K =C2=A04576K zio->i =C2=A01 =C2=A0 0:00 =C2=A00.00% sshd > 16405 bra =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A044 =C2=A0 =C2=A00 37= 944K =C2=A05012K zio->i =C2=A00 =C2=A0 0:00 =C2=A00.00% sshd > 1064 postfix =C2=A0 =C2=A0 =C2=A0 1 =C2=A044 =C2=A0 =C2=A00 =C2=A09104K = =C2=A01772K zio->i =C2=A01 =C2=A0 0:00 =C2=A00.00% pickup This sounds like you're being hit by the same performance slowdown (extensively documented) that seems to affect everybody currently (maybe not those guys with ssd's or 15k rpm drives in big arrays). There's a long thread on -STABLE. Basically how I see it it's impossible to read and write from zfs pool at the same time which might be caused how the arc cache behaves under freebsd (didn't have these problems when zfs was still 'unstable'). I couldn't even watch a 720p video while having small writes (less than 1k every few seconds) to the same array without the smb process going to zio->i state which seems to indicate a complete block on any i/o. Combine with 5400 rpm consumer drives... well... -> switched to opensolaris, performance is now great... --=20 br, Tommi From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 12:31: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 915161065670 for ; Wed, 3 Feb 2010 12:31:54 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7D58FC0C for ; Wed, 3 Feb 2010 12:31:53 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 4EE342086E2; Wed, 3 Feb 2010 13:31:52 +0100 (CET) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 21.5535] X-CRM114-CacheID: sfid-20100203_13315_4CA46860 X-CRM114-Status: Good ( pR: 21.5535 ) Message-ID: <4B696CB7.7070607@fsn.hu> Date: Wed, 03 Feb 2010 13:31:51 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: =?UTF-8?B?VG9tbWkgTMOkdHRp?= References: <4B694689.2030704@fsn.hu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (people.fsn.hu); Wed, 03 Feb 2010 13:31:51 +0100 (CET) Cc: freebsd-fs@freebsd.org Subject: Re: Machine stops for some seconds 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: Wed, 03 Feb 2010 12:31:54 -0000 Tommi Lätti wrote: >> After a long time, I've switched back to ZFS on my desktop. It runs >> 8-STABLE/amd64 with two SATA disks and an USB pendrive. >> One-one partition is used from each disk for the zpool, which is encrypted >> using GELI, and the pendrive is there for L2ARC: >> NAME STATE READ WRITE CKSUM >> data ONLINE 0 0 0 >> mirror ONLINE 0 0 0 >> ad0s1d.eli ONLINE 0 0 0 >> ad1s1d.eli ONLINE 0 0 0 >> cache >> da0 ONLINE 0 0 0 >> >> Today, after 12 days of uptime the machine has frozen. I could ping it from >> a different machine, even could open a telnet to its ssh port, but I >> couldn't get the ssh banner. >> >> Now I'm building a 9-CURRENT kernel and world to see whether the same >> problem persists with that, and during the make process I've noticed a >> strange thing. >> I build with -j4 (the machine has one dual core CPU), so the fans are >> screaming during the process. But every few minutes (I couldn't recognize >> any patterns in it) the machine goes completely silent (even more silent >> than normally), and everything halts. >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 16304 root 1 44 0 37944K 4576K zio->i 1 0:00 0.00% sshd >> 16405 bra 1 44 0 37944K 5012K zio->i 0 0:00 0.00% sshd >> 1064 postfix 1 44 0 9104K 1772K zio->i 1 0:00 0.00% pickup >> > > This sounds like you're being hit by the same performance slowdown > (extensively documented) that seems to affect everybody currently > (maybe not those guys with ssd's or 15k rpm drives in big arrays). > There's a long thread on -STABLE. > > Basically how I see it it's impossible to read and write from zfs pool > at the same time which might be caused how the arc cache behaves under > freebsd (didn't have these problems when zfs was still 'unstable'). I > couldn't even watch a 720p video while having small writes (less than > 1k every few seconds) to the same array without the smb process going > to zio->i state which seems to indicate a complete block on any i/o. > I'm not sure about these are being the same. When I see these "stops", nothing happens. gstat shows no IO, and everything goes very quiet for some painful (10s of) seconds. Also, buildworld doesn't do too heavy IO, at least for these drives. BTW, we are doing tests in a completely different environment with ZFS and NFS (15k drives, with BBWC), and it seems something similar happens there too, resulting in a freeze in the end. > Combine with 5400 rpm consumer drives... well... > Doesn't really count, but these drives are 7k2. > -> switched to opensolaris, performance is now great... > I would like to avoid that, because we don't have the same, well managed netbooted environment for that OS what we have for FreeBSD. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 12:40: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 505B21065670 for ; Wed, 3 Feb 2010 12:40:34 +0000 (UTC) (envelope-from sty@blosphere.net) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 32BD58FC08 for ; Wed, 3 Feb 2010 12:40:34 +0000 (UTC) Received: by pzk40 with SMTP id 40so1327968pzk.7 for ; Wed, 03 Feb 2010 04:40:33 -0800 (PST) MIME-Version: 1.0 Sender: sty@blosphere.net Received: by 10.114.249.21 with SMTP id w21mr4889984wah.123.1265200833652; Wed, 03 Feb 2010 04:40:33 -0800 (PST) In-Reply-To: <4B696CB7.7070607@fsn.hu> References: <4B694689.2030704@fsn.hu> <4B696CB7.7070607@fsn.hu> Date: Wed, 3 Feb 2010 21:40:33 +0900 X-Google-Sender-Auth: 733467579a9b8862 Message-ID: From: =?UTF-8?B?VG9tbWkgTMOkdHRp?= To: Attila Nagy Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: Machine stops for some seconds 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: Wed, 03 Feb 2010 12:40:34 -0000 > I'm not sure about these are being the same. When I see these "stops", > nothing happens. gstat shows no IO, and everything goes very quiet for some > painful (10s of) seconds. Also, buildworld doesn't do too heavy IO, at least > for these drives. Well that's what I experienced. iostat says 0, machine is kind of responsive, unless you try to read or write from the zfs pool.. > BTW, we are doing tests in a completely different environment with ZFS and > NFS (15k drives, with BBWC), and it seems something similar happens there > too, resulting in a freeze in the end. >> >> Combine with 5400 rpm consumer drives... well... >> > > Doesn't really count, but these drives are 7k2. If it's a zfs arc problem it would definitely manifest on 15k drives too, what I meant that the impact might be unnoticeable. But since I don't have a nice SAN to test with right now I can't try it out with 100+ disks. -- br, Tommi From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 12:48: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 B3C78106566B for ; Wed, 3 Feb 2010 12:48:33 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC168FC17 for ; Wed, 3 Feb 2010 12:48:32 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 7BDD02087A6; Wed, 3 Feb 2010 13:48:31 +0100 (CET) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 17.2525] X-CRM114-CacheID: sfid-20100203_13483_3BA244CE X-CRM114-Status: Good ( pR: 17.2525 ) Message-ID: <4B69709E.1090601@fsn.hu> Date: Wed, 03 Feb 2010 13:48:30 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: =?UTF-8?B?VG9tbWkgTMOkdHRp?= References: <4B694689.2030704@fsn.hu> <4B696CB7.7070607@fsn.hu> In-Reply-To: X-Stationery: 0.4.10 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (people.fsn.hu); Wed, 03 Feb 2010 13:48:30 +0100 (CET) Cc: freebsd-fs@freebsd.org Subject: Re: Machine stops for some seconds 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: Wed, 03 Feb 2010 12:48:33 -0000 Tommi Lätti wrote: >> I'm not sure about these are being the same. When I see these "stops", >> nothing happens. gstat shows no IO, and everything goes very quiet for some >> painful (10s of) seconds. Also, buildworld doesn't do too heavy IO, at least >> for these drives. >> > > Well that's what I experienced. iostat says 0, machine is kind of > responsive, unless you try to read or write from the zfs pool.. > Oh, that wasn't clear to me, so you are also experiencing a total blackout in disk IO. I'm not sure how this could be traced. > >> BTW, we are doing tests in a completely different environment with ZFS and >> NFS (15k drives, with BBWC), and it seems something similar happens there >> too, resulting in a freeze in the end. >> >>> Combine with 5400 rpm consumer drives... well... >>> >>> >> Doesn't really count, but these drives are 7k2. >> > > If it's a zfs arc problem it would definitely manifest on 15k drives > too, what I meant that the impact might be unnoticeable. But since I > don't have a nice SAN to test with right now I can't try it out with > 100+ disks. > I'm still not getting the point. If you see zero IO during the problem, how would a faster storage make impact on its visibility? From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 14:53: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 558FB1065694 for ; Wed, 3 Feb 2010 14:53:40 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id C7F3A8FC08 for ; Wed, 3 Feb 2010 14:53:39 +0000 (UTC) Received: from furia.intranet ([93.104.43.176]) (AUTH: LOGIN lopez.on.the.lists@yellowspace.net) by mail.yellowspace.net with esmtp; Wed, 03 Feb 2010 15:53:37 +0100 id 0036A185.000000004B698DF1.000022D2 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lorenzo Perone In-Reply-To: <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> Date: Wed, 3 Feb 2010 15:53:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B1DF836-0CCC-4CB2-B83C-3040428A7344@yellowspace.net> References: <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> To: Hywel Mallett X-Mailer: Apple Mail (2.1077) Cc: freebsd-fs@freebsd.org Subject: Re: Any news on the HAST Project? 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, 03 Feb 2010 14:53:40 -0000 On 28.01.2010, at 14:26, Hywel Mallett wrote: > About the same time a status update was posted on the FreeBSD = Foundation blog at = http://freebsdfoundation.blogspot.com/2009/12/update-on-hast-project.html Thanx, also to pjd's answer. That gives some nice insight already. Great = work! HAST could in fact change radically the way of using block devices = and distributing mass storage. I look forward to testing it first on a = few vboxes and shortly thereafter on real machines.=20 Really curious on how several things are implemented, e.g. performance / = latency / fail / sync issues (what happens for example when a big huge = file is written locally on a very fast primary, and there is not enough = ram to buffer it before sending it to a secondary.. etc, scenarios like = that).=20 And how well it will do with ZFS too: although ZFS has its 'own' HAST = via send/recv (and besides might get its own implementation for some = sort of 'streaming' send/recv..) it is also true that it'd allow for = some great flexibility in creating primary/secondary volumes (zvols). = Just imagining a scenario with sparse zvols and HAST disting them = around.. ok ok I stop here :-) Greets && Regards, Lorenzo From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 15:40:59 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 D3378106566C for ; Wed, 3 Feb 2010 15:40:59 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 98DF28FC0C for ; Wed, 3 Feb 2010 15:40:59 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o13FerEf019231; Wed, 3 Feb 2010 09:40:53 -0600 (CST) Date: Wed, 3 Feb 2010 09:40:53 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Attila Nagy In-Reply-To: <4B694689.2030704@fsn.hu> Message-ID: References: <4B694689.2030704@fsn.hu> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Wed, 03 Feb 2010 09:40:53 -0600 (CST) Cc: freebsd-fs@freebsd.org Subject: Re: Machine stops for some seconds 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: Wed, 03 Feb 2010 15:40:59 -0000 After reading this thread of discussion I see that the subject of the discussion is misleading since the subject provides a conclusion. It could have said "with FreeBSD" or some other feature of the system. The filesystem is obviously a key part of the system so that the system is not very usable without it. The mention of strange fan operation (extremely loud and then extremely silent and then extremely loud again) makes it sound like the problem has little to do with the filesystem. It would cause me to believe that there is something wrong with power management logic, which could be related to software or hardware, but not likely with zfs. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 18:16:53 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 242B21065679 for ; Wed, 3 Feb 2010 18:16:53 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id D51AC8FC18 for ; Wed, 3 Feb 2010 18:16:52 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 2F941209769; Wed, 3 Feb 2010 19:16:51 +0100 (CET) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 19.9104] X-CRM114-CacheID: sfid-20100203_19165_BEF56371 X-CRM114-Status: Good ( pR: 19.9104 ) Message-ID: <4B69BD8E.5020501@fsn.hu> Date: Wed, 03 Feb 2010 19:16:46 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Bob Friesenhahn References: <4B694689.2030704@fsn.hu> In-Reply-To: X-Stationery: 0.4.10 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (people.fsn.hu); Wed, 03 Feb 2010 19:16:50 +0100 (CET) Cc: freebsd-fs@freebsd.org Subject: Re: Machine stops for some seconds 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: Wed, 03 Feb 2010 18:16:53 -0000 Bob Friesenhahn wrote: > After reading this thread of discussion I see that the subject of the > discussion is misleading since the subject provides a conclusion. It > could have said "with FreeBSD" or some other feature of the system. > > The filesystem is obviously a key part of the system so that the > system is not very usable without it. > > The mention of strange fan operation (extremely loud and then > extremely silent and then extremely loud again) makes it sound like > the problem has little to do with the filesystem. It would cause me > to believe that there is something wrong with power management logic, > which could be related to software or hardware, but not likely with zfs. Well, maybe it's my english (I'm not a native speaker), but I thought it was clear. If no, I'm trying to re-structure it again, hopefully this time with more luck: - this machine has been running with FreeBSD 8 and UFS for ages for me (well, about two years). Everything was the same, except in the place of a mirrored zpool there was a gmirrored UFS (on top of GELI). - I've switched back to ZFS recently, and noticing the stuff, I've written, namely: - the machine froze after 12 days of operation (I could ping it, TCP ports were open, but the console was dead and nothing was accessible on the TCP ports besides the three way handshaking) - during building a world from ZFS, I've noticed that the machine occasionally goes very silent. Building world means CPU usage, CPU usage means higher temperatures, higher temperatures mean fans spinning faster, and fans spinning faster make a lot of noise. So the loudness is normal when it builds world. The silency is also normal when it does not. But it's not normal when during a buildworld the whole machine stops for about 10-30 seconds (stopping means the CPU is so much idle, that the machine can completely stop the fans, which during normal operation does not occur). Yes, of course this is ZFS on FreeBSD, I could write that into the subject, but if this wasn't on FreeBSD, I would wrote to the OpenSolaris list... From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 18:54: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 CB3FC106566C for ; Wed, 3 Feb 2010 18:54:00 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 911A28FC15 for ; Wed, 3 Feb 2010 18:54:00 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o13IrwTg021922; Wed, 3 Feb 2010 12:53:59 -0600 (CST) Date: Wed, 3 Feb 2010 12:53:58 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Attila Nagy In-Reply-To: <4B69BD8E.5020501@fsn.hu> Message-ID: References: <4B694689.2030704@fsn.hu> <4B69BD8E.5020501@fsn.hu> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Wed, 03 Feb 2010 12:53:59 -0600 (CST) Cc: freebsd-fs@freebsd.org Subject: Re: Machine stops for some seconds 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: Wed, 03 Feb 2010 18:54:00 -0000 On Wed, 3 Feb 2010, Attila Nagy wrote: > - I've switched back to ZFS recently, and noticing the stuff, I've written, Ok. > - during building a world from ZFS, I've noticed that the machine > occasionally goes very silent. Building world means CPU usage, CPU usage > means higher temperatures, higher temperatures mean fans spinning faster, and > fans spinning faster make a lot of noise. So the loudness is normal when it > builds world. The silency is also normal when it does not. But it's not > normal when during a buildworld the whole machine stops for about 10-30 > seconds (stopping means the CPU is so much idle, that the machine can > completely stop the fans, which during normal operation does not occur). Your previous description made it sound like the fan speed changes were quite abrupt and dramatic. If this was so, then it could indicate a software or hardware problem related to power management. For example, some needed hardware might be temporarily shut down. My wife's Apple G5 abruptly roars its fans due to a few mouse movements but I can run intense benchmarks on it for hours via a network login and the fan speed does not increase (and it does not melt) so it seems obvious that fan designs can be stupid. > Yes, of course this is ZFS on FreeBSD, I could write that into the subject, > but if this wasn't on FreeBSD, I would wrote to the OpenSolaris list... My point is that you are assuming that the issue is with ZFS since 12-days after switching to it, you encountered a problem. The problem may very well be something else such as a hardware problem, a device driver problem, or something related to power management. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Wed Feb 3 19:43:42 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 D53B11065670 for ; Wed, 3 Feb 2010 19:43:42 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 90F258FC0C for ; Wed, 3 Feb 2010 19:43:41 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id CE856209AE1; Wed, 3 Feb 2010 20:43:40 +0100 (CET) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 24.6762] X-CRM114-CacheID: sfid-20100203_20434_40AB70EA X-CRM114-Status: Good ( pR: 24.6762 ) Message-ID: <4B69D1EA.7020209@fsn.hu> Date: Wed, 03 Feb 2010 20:43:38 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Bob Friesenhahn References: <4B694689.2030704@fsn.hu> <4B69BD8E.5020501@fsn.hu> In-Reply-To: X-Stationery: 0.4.10 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (people.fsn.hu); Wed, 03 Feb 2010 20:43:39 +0100 (CET) Cc: freebsd-fs@freebsd.org Subject: Re: Machine stops for some seconds 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: Wed, 03 Feb 2010 19:43:42 -0000 Bob Friesenhahn wrote: > Your previous description made it sound like the fan speed changes > were quite abrupt and dramatic. If this was so, then it could > indicate a software or hardware problem related to power management. > For example, some needed hardware might be temporarily shut down. It seems this misguided you (or maybe others), maybe I shouldn't put that in. I've mentioned the fans spinning and not spinning issue, because my machine works OK otherwise with FreeBSD (I know), and I know how much the fan spins in normal, idle time and how much when I use 100% CPU. And compared to that, those blackouts, when there was no activity, the fan stopped. It seems to you this means a hardware failure, for me it's a clear indicator, that even the small load, which keeps it running disappeared for that time. >> Yes, of course this is ZFS on FreeBSD, I could write that into the >> subject, but if this wasn't on FreeBSD, I would wrote to the >> OpenSolaris list... > > My point is that you are assuming that the issue is with ZFS since > 12-days after switching to it, you encountered a problem. The problem > may very well be something else such as a hardware problem, a device > driver problem, or something related to power management. I'm not assuming, I know. I use ZFS on FreeBSD since it hit the tree, so I've seen a lot of odd things. I see this on a number of other machines, the difference is that those are netbooted, and hence not everything is on ZFS, so I can do things while this happens and also can work on UFS as normal. I've already written about that pretty much ago, and others were seeing the same issue (and it seems it's still with us, as you can see, I'm not the only one noticing similar problems). I would like to help to get this sorted out, but I'm not sure how. During the freeze (on the servers, not my desktop), even an NMI can't help (writes "NMI ... going to debugger" lines the number of the CPU cores the machine has and nothing happens, only hard reset solves the issue). On those machines we use a moderate amount of NFS (30-50 Mbps), so I thought this is related to it, but I ran into the same on my desktop, which of course doesn't do NFS serving. So it's not 12 days, but about two years (or when was the ZFS code imported into -CURRENT). With heavy NFS IO I can reproduce this somewhat, but I'm not sure if anyone has the time to look into the issue. As always, remote access is granted to developers, if that helps. From owner-freebsd-fs@FreeBSD.ORG Thu Feb 4 04:42:47 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 1BEC0106566B for ; Thu, 4 Feb 2010 04:42:47 +0000 (UTC) (envelope-from randysofia@gmail.com) Received: from mail-pz0-f184.google.com (mail-pz0-f184.google.com [209.85.222.184]) by mx1.freebsd.org (Postfix) with ESMTP id E96CB8FC15 for ; Thu, 4 Feb 2010 04:42:46 +0000 (UTC) Received: by pzk14 with SMTP id 14so38506pzk.3 for ; Wed, 03 Feb 2010 20:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=qgBhjzKkPhiQ81KkfLBiB49+EMzf60aTHL9q2S9uvvc=; b=NbdJJurOzovvHXX8acmo2BwjoYL13rbmzGQ9SjJdlOpmC5XbopTOs2qmlJYujithUW H5FM+2QNx+HAkKy4MsAlvAsdh5lO/AWPPuCTtV/FUUiOvHj8PlbUfB9Mgt36YWm4MAhs mWdVWLcf7+QO3snm6cLugdE/yLRW1esslmw7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=v2QDxcl/vkgOQutJyl2iT+YMvmuKBddlzYAEfp7dF2KSsbIHLw3UCvWmbupZ5IBvzN 0crcfc/YLPyp18YsEQpKIpBMnTLwOTVpR4ZloRoElgSoQ8RibeSNsH0lvupzl2FFONIQ s5Rd4vWd8TEdgPaD2nkhYuzQWHBkc3XK5Uz/k= MIME-Version: 1.0 Received: by 10.142.56.13 with SMTP id e13mr380109wfa.119.1265256877514; Wed, 03 Feb 2010 20:14:37 -0800 (PST) Date: Wed, 3 Feb 2010 23:14:37 -0500 Message-ID: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> From: Randy Sofia To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Unable to pwd in ZFS snapshot 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, 04 Feb 2010 04:42:47 -0000 `pwd` returns "No such file or directory" when browsing snapshot files. This was addressed in: http://lists.freebsd.org/pipermail/freebsd-fs/2009-February/005675.html but remains the same as of 8.0-RELEASE. I am wondering if this is the expected behavior or if this was left by the wayside. A work around is available as per the previous discussion: zfs set snapdir=visible volume Reproducible behavior: CANAAN# zfs snapshot pithos/media@0_day_ago CANAAN# cd /pithos/media/.zfs/snapshot/0_day_ago/ CANAAN# pwd pwd: .: No such file or directory CANAAN# uname -a FreeBSD CANAAN 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Fri Dec 18 00:38:33 UTC 2009 root@:/usr/obj/usr/src/sys/CANAAN amd64 --randy From owner-freebsd-fs@FreeBSD.ORG Thu Feb 4 05:00: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 8EA891065670 for ; Thu, 4 Feb 2010 05:00:11 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f178.google.com (mail-iw0-f178.google.com [209.85.223.178]) by mx1.freebsd.org (Postfix) with ESMTP id B78808FC08 for ; Thu, 4 Feb 2010 05:00:10 +0000 (UTC) Received: by iwn8 with SMTP id 8so2285508iwn.13 for ; Wed, 03 Feb 2010 21:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=pho76P14rnlZrGr+p2o0+yGfn4o7b1kzYDAix4aUhvk=; b=pviqJzCML/8ZeM2TlYNOwyrbZbqTpn28iJycaENqEzZkw4+ZsidL+d3Y8bFhZjkbtw b71R5eN0HetHrWeb0ztiz8ftIUuZm7NHm9MfuA8n/vfTGLw0yOg4IbgVPV+lMb64ZzJX VM6RJPSgrwEOmji4pUZBj2cINCRiIQXSgFSc0= 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=okDeHYHpTM2xe+Cx5QXXfd6CWJq+eEel1vZvuyd8xQRbKNwraceCk69b97d4EXpe3U /WbGqjEm5pzMRyDgTfA5nOc5uWO/8Lz7rKO5TJ1GDNnSYDNnyMXn+Z7h4Zy18Vr1+uzj U3tvaK3oNy+GdILM5aOtfioc00mHcD/sxY5yo= MIME-Version: 1.0 Received: by 10.231.150.2 with SMTP id w2mr980792ibv.90.1265259609895; Wed, 03 Feb 2010 21:00:09 -0800 (PST) In-Reply-To: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> Date: Wed, 3 Feb 2010 21:00:09 -0800 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: Unable to pwd in ZFS snapshot 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, 04 Feb 2010 05:00:11 -0000 On Wed, Feb 3, 2010 at 8:14 PM, Randy Sofia wrote: > `pwd` returns "No such file or directory" when browsing snapshot files. > This > was addressed in: > http://lists.freebsd.org/pipermail/fr > >> >> --randy >> _______________________________________________ >> 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" >> > eebsd-fs/2009-February/005675.html but > remains the same as of 8.0-RELEASE. > > I am wondering if this is the expected behavior or if this was left by the > wayside. > > A work around is available as per the previous discussion: > zfs set snapdir=visible volume > > Reproducible behavior: > CANAAN# zfs snapshot pithos/media@0_day_ago > CANAAN# cd /pithos/media/.zfs/snapshot/0_day_ago/ > CANAAN# pwd > pwd: .: No such file or directory > CANAAN# uname -a > FreeBSD CANAAN 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Fri Dec 18 00:38:33 UTC > 2009 root@:/usr/obj/usr/src/sys/CANAAN amd64 > I believe this is a "bug" in csh, in that it doesn't have a pwd shell built-in, and uses /bin/pwd. The real issue lies in /bin/pwd. It works correctly in sh, zsh, and bash, which each have pwd built-ins. As a workaround, use a non-csh-based shell. :) Doing a truss on /bin/pwd when in /home/.zfs/snapshot/2009-12-31 (I snapshot /home daily) gives the following with snapdir=hidden: __getcwd(0x28201400,1024) ERR#2 'No such file or directory' stat("/",{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 (0x0) lstat(".",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) stat("..",{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) open("..",O_NONBLOCK,05001200603) = 3 (0x3) fstat(3,{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) __sysctl(0x84bfe6a8,0x2,0x281994bc,0x84bfe6b0,0x0,0x0) = 0 (0x0) fstatfs(0x3,0x84bfe780,0x1,0x0,0x3,0x28073c94) = 0 (0x0) fstat(3,{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x28086400) = 1164 (0x48c) lstat("../2010-01-26",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-26",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-14",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-14",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-07",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-13",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-19",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-21",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-21",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-25",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-25",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-02-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-17",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-17",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-04",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-04",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-09",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-09",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-31",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-31",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lseek(3,0x0,SEEK_SET) = 0 (0x0) close(3) = 0 (0x0) lstat("../",{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) stat("../..",{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) open("../..",O_NONBLOCK,05001200603) = 3 (0x3) fstat(3,{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) fstatfs(0x3,0x84bfe780,0x1,0x0,0x3,0x28073c94) = 0 (0x0) fstat(3,{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x6cd7212) = 44 (0x2c) lseek(3,0x0,SEEK_SET) = 0 (0x0) close(3) = 0 (0x0) lstat("../../",{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) stat("../../..",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) open("../../..",O_NONBLOCK,03777777) = 3 (0x3) fstat(3,{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) fstatfs(0x3,0x84bfe780,0x1,0x0,0x3,0x28073c94) = 0 (0x0) fstat(3,{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x6cd7212) = 56 (0x38) getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x6cd7212) = 0 (0x0) lseek(3,0x0,SEEK_SET) = 0 (0x0) close(3) = 0 (0x0) And gives the following when snapdir=visible: __getcwd(0x28201400,1024) ERR#2 'No such file or directory' stat("/",{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 (0x0) lstat(".",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) stat("..",{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) open("..",O_NONBLOCK,05001200603) = 3 (0x3) fstat(3,{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) __sysctl(0x84bfe6f8,0x2,0x281994bc,0x84bfe700,0x0,0x0) = 0 (0x0) fstatfs(0x3,0x84bfe7d0,0x1,0x0,0x3,0x28073c94) = 0 (0x0) fstat(3,{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x28086400) = 1164 (0x48c) lstat("../2010-01-26",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-26",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-14",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-14",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-07",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-13",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-19",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-21",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-21",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-25",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-25",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-02-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-17",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-17",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-04",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-04",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-09",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-09",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2010-01-31",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lstat("../2009-12-31",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lseek(3,0x0,SEEK_SET) = 0 (0x0) close(3) = 0 (0x0) lstat("../",{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) stat("../..",{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) open("../..",O_NONBLOCK,05001200603) = 3 (0x3) fstat(3,{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) fstatfs(0x3,0x84bfe7d0,0x1,0x0,0x3,0x28073c94) = 0 (0x0) fstat(3,{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x6cd7212) = 44 (0x2c) lseek(3,0x0,SEEK_SET) = 0 (0x0) close(3) = 0 (0x0) lstat("../../",{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) stat("../../..",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) open("../../..",O_NONBLOCK,03777777) = 3 (0x3) fstat(3,{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) fstatfs(0x3,0x84bfe7d0,0x1,0x0,0x3,0x28073c94) = 0 (0x0) fstat(3,{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x6cd7212) = 72 (0x48) lseek(3,0x0,SEEK_SET) = 0 (0x0) close(3) = 0 (0x0) lstat("../../../",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) stat("../../../..",{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 (0x0) open("../../../..",O_NONBLOCK,03777777) = 3 (0x3) fstat(3,{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 (0x0) fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) fstatfs(0x3,0x84bfe7d0,0x1,0x0,0x3,0x28073c94) = 0 (0x0) fstat(3,{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 (0x0) getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x489629aa,0x0) = 512 (0x200) lstat("../../../../.snap",{ mode=drwxrwxr-x ,inode=3,size=512,blksize=4096 }) = 0 (0x0) lstat("../../../../dev",{ mode=dr-xr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 (0x0) lstat("../../../../etc",{ mode=drwxr-xr-x ,inode=141312,size=2560,blksize=4096 }) = 0 (0x0) lstat("../../../../cdrom",{ mode=drwxr-xr-x ,inode=211968,size=512,blksize=4096 }) = 0 (0x0) lstat("../../../../bin",{ mode=drwxr-xr-x ,inode=23552,size=1024,blksize=4096 }) = 0 (0x0) lstat("../../../../boot",{ mode=drwxr-xr-x ,inode=164864,size=1024,blksize=4096 }) = 0 (0x0) lstat("../../../../lib",{ mode=drwxr-xr-x ,inode=70656,size=2048,blksize=4096 }) = 0 (0x0) lstat("../../../../libexec",{ mode=drwxr-xr-x ,inode=117760,size=512,blksize=4096 }) = 0 (0x0) lstat("../../../../media",{ mode=drwxr-xr-x ,inode=94208,size=512,blksize=4096 }) = 0 (0x0) lstat("../../../../mnt",{ mode=drwxr-xr-x ,inode=188416,size=512,blksize=4096 }) = 0 (0x0) lstat("../../../../proc",{ mode=dr-xr-xr-x ,inode=117763,size=512,blksize=4096 }) = 0 (0x0) lstat("../../../../rescue",{ mode=drwxr-xr-x ,inode=23590,size=2560,blksize=4096 }) = 0 (0x0) lstat("../../../../root",{ mode=drwxr-xr-x ,inode=211969,size=1024,blksize=4096 }) = 0 (0x0) lstat("../../../../sbin",{ mode=drwxr-xr-x ,inode=47105,size=2560,blksize=4096 }) = 0 (0x0) lstat("../../../../tmp",{ mode=drwxrwxrwt ,inode=3,size=26,blksize=4096 }) = 0 (0x0) lstat("../../../../usr",{ mode=drwxr-xr-x ,inode=11,size=512,blksize=4096 }) = 0 (0x0) lstat("../../../../var",{ mode=drwxr-xr-x ,inode=3,size=25,blksize=4096 }) = 0 (0x0) lstat("../../../../restoresymtable",{ mode=-rw------- ,inode=4,size=1948892,blksize=4096 }) = 0 (0x0) lstat("../../../../sys",{ mode=lrwxr-xr-x ,inode=8,size=11,blksize=4096 }) = 0 (0x0) lstat("../../../../COPYRIGHT",{ mode=-r--r--r-- ,inode=12,size=6198,blksize=4096 }) = 0 (0x0) lstat("../../../../compat",{ mode=lrwxrwxrwx ,inode=7,size=10,blksize=4096 }) = 0 (0x0) lstat("../../../../home",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) lseek(3,0x0,SEEK_SET) = 0 (0x0) close(3) = 0 (0x0) lstat("../../../../",{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 (0x0) fstat(1,{ mode=crw--w---- ,inode=145,size=0,blksize=4096 }) = 0 (0x0) ioctl(1,TIOCGETA,0x84bfea10) = 0 (0x0) /home/.zfs/snapshot/2009-12-31 write(1,"/home/.zfs/snapshot/2009-12-31\n",31) = 31 (0x1f) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Thu Feb 4 12:57: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 CFCE5106566C for ; Thu, 4 Feb 2010 12:57:33 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 5AE588FC26 for ; Thu, 4 Feb 2010 12:57:33 +0000 (UTC) Received: by ewy3 with SMTP id 3so307938ewy.13 for ; Thu, 04 Feb 2010 04:57:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=mbZJIGIJB1gtJ6pShBTxJYUyS3UYKw1EzqraJpqWrXw=; b=U5nVCijjlPYAMtqqlhQ6/X14rICJc15lL6nOLahLNTPwHhdhfSPQ7n+2GuAvXKcUK3 nGA+VQyTXutkfIGaJKPCDjSyTCKhWJrDW06EN4Nuj0/o+TVkwDGnqfpwaNpgVyxaX5TI qeNSeb9BTrwbceP9FQllH2C69EfkCjiKxfxuU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=xtPaUtRJlsZ94RYKnbLmbCdf0HizXLpyTVcOV9Pedp8L0l/E+BxATBDbEinnWjlEcv Zf8/ayC0J7/QFGoBiI7D+FSn1INDJkU5QSqZkDOlYnCTYjNKgoYehGci8c74xuKBm0pq oTWxX/3PeX1zcnI2drLr97ty8FO+9NT2y8j78= Received: by 10.213.107.69 with SMTP id a5mr937868ebp.73.1265288251951; Thu, 04 Feb 2010 04:57:31 -0800 (PST) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id 14sm66226ewy.3.2010.02.04.04.57.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 04:57:31 -0800 (PST) Date: Thu, 4 Feb 2010 14:57:26 +0200 From: Gleb Kurtsou To: Freddie Cash Message-ID: <20100204125726.GB5784@tops.skynet.lt> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: Unable to pwd in ZFS snapshot 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, 04 Feb 2010 12:57:33 -0000 On (03/02/2010 21:00), Freddie Cash wrote: > On Wed, Feb 3, 2010 at 8:14 PM, Randy Sofia wrote: > > > `pwd` returns "No such file or directory" when browsing snapshot files. > > This > > was addressed in: > > http://lists.freebsd.org/pipermail/fr > > > >> > >> --randy > > eebsd-fs/2009-February/005675.html but > > remains the same as of 8.0-RELEASE. > > > > I am wondering if this is the expected behavior or if this was left by the > > wayside. > > > > A work around is available as per the previous discussion: > > zfs set snapdir=visible volume > > > > Reproducible behavior: > > CANAAN# zfs snapshot pithos/media@0_day_ago > > CANAAN# cd /pithos/media/.zfs/snapshot/0_day_ago/ > > CANAAN# pwd > > pwd: .: No such file or directory > > CANAAN# uname -a > > FreeBSD CANAAN 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Fri Dec 18 00:38:33 UTC > > 2009 root@:/usr/obj/usr/src/sys/CANAAN amd64 > > > > I believe this is a "bug" in csh, in that it doesn't have a pwd shell > built-in, and uses /bin/pwd. The real issue lies in /bin/pwd. > > It works correctly in sh, zsh, and bash, which each have pwd built-ins. As > a workaround, use a non-csh-based shell. :) /bin/pwd is absolutely correct! It's filesystems that fail to set inode numbers correctly. Try using pwd in fuse-sshfs (it completely ignores inode numbers). pwd builtins cache current working directory, thus just work. All inode numbers are the same for snapshot entries. I'll try to find time to look into it on the weekend. On my machine: /home/.zfs/snapshot % ls 2009-12-05 2009-12-25 2010-02-04 /home/.zfs/snapshot % stat -s * st_dev=735101931 st_ino=3 st_mode=040755 st_nlink=4 st_uid=0 st_gid=0 st_rdev=0 st_size=4 st_atime=1259939945 st_mtime=1259945157 st_ctime=1259945157 st_birthtime=1259939945 st_blksize=4096 st_blocks=3 st_flags=0 st_dev=2095450778 st_ino=3 st_mode=040755 st_nlink=5 st_uid=0 st_gid=0 st_rdev=0 st_size=5 st_atime=1259939945 st_mtime=1260923930 st_ctime=1260923930 st_birthtime=1259939945 st_blksize=4096 st_blocks=3 st_flags=0 st_dev=2506498978 st_ino=3 st_mode=040755 st_nlink=5 st_uid=0 st_gid=0 st_rdev=0 st_size=5 st_atime=1259939945 st_mtime=1263206215 st_ctime=1263206215 st_birthtime=1259939945 st_blksize=4096 st_blocks=3 st_flags=0 > > Doing a truss on /bin/pwd when in /home/.zfs/snapshot/2009-12-31 (I snapshot > /home daily) gives the following with snapdir=hidden: > > __getcwd(0x28201400,1024) ERR#2 'No such file or > directory' > stat("/",{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 (0x0) > lstat(".",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) > stat("..",{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) > open("..",O_NONBLOCK,05001200603) = 3 (0x3) > fstat(3,{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) > __sysctl(0x84bfe6a8,0x2,0x281994bc,0x84bfe6b0,0x0,0x0) = 0 (0x0) > fstatfs(0x3,0x84bfe780,0x1,0x0,0x3,0x28073c94) = 0 (0x0) > fstat(3,{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) > getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x28086400) = 1164 > (0x48c) > lstat("../2010-01-26",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-26",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-14",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-14",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-07",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-13",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-19",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-21",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-21",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-25",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-25",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-02-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-17",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-17",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-04",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-04",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-09",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-09",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-31",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-31",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lseek(3,0x0,SEEK_SET) = 0 (0x0) > close(3) = 0 (0x0) > lstat("../",{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 (0x0) > stat("../..",{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) > open("../..",O_NONBLOCK,05001200603) = 3 (0x3) > fstat(3,{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) > fstatfs(0x3,0x84bfe780,0x1,0x0,0x3,0x28073c94) = 0 (0x0) > fstat(3,{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) > getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x6cd7212) = 44 > (0x2c) > lseek(3,0x0,SEEK_SET) = 0 (0x0) > close(3) = 0 (0x0) > lstat("../../",{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 (0x0) > stat("../../..",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) > open("../../..",O_NONBLOCK,03777777) = 3 (0x3) > fstat(3,{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0) > fstatfs(0x3,0x84bfe780,0x1,0x0,0x3,0x28073c94) = 0 (0x0) > fstat(3,{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 (0x0) > getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x6cd7212) = 56 > (0x38) > getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x6cd7212) = 0 > (0x0) > lseek(3,0x0,SEEK_SET) = 0 (0x0) > close(3) = 0 (0x0) > > > And gives the following when snapdir=visible: > __getcwd(0x28201400,1024) ERR#2 'No such file or > directory' > stat("/",{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 > (0x0) > lstat(".",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > stat("..",{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 > (0x0) > open("..",O_NONBLOCK,05001200603) = 3 > (0x3) > fstat(3,{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 > (0x0) > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 > (0x0) > __sysctl(0x84bfe6f8,0x2,0x281994bc,0x84bfe700,0x0,0x0) = 0 > (0x0) > fstatfs(0x3,0x84bfe7d0,0x1,0x0,0x3,0x28073c94) = 0 > (0x0) > fstat(3,{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 > (0x0) > getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x28086400) = 1164 > (0x48c) > lstat("../2010-01-26",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-26",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-14",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-14",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-07",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-13",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-19",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-21",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-21",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-25",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-25",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-02-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-17",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-17",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-04",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-04",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-09",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-09",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-03",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2010-01-31",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lstat("../2009-12-31",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > lseek(3,0x0,SEEK_SET) = 0 > (0x0) > close(3) = 0 > (0x0) > lstat("../",{ mode=dr-xr-xr-x ,inode=2,size=24,blksize=4096 }) = 0 > (0x0) > stat("../..",{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 > (0x0) > open("../..",O_NONBLOCK,05001200603) = 3 > (0x3) > fstat(3,{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 > (0x0) > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 > (0x0) > fstatfs(0x3,0x84bfe7d0,0x1,0x0,0x3,0x28073c94) = 0 > (0x0) > fstat(3,{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 > (0x0) > getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x6cd7212) = 44 > (0x2c) > lseek(3,0x0,SEEK_SET) = 0 > (0x0) > close(3) = 0 > (0x0) > lstat("../../",{ mode=dr-xr-xr-x ,inode=1,size=3,blksize=4096 }) = 0 > (0x0) > stat("../../..",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > open("../../..",O_NONBLOCK,03777777) = 3 > (0x3) > fstat(3,{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 > (0x0) > fstatfs(0x3,0x84bfe7d0,0x1,0x0,0x3,0x28073c94) = 0 > (0x0) > fstat(3,{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x484328eb,0x6cd7212) = 72 > (0x48) > lseek(3,0x0,SEEK_SET) = 0 > (0x0) > close(3) = 0 > (0x0) > lstat("../../../",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = 0 > (0x0) > stat("../../../..",{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 > (0x0) > open("../../../..",O_NONBLOCK,03777777) = 3 > (0x3) > fstat(3,{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 > (0x0) > fcntl(3,F_SETFD,FD_CLOEXEC) = 0 > (0x0) > fstatfs(0x3,0x84bfe7d0,0x1,0x0,0x3,0x28073c94) = 0 > (0x0) > fstat(3,{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 > (0x0) > getdirentries(0x3,0x2820e000,0x1000,0x2820d054,0x489629aa,0x0) = 512 > (0x200) > lstat("../../../../.snap",{ mode=drwxrwxr-x ,inode=3,size=512,blksize=4096 > }) = 0 (0x0) > lstat("../../../../dev",{ mode=dr-xr-xr-x ,inode=2,size=512,blksize=4096 }) > = 0 (0x0) > lstat("../../../../etc",{ mode=drwxr-xr-x > ,inode=141312,size=2560,blksize=4096 }) = 0 (0x0) > lstat("../../../../cdrom",{ mode=drwxr-xr-x > ,inode=211968,size=512,blksize=4096 }) = 0 (0x0) > lstat("../../../../bin",{ mode=drwxr-xr-x > ,inode=23552,size=1024,blksize=4096 }) = 0 (0x0) > lstat("../../../../boot",{ mode=drwxr-xr-x > ,inode=164864,size=1024,blksize=4096 }) = 0 (0x0) > lstat("../../../../lib",{ mode=drwxr-xr-x > ,inode=70656,size=2048,blksize=4096 }) = 0 (0x0) > lstat("../../../../libexec",{ mode=drwxr-xr-x > ,inode=117760,size=512,blksize=4096 }) = 0 (0x0) > lstat("../../../../media",{ mode=drwxr-xr-x > ,inode=94208,size=512,blksize=4096 }) = 0 (0x0) > lstat("../../../../mnt",{ mode=drwxr-xr-x > ,inode=188416,size=512,blksize=4096 }) = 0 (0x0) > lstat("../../../../proc",{ mode=dr-xr-xr-x > ,inode=117763,size=512,blksize=4096 }) = 0 (0x0) > lstat("../../../../rescue",{ mode=drwxr-xr-x > ,inode=23590,size=2560,blksize=4096 }) = 0 (0x0) > lstat("../../../../root",{ mode=drwxr-xr-x > ,inode=211969,size=1024,blksize=4096 }) = 0 (0x0) > lstat("../../../../sbin",{ mode=drwxr-xr-x > ,inode=47105,size=2560,blksize=4096 }) = 0 (0x0) > lstat("../../../../tmp",{ mode=drwxrwxrwt ,inode=3,size=26,blksize=4096 }) = > 0 (0x0) > lstat("../../../../usr",{ mode=drwxr-xr-x ,inode=11,size=512,blksize=4096 }) > = 0 (0x0) > lstat("../../../../var",{ mode=drwxr-xr-x ,inode=3,size=25,blksize=4096 }) = > 0 (0x0) > lstat("../../../../restoresymtable",{ mode=-rw------- > ,inode=4,size=1948892,blksize=4096 }) = 0 (0x0) > lstat("../../../../sys",{ mode=lrwxr-xr-x ,inode=8,size=11,blksize=4096 }) = > 0 (0x0) > lstat("../../../../COPYRIGHT",{ mode=-r--r--r-- > ,inode=12,size=6198,blksize=4096 }) = 0 (0x0) > lstat("../../../../compat",{ mode=lrwxrwxrwx ,inode=7,size=10,blksize=4096 > }) = 0 (0x0) > lstat("../../../../home",{ mode=drwxr-xr-x ,inode=3,size=4,blksize=4096 }) = > 0 (0x0) > lseek(3,0x0,SEEK_SET) = 0 > (0x0) > close(3) = 0 > (0x0) > lstat("../../../../",{ mode=drwxr-xr-x ,inode=2,size=512,blksize=4096 }) = 0 > (0x0) > fstat(1,{ mode=crw--w---- ,inode=145,size=0,blksize=4096 }) = 0 > (0x0) > ioctl(1,TIOCGETA,0x84bfea10) = 0 > (0x0) > /home/.zfs/snapshot/2009-12-31 > > write(1,"/home/.zfs/snapshot/2009-12-31\n",31) = 31 > (0x1f) > > > -- > Freddie Cash > fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Thu Feb 4 18: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 2E6D11065670 for ; Thu, 4 Feb 2010 18: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 04AD48FC1B for ; Thu, 4 Feb 2010 18:40:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o14Ie4t7049654 for ; Thu, 4 Feb 2010 18:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o14Ie4Ol049653; Thu, 4 Feb 2010 18:40:04 GMT (envelope-from gnats) Date: Thu, 4 Feb 2010 18:40:04 GMT Message-Id: <201002041840.o14Ie4Ol049653@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Pedro F. Giffuni" Cc: Subject: Re: kern/142597: [ext2fs] ext2fs does not work on filesystems with really big directories X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Pedro F. Giffuni" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 18:40:05 -0000 The following reply was made to PR kern/142597; it has been noted by GNATS. From: "Pedro F. Giffuni" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/142597: [ext2fs] ext2fs does not work on filesystems with really big directories Date: Thu, 4 Feb 2010 10:33:16 -0800 (PST) --0-388987257-1265308396=:19947 Content-Type: text/plain; charset=us-ascii A bug was recently found in UFS that may be related: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+current/freebsd-fs I made a similar patch for the BSD-licensed ext2fs and, while here, I fixed some typos that were also cleaned from UFS. --0-388987257-1265308396=:19947 Content-Type: application/octet-stream; name="patch-ext2_alloc.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-ext2_alloc.c" LS0tIC4uL2V4dDJmcy5ic2QvZXh0Ml9hbGxvYy5jCTIwMTAtMDEtMTcgMTk6 MDA6NDcuMDAwMDAwMDAwICswMDAwCisrKyBleHQyX2FsbG9jLmMJMjAxMC0w Mi0wNCAxMzoyMDoxNC4wMDAwMDAwMDAgKzAwMDAKQEAgLTYwLDcgKzYwLDcg QEAKIHN0YXRpYyBkYWRkcl90CWV4dDJfbm9kZWFsbG9jY2coc3RydWN0IGlu b2RlICosIGludCwgZGFkZHJfdCwgaW50KTsKIHN0YXRpYyBkYWRkcl90ICBl eHQyX21hcHNlYXJjaChzdHJ1Y3QgbV9leHQyZnMgKiwgY2hhciAqLCBkYWRk cl90KTsKIC8qCi0gKiBBbGxvY2F0ZSBhIGJsb2NrIGluIHRoZSBmaWxlIHN5 c3RlbS4KKyAqIEFsbG9jYXRlIGEgYmxvY2sgaW4gdGhlIGZpbGVzeXN0ZW0u CiAgKgogICogQSBwcmVmZXJlbmNlIG1heSBiZSBvcHRpb25hbGx5IHNwZWNp ZmllZC4gSWYgYSBwcmVmZXJlbmNlIGlzIGdpdmVuCiAgKiB0aGUgZm9sbG93 aW5nIGhpZXJhcmNoeSBpcyB1c2VkIHRvIGFsbG9jYXRlIGEgYmxvY2s6CkBA IC0xMzcsOCArMTM3LDggQEAKICAgICAgICAgfQogbm9zcGFjZToKIAlFWFQy X1VOTE9DSyh1bXApOwotCWV4dDJfZnNlcnIoZnMsIGNyZWQtPmNyX3VpZCwg ImZpbGUgc3lzdGVtIGZ1bGwiKTsKLQl1cHJpbnRmKCJcbiVzOiB3cml0ZSBm YWlsZWQsIGZpbGUgc3lzdGVtIGlzIGZ1bGxcbiIsIGZzLT5lMmZzX2ZzbW50 KTsKKwlleHQyX2ZzZXJyKGZzLCBjcmVkLT5jcl91aWQsICJmaWxlc3lzdGVt IGZ1bGwiKTsKKwl1cHJpbnRmKCJcbiVzOiB3cml0ZSBmYWlsZWQsIGZpbGVz eXN0ZW0gaXMgZnVsbFxuIiwgZnMtPmUyZnNfZnNtbnQpOwogCXJldHVybiAo RU5PU1BDKTsKIH0KIApAQCAtMzMyLDcgKzMzMiw3IEBACiB9CiAKIC8qCi0g KiBBbGxvY2F0ZSBhbiBpbm9kZSBpbiB0aGUgZmlsZSBzeXN0ZW0uCisgKiBB bGxvY2F0ZSBhbiBpbm9kZSBpbiB0aGUgZmlsZXN5c3RlbS4KICAqIAogICov CiBpbnQKQEAgLTc5MCw3ICs3OTAsNyBAQAogCX0KIAlFWFQyX1VOTE9DSyh1 bXApOwogCWJkd3JpdGUoYnApOwotCXJldHVybiAoY2cgKiBmcy0+ZTJmcy0+ ZTJmc19pcGcgKyBpcHJlZiArMSk7CisJcmV0dXJuICgodW5zaWduZWQgaW50 KWNnICogZnMtPmUyZnMtPmUyZnNfaXBnICsgaXByZWYgKzEpOwogfQogCiAv KgpAQCAtOTQyLDcgKzk0Miw3IEBACiB9CiAKIC8qCi0gKiBGc2VyciBwcmlu dHMgdGhlIG5hbWUgb2YgYSBmaWxlIHN5c3RlbSB3aXRoIGFuIGVycm9yIGRp YWdub3N0aWMuCisgKiBGc2VyciBwcmludHMgdGhlIG5hbWUgb2YgYSBmaWxl c3lzdGVtIHdpdGggYW4gZXJyb3IgZGlhZ25vc3RpYy4KICAqIAogICogVGhl IGZvcm0gb2YgdGhlIGVycm9yIG1lc3NhZ2UgaXM6CiAgKglmczogZXJyb3Ig bWVzc2FnZQo= --0-388987257-1265308396=:19947-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 4 20:56:01 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 3ADFD106568B; Thu, 4 Feb 2010 20:56:01 +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 760BA8FC19; Thu, 4 Feb 2010 20:55:59 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 851F845CBA; Thu, 4 Feb 2010 21:55:56 +0100 (CET) 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 44B7A45C8C; Thu, 4 Feb 2010 21:55:51 +0100 (CET) Date: Thu, 4 Feb 2010 21:55:46 +0100 From: Pawel Jakub Dawidek To: Randy Sofia Message-ID: <20100204205546.GA1733@garage.freebsd.pl> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.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 i386 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@freebsd.org, Jaakko Heinonen Subject: Re: Unable to pwd in ZFS snapshot 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, 04 Feb 2010 20:56:01 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 03, 2010 at 11:14:37PM -0500, Randy Sofia wrote: > `pwd` returns "No such file or directory" when browsing snapshot files. T= his > was addressed in: > http://lists.freebsd.org/pipermail/freebsd-fs/2009-February/005675.html = but > remains the same as of 8.0-RELEASE. >=20 > I am wondering if this is the expected behavior or if this was left by the > wayside. >=20 > A work around is available as per the previous discussion: > zfs set snapdir=3Dvisible volume >=20 > Reproducible behavior: > CANAAN# zfs snapshot pithos/media@0_day_ago > CANAAN# cd /pithos/media/.zfs/snapshot/0_day_ago/ > CANAAN# pwd > pwd: .: No such file or directory > CANAAN# uname -a > FreeBSD CANAAN 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Fri Dec 18 00:38:33 UTC > 2009 root@:/usr/obj/usr/src/sys/CANAAN amd64 It was reported to me by Jaakko some time ago, that r197513 (committed by me) is responsible for this breakage. Unfortunately I had no time to fix it yet. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktrNFIACgkQForvXbEpPzQbpwCg70a3azuet1EwIe4BxuFA7k5H sU4An1CpB2bLorGTYPLWYj8gdODVaY2y =0cTD -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 4 21:05: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 F2A561065692 for ; Thu, 4 Feb 2010 21:05: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 345148FC13 for ; Thu, 4 Feb 2010 21:05:33 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id CA69E45E11; Thu, 4 Feb 2010 22:05:31 +0100 (CET) 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 4DCF645CD9; Thu, 4 Feb 2010 22:05:26 +0100 (CET) Date: Thu, 4 Feb 2010 22:05:22 +0100 From: Pawel Jakub Dawidek To: Lorenzo Perone Message-ID: <20100204210522.GB1733@garage.freebsd.pl> References: <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> <9B1DF836-0CCC-4CB2-B83C-3040428A7344@yellowspace.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5/uDoXvLw7AC5HRs" Content-Disposition: inline In-Reply-To: <9B1DF836-0CCC-4CB2-B83C-3040428A7344@yellowspace.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 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@freebsd.org Subject: Re: Any news on the HAST Project? 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, 04 Feb 2010 21:05:34 -0000 --5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 03, 2010 at 03:53:37PM +0100, Lorenzo Perone wrote: >=20 > On 28.01.2010, at 14:26, Hywel Mallett wrote: >=20 > > About the same time a status update was posted on the FreeBSD Foundatio= n blog at http://freebsdfoundation.blogspot.com/2009/12/update-on-hast-proj= ect.html >=20 > Thanx, also to pjd's answer. That gives some nice insight already. Great = work! HAST could in fact change radically the way of using block devices an= d distributing mass storage. I look forward to testing it first on a few vb= oxes and shortly thereafter on real machines.=20 >=20 > Really curious on how several things are implemented, e.g. performance / = latency / fail / sync issues (what happens for example when a big huge file= is written locally on a very fast primary, and there is not enough ram to = buffer it before sending it to a secondary.. etc, scenarios like that).=20 Every write request is handled synchronously by HAST. It is reported as completed only when it is stored on local and on remote node. > And how well it will do with ZFS too: although ZFS has its 'own' HAST via= send/recv (and besides might get its own implementation for some sort of '= streaming' send/recv..) it is also true that it'd allow for some great flex= ibility in creating primary/secondary volumes (zvols). Just imagining a sce= nario with sparse zvols and HAST disting them around.. ok ok I stop here :-) ZFS send/recv is something else. It can't work synchronously, where HAST works always that way. This means that when your primary node dies you won't lose even a single bit of data. Although be aware that file systems like UFS can be in inconsistent state after primary failure, so secondary node after switching to primary role has to check file system with fsck(8) before mounting it. This also makes ZFS great choice for running on HAST as 'zpool import' is very fast as oppose to fsck (at least until Jeff finish his SU+J project). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --5/uDoXvLw7AC5HRs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktrNpEACgkQForvXbEpPzQQEQCfdakqsJSq50R58VVjxZzSuTmf q94AoNijgS01r0mu9DlZZg1DbUdBCavb =DtXb -----END PGP SIGNATURE----- --5/uDoXvLw7AC5HRs-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 4 21:12:50 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 77B361065694 for ; Thu, 4 Feb 2010 21:12:50 +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 B18628FC17 for ; Thu, 4 Feb 2010 21:12:49 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 34E9445D8D; Thu, 4 Feb 2010 22:12:48 +0100 (CET) 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 E3C3545CBA; Thu, 4 Feb 2010 22:12:42 +0100 (CET) Date: Thu, 4 Feb 2010 22:12:38 +0100 From: Pawel Jakub Dawidek To: Michael Reifenberger Message-ID: <20100204211238.GC1733@garage.freebsd.pl> References: <20100130220221.GC1660@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xesSdrSSBC0PokLI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 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@freebsd.org Subject: Re: zpool create fails on gpart 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: Thu, 04 Feb 2010 21:12:50 -0000 --xesSdrSSBC0PokLI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 30, 2010 at 11:30:33PM +0100, Michael Reifenberger wrote: > On Sat, 30 Jan 2010, Pawel Jakub Dawidek wrote: > ... > >>Unfortunately I get the same symptom when trying to create a new pool= =20 > >>using > >>newly attached ada devices: > >[...] > > > >I got no response how the patch works. Maybe you could try it? > > > > http://people.freebsd.org/~pjd/patches/vdev_geom.c.2.patch > > >=20 > The patch works for me (after removing the ';' in line 414): >=20 > ... > pool: z > state: ONLINE > scrub: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > z ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > ada0p3 ONLINE 0 0 0 > ada1p3 ONLINE 0 0 0 > ada2p3 ONLINE 0 0 0 > ada3p3 ONLINE 0 0 0 > ada4p3 ONLINE 0 0 0 > ada5p3 ONLINE 0 0 0 >=20 > errors: No known data errors > ... >=20 > If you feel comftable with the patch, > should I commit the fix to HEAD? >=20 > Thanks for fixing! I just committed it. Thanks for reporting and testing! --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --xesSdrSSBC0PokLI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktrOEYACgkQForvXbEpPzRkIgCgriWAY2gWH5qugMEvXmzsCO9z Av8AoJcQGNmnkujxB17TVpL4i+KCH1xU =aQof -----END PGP SIGNATURE----- --xesSdrSSBC0PokLI-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 4 22:46:12 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 81B401065695; Thu, 4 Feb 2010 22:46:12 +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 5919A8FC1E; Thu, 4 Feb 2010 22:46:11 +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 AAA02408; Fri, 05 Feb 2010 00:46:07 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NdASd-0004N1-2x; Fri, 05 Feb 2010 00:46:07 +0200 Message-ID: <4B6B4E2E.2010902@icyb.net.ua> Date: Fri, 05 Feb 2010 00:46:06 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: Stephane LAPIE References: <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua> <4B686324.2090308@elischer.org> <4B68641D.9000201@icyb.net.ua> <4B695CA3.50008@darkbsd.org> In-Reply-To: <4B695CA3.50008@darkbsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Julian Elischer , freebsd-hardware@freebsd.org Subject: Re: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE 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, 04 Feb 2010 22:46:12 -0000 on 03/02/2010 13:23 Stephane LAPIE said the following: > > I just rebuilt a kernel with debugger options, and obtained the > following output upon pulling out one disk : > > Sleeping thread (tid 100024, pid 0) owns a non-sleepable lock > sched_switch() at sched_switch+0xf8 > mi_switch() at mi_switch+0x16f > sleepq_timedwait() at sleepq_timedwait+0x42 > _cv_timedwait() at _cv_timedwait+0x129 > _sema_timedwait() at _sema_timedwait+0x55 > ata_queue_request() at ata_queue_request+0x526 > ata_controlcmd() at ata_controlcmd+0xa1 > ata_setmode() at ata_setmode+0xdc > ad_init() at ad_init+0x27 > ad_reinit() at ad_reinit+0x48 > ata_reinit() at ata_reinit+0x268 > ata_conn_event() at ata_conn_event+0x49 > taskqueue_run() at taskqueue_run+0x93 > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff80000aad30, rbp = 0 --- > panic: sleeping thread > cpuid = 2 > KDB: enter: panic > [thread pid 12 tid 100008 ] > Stopped at kdb_enter+0x3d: movq $0,0x4943d0(%rip) Not sure if I can derive anything useful from here. Someone with more expertise is needed. One thing I noticed is that ata_conn_event and ata_reinit and some other functions up the stack acquire state_mtx recursively, but the mutex is not initialized with MTX_RECURSE. Perhaps, indeed you would have a better luck with AHCI controller _and_ ahci(4) driver. It seems to handle dynamic coming and going of disks much better than ata(4). -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Feb 5 01:12: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 7A17D106566B; Fri, 5 Feb 2010 01:12:38 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC238FC08; Fri, 5 Feb 2010 01:12:33 +0000 (UTC) Received: by ewy3 with SMTP id 3so1047366ewy.13 for ; Thu, 04 Feb 2010 17:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=HJRZ7Pd8B4v2j2xixwq6kBnQRfDbvopjPGH6W68c+AA=; b=gstA1lrKJm9F+0av5vdKpM0bGOMkoUs/rNoCcDcUTYMduhmarLX+opc41LVwIuaOdo YUVy5/vLtmZZc/2HmZ1XORCN3J+1HYkBgY1k485KOPP5HeFVTd0YApyPC+CxA0vhksny 05Vkl+pn+Wk6ywjBOr4imrxBHePg5b2SlaK4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=PzgNliGqtrl5/1SdSF1vsAg3CS7FoZtmLJE/ELh5rDazBZ97Tnfm8lJtsJaWHGIzBF BpRnEXDTrKgVgqe0ywLp/47TKkkj8LYqXUPwBV7S/v8zMTmva2mnYNlhCAXUE4vlHV9Z nqIpRKxXKT6/XZHPgvs+mB2laD+mNFFlbA4ig= Received: by 10.213.100.203 with SMTP id z11mr479ebn.43.1265332352553; Thu, 04 Feb 2010 17:12:32 -0800 (PST) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id 7sm3780368eyb.26.2010.02.04.17.12.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 17:12:31 -0800 (PST) Date: Fri, 5 Feb 2010 03:12:26 +0200 From: Gleb Kurtsou To: Pawel Jakub Dawidek Message-ID: <20100205011226.GA2657@tops.skynet.lt> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> <20100204205546.GA1733@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <20100204205546.GA1733@garage.freebsd.pl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Jaakko Heinonen Subject: Re: Unable to pwd in ZFS snapshot 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, 05 Feb 2010 01:12:38 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On (04/02/2010 21:55), Pawel Jakub Dawidek wrote: > On Wed, Feb 03, 2010 at 11:14:37PM -0500, Randy Sofia wrote: > > `pwd` returns "No such file or directory" when browsing snapshot files. This > > was addressed in: > > http://lists.freebsd.org/pipermail/freebsd-fs/2009-February/005675.html but > > remains the same as of 8.0-RELEASE. > > > > I am wondering if this is the expected behavior or if this was left by the > > wayside. > > > > A work around is available as per the previous discussion: > > zfs set snapdir=visible volume > > > > Reproducible behavior: > > CANAAN# zfs snapshot pithos/media@0_day_ago > > CANAAN# cd /pithos/media/.zfs/snapshot/0_day_ago/ > > CANAAN# pwd > > pwd: .: No such file or directory > > CANAAN# uname -a > > FreeBSD CANAAN 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Fri Dec 18 00:38:33 UTC > > 2009 root@:/usr/obj/usr/src/sys/CANAAN amd64 > > It was reported to me by Jaakko some time ago, that r197513 (committed > by me) is responsible for this breakage. Unfortunately I had no time to > fix it yet. It looks like pwd gets puzzled by all inodes having the same inode number under .zfs/snapshot. Besides we're trying to hide a fact that each snapshot is actually a mount point. Comments in zfs_ctldir.c explain the inode numbering scheme under .zfs in detail, each snapshot node has to have unique inode number. Correct inode number is returned by READDIR call, but not by GETATTR for the same vnode. This breaks our pwd (getcwd). The patch attached adds a hack to VOP_GETATTR to return expected inode numbers. Also, with r197513 reverted all inode numbers are still the same, but it seems to work as expected. Unfortunately I have no OpenSolaris installed to verify if inode numbers are also the same there. I think I should file a PR for the issue, so it doesn't get lost, what do you think? > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="zfs-snapshot-pwd.patch.txt" diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c index 7820293..bb7e0ae 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c @@ -1061,6 +1061,7 @@ zfsctl_snapshot_mknode(vnode_t *pvp, uint64_t objset) VN_HOLD(vp); zcp = vp->v_data; zcp->zc_id = objset; + gfs_file_set_inode(vp, objset); VFS_HOLD(vp->v_vfsp); VOP_UNLOCK(vp, 0); diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c index 4f61f5f..19a3738 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -2371,6 +2372,15 @@ zfs_getattr(vnode_t *vp, vattr_t *vap, int flags, cred_t *cr, zfs_fuid_map_ids(zp, cr, &vap->va_uid, &vap->va_gid); // vap->va_fsid = zp->z_zfsvfs->z_vfs->vfs_dev; vap->va_nodeid = zp->z_id; + /* + * XXX Should root inode number for every mounted zfs + * filesystem/snapshot be the same? + * VROOT flag gets removed from the vp in zfsctl_snapdir_lookup + */ + if (zfsvfs->z_issnap && zp->z_id == zfsvfs->z_root) { + vnode_t *svp = zfsvfs->z_vfs->mnt_vnodecovered; + vap->va_nodeid = gfs_file_inode(svp); + } if ((vp->v_flag & VROOT) && zfs_show_ctldir(zp)) links = pzp->zp_links + 1; else --4Ckj6UjgE2iN1+kY-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 5 06:35:53 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 3316F106566C; Fri, 5 Feb 2010 06:35:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2908FC13; Fri, 5 Feb 2010 06:35:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o156ZqCS072228; Fri, 5 Feb 2010 06:35:52 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o156ZqLX072224; Fri, 5 Feb 2010 06:35:52 GMT (envelope-from linimon) Date: Fri, 5 Feb 2010 06:35:52 GMT Message-Id: <201002050635.o156ZqLX072224@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-fs@FreeBSD.org, freebsd-bugs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141235: [ata] 8.0 no longer provides /dev entries for all disk slices [regression] 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, 05 Feb 2010 06:35:53 -0000 Old Synopsis: [disklabel] 8.0 no longer provides /dev entries for all disk slices [regression] New Synopsis: [ata] 8.0 no longer provides /dev entries for all disk slices [regression] Responsible-Changed-From-To: freebsd-fs->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 5 06:33:28 UTC 2010 Responsible-Changed-Why: On looking at this again, I'm wondering if it might not be a problem with the ata rework, instead. http://www.freebsd.org/cgi/query-pr.cgi?pr=141235 From owner-freebsd-fs@FreeBSD.ORG Fri Feb 5 10:21: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 A0BAD106566B for ; Fri, 5 Feb 2010 10:21:36 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3ACCE8FC13 for ; Fri, 5 Feb 2010 10:21:36 +0000 (UTC) Received: from [195.4.92.24] (helo=14.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NdLJf-0002xC-2U; Fri, 05 Feb 2010 11:21:35 +0100 Received: from p57ae1515.dip0.t-ipconnect.de ([87.174.21.21]:31076 helo=ernst.jennejohn.org) by 14.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #1) id 1NdLJe-0006uO-Ep; Fri, 05 Feb 2010 11:21:34 +0100 Date: Fri, 5 Feb 2010 11:21:32 +0100 From: Gary Jennejohn To: freebsd-fs@freebsd.org Message-ID: <20100205112132.184eb12b@ernst.jennejohn.org> In-Reply-To: <20100204210522.GB1733@garage.freebsd.pl> References: <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> <9B1DF836-0CCC-4CB2-B83C-3040428A7344@yellowspace.net> <20100204210522.GB1733@garage.freebsd.pl> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: Any news on the HAST Project? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 10:21:36 -0000 On Thu, 4 Feb 2010 22:05:22 +0100 Pawel Jakub Dawidek wrote: > On Wed, Feb 03, 2010 at 03:53:37PM +0100, Lorenzo Perone wrote: > > > > On 28.01.2010, at 14:26, Hywel Mallett wrote: > > > > > About the same time a status update was posted on the FreeBSD Foundation blog at http://freebsdfoundation.blogspot.com/2009/12/update-on-hast-project.html > > > > Thanx, also to pjd's answer. That gives some nice insight already. Great work! HAST could in fact change radically the way of using block devices and distributing mass storage. I look forward to testing it first on a few vboxes and shortly thereafter on real machines. > > > > Really curious on how several things are implemented, e.g. performance / latency / fail / sync issues (what happens for example when a big huge file is written locally on a very fast primary, and there is not enough ram to buffer it before sending it to a secondary.. etc, scenarios like that). > > Every write request is handled synchronously by HAST. It is reported as > completed only when it is stored on local and on remote node. > > > And how well it will do with ZFS too: although ZFS has its 'own' HAST via send/recv (and besides might get its own implementation for some sort of 'streaming' send/recv..) it is also true that it'd allow for some great flexibility in creating primary/secondary volumes (zvols). Just imagining a scenario with sparse zvols and HAST disting them around.. ok ok I stop here :-) > > ZFS send/recv is something else. It can't work synchronously, where HAST > works always that way. This means that when your primary node dies you > won't lose even a single bit of data. > > Although be aware that file systems like UFS can be in inconsistent > state after primary failure, so secondary node after switching to > primary role has to check file system with fsck(8) before mounting it. > This also makes ZFS great choice for running on HAST as 'zpool import' > is very fast as oppose to fsck (at least until Jeff finish his SU+J > project). > I can testify to the benefits of SU+J. I had two crashes on Wednesday and SU+J recovered my file systems in seconds. With fsck it would have taken about 30 minutes. --- Gary Jennejohn From owner-freebsd-fs@FreeBSD.ORG Fri Feb 5 10:51:10 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 1A01F1065672 for ; Fri, 5 Feb 2010 10:51:10 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id AAE938FC13 for ; Fri, 5 Feb 2010 10:51:09 +0000 (UTC) Received: by ewy3 with SMTP id 3so1349108ewy.13 for ; Fri, 05 Feb 2010 02:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=7uKh4AH3DGIuHkaLsWzXqv6i5d1UXBRYz42tLPRXpMc=; b=ceJmxwHMItBN6ih6u5ocfZYqA/gGUXNV1YQ7Pzdo1q9qw5ijE7MiHBMKMcXV0h69cg Ce49CXwlzK/5+tH6EN+ZWRMIF5VdzvOoQ884wG7BAbp6iBvMbFtnsA7dSP6XNBkg4Zt/ c1CTxqtfqW65EpvTAubFbZeQi5KlXDtxn0bFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KWBwM2TTZVAGEN9qUruGnTo2tOezSF/+xvLgHXRxuRyCw06SEAmtTjqE+uNDjf/Er7 AxaOD0m/JjOtECkZQKMo9rwGZdU+y10yJj/K/ivur8F31ulsUdjCT1gBAmEQIcAgYtEs s0W5NDv1RLapRGo0IUARpZQwoVQ62KzmipjK0= MIME-Version: 1.0 Received: by 10.213.52.76 with SMTP id h12mr446289ebg.23.1265367068477; Fri, 05 Feb 2010 02:51:08 -0800 (PST) Date: Fri, 5 Feb 2010 05:51:08 -0500 Message-ID: From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ZFS version info 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, 05 Feb 2010 10:51:10 -0000 Been following ZFS things. ZFS crypto codereview is done. Looks like it will be integrated this quarter. Wanted to suggest another merge at that time? Approximately how many LOC would a diff between OpenSolaris and RELENG_8 be? Primarily for the case where a site wished to try their own merge. There had been talk of zpool resizing but I'd guess that's quite a ways off. RELENG_8: This system is currently running ZFS pool version 14. This system is currently running ZFS filesystem version 3. OpenSolaris [since RELENG_8]: ======================================== ZFS File System Version 4 This version includes support for the following features: * userused@... and groupused@... properties * userquota@... and groupquota@... properties These features are available in: * Solaris Express Community Edition, build 114 The related bug and PSARC case for version 4 changes are: * 6501037 want user/group quotas on ZFS * PSARC 2009/204 ZFS user/group quotas & space accounting ======================================== ======================================== ZFS Pool Version 22 This version includes support for zfs receive properties. Pool version 22 is available in this release: * Solaris Express Community Edition, build 128 The PSARC case for the version 22 change is: * PSARC/2009/510 ZFS Received Properties ======================================== ZFS Pool Version 21 This version includes support for ZFS deduplication properties. Pool version 21 is available in this release: * Solaris Express Community Edition, build 128 The PSARC case for the version 21 change is: * PSARC/2009/571 ZFS Deduplication Properties ======================================== ZFS Pool Version 20 This version includes the zle compression algorithm that is needed to support the ZFS deduplication properties in ZFS pool version 21. Both pool versions are available in this release: * Solaris Express Community Edition, build 128 The PSARC case for the version 20 change is: * PSARC/2009/571 ZFS Deduplication Properties ======================================== ZFS Pool Version 19 This version includes support for the following feature: * ZFS log device removal This feature is available in: * Solaris Express Community Edition, build 125 The related change record for the version 19 change is: * 6574286 removing a slog doesn't work ======================================== ZFS Pool Version 18 This version includes support for the following feature: * ZFS snapshot holds This feature is available in: * Solaris Express Community Edition, build 121 The related change record for the version 18 change is: * 6803121 want user-settable refcounts on snapshots ======================================== ZFS Pool Version 17 This version includes support for the following feature: * triple-parity RAID-Z This feature is available in: * Solaris Express Community Edition, build 120 The related change record for the version 17 change is: * 6854612 triple-parity RAID-Z ======================================== ZFS Pool Version 16 This version includes support for the following feature: * stmf property support This feature is available in: * Solaris Express Community Edition, build 116 The related bug for the version 16 change is: * 6736004 zvols need an additional property for comstar support ======================================== ZFS Pool Version 15 This version includes support for the following features: * userused@... and groupused@... properties * userquota@... and groupquota@... properties These features are available in: * Solaris Express Community Edition, build 114 The related bug and PSARC case for version 15 changes are: * 6501037 want user/group quotas on ZFS * PSARC 2009/204 ZFS user/group quotas & space accounting ======================================== From owner-freebsd-fs@FreeBSD.ORG Fri Feb 5 16:35:09 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 8EF7D106566C; Fri, 5 Feb 2010 16:35:09 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f174.google.com (mail-iw0-f174.google.com [209.85.223.174]) by mx1.freebsd.org (Postfix) with ESMTP id 36D088FC17; Fri, 5 Feb 2010 16:35:08 +0000 (UTC) Received: by iwn4 with SMTP id 4so4296239iwn.27 for ; Fri, 05 Feb 2010 08:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7xZSEbF/3JjSqgCWAek5byZyoG57Mrtb7TPlldxtxLM=; b=Er9Zi8mQjrNuOSbp16wPVTZulvcx0DTsVSxmHESdWjJlAQBrBN54MXd6+aEWAuxDY/ eqk5SheRHR7rnAWrQNK5gFeADpCyq6U90YNhfSuBdXyPvgEL3hdhUaKVz3Uq6QSViKum kmTWTO8ok2z9gP1BgQozOL6WkjOO1ZIKqypiQ= 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=TfW3ZnLYCyg4o9e6WXWC7qhhJ0Km+a2PNsFCsshk06VnzeC2aP3yyIvjU32G3zLtWz odqbrI1tPj5+UNsUQmogj8DJjKbYanJaKVd+Zr3s5RBz+mLFYySkPKR5rOCNmLiTmQHN 4liu/dOwm2+TWvTHG25UO3qTMQKzosP1mD02U= MIME-Version: 1.0 Received: by 10.231.143.12 with SMTP id s12mr886996ibu.38.1265387708332; Fri, 05 Feb 2010 08:35:08 -0800 (PST) In-Reply-To: <20100204210522.GB1733@garage.freebsd.pl> References: <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> <9B1DF836-0CCC-4CB2-B83C-3040428A7344@yellowspace.net> <20100204210522.GB1733@garage.freebsd.pl> Date: Fri, 5 Feb 2010 08:35:08 -0800 Message-ID: From: Freddie Cash To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Any news on the HAST Project? 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, 05 Feb 2010 16:35:09 -0000 On Thu, Feb 4, 2010 at 1:05 PM, Pawel Jakub Dawidek wrote: > On Wed, Feb 03, 2010 at 03:53:37PM +0100, Lorenzo Perone wrote: > > On 28.01.2010, at 14:26, Hywel Mallett wrote: > > > About the same time a status update was posted on the FreeBSD > Foundation blog at > http://freebsdfoundation.blogspot.com/2009/12/update-on-hast-project.html > > > > Thanx, also to pjd's answer. That gives some nice insight already. Great > work! HAST could in fact change radically the way of using block devices and > distributing mass storage. I look forward to testing it first on a few > vboxes and shortly thereafter on real machines. > > > > Really curious on how several things are implemented, e.g. performance / > latency / fail / sync issues (what happens for example when a big huge file > is written locally on a very fast primary, and there is not enough ram to > buffer it before sending it to a secondary.. etc, scenarios like that). > > Every write request is handled synchronously by HAST. It is reported as > completed only when it is stored on local and on remote node. > > > And how well it will do with ZFS too: although ZFS has its 'own' HAST via > send/recv (and besides might get its own implementation for some sort of > 'streaming' send/recv..) it is also true that it'd allow for some great > flexibility in creating primary/secondary volumes (zvols). Just imagining a > scenario with sparse zvols and HAST disting them around.. ok ok I stop here > :-) > > ZFS send/recv is something else. It can't work synchronously, where HAST > works always that way. This means that when your primary node dies you > won't lose even a single bit of data. > > Although be aware that file systems like UFS can be in inconsistent > state after primary failure, so secondary node after switching to > primary role has to check file system with fsck(8) before mounting it. > This also makes ZFS great choice for running on HAST as 'zpool import' > is very fast as oppose to fsck (at least until Jeff finish his SU+J > project). > > Am I correct in thinking that this will solve my issue with creating a fail-over SAN setup, as detailed here back in June? http://lists.freebsd.org/pipermail/freebsd-fs/2009-June/006394.html In essence, create a master storage server at SiteA using HAST as the underlying GEOM for the zpool, and create an identical slave storage server at SiteB, also using HAST to create the zpool. Then use CARP to create a shared IP between the two, and use that IP for the iSCSI links to the VM servers at each site. The setup would be like so: [Server Room 1] . [Server Room 2] ----------------- . ------------------- . [storage server] . [storage server] | . | | . | [storage switch] . [storage switch] | \----fibre----/ | | . | | . | /---[switch]---\ . /---[switch]---\ | | | . | | | | [VM box] | . | [VM box] | | | | . | | | [VM box] | | . [VM box] | | | | [VM box] . | | [VM box] | | | . | | | [network switch] . [network switch] | . | | . | [internet] . [internet] Server room 1 would be live, with the storage server marked as master, and the storage server in Server room 2 would be the slave. Initially, the VMs would run in server room 1, but could fail-over or migrade to server room. Will be very interesting to see how this all works with ZFS. Could be a killer combination: all the GEOM goodies, HAST, ZFS, CARP, etc. It's days like this that I'm glad I use FreeBSD. :D Keep up the good work!! -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Feb 5 19:51:20 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 06231106566B; Fri, 5 Feb 2010 19:51:20 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4F78FC1B; Fri, 5 Feb 2010 19:51:19 +0000 (UTC) Received: from furia.intranet ([93.104.43.176]) (AUTH: LOGIN lopez.on.the.lists@yellowspace.net) by mail.yellowspace.net with esmtp; Fri, 05 Feb 2010 20:51:16 +0100 id 0036A17F.000000004B6C76B4.0000655E Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lorenzo Perone In-Reply-To: <20100204210522.GB1733@garage.freebsd.pl> Date: Fri, 5 Feb 2010 20:51:15 +0100 Content-Transfer-Encoding: 7bit Message-Id: <25CA86F9-4B63-44FE-8A03-855DC1D4DF60@yellowspace.net> References: <914E8A1F-2FE9-4A7E-9BC7-6174402B57D3@yellowspace.net> <20100128132613.olxiwcq0go0g0w88@www.hmallett.co.uk> <9B1DF836-0CCC-4CB2-B83C-3040428A7344@yellowspace.net> <20100204210522.GB1733@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1077) Cc: freebsd-fs@freebsd.org Subject: Re: Any news on the HAST Project? 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, 05 Feb 2010 19:51:20 -0000 On 04.02.2010, at 22:05, Pawel Jakub Dawidek wrote: > Every write request is handled synchronously by HAST. It is reported as > completed only when it is stored on local and on remote node. That's great for state - yet it also means that it won't be suitable for some scenarios - such as secondaries connected over slow links or with noticeably slower media. While I sort of imagine some of the tricky, messy implications of an aynchronous implementation, I was hoping for it somehow. That doesn't make HAST less magic - it just shifts its use to different scenarios than some I originally imagined, were it was something more similar to what dfly's is doing with hammer mirror-stream - but at a filesystem-agnostic level (wonder if that's even possible in theory).. > This also makes ZFS great choice for running on HAST as 'zpool import' > is very fast as oppose to fsck (at least until Jeff finish his SU+J > project). This sounds like great marriage. Could latency be further enhanced by HASTing the pool geoms and using an 'unHASTed' device as ZIL device, in theory (as soon as that's possible)? Thanx a lot! Regards, Lorenzo From owner-freebsd-fs@FreeBSD.ORG Sat Feb 6 14:51: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 83407106566B for ; Sat, 6 Feb 2010 14:51:16 +0000 (UTC) (envelope-from urmas.lett@eenet.ee) Received: from muheleja.eenet.ee (muheleja.eenet.ee [193.40.0.132]) by mx1.freebsd.org (Postfix) with ESMTP id 3780A8FC12 for ; Sat, 6 Feb 2010 14:51:15 +0000 (UTC) Received: from muheleja.eenet.ee (localhost [127.0.0.1]) by localhost.eenet.ee (Postfix) with ESMTP id E79FF1CC27 for ; Sat, 6 Feb 2010 16:51:13 +0200 (EET) X-Virus-Scanned: amavisd-new at eenet.ee Received: from muheleja.eenet.ee ([127.0.0.1]) by muheleja.eenet.ee (muheleja.eenet.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1RPRx20yDBF for ; Sat, 6 Feb 2010 16:51:11 +0200 (EET) Received: from [193.40.0.223] (poriseja.eenet.ee [193.40.0.223]) by muheleja.eenet.ee (Postfix) with ESMTP id 628851CC1F for ; Sat, 6 Feb 2010 16:51:11 +0200 (EET) Message-ID: <4B6D81DB.3090100@eenet.ee> Date: Sat, 06 Feb 2010 16:51:07 +0200 From: Urmas Lett Organization: EENet User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4B619485.8080106@eenet.ee> <4B63088F.9030407@comcast.net> In-Reply-To: <4B63088F.9030407@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Reading from ZFS mirror 2x slower than expected? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 14:51:16 -0000 Steve Polyack wrote: > I can also vouch that the mirror performance is less than stellar. > Writes are also about 50% slower than single-disk performance, although > this may be expected due to checksums / other ZFS overhead. I can try > to provide more details when I get time. I'm luckily observing only 50% slowness when reading from mirror. Writing seems to be OK. dd if=/dev/zero of=test.bin bs=1m count=8192 8589934592 bytes transferred in 143.145040 secs (60008608 bytes/sec) systat -vm shows 400+ tps per disk dd if=test.bin of=/dev/null bs=1m 8589934592 bytes transferred in 155.068721 secs (55394373 bytes/sec) Disks ada0 ada1 ada2 pass0 pass1 pass2 KB/t 0.00 128 128 0.00 0.00 0.00 tps 0 226 224 0 0 0 MB/s 0.00 28.30 28.06 0.00 0.00 0.00 %busy 0 54 64 0 0 0 systat -vm shows only 200+ tps per disk After detaching one disk from mirror: dd if=test.bin of=/dev/null bs=1m 8589934592 bytes transferred in 149.991512 secs (57269471 bytes/sec) Disks ada0 ada1 ada2 pass0 pass1 pass2 KB/t 0.00 128 0.00 0.00 0.00 0.00 tps 0 444 0 0 0 0 MB/s 0.00 55.55 0.00 0.00 0.00 0.00 %busy 0 98 0 0 0 0 systat -vm shows 400+ tps Now I did simple test on the same hardware with Belenix 7.1 liveCD: jack@belenix:/zpool0# dd if=/dev/zero of=8gb.test bs=1024k count=8192 8192+0 records in 8192+0 records out 8589934592 bytes (8.6 GB) copied, 167.512 s, 51.3 MB/s jack@belenix:/zpool0# dd if=8gb.test of=/dev/null bs=1024k 8192+0 records in 8192+0 records out 8589934592 bytes (8.6 GB) copied, 82.4957 s, 104 MB/s read speed from mirror is 2x better and Solaris iostat shows 400+ tps and 50+ MB/s per mirrored disk. -- Urmas Lett Tel: +(372) 7 302 110 Fax: +(372) 7 302 111 E-Mail: urmas.lett@eenet.ee