From owner-freebsd-fs@FreeBSD.ORG Sun Feb 7 02:44:41 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 A85191065676; Sun, 7 Feb 2010 02:44:41 +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 25B5E8FC1E; Sun, 7 Feb 2010 02:44:40 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id D3D11143E; Sun, 7 Feb 2010 03:44:33 +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 x8Ofn3fUFG2n; Sun, 7 Feb 2010 03:44:31 +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 86A981437; Sun, 7 Feb 2010 03:44:29 +0100 (CET) Message-ID: <4B6E2921.60403@darkbsd.org> Date: Sun, 07 Feb 2010 11:44:49 +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> <4B695CA3.50008@darkbsd.org> <4B6B4E2E.2010902@icyb.net.ua> In-Reply-To: <4B6B4E2E.2010902@icyb.net.ua> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAD01E28EFD635FCFABC45B17" 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: Sun, 07 Feb 2010 02:44:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAD01E28EFD635FCFABC45B17 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > 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 =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) >=20 > 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 othe= r > functions up the stack acquire state_mtx recursively, but the mutex is = not > initialized with MTX_RECURSE. >=20 > 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 bett= er than > ata(4). I just moved half of the "flaky" drives on an AHCI controller. This seems to work much better, starting with disk detection issues=20 being solved, and hotplug working exactly like SCSI does. It does=20 require using camcontrol to recognize the disks again, but that much is=20 not exactly a problem. Although I'm probably dreaming : Did anyone heard about AHCI controllers = beside the on-board ones ? Thanks to everyone for their advice. --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enigAD01E28EFD635FCFABC45B17 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 iEYEARECAAYFAktuKSQACgkQ24Ql8u6TF2Mi0wCeMGhdcjKdsyf7TBUyBF1L2n/4 WH8Anjbf3lVlT2hX7D8dABVqck5WAdPv =DwuS -----END PGP SIGNATURE----- --------------enigAD01E28EFD635FCFABC45B17-- From owner-freebsd-fs@FreeBSD.ORG Sun Feb 7 20:31:51 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4059F106568B; Sun, 7 Feb 2010 20:31:51 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1857D8FC14; Sun, 7 Feb 2010 20:31:51 +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 o17KVolb004141; Sun, 7 Feb 2010 20:31:50 GMT (envelope-from pjd@freefall.freebsd.org) Received: (from pjd@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o17KVoHY004137; Sun, 7 Feb 2010 20:31:50 GMT (envelope-from pjd) Date: Sun, 7 Feb 2010 20:31:50 GMT Message-Id: <201002072031.o17KVoHY004137@freefall.freebsd.org> To: torindel@gmail.com, pjd@FreeBSD.org, freebsd-fs@FreeBSD.org, pjd@FreeBSD.org From: pjd@FreeBSD.org Cc: Subject: Re: kern/142271: [zfs] [patch] race condition on zpool create X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 20:31:51 -0000 Synopsis: [zfs] [patch] race condition on zpool create State-Changed-From-To: open->patched State-Changed-By: pjd State-Changed-When: ndz 7 lut 2010 20:31:00 UTC State-Changed-Why: Should be fixed in HEAD (r203504). Responsible-Changed-From-To: freebsd-fs->pjd Responsible-Changed-By: pjd Responsible-Changed-When: ndz 7 lut 2010 20:31:00 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=142271 From owner-freebsd-fs@FreeBSD.ORG Mon Feb 8 11:06: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 536341065676 for ; Mon, 8 Feb 2010 11:06:55 +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 2A3128FC25 for ; Mon, 8 Feb 2010 11:06:55 +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 o18B6t2h087364 for ; Mon, 8 Feb 2010 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o18B6sTo087362 for freebsd-fs@FreeBSD.org; Mon, 8 Feb 2010 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Feb 2010 11:06:54 GMT Message-Id: <201002081106.o18B6sTo087362@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, 08 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/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs/ufs Lock order reversal 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/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 162 problems total. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 10 00:46:33 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 28BE4106568D; Wed, 10 Feb 2010 00:46:33 +0000 (UTC) (envelope-from mckusick@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 00A328FC08; Wed, 10 Feb 2010 00:46:33 +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 o1A0kWIP072503; Wed, 10 Feb 2010 00:46:32 GMT (envelope-from mckusick@freefall.freebsd.org) Received: (from mckusick@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1A0kWjK072499; Wed, 10 Feb 2010 00:46:32 GMT (envelope-from mckusick) Date: Wed, 10 Feb 2010 00:46:32 GMT Message-Id: <201002100046.o1A0kWjK072499@freefall.freebsd.org> To: mckusick@FreeBSD.org, freebsd-fs@FreeBSD.org, mckusick@FreeBSD.org From: mckusick@FreeBSD.org Cc: Subject: Re: kern/133980: [panic] [ffs] panic: ffs_valloc: dup alloc 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, 10 Feb 2010 00:46:33 -0000 Synopsis: [panic] [ffs] panic: ffs_valloc: dup alloc Responsible-Changed-From-To: freebsd-fs->mckusick Responsible-Changed-By: mckusick Responsible-Changed-When: Wed Feb 10 00:43:46 UTC 2010 Responsible-Changed-Why: I will take responsibility for this one. It will require a change in the kernel to properly handle inode numbers as unsigned. It will also require a change to newfs to ensure that a filesystem allocates no more than 2^32 inodes. Stay tuned for these patches. http://www.freebsd.org/cgi/query-pr.cgi?pr=133980 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 10 13:30:05 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4111F106568B for ; Wed, 10 Feb 2010 13:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 15EC18FC1B for ; Wed, 10 Feb 2010 13:30: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 o1ADU4IP063235 for ; Wed, 10 Feb 2010 13:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1ADU4sg063230; Wed, 10 Feb 2010 13:30:04 GMT (envelope-from gnats) Date: Wed, 10 Feb 2010 13:30:04 GMT Message-Id: <201002101330.o1ADU4sg063230@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Gerrit =?ISO-8859-1?Q?K=FChn?= Cc: Subject: Re: kern/140433: [zfs] [panic] panic while replaying ZIL after crash X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gerrit =?ISO-8859-1?Q?K=FChn?= List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 13:30:05 -0000 The following reply was made to PR kern/140433; it has been noted by GNATS. From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/140433: [zfs] [panic] panic while replaying ZIL after crash Date: Wed, 10 Feb 2010 14:01:22 +0100 For the record: I fixed my pool now by booting OpenSolaris dev 131 and simply importing/exporting the pool. Now it works fine again under FreeBSD. Since v128 OSL also has a -F(ix) feature for importing corrupt pools. This would be a very useful feature in FreeBSD, too. cu Gerrit From owner-freebsd-fs@FreeBSD.ORG Wed Feb 10 18:50:04 2010 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05D811065672 for ; Wed, 10 Feb 2010 18:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CEC178FC15 for ; Wed, 10 Feb 2010 18:50:03 +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 o1AIo3us043993 for ; Wed, 10 Feb 2010 18:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1AIo30m043992; Wed, 10 Feb 2010 18:50:03 GMT (envelope-from gnats) Date: Wed, 10 Feb 2010 18:50:03 GMT Message-Id: <201002101850.o1AIo30m043992@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: David Naylor Cc: Subject: Re: kern/141950: [unionfs] [lor] ufs/unionfs/ufs Lock order reversal X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Naylor List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:50:04 -0000 The following reply was made to PR kern/141950; it has been noted by GNATS. From: David Naylor To: bug-followup@freebsd.org Cc: Subject: Re: kern/141950: [unionfs] [lor] ufs/unionfs/ufs Lock order reversal Date: Wed, 10 Feb 2010 20:44:58 +0200 --nextPart2650448.KVKX8H28Pz Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A recent -current kernel has produced a different backtrace. I am still=20 experiencing io freezes involving the unionfs mounts. =20 lock order reversal: 1st 0xffffff017423bbd8 unionfs (unionfs) @=20 /usr/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:356 2nd 0xffffff0113c2a9f8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2204 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7ea __lockmgr_args() at __lockmgr_args+0xd43 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x50 vputx() at vputx+0x285 unionfs_noderem() at unionfs_noderem+0x1c4 unionfs_reclaim() at unionfs_reclaim+0x11 vgonel() at vgonel+0xf6 vrecycle() at vrecycle+0x58 unionfs_inactive() at unionfs_inactive+0x20 vinactive() at vinactive+0x6b vputx() at vputx+0x267 kern_mkdirat() at kern_mkdirat+0x2e7 syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 =2D-- syscall (136, FreeBSD ELF64, mkdir), rip =3D 0x80083f8dc, rsp =3D=20 0x7fffffffe778, rbp =3D 0x800a3a180 --- --nextPart2650448.KVKX8H28Pz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEABECAAYFAkty/q0ACgkQUaaFgP9pFrLK7QCeNZfotOiudE3qbm6ct/U8usV/ tUAAn16IFjAEgw9i0A50CL/yMNXTQfuK =F4NZ -----END PGP SIGNATURE----- --nextPart2650448.KVKX8H28Pz-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 10 20:09:30 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 1F4FB1065693; Wed, 10 Feb 2010 20:09:30 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id D34BE8FC08; Wed, 10 Feb 2010 20:09:28 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 935E515176A; Wed, 10 Feb 2010 22:09:23 +0200 (EET) Date: Wed, 10 Feb 2010 22:09:23 +0200 From: Jaakko Heinonen To: Gleb Kurtsou Message-ID: <20100210200922.GA3109@a91-153-117-195.elisa-laajakaista.fi> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> <20100204205546.GA1733@garage.freebsd.pl> <20100205011226.GA2657@tops.skynet.lt> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100205011226.GA2657@tops.skynet.lt> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek 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: Wed, 10 Feb 2010 20:09:30 -0000 On 2010-02-05, Gleb Kurtsou wrote: > 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. r196309 added a VOP_VPTOCNP(9) implementation for snapshots. However due to changes made in r197513 zfsctl_snapshot_vptocnp() never gets called. There's also another problem with the hidden .zfs directory: if the directory is not in the name cache, __getcwd() will fail. To reproduce this set debug.vfscache sysctl to 0 before the directory enters to cache. # sysctl debug.vfscache=0 # cd /scratch/.zfs # /bin/pwd pwd: .: No such file or directory Here's a patch which tries to fix/work around these problems: http://people.freebsd.org/~jh/patches/zfs-ctldir-vptocnp.diff The patch needs more work and I have tested it only very lightly. -- Jaakko From owner-freebsd-fs@FreeBSD.ORG Thu Feb 11 03:00: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 D0C7D1065672 for ; Thu, 11 Feb 2010 03:00: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 B54338FC15 for ; Thu, 11 Feb 2010 03:00: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 o1B305Ma055672 for ; Thu, 11 Feb 2010 03:00:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1B305B3055671; Thu, 11 Feb 2010 03:00:05 GMT (envelope-from gnats) Date: Thu, 11 Feb 2010 03:00:05 GMT Message-Id: <201002110300.o1B305B3055671@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, 11 Feb 2010 03:00: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: Wed, 10 Feb 2010 18:56:28 -0800 (PST) --0-1240140841-1265856988=:21423 Content-Type: text/plain; charset=us-ascii The previous patch was incomplete. There is now a complete fix for UFS available as SVN Revision 203763. Translating it to ext2fs gives the attached patch. (I kept the file system --> filesystem corrections) Please note that ext2_blkpref is very different to ffs1_blkpref. We probably have to review that function for (un)signed issues too. --0-1240140841-1265856988=:21423 Content-Type: application/octet-stream; name="patch-ext2_alloc.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-ext2_alloc.c" LS0tIC4uL2V4dDJmcy5ic2QvZXh0Ml9hbGxvYy5jCTIwMTAtMDEtMTcgMTk6 MDA6NDcuMDAwMDAwMDAwICswMDAwCisrKyBleHQyX2FsbG9jLmMJMjAxMC0w Mi0xMCAyMTo0MDoyNS4wMDAwMDAwMDAgKzAwMDAKQEAgLTUxLDE2ICs1MSwx NiBAQAogI2luY2x1ZGUgPGZzL2V4dDJmcy9mcy5oPgogI2luY2x1ZGUgPGZz L2V4dDJmcy9leHQyX2V4dGVybi5oPgogCi1zdGF0aWMgZGFkZHJfdAlleHQy X2FsbG9jY2coc3RydWN0IGlub2RlICosIGludCwgZGFkZHJfdCwgaW50KTsK K3N0YXRpYyBkYWRkcl90CWV4dDJfYWxsb2NjZyhzdHJ1Y3QgaW5vZGUgKiwg dV9pbnQsIGRhZGRyX3QsIGludCk7CiBzdGF0aWMgdV9sb25nCWV4dDJfZGly cHJlZihzdHJ1Y3QgaW5vZGUgKik7CiBzdGF0aWMgdm9pZAlleHQyX2ZzZXJy KHN0cnVjdCBtX2V4dDJmcyAqLCB1aWRfdCwgY2hhciAqKTsKIHN0YXRpYyB1 X2xvbmcJZXh0Ml9oYXNoYWxsb2Moc3RydWN0IGlub2RlICosIGludCwgbG9u ZywgaW50LAotCQkJCWRhZGRyX3QgKCopKHN0cnVjdCBpbm9kZSAqLCBpbnQs IGRhZGRyX3QsIAorCQkJCWRhZGRyX3QgKCopKHN0cnVjdCBpbm9kZSAqLCB1 X2ludCwgZGFkZHJfdCwgCiAJCQkJCQlpbnQpKTsKLXN0YXRpYyBkYWRkcl90 CWV4dDJfbm9kZWFsbG9jY2coc3RydWN0IGlub2RlICosIGludCwgZGFkZHJf dCwgaW50KTsKK3N0YXRpYyBkYWRkcl90CWV4dDJfbm9kZWFsbG9jY2coc3Ry dWN0IGlub2RlICosIHVfaW50LCBkYWRkcl90LCBpbnQpOwogc3RhdGljIGRh ZGRyX3QgIGV4dDJfbWFwc2VhcmNoKHN0cnVjdCBtX2V4dDJmcyAqLCBjaGFy ICosIGRhZGRyX3QpOwogLyoKLSAqIEFsbG9jYXRlIGEgYmxvY2sgaW4gdGhl IGZpbGUgc3lzdGVtLgorICogQWxsb2NhdGUgYSBibG9jayBpbiB0aGUgZmls ZXN5c3RlbS4KICAqCiAgKiBBIHByZWZlcmVuY2UgbWF5IGJlIG9wdGlvbmFs bHkgc3BlY2lmaWVkLiBJZiBhIHByZWZlcmVuY2UgaXMgZ2l2ZW4KICAqIHRo ZSBmb2xsb3dpbmcgaGllcmFyY2h5IGlzIHVzZWQgdG8gYWxsb2NhdGUgYSBi bG9jazoKQEAgLTEwMiw3ICsxMDIsNyBAQAogCXN0cnVjdCBtX2V4dDJmcyAq ZnM7CiAJc3RydWN0IGV4dDJtb3VudCAqdW1wOwogCWludDMyX3QgYm5vOwot CWludCBjZzsJCisJdV9pbnQgY2c7CQogCSpibnAgPSAwOwogCWZzID0gaXAt PmlfZTJmczsKIAl1bXAgPSBpcC0+aV91bXA7CkBAIC0xMzcsOCArMTM3LDgg QEAKICAgICAgICAgfQogbm9zcGFjZToKIAlFWFQyX1VOTE9DSyh1bXApOwot CWV4dDJfZnNlcnIoZnMsIGNyZWQtPmNyX3VpZCwgImZpbGUgc3lzdGVtIGZ1 bGwiKTsKLQl1cHJpbnRmKCJcbiVzOiB3cml0ZSBmYWlsZWQsIGZpbGUgc3lz dGVtIGlzIGZ1bGxcbiIsIGZzLT5lMmZzX2ZzbW50KTsKKwlleHQyX2ZzZXJy KGZzLCBjcmVkLT5jcl91aWQsICJmaWxlc3lzdGVtIGZ1bGwiKTsKKwl1cHJp bnRmKCJcbiVzOiB3cml0ZSBmYWlsZWQsIGZpbGVzeXN0ZW0gaXMgZnVsbFxu IiwgZnMtPmUyZnNfZnNtbnQpOwogCXJldHVybiAoRU5PU1BDKTsKIH0KIApA QCAtMzMyLDcgKzMzMiw3IEBACiB9CiAKIC8qCi0gKiBBbGxvY2F0ZSBhbiBp bm9kZSBpbiB0aGUgZmlsZSBzeXN0ZW0uCisgKiBBbGxvY2F0ZSBhbiBpbm9k ZSBpbiB0aGUgZmlsZXN5c3RlbS4KICAqIAogICovCiBpbnQKQEAgLTM0Nyw3 ICszNDcsOCBAQAogCXN0cnVjdCBpbm9kZSAqaXA7CiAJc3RydWN0IGV4dDJt b3VudCAqdW1wOwogCWlub190IGlubywgaXByZWY7Ci0JaW50IGksIGVycm9y LCBjZzsKKwl1X2ludCBjZzsKKwlpbnQgaSwgZXJyb3I7CiAJCiAJKnZwcCA9 IE5VTEw7CiAJcGlwID0gVlRPSShwdnApOwpAQCAtNDMzLDExICs0MzQsMTEg QEAKIGV4dDJfZGlycHJlZihzdHJ1Y3QgaW5vZGUgKnBpcCkKIHsKIAlzdHJ1 Y3QgbV9leHQyZnMgKmZzOwotICAgICAgICBpbnQgY2csIHByZWZjZywgZGly c2l6ZSwgY2dzaXplOwotCWludCBhdmdpZnJlZSwgYXZnYmZyZWUsIGF2Z25k aXIsIGN1cmRpcnNpemU7Ci0JaW50IG1pbmlmcmVlLCBtaW5iZnJlZSwgbWF4 bmRpcjsKLQlpbnQgbWluY2csIG1pbm5kaXI7Ci0JaW50IG1heGNvbnRpZ2Rp cnM7CisgICAgICAgIHVfaW50IGNnLCBwcmVmY2csIGRpcnNpemUsIGNnc2l6 ZTsKKwl1X2ludCBhdmdpZnJlZSwgYXZnYmZyZWUsIGF2Z25kaXIsIGN1cmRp cnNpemU7CisJdV9pbnQgbWluaWZyZWUsIG1pbmJmcmVlLCBtYXhuZGlyOwor CXVfaW50IG1pbmNnLCBtaW5uZGlyOworCXVfaW50IG1heGNvbnRpZ2RpcnM7 CiAKIAltdHhfYXNzZXJ0KEVYVDJfTVRYKHBpcC0+aV91bXApLCBNQV9PV05F RCk7CiAJZnMgPSBwaXAtPmlfZTJmczsKQEAgLTU4NCwxMiArNTg1LDEyIEBA CiAgKiAgIDMpIGJydXRlIGZvcmNlIHNlYXJjaCBmb3IgYSBmcmVlIGJsb2Nr LgogICovCiBzdGF0aWMgdV9sb25nCi1leHQyX2hhc2hhbGxvYyhzdHJ1Y3Qg aW5vZGUgKmlwLCBpbnQgY2csIGxvbmcgcHJlZiwgaW50IHNpemUsCitleHQy X2hhc2hhbGxvYyhzdHJ1Y3QgaW5vZGUgKmlwLCB1X2ludCBjZywgbG9uZyBw cmVmLCBpbnQgc2l6ZSwKICAgICAgICAgICAgICAgICBkYWRkcl90ICgqYWxs b2NhdG9yKShzdHJ1Y3QgaW5vZGUgKiwgaW50LCBkYWRkcl90LCBpbnQpKQog ewogCXN0cnVjdCBtX2V4dDJmcyAqZnM7CiAJaW5vX3QgcmVzdWx0OwotCWlu dCBpLCBpY2cgPSBjZzsKKwl1X2ludCBpLCBpY2cgPSBjZzsKIAogCW10eF9h c3NlcnQoRVhUMl9NVFgoaXAtPmlfdW1wKSwgTUFfT1dORUQpOwogCWZzID0g aXAtPmlfZTJmczsKQEAgLTYzNCw3ICs2MzUsNyBAQAogICogYW5kIGlmIGl0 IGlzLCBhbGxvY2F0ZSBpdC4KICAqLwogc3RhdGljIGRhZGRyX3QKLWV4dDJf YWxsb2NjZyhzdHJ1Y3QgaW5vZGUgKmlwLCBpbnQgY2csIGRhZGRyX3QgYnBy ZWYsIGludCBzaXplKQorZXh0Ml9hbGxvY2NnKHN0cnVjdCBpbm9kZSAqaXAs IHVfaW50IGNnLCBkYWRkcl90IGJwcmVmLCBpbnQgc2l6ZSkKIHsKIAlzdHJ1 Y3QgbV9leHQyZnMgKmZzOwogCXN0cnVjdCBidWYgKmJwOwpAQCAtNzI0LDcg KzcyNSw3IEBACiAgKiBhbGxvY2F0ZSBpdCB1c2luZyB0b2RlIGluIHRoZSBz cGVjaWZpZWQgY3lsaW5kZXIgZ3JvdXAuCiAgKi8KIHN0YXRpYyBkYWRkcl90 Ci1leHQyX25vZGVhbGxvY2NnKHN0cnVjdCBpbm9kZSAqaXAsIGludCBjZywg ZGFkZHJfdCBpcHJlZiwgaW50IG1vZGUpCitleHQyX25vZGVhbGxvY2NnKHN0 cnVjdCBpbm9kZSAqaXAsIHVfaW50IGNnLCBkYWRkcl90IGlwcmVmLCBpbnQg bW9kZSkKIHsKIAlzdHJ1Y3QgbV9leHQyZnMgKmZzOwogCXN0cnVjdCBidWYg KmJwOwpAQCAtNzkwLDcgKzc5MSw3IEBACiAJfQogCUVYVDJfVU5MT0NLKHVt cCk7CiAJYmR3cml0ZShicCk7Ci0JcmV0dXJuIChjZyAqIGZzLT5lMmZzLT5l MmZzX2lwZyArIGlwcmVmICsxKTsKKwlyZXR1cm4gKChpbm9fdCljZyAqIGZz LT5lMmZzLT5lMmZzX2lwZyArIGlwcmVmICsxKTsKIH0KIAogLyoKQEAgLTgw Niw3ICs4MDcsOCBAQAogCXN0cnVjdCBtX2V4dDJmcyAqZnM7CiAJc3RydWN0 IGJ1ZiAqYnA7CiAJc3RydWN0IGV4dDJtb3VudCAqdW1wOwotCWludCBjZywg ZXJyb3I7CisJdV9pbnQgY2c7CisJaW50IGVycm9yOwogCWNoYXIgKmJicDsK IAogCWZzID0gaXAtPmlfZTJmczsKQEAgLTk0Miw3ICs5NDQsNyBAQAogfQog CiAvKgotICogRnNlcnIgcHJpbnRzIHRoZSBuYW1lIG9mIGEgZmlsZSBzeXN0 ZW0gd2l0aCBhbiBlcnJvciBkaWFnbm9zdGljLgorICogRnNlcnIgcHJpbnRz IHRoZSBuYW1lIG9mIGEgZmlsZXN5c3RlbSB3aXRoIGFuIGVycm9yIGRpYWdu b3N0aWMuCiAgKiAKICAqIFRoZSBmb3JtIG9mIHRoZSBlcnJvciBtZXNzYWdl IGlzOgogICoJZnM6IGVycm9yIG1lc3NhZ2UK --0-1240140841-1265856988=:21423-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 11 23:53:02 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 C3401106568F; Thu, 11 Feb 2010 23:53:02 +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 9B7C98FC13; Thu, 11 Feb 2010 23:53:02 +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 o1BNr2al005245; Thu, 11 Feb 2010 23:53:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1BNr2F6005241; Thu, 11 Feb 2010 23:53:02 GMT (envelope-from linimon) Date: Thu, 11 Feb 2010 23:53:02 GMT Message-Id: <201002112353.o1BNr2F6005241@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143825: [nfs] [panic] Kernel panic on NFS client 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, 11 Feb 2010 23:53:02 -0000 Old Synopsis: Kernel panic on NFS client New Synopsis: [nfs] [panic] Kernel panic on NFS client Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Feb 11 23:52:49 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143825 From owner-freebsd-fs@FreeBSD.ORG Fri Feb 12 18:31:13 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83F511065672 for ; Fri, 12 Feb 2010 18:31:13 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 5283D8FC1A for ; Fri, 12 Feb 2010 18:31:13 +0000 (UTC) Received: from reflector.ws.pitbpa0.priv.collaborativefusion.com ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Fri, 12 Feb 2010 13:53:31 -0500 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::321 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-fs@freebsd.org X-SMFBL: ZnJlZWJzZC1mc0BmcmVlYnNkLm9yZw== Message-ID: <4B759E70.4030809@comcast.net> Date: Fri, 12 Feb 2010 13:31:12 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100211 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable , freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ZFS ARC being limited below what is defined in /boot/loader.conf 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, 12 Feb 2010 18:31:13 -0000 Has anyone had an issue with the ZFS ARC max being limited below what has been defined in /boot/loader.conf? I just upgraded the RAM in a ZFS-equipped system and attempted to devote 4GB to the ARC cache by placing the following in loader.conf: vfs.zfs.arc_max="4096M" However, after rebooting, querying the sysctl gives me this: $ sysctl vfs.zfs.arc_max vfs.zfs.arc_max: 1726489600 or about 1.7GB, an odd number that I can't find any references to. For reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with 8GB of RAM. The system was previously very stable with 4GB of RAM and a 512MB arc_max. I have not modified vm.kmem_size_max (defaults to ~330GB on amd64) or any other ZFS tunables. I'd also like to avoid syncing up to the current 8-STABLE if at all possible. Thanks, Steve Polyack From owner-freebsd-fs@FreeBSD.ORG Fri Feb 12 18:47:41 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 449481065693; Fri, 12 Feb 2010 18:47:41 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by mx1.freebsd.org (Postfix) with ESMTP id EFE788FC13; Fri, 12 Feb 2010 18:47:40 +0000 (UTC) Received: by iwn32 with SMTP id 32so4022144iwn.14 for ; Fri, 12 Feb 2010 10:47:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=i9qneCSkAuxoeT4+Nrm75Bw61Rquoiz+P0SQk0Vod5g=; b=GOHHrXanLA+zW3zpS45jYOxaL2cgX8IPzgdxVg1ES9Vm4qII1CTo0Lt62gbCDjIq6g W2HqF7Rwa7DQHprNHM1teQ4PsARANMiJDpcDEbPd0FJIDzk+vOe7ygHx0I7Op7/6f0OJ bPw57pWtBVkeh9dopXB+fz0pteV5wGAeSs9JI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=q7Z64EmtTJ8gWIRPd4WleukudNG1Tw906O63yjKQ8d8bdXWQIT2nhR5a/w8/fg16uF 0CxlXZ07J9eNq0wvd+7pO1gv9wPY1opynpsFECTPR0Phgo0lpVxaVNgpQA00QsiBa4ue Wrk1zknpowsuM8VdvRd39h35UqlXHPWASiDt8= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.147.149 with SMTP id l21mr314072ibv.0.1266000460156; Fri, 12 Feb 2010 10:47:40 -0800 (PST) In-Reply-To: <4B759E70.4030809@comcast.net> References: <4B759E70.4030809@comcast.net> Date: Fri, 12 Feb 2010 10:47:40 -0800 X-Google-Sender-Auth: 5b14e99a2562fe94 Message-ID: From: Artem Belevich To: Steve Polyack Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-stable Subject: Re: ZFS ARC being limited below what is defined in /boot/loader.conf 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, 12 Feb 2010 18:47:41 -0000 Check your vm.kmem_size. Default setting is way too low. Set it to at least double of desired arc size. --Artem On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyack wrote: > Has anyone had an issue with the ZFS ARC max being limited below what has > been defined in /boot/loader.conf? =A0I just upgraded the RAM in a > ZFS-equipped system and attempted to devote 4GB to the ARC cache by placi= ng > the following in loader.conf: > =A0vfs.zfs.arc_max=3D"4096M" > > However, after rebooting, querying the sysctl gives me this: > $ sysctl vfs.zfs.arc_max > vfs.zfs.arc_max: 1726489600 > > or about 1.7GB, an odd number that I can't find any references to. =A0For > reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with = 8GB > of RAM. =A0The system was previously very stable with 4GB of RAM and a 51= 2MB > arc_max. =A0I have not modified vm.kmem_size_max (defaults to ~330GB on a= md64) > or any other ZFS tunables. =A0I'd also like to avoid syncing up to the cu= rrent > 8-STABLE if at all possible. > > Thanks, > Steve Polyack > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Fri Feb 12 19:36: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 CD3611065679 for ; Fri, 12 Feb 2010 19:36:42 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 984EA8FC1E for ; Fri, 12 Feb 2010 19:36:42 +0000 (UTC) Received: from reflector.ws.pitbpa0.priv.collaborativefusion.com ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Fri, 12 Feb 2010 14:58:58 -0500 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::322 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-fs@freebsd.org X-SMFBL: ZnJlZWJzZC1mc0BmcmVlYnNkLm9yZw== Message-ID: <4B75ADC7.6000308@comcast.net> Date: Fri, 12 Feb 2010 14:36:39 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100211 Thunderbird/3.0.1 MIME-Version: 1.0 To: Artem Belevich References: <4B759E70.4030809@comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable Subject: Re: ZFS ARC being limited below what is defined in /boot/loader.conf 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, 12 Feb 2010 19:36:42 -0000 On 02/12/10 13:47, Artem Belevich wrote: > On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyack wrote: > > >> Has anyone had an issue with the ZFS ARC max being limited below what has >> been defined in /boot/loader.conf? I just upgraded the RAM in a >> ZFS-equipped system and attempted to devote 4GB to the ARC cache by placing >> the following in loader.conf: >> vfs.zfs.arc_max="4096M" >> >> However, after rebooting, querying the sysctl gives me this: >> $ sysctl vfs.zfs.arc_max >> vfs.zfs.arc_max: 1726489600 >> >> or about 1.7GB, an odd number that I can't find any references to. For >> reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with 8GB >> of RAM. The system was previously very stable with 4GB of RAM and a 512MB >> arc_max. I have not modified vm.kmem_size_max (defaults to ~330GB on amd64) >> or any other ZFS tunables. I'd also like to avoid syncing up to the current >> 8-STABLE if at all possible. >> >> Thanks, >> Steve Polyack >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> > > Check your vm.kmem_size. Default setting is way too low. Set it to at > least double of desired arc size. > > --Artem I mentioned it briefly, but vm.kmem_size_max was left at the default for amd64. At 330GB it is way above and beyond what will ever be allocated to ARC: $ sysctl vm.kmem_size_max vm.kmem_size_max: 329853485875 From owner-freebsd-fs@FreeBSD.ORG Fri Feb 12 21:10: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 568361065696; Fri, 12 Feb 2010 21:10:54 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by mx1.freebsd.org (Postfix) with ESMTP id 0181C8FC22; Fri, 12 Feb 2010 21:10:53 +0000 (UTC) Received: by iwn32 with SMTP id 32so4194479iwn.14 for ; Fri, 12 Feb 2010 13:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=FYgMknWhea0eXc2bUza6On4QhmBItJpIcQAK/3J1Y8c=; b=h2HUFalGqkIqzyosiD0qeN6/NCCUEOic11SF9pytboviOUzTUS0OOg9ERupLuASSnx DJWbatkwQYO6WA1l/aJ70vRi8rL562CJSoTi75q0b2lFfU7NpZwdVsd64esEy4eEmm4i /1F7MfUJoS+YVmYt5mFMdC3kygf4nLxfeTifI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=D8TxuAEnDV5QD/DaEHYtFfgacLZfhNuj7I1uI11giVyhC+qefghsq+hwQh9Tdol8B5 TnhSYviKCJQymzXI7m6it3ETJCt20GjNWs37aSpCtNxEELH12v53aiRP6hfmazRYqzrX uQyY/wZzsqAVqBt8JL+qTc/F3go6lsUVnNlIE= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.154.77 with SMTP id n13mr1285922ibw.11.1266009051736; Fri, 12 Feb 2010 13:10:51 -0800 (PST) In-Reply-To: <4B75ADC7.6000308@comcast.net> References: <4B759E70.4030809@comcast.net> <4B75ADC7.6000308@comcast.net> Date: Fri, 12 Feb 2010 13:10:51 -0800 X-Google-Sender-Auth: fb3ee935a576a21d Message-ID: From: Artem Belevich To: Steve Polyack Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-stable Subject: Re: ZFS ARC being limited below what is defined in /boot/loader.conf 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, 12 Feb 2010 21:10:54 -0000 vm.kmem_size_max/vm.kmem_size_min define the range vm.kmem_size can be set = to. vm_kmem_size specifies the actual kmem size. ARC size in turn limited by vm.kmem_size. If you want to bump ARC size, you do need to bump vm.kmem_size. --Artem On Fri, Feb 12, 2010 at 11:36 AM, Steve Polyack wrote: > On 02/12/10 13:47, Artem Belevich wrote: >> >> On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyack >> =A0wrote: >> >> >>> >>> Has anyone had an issue with the ZFS ARC max being limited below what h= as >>> been defined in /boot/loader.conf? =A0I just upgraded the RAM in a >>> ZFS-equipped system and attempted to devote 4GB to the ARC cache by >>> placing >>> the following in loader.conf: >>> =A0vfs.zfs.arc_max=3D"4096M" >>> >>> However, after rebooting, querying the sysctl gives me this: >>> $ sysctl vfs.zfs.arc_max >>> vfs.zfs.arc_max: 1726489600 >>> >>> or about 1.7GB, an odd number that I can't find any references to. =A0F= or >>> reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system wit= h >>> 8GB >>> of RAM. =A0The system was previously very stable with 4GB of RAM and a >>> 512MB >>> arc_max. =A0I have not modified vm.kmem_size_max (defaults to ~330GB on >>> amd64) >>> or any other ZFS tunables. =A0I'd also like to avoid syncing up to the >>> current >>> 8-STABLE if at all possible. >>> >>> Thanks, >>> Steve Polyack >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" >>> >>> >> >> Check your vm.kmem_size. Default setting is way too low. Set it to at >> least double of desired arc size. >> >> --Artem > > I mentioned it briefly, but vm.kmem_size_max was left at the default for > amd64. =A0At 330GB it is way above and beyond what will ever be allocated= to > ARC: > $ sysctl vm.kmem_size_max > vm.kmem_size_max: 329853485875 > > > From owner-freebsd-fs@FreeBSD.ORG Fri Feb 12 23:51: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 8AF481065695 for ; Fri, 12 Feb 2010 23:51:23 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4743E8FC0A for ; Fri, 12 Feb 2010 23:51:23 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ng5I8-0001RG-4c for freebsd-fs@freebsd.org; Sat, 13 Feb 2010 00:51:20 +0100 Received: from 78-1-144-78.adsl.net.t-com.hr ([78.1.144.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Feb 2010 00:51:20 +0100 Received: from ivoras by 78-1-144-78.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Feb 2010 00:51:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Sat, 13 Feb 2010 00:50:57 +0100 Lines: 6 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-144-78.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090612) Sender: news Subject: ZFS file storage 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, 12 Feb 2010 23:51:23 -0000 Hi, Because of ZFS' interesting way of storing files, I'm wondering if there is a way to get information such as how fragmented a file is? I'm thinking about something like an utility that for a given file gives "file X is stored in Y fragments"? From owner-freebsd-fs@FreeBSD.ORG Sat Feb 13 00:00: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 12C021065672 for ; Sat, 13 Feb 2010 00:00:28 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id B29D28FC12 for ; Sat, 13 Feb 2010 00:00:27 +0000 (UTC) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta10.westchester.pa.mail.comcast.net with comcast id h7zM1d00L0xGWP85ABnD0F; Fri, 12 Feb 2010 23:47:13 +0000 Received: from [10.0.0.51] ([71.199.122.142]) by omta12.westchester.pa.mail.comcast.net with comcast id hBnC1d00534Sj4f3YBnCh7; Fri, 12 Feb 2010 23:47:13 +0000 Message-ID: <4B75E88A.1050300@comcast.net> Date: Fri, 12 Feb 2010 18:47:22 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Artem Belevich References: <4B759E70.4030809@comcast.net> <4B75ADC7.6000308@comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable Subject: Re: ZFS ARC being limited below what is defined in /boot/loader.conf 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, 13 Feb 2010 00:00:28 -0000 This was indeed the issue. I read your first response incorrectly. Thanks a bunch! On 2/12/2010 4:10 PM, Artem Belevich wrote: > vm.kmem_size_max/vm.kmem_size_min define the range vm.kmem_size can be set to. > vm_kmem_size specifies the actual kmem size. > > ARC size in turn limited by vm.kmem_size. > > If you want to bump ARC size, you do need to bump vm.kmem_size. > > --Artem > > > > On Fri, Feb 12, 2010 at 11:36 AM, Steve Polyack wrote: > >> On 02/12/10 13:47, Artem Belevich wrote: >> >>> On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyack >>> wrote: >>> >>> >>> >>>> Has anyone had an issue with the ZFS ARC max being limited below what has >>>> been defined in /boot/loader.conf? I just upgraded the RAM in a >>>> ZFS-equipped system and attempted to devote 4GB to the ARC cache by >>>> placing >>>> the following in loader.conf: >>>> vfs.zfs.arc_max="4096M" >>>> >>>> However, after rebooting, querying the sysctl gives me this: >>>> $ sysctl vfs.zfs.arc_max >>>> vfs.zfs.arc_max: 1726489600 >>>> >>>> or about 1.7GB, an odd number that I can't find any references to. For >>>> reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with >>>> 8GB >>>> of RAM. The system was previously very stable with 4GB of RAM and a >>>> 512MB >>>> arc_max. I have not modified vm.kmem_size_max (defaults to ~330GB on >>>> amd64) >>>> or any other ZFS tunables. I'd also like to avoid syncing up to the >>>> current >>>> 8-STABLE if at all possible. >>>> >>>> Thanks, >>>> Steve Polyack >>>> >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>>> >>>> >>>> >>> Check your vm.kmem_size. Default setting is way too low. Set it to at >>> least double of desired arc size. >>> >>> --Artem >>> >> I mentioned it briefly, but vm.kmem_size_max was left at the default for >> amd64. At 330GB it is way above and beyond what will ever be allocated to >> ARC: >> $ sysctl vm.kmem_size_max >> vm.kmem_size_max: 329853485875 >> >> >> >> > From owner-freebsd-fs@FreeBSD.ORG Sat Feb 13 00:39:32 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEEC31065692 for ; Sat, 13 Feb 2010 00:39:32 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 2599C8FC1E for ; Sat, 13 Feb 2010 00:39:31 +0000 (UTC) Received: by gxk10 with SMTP id 10so2801283gxk.3 for ; Fri, 12 Feb 2010 16: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 :date:message-id:subject:from:to:cc:content-type; bh=Pv4B+O6T0BR4MUvOHd8vF8wVm7F1/+/HC5QfsnUePh0=; b=su7xD0ZvQipqwZlS8Zdj5Br18lBxh0oAbfTT5lEQ+JiJVIQtaWU3R0j7fgb93W3qFn lKhgonOf1AYUyWVHft+efPIG8A7B6lv0uFTAJLsLsIkxLvL74paUUh5kJfatNJktypmK E2Mbm01LHEZqgjzTPZ0JQYjk2SC70LR5joyfg= 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=Ja+sCc7NjffUXH0YW/bLmoItrzIJ35VctuQ/0aCWMmxc1PQgNqCnxcphroizkZ08/P 3TRH+eCWpkk8DHGr841Gc6gEYNht3zLh58h3PJJBo0J3Fnj89RfuOsS9oo0a+XlEpK4C V5lE1ki9lCw8w4Y2yTbaTutQg2dnu6PLHmBgo= MIME-Version: 1.0 Received: by 10.151.89.37 with SMTP id r37mr3454682ybl.60.1266021570518; Fri, 12 Feb 2010 16:39:30 -0800 (PST) In-Reply-To: References: Date: Fri, 12 Feb 2010 16:39:30 -0800 Message-ID: From: Matt Reimer To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS file storage 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: Sat, 13 Feb 2010 00:39:32 -0000 On Fri, Feb 12, 2010 at 3:50 PM, Ivan Voras wrote: > Hi, > > Because of ZFS' interesting way of storing files, I'm wondering if there is > a way to get information such as how fragmented a file is? I'm thinking > about something like an utility that for a given file gives "file X is > stored in Y fragments"? > [root@gandalf ~]# ls -li /usr/bin/vi 6987 -r-xr-xr-x 6 root wheel 337136 Nov 21 14:31 /usr/bin/vi [root@gandalf ~]# zdb -ddddd glamdring/usr 6987 Dataset glamdring/usr [ZPL], ID 31, cr_txg 97, 1.59G, 77833 objects, rootbp [L0 DMU objset] 400L/200P DVA[0]=<0:10800c33e00:600> DVA[1]=<0:21000487800:600> fletcher4 lzjb LE contiguous birth=3345 fill=77833 cksum=1189b0387a:6d5fe773294:15d9bc7539ad2:2fb4ba66521d1e ZIL header: claim_txg 0, seq 0 first block: [L0 ZIL intent log] 20000L/20000P DVA[0]=<0:1b9730000:30000> zilog uncompressed LE contiguous birth=3233 fill=0 cksum=7fb9ac2ef6d387ee:edbcafeec75face4:1f:1 Block seqno 1, won't claim, [L0 ZIL intent log] 20000L/20000P DVA[0]=<0:1b9730000:30000> zilog uncompressed LE contiguous birth=3233 fill=0 cksum=7fb9ac2ef6d387ee:edbcafeec75face4:1f:1 Object lvl iblk dblk lsize asize type 6987 2 16K 128K 384K 388K ZFS plain file 264 bonus ZFS znode path /bin/ex uid 0 gid 0 atime Sat Feb 13 07:37:52 2010 mtime Sat Nov 21 14:31:07 2009 ctime Fri Feb 12 05:52:32 2010 crtime Fri Feb 12 05:52:32 2010 gen 145 mode 100555 size 337136 parent 4 links 6 xattr 0 rdev 0x0000000000000000 Indirect blocks: 0 L1 0:10bef000:c00 4000L/400P F=3 B=145 0 L0 0:10bf0000:30000 20000L/20000P F=1 B=145 20000 L0 0:10c30000:30000 20000L/20000P F=1 B=145 40000 L0 0:10c70000:30000 20000L/20000P F=1 B=145 segment [0000000000000000, 0000000000060000) size 384K You're interested in the "Indirect blocks" portion. Google raidzmap.tar.gz, download and build it, then do the following. Note that you'll drop the third portion of the zfs offset tuple (e.g. the "c00" in 0:10bef000:c00) and use the physical size (the hex number next to the "P" in "400P"). The devidx numbers correspond to the devices comprising the pool, zero-based. The offset numbers are the hex offset in blocks from the beginning of the disk. In the list of physical blocks the parity blocks come first, then the data blocks. Firstdatacol is the offset into the list of physical blocks where the data blocks begin. For example, in the first raidzmap command below, firstdatacol is 2 which corresponds to "devidx = 0, offset = 2ca7e00, size = 200". IIRC, YMMV, etc. [root@gandalf ~]# ./raidzmap glamdring:0:10bef000:400 Columns = 4, bigcols = 4, asize = c00, firstdatacol = 2 devidx = 4, offset = 2ca7c00, size = 200 devidx = 5, offset = 2ca7c00, size = 200 devidx = 0, offset = 2ca7e00, size = 200 devidx = 1, offset = 2ca7e00, size = 200 [root@gandalf ~]# ./raidzmap glamdring:0:10bf0000:20000 Columns = 6, bigcols = 0, asize = 30000, firstdatacol = 2 devidx = 0, offset = 2ca8000, size = 8000 devidx = 1, offset = 2ca8000, size = 8000 devidx = 2, offset = 2ca8000, size = 8000 devidx = 3, offset = 2ca8000, size = 8000 devidx = 4, offset = 2ca8000, size = 8000 devidx = 5, offset = 2ca8000, size = 8000 [root@gandalf ~]# ./raidzmap glamdring:0:10c30000:20000 Columns = 6, bigcols = 0, asize = 30000, firstdatacol = 2 devidx = 2, offset = 2cb2a00, size = 8000 devidx = 3, offset = 2cb2a00, size = 8000 devidx = 4, offset = 2cb2a00, size = 8000 devidx = 5, offset = 2cb2a00, size = 8000 devidx = 0, offset = 2cb2c00, size = 8000 devidx = 1, offset = 2cb2c00, size = 8000 [root@gandalf ~]# ./raidzmap glamdring:0:10c70000:20000 Columns = 6, bigcols = 0, asize = 30000, firstdatacol = 2 devidx = 4, offset = 2cbd400, size = 8000 devidx = 5, offset = 2cbd400, size = 8000 devidx = 0, offset = 2cbd600, size = 8000 devidx = 1, offset = 2cbd600, size = 8000 devidx = 2, offset = 2cbd600, size = 8000 devidx = 3, offset = 2cbd600, size = 8000 Matt From owner-freebsd-fs@FreeBSD.ORG Sat Feb 13 01:54: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 9E91E1065679 for ; Sat, 13 Feb 2010 01:54:16 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 32E138FC08 for ; Sat, 13 Feb 2010 01:54:15 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so82531eyd.9 for ; Fri, 12 Feb 2010 17:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=alZMr83MkssX9Hu+jDUn8R/daj3HuGcXgrPfefk+p9U=; b=eXYbSuxy7JBJcqm5YbhDpIJqUFPsSUSJ+LVBo9sIrQRlXu0Z+8wUNDHkKlC1oTWCru JP4x8aLTXvl7rkTemOnSQRb2f9pS81slof/E9eLE1pO1qYZF0oSrUFJ4fpqGGr8RK+o+ 2ZkZ322kPMyQDmKnvWz0IH5iw4HRV4t1LvuY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Z7U+jd90+1RT2oNhFdUs5wyZTJRT+k0AYVyHA7gxMMbldfaWbJEGoimMyQTbulR+CG 3VveMq1zPSZCDieRsvZeFLhid4sFrIAMiMTUdBBwzvoqJF/dUoEI0xzng/DvC6sWuAQr 6ZM1DgPtIwwfsQDULaIMaoTEL9z4viS+NcMx8= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.86.16 with SMTP id v16mr1287587wee.162.1266026055111; Fri, 12 Feb 2010 17:54:15 -0800 (PST) In-Reply-To: References: From: Ivan Voras Date: Sat, 13 Feb 2010 02:53:55 +0100 X-Google-Sender-Auth: 4ac8369b52fa713e Message-ID: <9bbcef731002121753j3787430cv2256b2baeddd9e1@mail.gmail.com> To: Matt Reimer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ZFS file storage 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: Sat, 13 Feb 2010 01:54:16 -0000 Clear as mud, but I'll try to understand it... > > =C2=A0=C2=A0 =C2=A0Object =C2=A0lvl =C2=A0 iblk =C2=A0 dblk =C2=A0lsize = =C2=A0asize =C2=A0type > =C2=A0=C2=A0 =C2=A0 =C2=A06987 =C2=A0 =C2=A02 =C2=A0 =C2=A016K =C2=A0 128= K =C2=A0 384K =C2=A0 388K =C2=A0ZFS plain file > =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 264 =C2=A0bonus =C2=A0ZFS zno= de > path /bin/ex > uid =C2=A0 =C2=A0 0 > gid =C2=A0 =C2=A0 0 > atime Sat Feb 13 07:37:52 2010 > mtime Sat Nov 21 14:31:07 2009 > ctime Fri Feb 12 05:52:32 2010 > crtime Fri Feb 12 05:52:32 2010 > gen 145 I assume "gen" is the file generation, e.g. number of write transactions to the file? (irrelevant, just curious about it; I have a database file with gen=3D10002980). > mode 100555 > size 337136 > parent 4 > links 6 > xattr 0 > rdev 0x0000000000000000 > Indirect blocks: > =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 L1 =C2=A00:10bef= 000:c00 4000L/400P F=3D3 B=3D145 > =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0L0 0:10bf0= 000:30000 20000L/20000P F=3D1 B=3D145 > =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20000 =C2=A0L0 0:10c30000:30000 = 20000L/20000P F=3D1 B=3D145 > =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 40000 =C2=A0L0 0:10c70000:30000 = 20000L/20000P F=3D1 B=3D145 > segment [0000000000000000, 0000000000060000) size =C2=A0384K > You're interested in the "Indirect blocks" portion. Google raidzmap.tar.g= z, > download and build it, then do the following. Note that you'll drop the > third portion of the zfs offset tuple (e.g. the "c00" in=C2=A00:10bef000:= c00) and For start, what information is there in the "zfs offset tuple"? I guess the first number is probably the pool id/index? > use the physical size (the hex number next to the "P" in "400P"). The dev= idx Can you give some information about each of the columns in the output above? I.e. in the line "0 L1 0:10bef000:c00 4000L/400P F=3D3 B=3D145" What are the fields' meanings? I tried to deduce that the first column looks like an offset within its "L" level, but this breaks down on my file example which has multiple "L1" records. I have no idea about the "F" and "B" fields. From owner-freebsd-fs@FreeBSD.ORG Sat Feb 13 02:15: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 3C6E8106566B for ; Sat, 13 Feb 2010 02:15:27 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 1A26E8FC1A for ; Sat, 13 Feb 2010 02:15:26 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Ng7HJ-0002jA-71 for freebsd-fs@freebsd.org; Fri, 12 Feb 2010 17:58:37 -0800 Message-ID: <27571737.post@talk.nabble.com> Date: Fri, 12 Feb 2010 17:58:37 -0800 (PST) From: Gregory Read To: freebsd-fs@freebsd.org In-Reply-To: <20091216214621.GA4217@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: zeph@clutteredmind.org References: <20091029205121.GB3418@garage.freebsd.pl> <9AA2C968-F09D-473D-BD13-F13B3F94ED60@sarenet.es> <20091214154750.GF1666@garage.freebsd.pl> <495F94EF-8F57-440D-8810-F40E40DE69D5@sarenet.es> <4B26B08E.5000203@FreeBSD.org> <20091216214621.GA4217@garage.freebsd.pl> Subject: Re: zfs receive gives: internal error: Argument list too long 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, 13 Feb 2010 02:15:27 -0000 Wanted to let those following the thread know that I also received the "argument list too big" error. I recompiled FREEBSD-8.0p2 with the E2BIG patch and it fixed the error for me as well. Thanks! Greg > > Martin, please go ahead and commit your patch. > > Thank you for looking into this! > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > > > -- View this message in context: http://old.nabble.com/Fwd%3A-Re%3A-zfs-receive-gives%3A-internal-error%3A-Argument-list-too-long-tp26102118p27571737.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@FreeBSD.ORG Sat Feb 13 14:30:07 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 8AB7E106566B for ; Sat, 13 Feb 2010 14:30:07 +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 61ABA8FC0A for ; Sat, 13 Feb 2010 14:30:07 +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 o1DEU70U012668 for ; Sat, 13 Feb 2010 14:30:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1DEU7r9012664; Sat, 13 Feb 2010 14:30:07 GMT (envelope-from gnats) Date: Sat, 13 Feb 2010 14:30:07 GMT Message-Id: <201002131430.o1DEU7r9012664@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Ruben van Staveren Cc: Subject: Re: kern/140661: [zfs] /boot/loader fails to work on a GPT/ZFS-only system on both 8.0-RC2 and RC3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ruben van Staveren List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 14:30:07 -0000 The following reply was made to PR kern/140661; it has been noted by GNATS. From: Ruben van Staveren To: FreeBSD Stable , kvs@pil.dk Cc: bug-followup@FreeBSD.org Subject: Re: kern/140661: [zfs] /boot/loader fails to work on a GPT/ZFS-only system on both 8.0-RC2 and RC3 Date: Sat, 13 Feb 2010 15:23:37 +0100 > On Nov 18, 2009, at 21:57 , Scot Hetzel wrote: > > Make sure you have LOADER_ZFS_SUPPORT in your /etc/src.conf: > >=20 > > dv8t01# cat /etc/src.conf > > LOADER_ZFS_SUPPORT=3DYES >=20 > Ah! I also have LOADER_TFTP_SUPPORT=3DYES. Removing that, and = everything works. > I don't know why I didn't think of that in the first place, but maybe = this > is either a bug, or something that should be warned about when = building > loader(8)? >=20 > /Kenneth I had the same problem which went away after removing TFTP support and = reinstalling the bootcode.=20 For now I suggest to add the following patch: --- sys/boot/i386/loader/conf.c.orig 2010-02-13 14:08:31.154391969 = +0000 +++ sys/boot/i386/loader/conf.c 2010-02-13 14:11:11.119255786 +0000 @@ -46,6 +46,10 @@ #error "Cannot have both tftp and nfs support yet." #endif =20 +#if defined(LOADER_ZFS_SUPPORT) && defined(LOADER_TFTP_SUPPORT) +#error "Cannot have both tftp and zfs support yet." +#endif + #if defined(LOADER_FIREWIRE_SUPPORT) extern struct devsw fwohci; #endif I think having both options corrupt each other's environment=20 system: FreeBSD freebsd-master 8.0-STABLE FreeBSD 8.0-STABLE #2: Mon Jan 18 = 16:14:24 UTC 2010 = root@freebsd-master:/usr/obj/usr/cvsup/8-stable/src/sys/VMWARE amd64 Regards, Ruben From owner-freebsd-fs@FreeBSD.ORG Sat Feb 13 20:04: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 14D6A106568F; Sat, 13 Feb 2010 20:04:33 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 954048FC0A; Sat, 13 Feb 2010 20:04:32 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 8so201701qwh.7 for ; Sat, 13 Feb 2010 12:04:31 -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=WsJM2XfT97V0dGFyC597g24F94X/Dyuish0k6wDG8ps=; b=W61QWICxTJUM31deQLmH/hVeQR27vXJo+6cBALS24Y3wp6zqY87dVKeq63GShJ1inl +nbSsqQDK45sjNL4TPRce5zSv8p1kvV6AQ4N7axjbPdc4l/fmWPXyKUtk70pabG9vrnd l8gSoY51QubJ2g01VZEM9TgXu+vLnQV8WrLqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JXxyGO38fTB1b/m8Gy47s+7VxYonlFuhgEu6P5lS/xOAZPrWUuA1wqiDufqJR4x7/V 1ihbrTBE0S5GRZsyx7VsYxIpIttsAB04QvT6YlCYp8q/1iI+38wbO3uWFbLQwlXXSr/L 39B8WYhEfCP/hDF3dxfPWFNY9/CngU6BCI4rM= MIME-Version: 1.0 Received: by 10.224.95.154 with SMTP id d26mr1496260qan.108.1266091471753; Sat, 13 Feb 2010 12:04:31 -0800 (PST) Date: Sat, 13 Feb 2010 22:04:31 +0200 Message-ID: From: Dan Naumov To: freebsd-questions@freebsd.org, freebsd-fs@freebsd.org, FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: booting off a ZFS pool consisting of multiple striped mirror vdevs 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, 13 Feb 2010 20:04:33 -0000 Hello I have succesfully tested and used a "full ZFS install" of FreeBSD 8.0 on both single disk and mirror disk configurations using both MBR and GPT partitioning. AFAIK, with the more recent -CURRENT and -STABLE it is also possible to boot off a root filesystem located on raidz/raidz2 pools. But what about booting off pools consisting of multiple striped mirror or raidz vdevs? Like this: Assume each disk looks like a half of a traditional ZFS mirror root configuration using GPT 1: freebsd-boot 2: freebsd-swap 3: freebsd-zfs |disk1+disk2| + |disk3+disk4| + |disk5+disk6| My logic tells me that while booting off any of the 6 disks, boot0 and boot1 stage should obviously work fine, but what about the boot2 stage? Can it properly handle booting off a root filesystem thats striped across 3 mirror vdevs or is booting off a single mirror vdev the best that one can do right now? - Sincerely, Dan Naumov From owner-freebsd-fs@FreeBSD.ORG Sat Feb 13 23:38: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 AD8C6106566C for ; Sat, 13 Feb 2010 23:38:23 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 360B28FC1C for ; Sat, 13 Feb 2010 23:38:22 +0000 (UTC) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1DLZGrP001112 for ; Sun, 14 Feb 2010 08:35:16 +1100 Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1DLZD32013085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Feb 2010 08:35:13 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1DLZ9Rv058785; Sun, 14 Feb 2010 08:35:09 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1DLZ9HO058784; Sun, 14 Feb 2010 08:35:09 +1100 (EST) (envelope-from peter) Date: Sun, 14 Feb 2010 08:35:09 +1100 From: Peter Jeremy To: Ivan Voras Message-ID: <20100213213509.GC93045@server.vk2pj.dyndns.org> References: <9bbcef731002121753j3787430cv2256b2baeddd9e1@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eRtJSFbw+EEWtPj3" Content-Disposition: inline In-Reply-To: <9bbcef731002121753j3787430cv2256b2baeddd9e1@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS file storage 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: Sat, 13 Feb 2010 23:38:23 -0000 --eRtJSFbw+EEWtPj3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-13 02:53:55 +0100, Ivan Voras wrote: >Clear as mud, but I'll try to understand it... I suggest you grab a copy of http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskform= at0822.pdf This will help explain the underlying structures. --=20 Peter Jeremy --eRtJSFbw+EEWtPj3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkt3Gw0ACgkQ/opHv/APuIcIMQCeMc266VUtTzN+KATclw26UP75 M6gAoKTCtRtBXzjFVkHIr3sMb8uEX8rA =z8ul -----END PGP SIGNATURE----- --eRtJSFbw+EEWtPj3--