From owner-freebsd-fs@FreeBSD.ORG Sun Aug 9 11:47:11 2009 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 968C31065672 for ; Sun, 9 Aug 2009 11:47:11 +0000 (UTC) (envelope-from sub.mesa@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 123848FC08 for ; Sun, 9 Aug 2009 11:47:10 +0000 (UTC) Received: by bwz2 with SMTP id 2so1562759bwz.43 for ; Sun, 09 Aug 2009 04:47:09 -0700 (PDT) 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=tbR0/pF0W+QwlAFkwLFfBIDI0B1JLWCK1fdy8AeWAYs=; b=VYcgo6QLRIdrkRrFnYSYq2Ed/G0oGeRm0J5MmvVK7lJZeqXI+ZJnt4kpwyIRgZYWvC ickImpis5pahDvt72/ucreNdmbGEqVSP0YY2UG+7TqNtbeTCHZN/udvN2H9QL29hDms0 oDGdzHC0Jyl8wrC7235xOUHWU/vGo2VY+YHdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SvSx54fgacDEw3hI7fDDnlh1Pqv6XhfIJYjQdZLHLQdUiE003W3U+ujkbpF9owmD0R gGIzgWmO63ZbT0TiB1XuIt9KUducKJAcJJHiqSSITvw9aq0omMOatZ++ZKvxMNVrb6X4 QehNtK8PDLYOxDXdZZkgV+xIMvcH3W1EE8bgc= MIME-Version: 1.0 Received: by 10.223.124.81 with SMTP id t17mr663634far.21.1249816472899; Sun, 09 Aug 2009 04:14:32 -0700 (PDT) Date: Sun, 9 Aug 2009 13:14:32 +0200 Message-ID: <883b2dc50908090414o71bc5fc2q5aef64c2b5da653e@mail.gmail.com> From: Jason Edwards To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ZFS corruption on 8-CURRENT 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, 09 Aug 2009 11:47:11 -0000 Hi guys, I'm investigating some weird corruption issue. After filling up my 8-disk RAID-Z pool with data and using it for a few weeks, it started to show me this: # zpool status sub pool: sub state: UNAVAIL status: One or more devices could not be used because the label is missing or invalid. There are insufficient replicas for the pool to continue functioning. action: Destroy and re-create the pool from a backup source. see: http://www.sun.com/msg/ZFS-8000-5E scrub: none requested config: NAME STATE READ WRITE CKSUM sub UNAVAIL 0 0 0 insufficient replicas raidz1 UNAVAIL 0 0 0 insufficient replicas ad14a FAULTED 0 0 0 corrupted data ad8a ONLINE 0 0 0 ad10a ONLINE 0 0 0 ad10a FAULTED 0 0 0 corrupted data ad18a FAULTED 0 0 0 corrupted data ad12a FAULTED 0 0 0 corrupted data ad16a FAULTED 0 0 0 corrupted data ad8a FAULTED 0 0 0 corrupted data oops? What happened here? Besides the "corrupted data" it can also be seen ad10a is displayed twice, one online and one failed. After rebooting, it shows a little cleaner, but it found a problem with the ZIL: # zpool status sub pool: sub state: FAULTED status: An intent log record could not be read. Waiting for adminstrator intervention to fix the faulted pool. action: Either restore the affected device(s) and run 'zpool online', or ignore the intent log records by running 'zpool clear'. scrub: none requested config: NAME STATE READ WRITE CKSUM sub FAULTED 0 0 0 bad intent log raidz1 ONLINE 0 0 0 ad14a ONLINE 0 0 0 ad4a ONLINE 0 0 0 ad6a ONLINE 0 0 0 ad10a ONLINE 0 0 0 ad18a ONLINE 6 0 0 ad12a ONLINE 0 0 0 ad16a ONLINE 0 0 0 ad8a ONLINE 0 0 0 Additionally, i got some read errors on ad18. But since this is a raid-z i guess one disk alone cannot corrupt/fail the entire array. Before i do any actions that might be destructive, anybody has a clue what happened here and how i can prevent this in the future? Box is a quadcore X4 9350e with 6GB RAM and its running 8-CURRENT as of July 21th 2009 (after 8.0-BETA2). It did work correctly before upgrading CURRENT to a newer date. Maybe some bug slipped in? Kind regards, sub From owner-freebsd-fs@FreeBSD.ORG Sun Aug 9 18:20:11 2009 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 31E0E106564A for ; Sun, 9 Aug 2009 18:20:11 +0000 (UTC) (envelope-from michael@fuckner.net) Received: from dedihh.fuckner.net (dedihh.fuckner.net [81.209.183.161]) by mx1.freebsd.org (Postfix) with ESMTP id E61BC8FC20 for ; Sun, 9 Aug 2009 18:20:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dedihh.fuckner.net (Postfix) with ESMTP id DBAC761D67; Sun, 9 Aug 2009 20:02:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at fuckner.net Received: from dedihh.fuckner.net ([127.0.0.1]) by localhost (dedihh.fuckner.net [127.0.0.1]) (amavisd-new, port 10024) with SMTP id hUnosQDAnoRm; Sun, 9 Aug 2009 20:02:08 +0200 (CEST) Received: from c64.rebootking.de (e176185175.adsl.alicedsl.de [85.176.185.175]) by dedihh.fuckner.net (Postfix) with ESMTPA id 2D6C861D58; Sun, 9 Aug 2009 20:02:08 +0200 (CEST) Message-ID: <4A7F0F0E.207@fuckner.net> Date: Sun, 09 Aug 2009 20:01:50 +0200 From: Michael Fuckner User-Agent: Thunderbird 2.0.0.22 (X11/20090726) MIME-Version: 1.0 To: aoyama@peach.ne.jp, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Using Intel Iscsi remote boot with istgt 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, 09 Aug 2009 18:20:11 -0000 Hi, I try to boot from Intel iSCSI Nic, but it does not work as planned. I am using the following setup: 192.168.2.1 :iscsi-initiator, gateway 192.168.2.65: iscsi-target with intel iscsi rom installed istgt is 20090428, iscsi-initiator is 2.2.3 I can connect from the OS c64# iscontrol -d -t 192.168.2.1 -c /etc/iscsi.conf -n c64iscsi TargetName=iqn.2007-09.jp.ne.peach.istgt:target0 TargetAddress=192.168.2.1:3260,1 c64# iscontrol -t 192.168.2.1 -c /etc/iscsi.conf -n c64iscsi c64# iscontrol[1576]: running iscontrol[1576]: (pass1:iscsi0:0:0:0): tagged openings now 0 iscontrol: supervise starting main loop c64# dmesg |grep da0 da0 at iscsi0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0 at iscsi0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device c64# cat /etc/iscsi.conf c64iscsi { AuthMethod = None chapIName = c64iscsi chapSecret = 1234567890123456 Initiatorname = iqn.1991-05.com.microsoft:c64iscsi TargetName = iqn.2007-09.jp.ne.peach.istgt:target0 TargetAddress = 192.168.2.1 # your iscsi server IP } When trying to connect using the Intel Card I get: ------------------------------------------- Intel(R) iSCSI Boot version 2.3.52 Copyright (c) 2003-2009 Intel Corporation. All rights reserved. Press ESC key to skip iscsi boot initialization Initializing adapter configuration - MAC address(0015177CC363). Using STATIC configuration for primary port. Please wait. iSCSI Target Name : iqn.2007-09.jp.ne.peach.istgt:target0 iSCSI Target IP Address : 192.168.2.1 LUN ID: 1 Port 3260 VLAN ID : 3 iSCSI Initiator IP: 192.168.2.65 iSCSI Gateway IP: 192.168.2.1 iSCSI Initiator Name: iqn.1991-05.com.microsoft:c64iscsi Attempting to connect to target disk using MAC address(0015177CC363) ERROR: Could not establish TCP/IP connection with iSCSI target. No disk found! ------------------------------------------- In tcpdump I don't even see the card trying to do anything useful. tcpdump -nvi em0 port 3260 18:05:18.602286 IP (tos 0x0, ttl 64, id 24099, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.51302: P 144:192(48) ack 1 win 8326 Any idea how to tell the Intel card to boot via network? Regards, Michael! From owner-freebsd-fs@FreeBSD.ORG Mon Aug 10 09:35:47 2009 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 940101065672 for ; Mon, 10 Aug 2009 09:35:47 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 352238FC31 for ; Mon, 10 Aug 2009 09:35:46 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n7A9ZiLH043249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 11:35:45 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <459140BF-273E-4587-93CC-085BD446E8F6@lassitu.de> From: Stefan Bethke To: Michael Fuckner In-Reply-To: <4A7F0F0E.207@fuckner.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Aug 2009 11:35:43 +0200 References: <4A7F0F0E.207@fuckner.net> X-Mailer: Apple Mail (2.936) Cc: freebsd-fs@freebsd.org, aoyama@peach.ne.jp Subject: Re: Using Intel Iscsi remote boot with istgt 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, 10 Aug 2009 09:35:47 -0000 Am 09.08.2009 um 20:01 schrieb Michael Fuckner: > Initializing adapter configuration - MAC address(0015177CC363). > Using STATIC configuration for primary port. Please wait. > iSCSI Target Name : iqn.2007-09.jp.ne.peach.istgt:target0 > iSCSI Target IP Address : 192.168.2.1 > LUN ID: 1 Port 3260 > VLAN ID : 3 ^^ > iSCSI Initiator IP: 192.168.2.65 > iSCSI Gateway IP: 192.168.2.1 > iSCSI Initiator Name: iqn.1991-05.com.microsoft:c64iscsi Does that match your network configuration? Can you try capturing all traffic the card sends towards the server, not just tcp port 3260? Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-fs@FreeBSD.ORG Mon Aug 10 11:06:55 2009 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 48D9E1065678 for ; Mon, 10 Aug 2009 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 36D3E8FC1A for ; Mon, 10 Aug 2009 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 n7AB6tkU025134 for ; Mon, 10 Aug 2009 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 n7AB6sxJ025130 for freebsd-fs@FreeBSD.org; Mon, 10 Aug 2009 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Aug 2009 11:06:54 GMT Message-Id: <200908101106.n7AB6sxJ025130@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, 10 Aug 2009 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/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/136942 fs [zfs] zvol resize not reflected until reboot 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/136218 fs [zfs] Exported ZFS pools can't be imported into (Open) 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/135480 fs [zfs] panic: lock &arg.lock already initialized o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o bin/135314 fs [zfs] assertion failed for zdb(8) usage o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot f kern/134496 fs [zfs] [panic] ZFS pool export occasionally causes a ke 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 [smbfs] [panic] panic: ffs_truncate: read-only filesys o kern/133373 fs [zfs] umass attachment causes ZFS checksum errors, dat 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/133134 fs [zfs] Missing ZFS zpool labels o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132551 fs [zfs] ZFS locks up on extattr_list_link syscall 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 f kern/132068 fs [zfs] page fault when using ZFS over NFS on 7.1-RELEAS o kern/131995 fs [nfs] Failure to mount NFSv4 server 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/131086 fs [ext2fs] [patch] mkfs.ext2 creates rotten partition 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/129148 fs [zfs] [panic] panic on concurrent writing & rollback 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/128633 fs [zfs] [lor] lock order reversal in zfs o kern/128514 fs [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Ad f kern/128173 fs [ext2fs] ls gives "Input/output error" on mounted ext3 o kern/127659 fs [tmpfs] tmpfs memory leak o kern/127492 fs [zfs] System hang on ZFS input-output o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption 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 o kern/125644 fs [zfs] [panic] zfs unfixable fs errors caused panic whe f kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/125149 fs [nfs] [panic] changing into .zfs dir from nfs client c f 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/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o kern/122173 fs [zfs] [panic] Kernel Panic if attempting to replace a o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o kern/122047 fs [ext2fs] [patch] incorrect handling of UF_IMMUTABLE / o kern/122038 fs [tmpfs] [panic] tmpfs: panic: tmpfs_alloc_vp: type 0xc 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 kern/121770 fs [zfs] ZFS on i386, large file or heavy I/O leads to ke 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 o bin/120288 fs zfs(8): "zfs share -a" does not send SIGHUP to mountd 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 misc/118855 fs [zfs] ZFS-related commands are nonfunctional in fixit o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118320 fs [zfs] [patch] NFS SETATTR sometimes fails to set file 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 kern/113180 fs [zfs] Setting ZFS nfsshare property does not cause inh 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/105093 fs [ext2fs] [patch] ext2fs on read-only media cannot be m 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/89991 fs [ufs] softupdates with mount -ur causes fs UNREFS 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/77826 fs [ext2fs] ext2fs usb filesystem will not mount RW 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 149 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Aug 10 19:31:26 2009 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 4E73A106566B; Mon, 10 Aug 2009 19:31:26 +0000 (UTC) (envelope-from trevor.hearn@Vanderbilt.Edu) Received: from mailgate.vanderbilt.edu (mailgate.vanderbilt.edu [129.59.4.20]) by mx1.freebsd.org (Postfix) with ESMTP id 0B70E8FC16; Mon, 10 Aug 2009 19:31:25 +0000 (UTC) Received: from its-hcwnem22.ds.vanderbilt.edu ([10.1.137.30]) by mailgate02.csm.vanderbilt.edu (8.14.1/8.14.1) with ESMTP id n7AJVOIa000664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Aug 2009 14:31:24 -0500 Received: from its-hcwnem03.ds.Vanderbilt.edu ([10.1.137.103]) by ITS-SCWNEM24.ds.Vanderbilt.edu ([::1]) with mapi; Mon, 10 Aug 2009 14:31:24 -0500 From: "Hearn, Trevor" To: John Baldwin , "freebsd-fs@freebsd.org" Date: Mon, 10 Aug 2009 14:31:23 -0500 Thread-Topic: UFS Filesystem issues, and the loss of my hair... Thread-Index: AcoXXNmmaCZfKhlkSFqJW+8C5zze3QCkP4zO Message-ID: <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34CA@ITS-HCWNEM03.ds.Vanderbilt.edu> References: <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34C3@ITS-HCWNEM03.ds.Vanderbilt.edu>, <200908070829.54571.jhb@freebsd.org> In-Reply-To: <200908070829.54571.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-08-10_10:2009-07-24, 2009-08-10, 2009-08-10 signatures=0 X-PPS: No, score=0 Cc: Subject: RE: UFS Filesystem issues, and the loss of my hair... 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, 10 Aug 2009 19:31:26 -0000 To the FreeBSD-FS group at large... Well, I've spent alot of time looking this one over... I setup a share on a= webserver to put up redacted images of the errors I am getting. They are h= ere: http://www.trevorhearn.com/Array/IMG_0056.jpg http://www.trevorhearn.com/Array/IMG_0061.jpg http://www.trevorhearn.com/Array/IMG_0063.jpg http://www.trevorhearn.com/Array/IMG_0065.jpg http://www.trevorhearn.com/Array/IMG_0067.jpg http://www.trevorhearn.com/Array/IMG_0069.jpg So, while I am in a meeting about the array, oddly, I have this come rollin= g across the screen of the terminal session I am in... Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, length=3D16384)]error =3D 5 Aug 10 10:53:43 XXXX last message repeated 20 times Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, length=3D1638d)]error =3D 5 Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, length=3D16384)]error =3D 5 Aug 10 10:53:43 XXXX last message repeated 18 times When I say it was rolling across the screen, I mean it did it for about 5 m= inutes... I was waiting for the hard-lock to happen, but the process that w= as touching the file(s) went to 99.02%, and has stayed there the remainder = of the day... PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAN= D 1351 xxxxxxxx 1 -8 0 10928K 4656K CPU1 0 2:10 99.02% smbd While this happened earlier in the morning, which we were only seeing moder= ate useage: Aug 10 09:54:18 PRSA kernel: pid 1776 (smbd), uid 1194 inumber 107797529 on= /xxxxxxxxxx: bad block Aug 10 09:54:18 PRSA kernel: bad block 165436921330628865, ino 107797529 The bad block number is WAAAY outside of what is used on the machine. So...= . Everything that I have found relating to these problems is everyone asking,= 'How do I fix this', and NONE of them so far have been a fix. 'Error =3D 5= ' relates to EIO, or an error in the input/output to a device. Now, that be= ing said, I either have a problem with the controller in my Promise Array, = which I am learning is possible, or, I have an issue with a driver in FreeB= SD, and just happen to have a circumstance where it will appear. There does= not seem to be a rhyme or reason to what is taking place. How does a set o= f array controllers throw a bad block error? I mean, with a standard drive,= I can see it... but an array controller? Some other things that I have fou= nd... The link below tells about using 'find / -type d -exec stat {} ;' to run t= hru the filesystem and find the corrupted files. I did this earlier this mo= rning, and found none. I went back thru several of the inodes that are show= ing in the pictures above, and only found one in existence. I battened down= the hatches, and hit that directory. I was able to cp all of the info in t= hat directory to another directory without a single problem. With all that = I have been reading, this should have caused all manner of hell. I ran fsck= on all directories, and got the server back online... Back online? Yes. It= hard-locked at 3:09AM Sunday morning. Odd, since it has done that MANY tim= es at 3:09 AM. I have Nagios watching the server, and it always seems to do= so at the same time. I looked at cron jobs, and found that it runs PERIODI= C DAILY at 3:01AM. My Nagios box checks every 5 minutes, with three interva= ls of one minute afterwards if a service is not available. SO, somewhere in= the list of things that the server does in the PERIODIC DAILY job, there i= s something that makes the server fault. Tonight, I will be going thru the = jobs, running them one by one, seeing exactly which one causes the fault. I= have seen others speak of it going down at 3:00AMish, so I think this migh= t be a bit of a clue. At this point, I am purchasing another 2 port fibre channel card, with hope= s of installing it in a spare 1U server I have, to migrate to Ubuntu, or si= milar. I'd like to test it out with Ubuntu, but I do not know at this point= if it will see the array partitions correctly, nor if it will allow me to = access the UFS partitions that are there. Worst case, I will backup, and re= -format the chassis themselves. I would hope that this would not be necessa= ry, but I am almost at my wit's end. Has ANYONE got any ideas, other than the ones presented? I'm keen to see if= there is a fix, because I love FreeBSD, but I can't be a evangelist for it= when it is giving me so much grief. Thanks for listening, I'll be here all= week. :) -Trevor ________________________________________ From: John Baldwin [jhb@freebsd.org] Sent: Friday, August 07, 2009 7:29 AM To: freebsd-fs@freebsd.org Cc: Hearn, Trevor Subject: Re: UFS Filesystem issues, and the loss of my hair... On Thursday 06 August 2009 9:51:04 am Hearn, Trevor wrote: > First off, let me state that I love FreeBSD. I've used it for years, and have not had any major problems with it... Until now. > > As you can tell, I work for a major university. I setup a large storage array to hold data for a project they have here. No great shakes, just some standard files and such. The fun started when I started loading users onto the system, and they started using it... Isn't that always the case? Now, I get ufs_dirbad errors, and the system hard locks. This isn't the worst thin= g that could happen, but when you're talking about file partitions the size that I am using, the fsck takes FOREVER. Somewhere on the order of 1.5 hour= s. During that time, I am bringing the individual shares/partitions online, bu= t the users suffer. I've asked about this before, in a different forum, but g= ot no usable information that I could see. So, here goes... > > The system is as such. A dell 2950 1U server, with a Qlogic Fibre Channel card. It is connected to two Promise Array chassis, 610 series, each with 1= 6 drives. Each chassis is running RAID 6, which gives me about 12.73tb of storage per chassis. From there, the logical drives are sliced up into smaller partitions. At most, I have a 3.6tb partition. The smallest is a 100gig partition. > > Filesystem Size Used Avail Capacity Mounted on > /dev/mfid0s1a 197G 10G 170G 6% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/da0p1 1.8T 1.5T 130G 92% /slice1 > /dev/da0p5 2.7T 1.8T 661G 74% /slice2 > /dev/da0p9 250G 21G 209G 9% /slice3 > /dev/da1p3 103G 12G 83G 12% /slice4 > /dev/da1p4 205G 54G 135G 29% /slice5 > /dev/da1p5 103G 7.3G 87G 8% /slice6 > /dev/da1p6 103G 22G 72G 23% /slice7 > etc... > > I had to use GPT to setup the partitions, and they are using UFS2 for the filesystem. Now... If that's not fun enough... I have TWO of these creature= s, which RSYNC every 4 hours. The secondary system is across campus, and sits idle 99% of the time. Every 4 hours, in a stepped schedule, the primary arr= ay syncs to the secondary array. If the primary goes down, I FSCK, and any fil= es that are fried, I bring back across from the secondary and replace them. Th= is has worked OK for a while, but now I am getting Kernel Panics on a regular basis. I've been told to migrate to a different filesystem, but my options are ZFS and using GJOURNAL with UFS, from what I can tell. I need something repeatable, simple, and I need something robust. I have NO idea why I keep getting errors like this, but I imagine it's a cascading effect of other hangs that have caused more corruption. > > I'd buy a fella, or gal, a cup of coffee and a pop-tart if they could hel= p a brother out. I have checked out this link: > http://phaq.phunsites.net/2007/07/01/ufs_dirbad-panic-with-mangled-entries-= in-ufs/ > and decided that I need to give this a shot after hours, but being the ki= nda guy I am, I need to make sure I am covering all of my bases. Are you seeing ufs_dirbad panics? Specifically, can you capture the messag= es on the console when the machine panics? -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Aug 10 20:06:47 2009 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 010AD1065674 for ; Mon, 10 Aug 2009 20:06:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C4A9E8FC1E for ; Mon, 10 Aug 2009 20:06:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 524C446B29; Mon, 10 Aug 2009 16:06:46 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 656F28A0AB; Mon, 10 Aug 2009 16:06:45 -0400 (EDT) From: John Baldwin To: "Hearn, Trevor" Date: Mon, 10 Aug 2009 16:05:12 -0400 User-Agent: KMail/1.9.7 References: <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34C3@ITS-HCWNEM03.ds.Vanderbilt.edu> <200908070829.54571.jhb@freebsd.org> <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34CA@ITS-HCWNEM03.ds.Vanderbilt.edu> In-Reply-To: <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34CA@ITS-HCWNEM03.ds.Vanderbilt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908101605.12332.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 10 Aug 2009 16:06:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "freebsd-fs@freebsd.org" Subject: Re: UFS Filesystem issues, and the loss of my hair... 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, 10 Aug 2009 20:06:47 -0000 On Monday 10 August 2009 3:31:23 pm Hearn, Trevor wrote: > To the FreeBSD-FS group at large... > > Well, I've spent alot of time looking this one over... I setup a share on a webserver to put up redacted images of the errors I am getting. They are here: > > http://www.trevorhearn.com/Array/IMG_0056.jpg > http://www.trevorhearn.com/Array/IMG_0061.jpg > http://www.trevorhearn.com/Array/IMG_0063.jpg > http://www.trevorhearn.com/Array/IMG_0065.jpg > http://www.trevorhearn.com/Array/IMG_0067.jpg > http://www.trevorhearn.com/Array/IMG_0069.jpg > > So, while I am in a meeting about the array, oddly, I have this come rolling across the screen of the terminal session I am in... > > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, length=16384)]error = 5 > Aug 10 10:53:43 XXXX last message repeated 20 times > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, length=1638d)]error = 5 > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, length=16384)]error = 5 > Aug 10 10:53:43 XXXX last message repeated 18 times Is the '1638d' above a typo in the cut and paste or does it actually have a 'd' instead of a '4' in the log? '4' is 0x34 and 'd' is 0x64 so that could be indicative of a two-bit memory error perhaps? -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Aug 10 20:19:15 2009 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 D39D71065672; Mon, 10 Aug 2009 20:19:15 +0000 (UTC) (envelope-from trevor.hearn@Vanderbilt.Edu) Received: from mailgate.vanderbilt.edu (mailgate.vanderbilt.edu [129.59.4.20]) by mx1.freebsd.org (Postfix) with ESMTP id 6B9FC8FC43; Mon, 10 Aug 2009 20:19:15 +0000 (UTC) Received: from its-hcwnem22.ds.vanderbilt.edu ([10.1.137.28]) by mailgate03.csm.vanderbilt.edu (8.14.1/8.14.1) with ESMTP id n7AKJEbj010424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Aug 2009 15:19:14 -0500 Received: from its-hcwnem03.ds.Vanderbilt.edu ([10.1.137.103]) by ITS-HCWNEM22.ds.Vanderbilt.edu ([10.2.171.114]) with mapi; Mon, 10 Aug 2009 15:19:11 -0500 From: "Hearn, Trevor" To: John Baldwin Date: Mon, 10 Aug 2009 15:15:44 -0500 Thread-Topic: UFS Filesystem issues, and the loss of my hair... Thread-Index: AcoZ9hoZCPm8CxnqTnOQjuE/wqRX5QAATzGq Message-ID: <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34CC@ITS-HCWNEM03.ds.Vanderbilt.edu> References: <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34C3@ITS-HCWNEM03.ds.Vanderbilt.edu> <200908070829.54571.jhb@freebsd.org> <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34CA@ITS-HCWNEM03.ds.Vanderbilt.edu>, <200908101605.12332.jhb@freebsd.org> In-Reply-To: <200908101605.12332.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-08-10_10:2009-07-24, 2009-08-10, 2009-08-10 signatures=0 X-PPS: No, score=0 Cc: "freebsd-fs@freebsd.org" Subject: RE: UFS Filesystem issues, and the loss of my hair... 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, 10 Aug 2009 20:19:17 -0000 Here is the chunk that I grabbed from the screen to save as a memento. :) Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, length=3D16384)]error =3D 5 Aug 10 10:53:43 XXXX last message repeated 20 times Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, length=3D1638d)]error =3D 5 Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, length=3D16384)]error =3D 5 Aug 10 10:53:43 XXXX last message repeated 18 times Aug 10 10:53:43 XXXX kernel: g_vfs_done()-da1p7[READ(offset=3D Aug 10 10:53:43 XXXX kernel: -6419569950008350720, length=3D16384)]error = =3D 5 Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, length=3D16384)]error =3D 5 Aug 10 10:53:43 XXXX last message repeated 19 times Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, l=3Dngth=3D16384)]error 1 5 Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, length=3D16384)]error =3D 5 Aug 10 10:53:43 XXXX last message repeated 6 times Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, length=3D16384o]error =3D 5 Aug 10 10:53:43 XXXX kernel: Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, length=3D16384)]error =3D 5 Aug 10 10:53:43 XXXX last message repeated 22 times Aug 10 10:53:44 XXXX kernel: READ(offset=3D-6419569950008350720, length=3D1= 6384)]error =3D 5 Aug 10 10:53:44 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-641956995000= 8350720, length=3D16384)]error =3D 5 Aug 10 10:53:44 XXXX last message repeated 849 times As you can see, it's a little disjointed. I would assume that the screwed u= p length information is from the speed at which it was coming out, and poss= ibly another message got throw in at the same time?=20 -Trevor ________________________________________ From: John Baldwin [jhb@freebsd.org] Sent: Monday, August 10, 2009 3:05 PM To: Hearn, Trevor Cc: freebsd-fs@freebsd.org Subject: Re: UFS Filesystem issues, and the loss of my hair... On Monday 10 August 2009 3:31:23 pm Hearn, Trevor wrote: > To the FreeBSD-FS group at large... > > Well, I've spent alot of time looking this one over... I setup a share on= a webserver to put up redacted images of the errors I am getting. They are= here: > > http://www.trevorhearn.com/Array/IMG_0056.jpg > http://www.trevorhearn.com/Array/IMG_0061.jpg > http://www.trevorhearn.com/Array/IMG_0063.jpg > http://www.trevorhearn.com/Array/IMG_0065.jpg > http://www.trevorhearn.com/Array/IMG_0067.jpg > http://www.trevorhearn.com/Array/IMG_0069.jpg > > So, while I am in a meeting about the array, oddly, I have this come roll= ing across the screen of the terminal session I am in... > > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, length=3D16384)]error =3D 5 > Aug 10 10:53:43 XXXX last message repeated 20 times > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, length=3D1638d)]error =3D 5 > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, length=3D16384)]error =3D 5 > Aug 10 10:53:43 XXXX last message repeated 18 times Is the '1638d' above a typo in the cut and paste or does it actually have a 'd' instead of a '4' in the log? '4' is 0x34 and 'd' is 0x64 so that could be indicative of a two-bit memory error perhaps? -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Aug 10 21:08:04 2009 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 6F75B1065689 for ; Mon, 10 Aug 2009 21:08:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3F3A08FC3D for ; Mon, 10 Aug 2009 21:08:04 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D1C1146B09; Mon, 10 Aug 2009 17:08:03 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2DF7C8A0AB; Mon, 10 Aug 2009 17:08:03 -0400 (EDT) From: John Baldwin To: "Hearn, Trevor" Date: Mon, 10 Aug 2009 17:07:49 -0400 User-Agent: KMail/1.9.7 References: <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34C3@ITS-HCWNEM03.ds.Vanderbilt.edu> <200908101605.12332.jhb@freebsd.org> <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34CC@ITS-HCWNEM03.ds.Vanderbilt.edu> In-Reply-To: <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34CC@ITS-HCWNEM03.ds.Vanderbilt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908101707.49526.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 10 Aug 2009 17:08:03 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "freebsd-fs@freebsd.org" Subject: Re: UFS Filesystem issues, and the loss of my hair... 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, 10 Aug 2009 21:08:04 -0000 On Monday 10 August 2009 4:15:44 pm Hearn, Trevor wrote: > Here is the chunk that I grabbed from the screen to save as a memento. :) > > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, length=16384)]error = 5 > Aug 10 10:53:43 XXXX last message repeated 20 times > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, length=1638d)]error = 5 > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, length=16384)]error = 5 > Aug 10 10:53:43 XXXX last message repeated 18 times > Aug 10 10:53:43 XXXX kernel: g_vfs_done()-da1p7[READ(offset= > Aug 10 10:53:43 XXXX kernel: -6419569950008350720, length=16384)]error = 5 > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, length=16384)]error = 5 > Aug 10 10:53:43 XXXX last message repeated 19 times > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, l=ngth=16384)]error 1 5 > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, length=16384)]error = 5 > Aug 10 10:53:43 XXXX last message repeated 6 times > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, length=16384o]error = 5 > Aug 10 10:53:43 XXXX kernel: > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, length=16384)]error = 5 > Aug 10 10:53:43 XXXX last message repeated 22 times > Aug 10 10:53:44 XXXX kernel: READ(offset=-6419569950008350720, length=16384)]error = 5 > Aug 10 10:53:44 XXXX kernel: g_vfs_done():da1p7[READ(offset=-6419569950008350720, length=16384)]error = 5 > Aug 10 10:53:44 XXXX last message repeated 849 times > > As you can see, it's a little disjointed. I would assume that the screwed up length information is from the speed at which it was coming out, and possibly another message got throw in at the same time? Yes, it does seem like it was part of one of the other messages. The isp(4) driver was just recently updated in HEAD by mjacob@ who has maintained that driver in the past. He may have some insight if there is an isp(4)-specific problem. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Aug 10 22:24:41 2009 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 C4055106566C; Mon, 10 Aug 2009 22:24:41 +0000 (UTC) (envelope-from trevor.hearn@Vanderbilt.Edu) Received: from mailgate.vanderbilt.edu (mailgate.vanderbilt.edu [129.59.4.20]) by mx1.freebsd.org (Postfix) with ESMTP id 814B88FC1A; Mon, 10 Aug 2009 22:24:41 +0000 (UTC) Received: from its-hcwnem22.ds.vanderbilt.edu ([10.1.137.28]) by mailgate03.csm.vanderbilt.edu (8.14.1/8.14.1) with ESMTP id n7AMOekc029443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Aug 2009 17:24:40 -0500 Received: from its-hcwnem03.ds.Vanderbilt.edu ([10.1.137.103]) by ITS-HCWNEM22.ds.Vanderbilt.edu ([10.2.171.114]) with mapi; Mon, 10 Aug 2009 17:24:41 -0500 From: "Hearn, Trevor" To: John Baldwin Date: Mon, 10 Aug 2009 17:20:44 -0500 Thread-Topic: UFS Filesystem issues, and the loss of my hair... Thread-Index: AcoZ/qowNE74XRw9QdWJ7GYzzv1lqwACiQRM Message-ID: <8E9591D8BCB72D4C8DE0884D9A2932DC6D2EDF21@ITS-HCWNEM03.ds.Vanderbilt.edu> References: <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34C3@ITS-HCWNEM03.ds.Vanderbilt.edu> <200908101605.12332.jhb@freebsd.org> <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34CC@ITS-HCWNEM03.ds.Vanderbilt.edu>, <200908101707.49526.jhb@freebsd.org> In-Reply-To: <200908101707.49526.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-08-10_11:2009-07-24, 2009-08-10, 2009-08-10 signatures=0 X-PPS: No, score=0 Cc: "freebsd-fs@freebsd.org" Subject: RE: UFS Filesystem issues, and the loss of my hair... 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, 10 Aug 2009 22:24:42 -0000 ________________________________________ From: John Baldwin [jhb@freebsd.org] Sent: Monday, August 10, 2009 4:07 PM To: Hearn, Trevor Cc: freebsd-fs@freebsd.org Subject: Re: UFS Filesystem issues, and the loss of my hair... On Monday 10 August 2009 4:15:44 pm Hearn, Trevor wrote: > Here is the chunk that I grabbed from the screen to save as a memento. :) > > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, length=3D16384)]error =3D 5 > Aug 10 10:53:43 XXXX last message repeated 20 times > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, length=3D1638d)]error =3D 5 > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, length=3D16384)]error =3D 5 > Aug 10 10:53:43 XXXX last message repeated 18 times > Aug 10 10:53:43 XXXX kernel: g_vfs_done()-da1p7[READ(offset=3D > Aug 10 10:53:43 XXXX kernel: -6419569950008350720, length=3D16384)]error = =3D 5 > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, length=3D16384)]error =3D 5 > Aug 10 10:53:43 XXXX last message repeated 19 times > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, l=3Dngth=3D16384)]error 1 5 > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, length=3D16384)]error =3D 5 > Aug 10 10:53:43 XXXX last message repeated 6 times > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, length=3D16384o]error =3D 5 > Aug 10 10:53:43 XXXX kernel: > Aug 10 10:53:43 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, length=3D16384)]error =3D 5 > Aug 10 10:53:43 XXXX last message repeated 22 times > Aug 10 10:53:44 XXXX kernel: READ(offset=3D-6419569950008350720, length= =3D16384)]error =3D 5 > Aug 10 10:53:44 XXXX kernel: g_vfs_done():da1p7[READ(offset=3D-6419569950= 008350720, length=3D16384)]error =3D 5 > Aug 10 10:53:44 XXXX last message repeated 849 times > > As you can see, it's a little disjointed. I would assume that the screwed= up length information is from the speed at which it was coming out, and po= ssibly another message got throw in at the same time? Yes, it does seem like it was part of one of the other messages. The isp(4= ) driver was just recently updated in HEAD by mjacob@ who has maintained that driver in the past. He may have some insight if there is an isp(4)-specifi= c problem. -- John Baldwin Heh. Ok, I just watched the same error message scroll across the screen for= about 5 minutes now, with a different offset, same length. The fun part is= that it is not touching the device, /dev/da1p7 at all. From the systat -vm= stat display, I see all of the traffic coming from the /dev/mfid0 drives. I= t ran for a while, then stopped. So, no access to the drive in question, da= 1p7, but on the root drive, mfid0. Odd. The partition is mapped to the root= drive. I wonder if the driver lost itself, and it tried to access the file= on the empty folder on the root drive. Sigh. Anyone? -Trevor= From owner-freebsd-fs@FreeBSD.ORG Tue Aug 11 00:51:10 2009 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 153521065672 for ; Tue, 11 Aug 2009 00:51:10 +0000 (UTC) (envelope-from nafzal@hotmail.com) Received: from col0-omc4-s8.col0.hotmail.com (col0-omc4-s8.col0.hotmail.com [65.55.34.210]) by mx1.freebsd.org (Postfix) with ESMTP id B86A68FC16 for ; Tue, 11 Aug 2009 00:51:09 +0000 (UTC) Received: from COL111-W23 ([65.55.34.199]) by col0-omc4-s8.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 17:41:06 -0700 Message-ID: X-Originating-IP: [192.55.54.39] From: Naeem Afzal To: Date: Tue, 11 Aug 2009 00:41:06 +0000 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Aug 2009 00:41:06.0703 (UTC) FILETIME=[69A0C1F0:01CA1A1C] Subject: filesystem size after newfs 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, 11 Aug 2009 00:51:10 -0000 resending to FS mailing list:I created this small partition of 512K bytes o= n disk=2C I am noticing about 24% is used up before system can be mounted a= nd used. My assumption was about 4% is supposed to be used if minfree is se= t to 0. #newfs -U -l -m 0 -n -o space /dev/ad1d /dev/ad1d: 0.5MB (1024 sectors) block size 16384=2C fragment size 2048 = using 1 cylinder groups of 0.50MB=2C 32 blks=2C 64 inodes with soft updates super-block backups (for fsck -b #) at: 160 #mount /dev/ad1d /test #df -H /test Filesystem Size Used Avail Capacity Mounted on /dev/ad1d 391k 2.0k 389k 1% /test Could someone explain where the 512-391=3D121K of disk space went to? W= hat is the relation between this used of space and total paritition size or= is it some fixed ratio? Thanks & Regards Naeem _________________________________________________________________ Get your vacation photos on your phone! http://windowsliveformobile.com/en-us/photos/default.aspx?&OCID=3D0809TL-HM= From owner-freebsd-fs@FreeBSD.ORG Tue Aug 11 05:22:46 2009 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 827711065672 for ; Tue, 11 Aug 2009 05:22:46 +0000 (UTC) (envelope-from michael@fuckner.net) Received: from dedihh.fuckner.net (dedihh.fuckner.net [81.209.183.161]) by mx1.freebsd.org (Postfix) with ESMTP id 25FA38FC2B for ; Tue, 11 Aug 2009 05:22:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dedihh.fuckner.net (Postfix) with ESMTP id 7F10961D58; Tue, 11 Aug 2009 07:22:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at fuckner.net Received: from dedihh.fuckner.net ([127.0.0.1]) by localhost (dedihh.fuckner.net [127.0.0.1]) (amavisd-new, port 10024) with SMTP id G1qvn3YhnpuG; Tue, 11 Aug 2009 07:22:39 +0200 (CEST) Received: from c64.rebootking.de (e176130149.adsl.alicedsl.de [85.176.130.149]) by dedihh.fuckner.net (Postfix) with ESMTPA id 2892661D1B; Tue, 11 Aug 2009 07:22:39 +0200 (CEST) Message-ID: <4A81000A.3020602@fuckner.net> Date: Tue, 11 Aug 2009 07:22:18 +0200 From: Michael Fuckner User-Agent: Thunderbird 2.0.0.22 (X11/20090726) MIME-Version: 1.0 To: Stefan Bethke References: <4A7F0F0E.207@fuckner.net> <459140BF-273E-4587-93CC-085BD446E8F6@lassitu.de> In-Reply-To: <459140BF-273E-4587-93CC-085BD446E8F6@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, aoyama@peach.ne.jp Subject: Re: Using Intel Iscsi remote boot with istgt 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, 11 Aug 2009 05:22:46 -0000 Stefan Bethke wrote: > Am 09.08.2009 um 20:01 schrieb Michael Fuckner: > >> Initializing adapter configuration - MAC address(0015177CC363). >> Using STATIC configuration for primary port. Please wait. >> iSCSI Target Name : iqn.2007-09.jp.ne.peach.istgt:target0 >> iSCSI Target IP Address : 192.168.2.1 >> LUN ID: 1 Port 3260 >> VLAN ID : 3 > ^^ >> iSCSI Initiator IP: 192.168.2.65 >> iSCSI Gateway IP: 192.168.2.1 >> iSCSI Initiator Name: iqn.1991-05.com.microsoft:c64iscsi > > > Does that match your network configuration? > > Can you try capturing all traffic the card sends towards the server, not > just tcp port 3260? > Hi Stefan, hi all, I am not using vlans @home. I don't know where this VLAN ID comes from. Ihis is what my tcpdump looks like. 10.1.2.254 is my router-box, connected to the internet, my iscsi-target-box is doing packet forwarding between workstation-net (192.168.2.x) and wlan/ internet (10.1.2.x). Regards, Michael g33# tcpdump -nvi em0 port 3260 tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes 18:40:39.773645 IP (tos 0x0, ttl 64, id 31710, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 2159158359:2159158407(48) ack 820164098 win 8326 18:40:40.246018 IP (tos 0x0, ttl 64, id 31712, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 0:48(48) ack 1 win 8326 18:40:40.986477 IP (tos 0x0, ttl 64, id 31724, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 0:48(48) ack 1 win 8326 18:40:42.264067 IP (tos 0x0, ttl 64, id 31726, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 0:48(48) ack 1 win 8326 18:40:44.615007 IP (tos 0x0, ttl 64, id 31729, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 0:48(48) ack 1 win 8326 18:40:49.112412 IP (tos 0x0, ttl 64, id 31735, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 0:48(48) ack 1 win 8326 18:40:56.727573 IP (tos 0x0, ttl 64, id 31751, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 0:48(48) ack 1 win 8326 18:41:01.204986 IP (tos 0x0, ttl 64, id 31760, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 48:96(48) ack 1 win 8326 18:41:11.747747 IP (tos 0x0, ttl 64, id 31786, offset 0, flags [DF], proto TCP (6), length 148) 192.168.2.1.3260 > 192.168.2.65.53739: P 0:96(96) ack 1 win 8326 18:41:22.633882 IP (tos 0x0, ttl 64, id 31798, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 96:144(48) ack 1 win 8326 18:41:41.592982 IP (tos 0x0, ttl 64, id 31842, offset 0, flags [DF], proto TCP (6), length 196) 192.168.2.1.3260 > 192.168.2.65.53739: P 0:144(144) ack 1 win 8326 18:41:44.062446 IP (tos 0x0, ttl 64, id 31848, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 144:192(48) ack 1 win 8326 18:42:05.489296 IP (tos 0x0, ttl 64, id 31899, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 192:240(48) ack 1 win 8326 18:42:26.922956 IP (tos 0x0, ttl 64, id 31934, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 240:288(48) ack 1 win 8326 18:42:41.077411 IP (tos 0x0, ttl 64, id 31963, offset 0, flags [DF], proto TCP (6), length 340) 192.168.2.1.3260 > 192.168.2.65.53739: P 0:288(288) ack 1 win 8326 18:42:48.352074 IP (tos 0x0, ttl 64, id 31997, offset 0, flags [DF], proto TCP (6), length 100) 192.168.2.1.3260 > 192.168.2.65.53739: P 288:336(48) ack 1 win 8326 18:42:48.352289 IP (tos 0x0, ttl 64, id 20, offset 0, flags [DF], proto TCP (6), length 40) 192.168.2.65.53739 > 192.168.2.1.3260: R, cksum 0x64c1 (correct), 820164098:820164098(0) win 0 19:22:19.459706 IP (tos 0x0, ttl 63, id 61907, offset 0, flags [DF], proto TCP (6), length 60) 10.1.2.254.3260 > 192.168.2.65.14013: S, cksum 0x91e6 (correct), 2095746219:2095746219(0) win 5840 19:22:19.460056 IP (tos 0x0, ttl 64, id 2519, offset 0, flags [DF], proto TCP (6), length 40) 192.168.2.65.14013 > 10.1.2.254.3260: R, cksum 0x92d8 (correct), 0:0(0) ack 2095746220 win 0 ^C 19 packets captured 1312938 packets received by filter 0 packets dropped by kernel g33# From owner-freebsd-fs@FreeBSD.ORG Tue Aug 11 08:20:06 2009 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 B8236106566B for ; Tue, 11 Aug 2009 08:20:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A539D8FC20 for ; Tue, 11 Aug 2009 08:20:06 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7B8K5cK051012 for ; Tue, 11 Aug 2009 08:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7B8K53Y051011; Tue, 11 Aug 2009 08:20:05 GMT (envelope-from gnats) Date: Tue, 11 Aug 2009 08:20:05 GMT Message-Id: <200908110820.n7B8K53Y051011@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Peter Much Cc: Subject: Re: kern/137037: [zfs] [hang] zfs rollback on root causes FreeBSD to freeze in few seconds X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Much List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 08:20:07 -0000 The following reply was made to PR kern/137037; it has been noted by GNATS. From: Peter Much To: bug-followup@FreeBSD.org, killasmurf86@gmail.com Cc: Subject: Re: kern/137037: [zfs] [hang] zfs rollback on root causes FreeBSD to freeze in few seconds Date: Tue, 11 Aug 2009 09:34:10 +0200 I considered to do more investigations before reporting my issue, but after seeing this bug report I think an interim report from my side should not harm. I also experience system failures after rollback, and the significant similarity is that in my case also the rollbacks succeed, and the system continues to work for some seconds (or sometimes even longer) before it fails. The failure is either (seldom) a system freeze or (much more often) an instanteous reboot without dumping. I am currently investigating about methods to capture some useful data. Maybe, if it freezes, running "watchdog" can trick it to do a dump... I am running 7.2-STABLE as of mid-July (that is ZFS V13). I admit I am someway low on memory to run ZFS (memory is ordered ;) ), but I use it only for a very limited number of filesystems and specific tasks, and I am watching carefully about my mem usage. Nevertheless, if the system would run out of memory, I would expect an orderly panic and not some hard reset or freeze. I am not using geli or anything like, also I am not working with the root; what I am doing is mainly an extensive use of the rollback feature, from script, in a way like this: while do zfs mount jb/x mount -t zfs jb/p /jb/x/p ... do some work ... umount /jb/x/p umount /jb/x zfs rollback jb/x@base zfs rollback jb/p@base done At first I tried this without the unmounting, but the crashes were so reproducible that I considered that unfunctional. With the unmounting it looked functional first, but now I also experience crashes about every 12 hours. Beware: this is an interim report, I have not yet extensively verified against possibilities of my own mistakes. Take it with the appropriate grains of salt. ;) ------------------------------ Update: I was able to obtain a dump. After running the above loop in a tough way and staying on the console, it suddenly started to do havoc, reported that it were not able to unmount the filesystems or could not detect them (something I also had seen occasionally before) and then dropped me into the debugger at _sx_xlock+0x16 lock cmpxchgl %edx,0x10(%ecx) The backtrace see attached below - but beware, since the havoc had already started before, this will very likely NOT point to the root cause of the problem. But maybe it gives some first impression. I suppose this should be reproducible, but in any case I would be glad to provide further data if requested (or do further tests). And as said before - if this is a result of low memory, then I am just sorry. ;) Ah, btw, its a dual Pentium3 SMP machine. (gdb) add-symbol-file /usr/src/sys/i386/compile/D1R72V1/modules/usr/src/sys/modules/zfs/zfs.ko 0xc0a59860 add symbol table from file "/usr/src/sys/i386/compile/D1R72V1/modules/usr/src/sys/modules/zfs/zfs.ko" at .text_addr = 0xc0a59860 (gdb) bt #0 doadump () at pcpu.h:196 #1 0xc05e8be6 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 #2 0xc05e8f07 in panic (fmt=Variable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:574 #3 0xc046ed77 in db_panic (addr=Could not find the frame base for "db_panic". ) at ../../../ddb/db_command.c:446 #4 0xc046f52a in db_command (last_cmdp=0xc0932a54, cmd_table=0x0, dopager=1) at ../../../ddb/db_command.c:413 #5 0xc046f645 in db_command_loop () at ../../../ddb/db_command.c:466 #6 0xc047117c in db_trap (type=12, code=0) at ../../../ddb/db_main.c:228 #7 0xc0617581 in kdb_trap (type=12, code=0, tf=0xdb76b9fc) at ../../../kern/subr_kdb.c:524 #8 0xc0855adf in trap_fatal (frame=0xdb76b9fc, eva=76) at ../../../i386/i386/trap.c:929 #9 0xc0855d8b in trap_pfault (frame=0xdb76b9fc, usermode=0, eva=76) at ../../../i386/i386/trap.c:851 #10 0xc0856786 in trap (frame=0xdb76b9fc) at ../../../i386/i386/trap.c:529 #11 0xc083b70b in calltrap () at ../../../i386/i386/exception.s:166 #12 0xc05f0a56 in _sx_xlock (sx=0x3c, opts=0, file=0xc0b4953d "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c", line=1807) at atomic.h:149 #13 0xc0a79185 in dmu_buf_update_user (db_fake=0x0, old_user_ptr=0xc2de3000, user_ptr=0x0, user_data_ptr_ptr=0x0, evict_func=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1807 #14 0xc0ad0cab in zfs_znode_dmu_fini (zp=0xc2de3000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:557 #15 0xc0aef214 in zfs_freebsd_reclaim (ap=0xdb76baf0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4385 #16 0xc0871602 in VOP_RECLAIM_APV (vop=0xc0b55560, a=0xdb76baf0) at vnode_if.c:1566 #17 0xc066d28f in vgonel (vp=0xc355ce04) at vnode_if.h:819 #18 0xc0670f26 in vflush (mp=0xc3db25a0, rootrefs=0, flags=Variable "flags" is not available. ) at ../../../kern/vfs_subr.c:2408 #19 0xc0aee0c8 in zfs_umount (vfsp=0xc3db25a0, fflag=134217728, td=0xc312bd80) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1005 #20 0xc066a201 in dounmount (mp=0xc3db25a0, flags=134217728, td=0xc312bd80) at ../../../kern/vfs_mount.c:1290 #21 0xc066a957 in unmount (td=0xc312bd80, uap=0xdb76bcfc) at ../../../kern/vfs_mount.c:1186 #22 0xc08560f5 in syscall (frame=0xdb76bd38) at ../../../i386/i386/trap.c:1089 #23 0xc083b770 in Xint0x80_syscall () at ../../../i386/i386/exception.s:262 #24 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (gdb) From owner-freebsd-fs@FreeBSD.ORG Tue Aug 11 19:18:38 2009 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 57B05106566C for ; Tue, 11 Aug 2009 19:18:38 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from hamlet.setfilepointer.com (hamlet.SetFilePointer.com [63.224.10.2]) by mx1.freebsd.org (Postfix) with SMTP id 0EC8E8FC3E for ; Tue, 11 Aug 2009 19:18:37 +0000 (UTC) Received: (qmail 12549 invoked from network); 11 Aug 2009 14:18:37 -0500 Received: from keira.kiwi-computer.com (HELO kiwi-computer.com) (63.224.10.3) by hamlet.setfilepointer.com with SMTP; 11 Aug 2009 14:18:37 -0500 Received: (qmail 67912 invoked by uid 2001); 11 Aug 2009 19:18:37 -0000 Date: Tue, 11 Aug 2009 14:18:37 -0500 From: "Rick C. Petty" To: Naeem Afzal Message-ID: <20090811191837.GB66530@keira.kiwi-computer.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org Subject: Re: filesystem size after newfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 19:18:38 -0000 On Tue, Aug 11, 2009 at 12:41:06AM +0000, Naeem Afzal wrote: > > resending to FS mailing list:I created this small partition of 512K bytes on disk, I am noticing about 24% is used up before system can be mounted and used. My assumption was about 4% is supposed to be used if minfree is set to 0. > #newfs -U -l -m 0 -n -o space /dev/ad1d > /dev/ad1d: 0.5MB (1024 sectors) block size 16384, fragment size 2048 using 1 cylinder groups of 0.50MB, 32 blks, 64 inodes with soft updates > super-block backups (for fsck -b #) at: > 160 > #mount /dev/ad1d /test > #df -H /test > Filesystem Size Used Avail Capacity Mounted on > /dev/ad1d 391k 2.0k 389k 1% /test > Could someone explain where the 512-391=121K of disk space went to? What is the relation between this used of space and total paritition size or is it some fixed ratio? When you use newfs(8), it leaves 64k at the front for bootstrap code. This is followed by at least one "block" for the superblock, one block for the superblock backup, one block for the cylinder group, and at least one block for inodes. Since your block size is 16k (the default), this means that your filesystem uses 64k for filesystem metadata. This isn't a problem with larger filesystems, but yours is 512k so 128k is "wasted" meaning you cannot even use the space. I'm not sure how you are seeing a filesystem of 391k.. I performed these same steps and I have a 382k filesystem: 512 - 128 - 2 = 382, so I'm not surprised with my numbers. That extra 2k is one fragment allocated to the root directory. If you want to better conserve space on your small partition, you should probably use UFS1 (which only reserves 8k for bootstrap) instead of UFS2 and specify smaller block and fragment sizes. I would also specify inode density. I tried the following: % newfs -O 1 -U -l -m 0 -n -o space -f 512 -b 4096 -i 1048576 /dev/md0 /dev/md0: 0.5MB (1024 sectors) block size 4096, fragment size 512 using 1 cylinder groups of 0.50MB, 128 blks, 32 inodes. with soft updates super-block backups (for fsck -b #) at: 32 After mounting, it shows: Filesystem Size Used Avail Capacity Mounted on /dev/md0 480K 512B 479K 0% /mnt There are a number of things of which you should be careful. Using UFS1, you won't be able to use bootstrap code larger than 8k and you won't be able to use large files (not a problem because your filesystem is only 512k). You also won't get snapshots, which you apparently don't want. Specifying inode density can put you in a bind if you need a lot of inodes. In my example there are exactly 16 inodes, which is somewhat limited. The first three inodes are reserved (2 is the root inode) which leaves you with a maximum of 13 files and/or directories. I'm assuming this isn't a problem since you're using such a small filesystem. The smaller block and fragment sizes help reduce the "wasted space" taken up by filesystem metadata, but will require some tuning if you want more inodes. Be sure that only one cylinder group is created, or you'll be wasting 16k or more for each cylinder group. I also recommend keeping the 8:1 ratio of blocks to fragments. If you do wish to tweak that, here are a few things to note. Minimum blocksize is 4096 and at least 4 blocks are allocated for each cylinder group (in addition to the leading 64k). More blocks are allocated if the inode density is higher (specifying a lower number to "newfs -i"). UFS1 can fit twice as many inodes in the same space as UFS2, which is why I recommend using it with very small filesystems. Since filesystem metadata is always allocated in blocks, it doesn't really help to tweak the fragment size. At one time I was thinking of writing up a patch to newfs to allow you specify the superblock offset, so you could save 16-64k per cylinder group. But there are limitations, since the FFS code searches for superblocks at specific offsets, namely (in order): 64k, 8k, 0, 256k. I also had thoughts about patching it to remove the superblock backup, so that fs_sblkno could be 0 instead of 144 or 32. Because of its structure, at least 16k (8k bootstrap plus 8k initial superblock) is unused for every cylinder group in UFS1 (at least 72k for UFS2). There isn't much to be gained in such a patch except for very small filesystems such as in your case. When you're dealing with 512k, that extra 16k (or more) is starting to look significant (3%). HTH, -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Tue Aug 11 20:06:39 2009 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 94C9D1065674 for ; Tue, 11 Aug 2009 20:06:39 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5A6D98FC39 for ; Tue, 11 Aug 2009 20:06:39 +0000 (UTC) Received: (qmail 87540 invoked from network); 11 Aug 2009 20:06:38 -0000 Received: from unknown (HELO ?192.168.0.137?) (spawk@128.238.9.199) by acm.poly.edu with AES256-SHA encrypted SMTP; 11 Aug 2009 20:06:38 -0000 Message-ID: <4A81CF20.7010108@acm.poly.edu> Date: Tue, 11 Aug 2009 16:05:52 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.19 (X11/20090108) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4A78AFB2.10103@acm.poly.edu> <20090805115621.GG1784@garage.freebsd.pl> <4A798A12.4070408@acm.poly.edu> <20090807073738.GA1607@garage.freebsd.pl> <20090807074400.GB1607@garage.freebsd.pl> <4A7C3002.8000003@acm.poly.edu> <20090807191334.GA1814@garage.freebsd.pl> <4A7C81CA.2040303@acm.poly.edu> <20090807193842.GA2487@garage.freebsd.pl> <4A7C87C5.1070608@acm.poly.edu> <20090807202756.GB2487@garage.freebsd.pl> In-Reply-To: <20090807202756.GB2487@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ZFS RAID-Z panic on vdev failure + subsequent panics and hangs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 20:06:39 -0000 Pawel Jakub Dawidek wrote: > On Fri, Aug 07, 2009 at 04:00:05PM -0400, Boris Kochergin wrote: > >> Pawel Jakub Dawidek wrote: >> >>> On Fri, Aug 07, 2009 at 03:34:34PM -0400, Boris Kochergin wrote: >>> >>> >>>> Pawel Jakub Dawidek wrote: >>>> >>>> >>>>> Yeah, that's strange indeed. Could you try: >>>>> >>>>> print ab->b_arc_node.list_prev >>>>> print ab->b_arc_node.list_next >>>>> >>>>> >>>>> >>>>> >>>> (kgdb) print ab->b_arc_node.list_prev >>>> $1 = (struct list_node *) 0x1 >>>> >>>> >>> Yeah, list_prev is corrupted. If it panics on you everytime, I could >>> send you a patch which will try to catch where the corruption occurs. >>> >>> >>> >> I eventually get the arc_evict panic every time I successfully manage to >> mount the filesystem, but it usually panics (with the other backtrace) >> as soon as I try to mount it, or mount just hangs. I'll gladly try the >> patch, though--the data on the array is important to me. Thanks. >> > > To get the data from there you could also try to 'zfs send' it without > mounting the dataset at all (just in case). > > Sorry for the delay. I had to find another machine to move the disks into so that I could continue experimenting. Anyway, the filesystem didn't have any snapshots I could send, so I tried creating one with "zfs snapshot home@1" and the machine hung. FYI, In the new machine, all disks (including the one with the / filesystem) retain their device names. -Boris From owner-freebsd-fs@FreeBSD.ORG Tue Aug 11 21:43:24 2009 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 DA1711065677; Tue, 11 Aug 2009 21:43:24 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by mx1.freebsd.org (Postfix) with ESMTP id 578468FC40; Tue, 11 Aug 2009 21:43:23 +0000 (UTC) Received: from uucp.dinoex.sub.de (uucp@uucp.dinoex.sub.de [194.45.71.2] (may be forged)) by uucp.dinoex.sub.de (8.14.3/8.14.2) with ESMTP id n7BLCdC0070587; Tue, 11 Aug 2009 23:12:39 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.14.3/8.14.2/Submit) with UUCP id n7BLCdZm070586; Tue, 11 Aug 2009 23:12:39 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.14.3/8.14.2) with ESMTP id n7BKvdcR029237; Tue, 11 Aug 2009 22:57:39 +0200 (CEST) (envelope-from pmc@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.14.3/8.14.3) with ESMTP id n7BKulBG029133; Tue, 11 Aug 2009 22:56:47 +0200 (CEST) (envelope-from pmc@gate.oper.dinoex.org) Received: (from pmc@localhost) by gate.oper.dinoex.org (8.14.3/8.14.3/Submit) id n7BKulp2029129; Tue, 11 Aug 2009 22:56:47 +0200 (CEST) (envelope-from pmc) Date: Tue, 11 Aug 2009 22:56:47 +0200 (CEST) From: Peter Much Message-Id: <200908112056.n7BKulp2029129@gate.oper.dinoex.org> To: freebsd-fs@freebsd.org, kmacy@freebsd.org X-Also-Posted-To: m2n.fbsd.stable References: <4A325E9F.2080802@icyb.net.ua> <3c1674c90906121354s6d6ae7ben5082708b1586e94f@mail.gmail.com> Organization: some more stinking socks X-Newsreader: trn 4.0-test76 (Apr 2, 2001) X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (uucp.dinoex.sub.de [194.45.71.2]); Tue, 11 Aug 2009 23:12:40 +0200 (CEST) Cc: Subject: Re: zfs/panic: short after rollback 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, 11 Aug 2009 21:43:25 -0000 aka Kip Macy schrieb mit Datum Fri, 12 Jun 2009 13:54:40 -0700 in m2n.fbsd.stable: |show sleepchain |show thread 100263 | |On Fri, Jun 12, 2009 at 6:56 AM, Andriy Gapon wrote: |> |> I did zfs rollback xxx@yyy |> And then did ls on a directory in the rolled-back fs. |> panic: sleeping thread This is quite likely the same problem as I experience. And it is maybe also the same problem as in kern/137037 and kern/129148. It seems to show up in some different flavours, while the bottomline is this: do a rollback, and soon after (usually at the next filesystem-related action) the kernel has gone fishing. I experienced it first when doing a rollback of a mounted filesystem. It crashed right after the first try, and it did so reproducible. (Well, more or less reproducible - another day under similar circumstances it did not crash.) Then I started thinking, and came to the conclusion that a rollback of a mounted filesystem (with possibly open files) could easily bring a lot of things into an undefined state, and should not be something one wants to do normally. So maybe it is not supposed to work at all. Anyway, when trying this, I do either get the "sleeping thread" message (as above), or a panic from _sx_xlock() (as shown in my addendum to kern/137037, and in the addendum to kern/129148). So I started to do rollbacks on unmounted filesystems (quite an excessive amount of them), and while this seemed to work at first, later on the system failures reappeared. These system failures took various shapes - I experienced immediate resets without dump, and system hangs. When deliberately trying to reproduce that (after installing a kernel with debugging info and watching the console), I also captured a panic coming from _sx_xlock() - so it seems to be the same problem as without unmounting, only that it takes a couple of rollbacks (a dozen or more) to hit. Over all, there was never any data loss or persistent damage. So, I consider rollback still functional and safe to use, but I consider a system no longer production stable after doing a rollback. rgds, PMc From owner-freebsd-fs@FreeBSD.ORG Wed Aug 12 00:16:10 2009 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 9D884106564A for ; Wed, 12 Aug 2009 00:16:10 +0000 (UTC) (envelope-from nafzal@hotmail.com) Received: from col0-omc2-s1.col0.hotmail.com (col0-omc2-s1.col0.hotmail.com [65.55.34.75]) by mx1.freebsd.org (Postfix) with ESMTP id 493998FC15 for ; Wed, 12 Aug 2009 00:16:10 +0000 (UTC) Received: from COL111-W50 ([65.55.34.71]) by col0-omc2-s1.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 17:16:09 -0700 Message-ID: X-Originating-IP: [192.55.54.37] From: Naeem Afzal To: Date: Wed, 12 Aug 2009 00:16:09 +0000 Importance: Normal In-Reply-To: <20090811191837.GB66530@keira.kiwi-computer.com> References: <20090811191837.GB66530@keira.kiwi-computer.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Aug 2009 00:16:09.0974 (UTC) FILETIME=[17EBC960:01CA1AE2] Cc: freebsd-fs@freebsd.org Subject: RE: filesystem size after newfs 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, 12 Aug 2009 00:16:10 -0000 Thanks you so much that was good explanation.=20 For some reason using UFS1 or UFS2 did not make any size difference after I= changed the block size and fragment size to minimum (4K/512).=20 One more thing=2C I tried to make the same partition as geli with HMAC/SHA2= 56 authentication and it eats up even more space. Without this authenticati= on=2C usage is pretty close to without geli. #geli init -a HMAC/SHA256 -P -K da2-64bytes.key /dev/ad1d # newfs -O 1 -U -l -m 0 -n -o space -f 512 -b 4096 -i 1048576 /dev/ad1d.eli= /dev/ad1d.eli: 0.2MB (511 sectors) block size 4096=2C fragment size 512 = using 1 cylinder groups of 0.25MB=2C 63 blks=2C 32 inodes. with = soft updatessuper-block backups (for fsck -b #) at: 32 #df -H /testFilesystem 1K-blocks Used Avail Capacity Mounted on/de= v/ad1d.eli 228k 512B 228k 0% /test ada1.eli should have been 0.5MB=2C but seems like it is reserving some area= for geli? How much is needed for HMAC/SHA256? What is allocation scheme if= we go for this SHA256 authentication? regardsnaeem > > There are a number of things of which you should be careful. Using UFS1= =2C > you won't be able to use bootstrap code larger than 8k and you won't be > able to use large files (not a problem because your filesystem is only > 512k). You also won't get snapshots=2C which you apparently don't want. > > Specifying inode density can put you in a bind if you need a lot of > inodes. In my example there are exactly 16 inodes=2C which is somewhat > limited. The first three inodes are reserved (2 is the root inode) which > leaves you with a maximum of 13 files and/or directories. I'm assuming > this isn't a problem since you're using such a small filesystem. The > smaller block and fragment sizes help reduce the "wasted space" taken up > by filesystem metadata=2C but will require some tuning if you want more > inodes. Be sure that only one cylinder group is created=2C or you'll be > wasting 16k or more for each cylinder group. > > I also recommend keeping the 8:1 ratio of blocks to fragments. If you do > wish to tweak that=2C here are a few things to note. Minimum blocksize is > 4096 and at least 4 blocks are allocated for each cylinder group (in > addition to the leading 64k). More blocks are allocated if the inode > density is higher (specifying a lower number to "newfs -i"). UFS1 can fit > twice as many inodes in the same space as UFS2=2C which is why I recommen= d > using it with very small filesystems. Since filesystem metadata is always > allocated in blocks=2C it doesn't really help to tweak the fragment size. > > At one time I was thinking of writing up a patch to newfs to allow you > specify the superblock offset=2C so you could save 16-64k per cylinder > group. But there are limitations=2C since the FFS code searches for > superblocks at specific offsets=2C namely (in order): 64k=2C 8k=2C 0=2C 2= 56k. > I also had thoughts about patching it to remove the superblock backup=2C = so > that fs_sblkno could be 0 instead of 144 or 32. Because of its structure= =2C > at least 16k (8k bootstrap plus 8k initial superblock) is unused for ever= y > cylinder group in UFS1 (at least 72k for UFS2). > > There isn't much to be gained in such a patch except for very small > filesystems such as in your case. When you're dealing with 512k=2C that > extra 16k (or more) is starting to look significant (3%). > > HTH=2C > > -- Rick C. Petty _________________________________________________________________ Get free photo software from Windows Live http://www.windowslive.com/online/photos?ocid=3DPID23393::T:WLMTAGL:ON:WL:e= n-US:SI_PH_software:082009= From owner-freebsd-fs@FreeBSD.ORG Wed Aug 12 05:28:26 2009 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 94AB5106566C for ; Wed, 12 Aug 2009 05:28:26 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id B5AD68FC15 for ; Wed, 12 Aug 2009 05:28:25 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 68D9945CD8; Wed, 12 Aug 2009 07:28:22 +0200 (CEST) Received: from localhost (chello087206049004.chello.pl [87.206.49.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3D78A45C8A; Wed, 12 Aug 2009 07:28:17 +0200 (CEST) Date: Wed, 12 Aug 2009 07:28:14 +0200 From: Pawel Jakub Dawidek To: Naeem Afzal Message-ID: <20090812052814.GD1600@garage.freebsd.pl> References: <20090811191837.GB66530@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mR8QP4gmHujQHb1c" 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 8.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: filesystem size after newfs 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, 12 Aug 2009 05:28:27 -0000 --mR8QP4gmHujQHb1c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 12, 2009 at 12:16:09AM +0000, Naeem Afzal wrote: >=20 > Thanks you so much that was good explanation.=20 > For some reason using UFS1 or UFS2 did not make any size difference after= I changed the block size and fragment size to minimum (4K/512).=20 > One more thing, I tried to make the same partition as geli with HMAC/SHA2= 56 authentication and it eats up even more space. Without this authenticati= on, usage is pretty close to without geli. > #geli init -a HMAC/SHA256 -P -K da2-64bytes.key /dev/ad1d > # newfs -O 1 -U -l -m 0 -n -o space -f 512 -b 4096 -i 1048576 /dev/ad1d.e= li/dev/ad1d.eli: 0.2MB (511 sectors) block size 4096, fragment size 512 = using 1 cylinder groups of 0.25MB, 63 blks, 32 inodes. with soft= updatessuper-block backups (for fsck -b #) at: 32 > #df -H /testFilesystem 1K-blocks Used Avail Capacity Mounted on/= dev/ad1d.eli 228k 512B 228k 0% /test >=20 > ada1.eli should have been 0.5MB, but seems like it is reserving some area= for geli? How much is needed for HMAC/SHA256? What is allocation scheme if= we go for this SHA256 authentication? > regardsnaeem To ensure atomicity of operations, geli stores hashes in the same sector as the data. Creating geli providers with block size of 512 bytes is very inefficient. It will consume two sectors for each sector, which looks like this: 1 512b of data -----> 480b for data + 32b for hash 2 32b for data + 32b for hash + 448b unused The most optimal block size for geli provider is 4kB, it consumes one extra sector for every 8 sectors: 1 512b of data -----> 480b for data + 32b for hash 2 512b of data 480b for data + 32b for hash 3 512b of data 480b for data + 32b for hash 4 512b of data 480b for data + 32b for hash 5 512b of data 480b for data + 32b for hash 6 512b of data 480b for data + 32b for hash 7 512b of data 480b for data + 32b for hash 8 512b of data 480b for data + 32b for hash 9 256b for data + 32b for hash + 224 unused --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --mR8QP4gmHujQHb1c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKglLuForvXbEpPzQRAmVaAJwNup9PAnDdQ5/qY7V1se9kG8x5YwCgxgR7 wWj9/H4/ZSvIb0X6N8czFu0= =P4XR -----END PGP SIGNATURE----- --mR8QP4gmHujQHb1c-- From owner-freebsd-fs@FreeBSD.ORG Wed Aug 12 05:38:10 2009 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 825511065673; Wed, 12 Aug 2009 05:38:10 +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 72D568FC1F; Wed, 12 Aug 2009 05:38:10 +0000 (UTC) Received: from freefall.freebsd.org (pjd@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7C5cAk2046207; Wed, 12 Aug 2009 05:38:10 GMT (envelope-from pjd@freefall.freebsd.org) Received: (from pjd@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7C5cAUF046203; Wed, 12 Aug 2009 05:38:10 GMT (envelope-from pjd) Date: Wed, 12 Aug 2009 05:38:10 GMT Message-Id: <200908120538.n7C5cAUF046203@freefall.freebsd.org> To: killasmurf86@gmail.com, pjd@FreeBSD.org, freebsd-fs@FreeBSD.org From: pjd@FreeBSD.org Cc: Subject: Re: kern/137037: [zfs] [hang] zfs rollback on root causes FreeBSD to freeze in few seconds 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, 12 Aug 2009 05:38:10 -0000 Synopsis: [zfs] [hang] zfs rollback on root causes FreeBSD to freeze in few seconds State-Changed-From-To: open->feedback State-Changed-By: pjd State-Changed-When: śro 12 sie 2009 05:33:06 UTC State-Changed-Why: Note that rollback of root file system is impossible to do on-line anyway. Rollback will modify data on your root file system and because of that file system being rolled back has to be unmounted and mounted with new data. You shouldn't be able to unmount root file system anyway. I'd like to have offline rollback, eg. you mark root file system for rollback and reboot, but I'm not sure it's possible right now. What I'd suggest instead is the following. Let's say your root file system is tank/root and you have a snapshot to which you're willing to rollback tank/root@snap. You could clone the snapshot and create tank/root2, edit your /etc/fstab so that tank/root2 will be your root file system and reboot. Once you reboot and verify everything is fine you could promote your clone, remove tank/root and rename tank/root2 to tank/root. http://www.freebsd.org/cgi/query-pr.cgi?pr=137037 From owner-freebsd-fs@FreeBSD.ORG Wed Aug 12 12:47:25 2009 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 BBCE7106566C; Wed, 12 Aug 2009 12:47:25 +0000 (UTC) (envelope-from p.christias@noc.ntua.gr) Received: from diomedes.noc.ntua.gr (diomedes.noc.ntua.gr [IPv6:2001:648:2000:de::220]) by mx1.freebsd.org (Postfix) with ESMTP id 1C54E8FC4E; Wed, 12 Aug 2009 12:47:24 +0000 (UTC) Received: from ajax.noc.ntua.gr (ajax6.noc.ntua.gr [IPv6:2001:648:2000:dc::1]) by diomedes.noc.ntua.gr (8.14.3/8.14.3) with ESMTP id n7CClMe7058513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Aug 2009 15:47:23 +0300 (EEST) (envelope-from p.christias@noc.ntua.gr) Received: from ajax.noc.ntua.gr (localhost [127.0.0.1]) by ajax.noc.ntua.gr (8.14.3/8.14.3) with ESMTP id n7CClM89077810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Aug 2009 15:47:22 +0300 (EEST) (envelope-from p.christias@noc.ntua.gr) Received: (from christia@localhost) by ajax.noc.ntua.gr (8.14.3/8.14.3/Submit) id n7CClLVX077809; Wed, 12 Aug 2009 15:47:21 +0300 (EEST) (envelope-from p.christias@noc.ntua.gr) X-Authentication-Warning: ajax.noc.ntua.gr: christia set sender to p.christias@noc.ntua.gr using -f Date: Wed, 12 Aug 2009 15:47:21 +0300 From: Panagiotis Christias To: "Hearn, Trevor" Message-ID: <20090812124721.GA71441@noc.ntua.gr> References: <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34C3@ITS-HCWNEM03.ds.Vanderbilt.edu> <200908101605.12332.jhb@freebsd.org> <200908101707.49526.jhb@freebsd.org> <8E9591D8BCB72D4C8DE0884D9A2932DC6D2EDF21@ITS-HCWNEM03.ds.Vanderbilt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E9591D8BCB72D4C8DE0884D9A2932DC6D2EDF21@ITS-HCWNEM03.ds.Vanderbilt.edu> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: clamav-milter 0.95.2 at diomedes.noc.ntua.gr X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (diomedes.noc.ntua.gr [IPv6:2001:648:2000:de::220]); Wed, 12 Aug 2009 15:47:23 +0300 (EEST) Cc: "freebsd-fs@freebsd.org" , "Kenneth D. Merry" Subject: Re: UFS Filesystem issues, and the loss of my hair... 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, 12 Aug 2009 12:47:26 -0000 On Mon, Aug 10, 2009 at 05:20:44PM -0500, Hearn, Trevor wrote: > Yes, it does seem like it was part of one of the other messages. The isp(4) > driver was just recently updated in HEAD by mjacob@ who has maintained that > driver in the past. He may have some insight if there is an isp(4)-specific > problem. > > -- > John Baldwin > > Heh. Ok, I just watched the same error message scroll across the screen > for about 5 minutes now, with a different offset, same length. The fun > part is that it is not touching the device, /dev/da1p7 at all. From the > systat -vmstat display, I see all of the traffic coming from the > /dev/mfid0 drives. It ran for a while, then stopped. So, no access to > the drive in question, da1p7, but on the root drive, mfid0. Odd. The > partition is mapped to the root drive. I wonder if the driver lost > itself, and it tried to access the file on the empty folder on the root > drive. Sigh. Anyone? Hello, we faced a similar problem here (major greek university) about a year ago [1]. Our setup consists of Dell 2950 servers, QLogic 2462 HBAs (PCI-E) and an EMC CLARiiON CX3-40. As soon as we tried to do a simple "tar zxf ports.tgz" on a SAN volume the system would freeze or/and panic (same error messages as yours). Oleg Sharoiko suggested that we could decrease the number of tag openings (tag queue depth). Decreasing it would make the system a bit more stable but did not eliminate the problem. Then, I contacted Matthew Jacob and tested his latest isp code [2] along with alternative solutions like zfs and gjournal. Matthew was kind enough to offer his support but eventually I ran out time and patience, so I moved a couple of servers to centos in order to put the storage into production. That was around December last year. About a month ago Kenneth Merry announced that a new version of isp was available [3] which corrected bugs and added new functionality. I thought it was worth trying so I set up FreeBSD 7-stable in two Dell boxes, added the isp patches, recompiled the kernel and started the stress tests. I also looked around for more info and hints regarding qlogic hbas. The Linux driver (ql2xxx) has a 32 max queue depth by default (see ql2xmaxqdepth) which is also the recommended value by EMC. There are also similar references for Solaris (see sd:sd_max_throttle). Some mention even smaller values depending the storage. Currently, I am running stress tests, using fsx, ffsb, postmark, iozone, bonnie++, blogbench and other home-made scripts (any other suggestion?) on two 7-stable-amd64 + isp_diffs.releng7.20090629 boxes. So far, at 32 maximum tag openings, everything looks good, I have not seen any panics and the following fsck run cleanly. I will keep running more tests for a week or two hoping that they will help draw a conclusion. Regards, Panagiotis ps. cc'ed to Kenneth Merry, I think he would be interested. [1] http://lists.freebsd.org/pipermail/freebsd-scsi/2008-October/003686.html [2] http://feral.com/isp.html [3] http://lists.freebsd.org/pipermail/freebsd-scsi/2009-June/003916.html -- Panagiotis J. Christias Network Management Center P.Christias@noc.ntua.gr National Technical Univ. of Athens, GREECE From owner-freebsd-fs@FreeBSD.ORG Wed Aug 12 15:13:50 2009 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 DD1B2106566B; Wed, 12 Aug 2009 15:13:50 +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 06C5F8FC1F; Wed, 12 Aug 2009 15:13:49 +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 n7CFDnD8093794; Wed, 12 Aug 2009 10:13:49 -0500 (CDT) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: content-type:content-transfer-encoding; b=alhEZ0w84XxLTI0oKepjGXEj7O8UwCs4f5TItaTeSWnNOxi8WJP/s0PZp9+O4BQeV iNWB/ZZoXSq0jPVwkmsa7ZsO2yP9al1nKX3mvmRp4wjCJDBWNM86mzdDrc541YDBS55 HRlHV9IhtxK+1BvIGnrTNf7RbOGg1VrfnZUUe4w= Message-ID: <4A82DC2D.6070400@jrv.org> Date: Wed, 12 Aug 2009 10:13:49 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek Subject: ZFS sx_xlock panic w/zfs_vnops.c.2.patch X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 15:13:51 -0000 FreeBSD bigback.housenet.jrv 8.0-BETA2 FreeBSD 8.0-BETA2 #1 r195757M: Wed Jul 29 13:44:06 CDT 2009 james@bigback.housenet.jrv:/usr/obj/usr/src/sys/BIGTEX amd64 with mav's siis.20090718.patch driver, with my libzfs_sendrecv.c path, with zfs_vnops.c.2.patch panic during reboot(8) ... zfs_umount:971[0]: Force unmount is experimental - report any problems. zfs_umount:971[0]: Force unmount is experimental - report any problems. panic: sx_xlock() of destroyed sx @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4361 cpuid = 0 KDB: enter: panic Physical memory: 9422 MB Dumping 1862 MB: 1847 1831 1815 1799 1783 1767 1751 1735 1719 1703 1687 1671 1655 1639 1623 1607 1591 1575 1559 1543 1527 1511 1495 1479 1463 1447 1431 1415 1399 1383 1367 1351 1335 1319 1303 1287 1271 1255 1239 1223 1207 1191 1175 1159 1143 1127 1111 1095 1079 1063 1047 1031 1015 999 983 967 951 935 919 903 887 871 855 839 823 807 791 775 759 743 727 711 695 679 663 647 631 615 599 583 567 551 535 519 503 487 471 455 439 423 407 391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/siis.ko...Reading symbols from /boot/kernel/siis.ko.symbols...done. done. Loaded symbols for /boot/kernel/siis.ko Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff801dfdec in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801e0121 in db_command (last_cmdp=0xffffffff80bbd9e0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801e0370 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801e2349 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff805bab85 in kdb_trap (type=3, code=0, tf=0xffffff810f0cf5e0) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff8083daf1 in trap (frame=0xffffff810f0cf5e0) at /usr/src/sys/amd64/amd64/trap.c:613 #7 0xffffffff80823883 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #8 0xffffffff805bad5d in kdb_enter (why=0xffffffff80936f79 "panic", msg=0xa
) at cpufunc.h:63 #9 0xffffffff8058b74b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:558 #10 0xffffffff80592f0c in _sx_xlock (sx=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/sys/kern/kern_sx.c:285 #11 0xffffffff8105fc56 in zfs_freebsd_reclaim (ap=Variable "ap" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4361 #12 0xffffffff8061ae05 in vgonel (vp=0xffffff00503fa1d8) at vnode_if.h:830 #13 0xffffffff8061e975 in vflush (mp=0xffffff00503ebbc0, rootrefs=0, flags=0, td=0xffffff0050248000) at /usr/src/sys/kern/vfs_subr.c:2449 #14 0xffffffff8105a598 in zfs_umount (vfsp=0xffffff00503ebbc0, fflag=524288) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:996 #15 0xffffffff80616336 in dounmount (mp=0xffffff00503ebbc0, flags=524288, td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_mount.c:1289 #16 0xffffffff8061be54 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:3141 #17 0xffffffff8058b58f in boot (howto=0) at /usr/src/sys/kern/kern_shutdown.c:401 #18 0xffffffff8058b8b8 in reboot (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:173 #19 0xffffffff8083d4af in syscall (frame=0xffffff810f0cfc80) at /usr/src/sys/amd64/amd64/trap.c:984 #20 0xffffffff80823b61 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 #21 0x000000080078f96c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-fs@FreeBSD.ORG Wed Aug 12 18:10:09 2009 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 2042A106564A for ; Wed, 12 Aug 2009 18:10:09 +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 0F3B58FC49 for ; Wed, 12 Aug 2009 18:10:09 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7CIA8qY058689 for ; Wed, 12 Aug 2009 18:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7CIA8Qv058688; Wed, 12 Aug 2009 18:10:08 GMT (envelope-from gnats) Date: Wed, 12 Aug 2009 18:10:08 GMT Message-Id: <200908121810.n7CIA8Qv058688@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: gprspb@mail.ru Cc: Subject: Re: kern/122038: [tmpfs] [panic] tmpfs: panic: tmpfs_alloc_vp: type 0xc7d2fab0 0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gprspb@mail.ru List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 18:10:09 -0000 The following reply was made to PR kern/122038; it has been noted by GNATS. From: gprspb@mail.ru To: bug-followup@FreeBSD.org, delphij@FreeBSD.org Cc: Subject: Re: kern/122038: [tmpfs] [panic] tmpfs: panic: tmpfs_alloc_vp: type 0xc7d2fab0 0 Date: Wed, 12 Aug 2009 21:47:01 +0400 This is 100% reproducible on my system with the following commands: # mkdir -p /tmp/1/2 # cd /tmp/1/2 # rm -rf /tmp/1 ; cd .. Panic String: tmpfs_alloc_vp: type 0xffffff00268b80e0 0 tmpfs on /tmp (tmpfs, local) FreeBSD gpr.nnz-home.ru 8.0-BETA2 FreeBSD 8.0-BETA2 #0 r196086M: Sat Aug 8 23:53:43 MSD 2009 gpr@gpr.nnz-home.ru:/usr/obj/usr/src/freebsd-head/sys/GPR amd64 I can make dump or submit additional info if it is necessary. From owner-freebsd-fs@FreeBSD.ORG Wed Aug 12 21:19:56 2009 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 BC4B11065677; Wed, 12 Aug 2009 21:19:56 +0000 (UTC) (envelope-from nafzal@hotmail.com) Received: from col0-omc1-s14.col0.hotmail.com (col0-omc1-s14.col0.hotmail.com [65.55.34.24]) by mx1.freebsd.org (Postfix) with ESMTP id AEC038FC5F; Wed, 12 Aug 2009 21:19:55 +0000 (UTC) Received: from COL111-W50 ([65.55.34.8]) by col0-omc1-s14.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 14:15:05 -0700 Message-ID: X-Originating-IP: [192.55.54.38] From: Naeem Afzal To: Date: Wed, 12 Aug 2009 21:15:05 +0000 Importance: Normal In-Reply-To: <20090812052814.GD1600@garage.freebsd.pl> References: <20090811191837.GB66530@keira.kiwi-computer.com> <20090812052814.GD1600@garage.freebsd.pl> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Aug 2009 21:15:05.0905 (UTC) FILETIME=[F6D82A10:01CA1B91] Cc: freebsd-fs@freebsd.org Subject: RE: filesystem size after newfs 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, 12 Aug 2009 21:19:57 -0000 Block size is set to 4K=2C did you mean fragment size should be 4K too? Are= you saying that for each block of 512b there is 32b for space consumed for= hash? Is this only when using authentication algorithm? regardsnaeem > > To ensure atomicity of operations=2C geli stores hashes in the same > sector as the data. Creating geli providers with block size of 512 bytes > is very inefficient. It will consume two sectors for each sector=2C which > looks like this: > > 1 512b of data -----> 480b for data + 32b for hash > 2 32b for data + 32b for hash + 448b unused > > The most optimal block size for geli provider is 4kB=2C it consumes one > extra sector for every 8 sectors: > > 1 512b of data -----> 480b for data + 32b for hash > 2 512b of data 480b for data + 32b for hash > 3 512b of data 480b for data + 32b for hash > 4 512b of data 480b for data + 32b for hash > 5 512b of data 480b for data + 32b for hash > 6 512b of data 480b for data + 32b for hash > 7 512b of data 480b for data + 32b for hash > 8 512b of data 480b for data + 32b for hash > 9 256b for data + 32b for hash + 224 unused > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes=2C I Am! _________________________________________________________________ Express your personality in color! Preview and select themes for Hotmail=AE= .=20 http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=3DPID233= 91::T:WLMTAGL:ON:WL:en-US:WM_HYGN_express:082009= From owner-freebsd-fs@FreeBSD.ORG Wed Aug 12 22:18:29 2009 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 89DD91065674 for ; Wed, 12 Aug 2009 22:18:29 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2325D8FC48 for ; Wed, 12 Aug 2009 22:18:28 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 372B945C9F; Thu, 13 Aug 2009 00:18:27 +0200 (CEST) Received: from localhost (chello087206049004.chello.pl [87.206.49.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 292F345C8C; Thu, 13 Aug 2009 00:18:22 +0200 (CEST) Date: Thu, 13 Aug 2009 00:18:20 +0200 From: Pawel Jakub Dawidek To: Naeem Afzal Message-ID: <20090812221820.GA1463@garage.freebsd.pl> References: <20090811191837.GB66530@keira.kiwi-computer.com> <20090812052814.GD1600@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" 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 8.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: filesystem size after newfs 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, 12 Aug 2009 22:18:29 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 12, 2009 at 09:15:05PM +0000, Naeem Afzal wrote: >=20 >=20 > Block size is set to 4K, did you mean fragment size should be 4K too? Are= you saying that for each block of 512b there is 32b for space consumed for= hash? Is this only when using authentication algorithm? The block size I was talking about is the one given by -s option to 'geli init'. If authentication is turned off there is no space overhead except for 512 bytes for metadata. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKgz+sForvXbEpPzQRAiLtAKDLEakXD+EBzQsTEadgHgARB/gRewCeKGix JOjjUyJ64+Rm4aAiMG2r02I= =hdOK -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-fs@FreeBSD.ORG Thu Aug 13 15:23:10 2009 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 5EDA6106567B for ; Thu, 13 Aug 2009 15:23:10 +0000 (UTC) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 0314F8FC1F for ; Thu, 13 Aug 2009 15:23:09 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.13.6) with ESMTP id n7DEo9Fd039518; Thu, 13 Aug 2009 08:50:09 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id n7DEo9Sa039517; Thu, 13 Aug 2009 08:50:09 -0600 (MDT) (envelope-from ken) Date: Thu, 13 Aug 2009 08:50:08 -0600 From: "Kenneth D. Merry" To: Panagiotis Christias Message-ID: <20090813145008.GA39384@nargothrond.kdm.org> References: <8E9591D8BCB72D4C8DE0884D9A2932DC35BD34C3@ITS-HCWNEM03.ds.Vanderbilt.edu> <200908101605.12332.jhb@freebsd.org> <200908101707.49526.jhb@freebsd.org> <8E9591D8BCB72D4C8DE0884D9A2932DC6D2EDF21@ITS-HCWNEM03.ds.Vanderbilt.edu> <20090812124721.GA71441@noc.ntua.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090812124721.GA71441@noc.ntua.gr> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.92.1/9689/Thu Aug 13 06:32:09 2009 on nargothrond.kdm.org X-Virus-Status: Clean Cc: "freebsd-fs@freebsd.org" , "Hearn, Trevor" Subject: Re: UFS Filesystem issues, and the loss of my hair... 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, 13 Aug 2009 15:23:10 -0000 On Wed, Aug 12, 2009 at 15:47:21 +0300, Panagiotis Christias wrote: > On Mon, Aug 10, 2009 at 05:20:44PM -0500, Hearn, Trevor wrote: > > Yes, it does seem like it was part of one of the other messages. The isp(4) > > driver was just recently updated in HEAD by mjacob@ who has maintained that > > driver in the past. He may have some insight if there is an isp(4)-specific > > problem. > > > > -- > > John Baldwin > > > > Heh. Ok, I just watched the same error message scroll across the screen > > for about 5 minutes now, with a different offset, same length. The fun > > part is that it is not touching the device, /dev/da1p7 at all. From the > > systat -vmstat display, I see all of the traffic coming from the > > /dev/mfid0 drives. It ran for a while, then stopped. So, no access to > > the drive in question, da1p7, but on the root drive, mfid0. Odd. The > > partition is mapped to the root drive. I wonder if the driver lost > > itself, and it tried to access the file on the empty folder on the root > > drive. Sigh. Anyone? > > Hello, > > we faced a similar problem here (major greek university) about a year ago > [1]. Our setup consists of Dell 2950 servers, QLogic 2462 HBAs (PCI-E) > and an EMC CLARiiON CX3-40. As soon as we tried to do a simple "tar zxf > ports.tgz" on a SAN volume the system would freeze or/and panic (same error > messages as yours). Oleg Sharoiko suggested that we could decrease the > number of tag openings (tag queue depth). Decreasing it would make the > system a bit more stable but did not eliminate the problem. > > Then, I contacted Matthew Jacob and tested his latest isp code [2] along > with alternative solutions like zfs and gjournal. Matthew was kind enough > to offer his support but eventually I ran out time and patience, so I moved > a couple of servers to centos in order to put the storage into production. > That was around December last year. > > About a month ago Kenneth Merry announced that a new version of isp was > available [3] which corrected bugs and added new functionality. I thought > it was worth trying so I set up FreeBSD 7-stable in two Dell boxes, added > the isp patches, recompiled the kernel and started the stress tests. I > also looked around for more info and hints regarding qlogic hbas. The > Linux driver (ql2xxx) has a 32 max queue depth by default (see > ql2xmaxqdepth) which is also the recommended value by EMC. There are also > similar references for Solaris (see sd:sd_max_throttle). Some mention > even smaller values depending the storage. > > Currently, I am running stress tests, using fsx, ffsb, postmark, iozone, > bonnie++, blogbench and other home-made scripts (any other suggestion?) on > two 7-stable-amd64 + isp_diffs.releng7.20090629 boxes. So far, at 32 maximum > tag openings, everything looks good, I have not seen any panics and the > following fsck run cleanly. I will keep running more tests for a week or two > hoping that they will help draw a conclusion. Thanks for the report! I'm glad to hear it is working for you. The driver has gone into -current, and will be in 8.0-RELEASE. Hopefully it'll get propagated back into RELENG_7 before too long. Ken -- Kenneth Merry ken@kdm.org From owner-freebsd-fs@FreeBSD.ORG Fri Aug 14 15:13:00 2009 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 DEF551065690 for ; Fri, 14 Aug 2009 15:13:00 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 67F298FC15 for ; Fri, 14 Aug 2009 15:12:59 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n7EFCwYQ099866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 14 Aug 2009 17:12:58 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <5BE7DB15-41CB-4F68-B1B0-72DA077453B7@lassitu.de> From: Stefan Bethke To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 Aug 2009 17:12:58 +0200 X-Mailer: Apple Mail (2.936) Subject: XtreemFS: new distributed FS 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, 14 Aug 2009 15:13:00 -0000 http://www.xtreemfs.org/ They have some bold claims, and no port to FreeBSD yet, but they're using Fuse, so it shouldn't be too hard... Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-fs@FreeBSD.ORG Sat Aug 15 19:31:42 2009 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 50C5C106568C for ; Sat, 15 Aug 2009 19:31:42 +0000 (UTC) (envelope-from gosand1982@yahoo.com) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by mx1.freebsd.org (Postfix) with SMTP id C92718FC43 for ; Sat, 15 Aug 2009 19:31:41 +0000 (UTC) Received: from [68.142.230.29] by n7.bullet.re3.yahoo.com with NNFMP; 15 Aug 2009 19:19:11 -0000 Received: from [67.195.9.81] by t2.bullet.re2.yahoo.com with NNFMP; 15 Aug 2009 19:19:11 -0000 Received: from [67.195.9.110] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 15 Aug 2009 19:19:11 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 15 Aug 2009 19:19:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 565005.77466.bm@omp114.mail.gq1.yahoo.com Received: (qmail 53167 invoked by uid 60001); 15 Aug 2009 19:19:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250363951; bh=4jd+buWr6WvCEhU9j2iON0/l4254zoP+xG9WkEaYShQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=exUmiZiPuqKLn6ZXAnGJT+lzGCKPEqdOmUnWCtBtKmytWE1QOw2AlDbXYo8FxlIjiU/bXI2/8Zfon4FtR+cAlTl7tniDv0aTbplB06pUdQMVUG68LDBk1PmgmPz5HewkgAilPHG07AIPMB5jqRthEMxH1gXApcC2SWGeruAcgcQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=V1sXXq88rMAU+An+lDtN+n4jQrmb77oiz4jVHZKvBj5aZv7ENKefTpEtVFX39Ar3Pyk2kFhBuN1Erft8jNCSRvscUl3K9ByDmsmtLeFbo84k9MgCH3Ch/9Idem1BB457kkmTXTh7dL/rBo6FIIO2KNHSH3bwKF22YcVz812v5o8=; Message-ID: <453373.52906.qm@web111616.mail.gq1.yahoo.com> X-YMail-OSG: 9HZ4pf4VM1mw3ZnZFoqrEWRzqcTwvbyTpRiV2JGozAxJoEUiz.CUXJvrvonez87dp7_.fjOMXoL4jA2z7hfMf.83HhYpW2t0pyqIyYOpX677zFqftj3NvVtdYoUZw7wl9gMYdxlvEvtWEKnVeI8t51_ZunRRZI3YYqXjZ.i6U6UoPvcFnnPjAVmq8WSHkE4.yXvsDhg8VjR9PNhniE9apFCngunmS34iSihDSHdOci63xeuuFKyQQP6XU4YfytYDHjxyTJDPXgkj4EBWXt_B Received: from [69.181.252.182] by web111616.mail.gq1.yahoo.com via HTTP; Sat, 15 Aug 2009 12:19:11 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 Date: Sat, 15 Aug 2009 12:19:11 -0700 (PDT) From: George Sanders To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: cannot use 2TB external USB drive ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 19:31:42 -0000 I bought a western digital 2TB USB external drive - shows up in dmesg as: da2 at umass-sim0 bus 0 target 0 lun 0 da2: Fixed Direct Access SCSI-4 device da2: 40.000MB/s transfers da2: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) Originally I tried to simply use it right off as a FAT32 device. However, this crashed my system after generating thousands of: g_vfs_done():da0s4[READ(offset=0, length=2048)]error = 5 g_vfs_done():da0s4[READ(offset=32768, length=2048)]error = 5 So I wiped the disk and recreated it in sysinstall using sysid 6 (msdos) and newfs_msdos ... my thought was that maybe western digital had some weird layouts or boot partitions, etc., and maybe I just needed to start with a clean slate. I got the same result. So finally, I gave up and since the end user of this system CANNOT use ufs2 (which is what I would prefer anyway) I installed the ext2 tools and made an ext2 volume: # mke2fs /dev/da2s1 mke2fs 1.41.8 (11-Jul-2009) Filesystem label= OS type: FreeBSD Block size=4096 (log=2) Fragment size=4096 (log=2) 122101760 inodes, 488378000 blocks 24418900 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 14905 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 Writing inode tables: This mke2fs operation completed successfully and I mounted the drive and began using it. I filled it up to just about the 1 TB level, and the system crashes. No errors, no output, nothing - just freezes up requiring a reset button. Note that my 4k block size in the mke2fs above does NOT imply a 1 TB filesystem size limit for ext2. So what am I doing wrong ? Again, I would love to just newfs this to ufs2, but the end user cannot use that - fat32 and ext2 are my only options... Is this drive just too big for freebsd to handle over USB ? From owner-freebsd-fs@FreeBSD.ORG Sat Aug 15 22:51:04 2009 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 48E02106568C for ; Sat, 15 Aug 2009 22:51:04 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by mx1.freebsd.org (Postfix) with ESMTP id CEA588FC45 for ; Sat, 15 Aug 2009 22:51:03 +0000 (UTC) Received: by ewy2 with SMTP id 2so239999ewy.43 for ; Sat, 15 Aug 2009 15:51:02 -0700 (PDT) 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=9hZp65wsBpxg5wB244g8+ib/W8nQwGwzPS1YShjOsSk=; b=B9ZXvkzyFAoXBDcCfugDaUg1RaI/hO6RBovaVYCnoU+/6hTTPP6a4D0oTuT5c2sKRD uiRvb08dTk5EpvsPDI8Dbf2j29wVKUMI7F+19i9iN6sAeKhOmOp7BRWklJOOh6QhMb6+ 3kFvLQK+I+nYXJXAZujZjtXjPhlqh46QgRke0= 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=LGro1duVYvqh5ArXqpTpeTFo5eBch9KptX0vPp5F+4MBT0nyP+da5nIBWhWV7PyC85 2NxMNWalPDhaLqVwfiLJowBYoIFzuwCU5RLU1LSHWk3rBQ1qmA/cdIMHrvqZJlU3b7k8 U9GG1HZtNMDWb/xu4a7NggtMWfh5cDpmpaQbA= MIME-Version: 1.0 Received: by 10.216.8.213 with SMTP id 63mr697764wer.161.1250374864158; Sat, 15 Aug 2009 15:21:04 -0700 (PDT) In-Reply-To: <453373.52906.qm@web111616.mail.gq1.yahoo.com> References: <453373.52906.qm@web111616.mail.gq1.yahoo.com> Date: Sat, 15 Aug 2009 18:21:04 -0400 Message-ID: <5f67a8c40908151521g2f152e56ge9928573dd784a88@mail.gmail.com> From: Zaphod Beeblebrox To: George Sanders Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: cannot use 2TB external USB drive ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 22:51:04 -0000 On Sat, Aug 15, 2009 at 3:19 PM, George Sanders wrote: > > > I bought a western digital 2TB USB external drive - shows up in dmesg as: > > da2: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > > Originally I tried to simply use it right off as a FAT32 device. However, > this crashed my system after generating thousands of: > [...] > So finally, I gave up and since the end user of this system CANNOT use ufs2 > (which is what I would prefer anyway) I installed the ext2 tools and made an > ext2 volume: Urm... I'm pretty sure that neither ext2 nor FAT32 can make a 2T filesystem. It's a limitation of the format. NTFS might work fine (use the fuse version) or ext3 might work (I'm fuzzy on that point). The other obvious choice would be to make partitions less than 1T.