From owner-freebsd-fs@FreeBSD.ORG Mon Mar 19 03:16:24 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E73F16A400 for ; Mon, 19 Mar 2007 03:16:24 +0000 (UTC) (envelope-from staalebk@ifi.uio.no) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by mx1.freebsd.org (Postfix) with ESMTP id BAF6413C46A for ; Mon, 19 Mar 2007 03:16:23 +0000 (UTC) (envelope-from staalebk@ifi.uio.no) Received: from eschew.pusen.org (unknown [193.69.145.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTP id 24AEC12C3B7 for ; Mon, 19 Mar 2007 03:50:03 +0100 (CET) Received: from chiller by eschew.pusen.org with local (Exim 4.50) id 1HT7ZY-0002yh-Ar for freebsd-fs@FreeBSD.org; Mon, 19 Mar 2007 03:26:08 +0100 Date: Mon, 19 Mar 2007 03:26:08 +0100 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: freebsd-fs@FreeBSD.org Message-ID: <20070319022608.GA7858@eschew.pusen.org> References: <20070318223005.ab2b7aa7.nork@FreeBSD.org> <20070318134240.GC16185@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070318134240.GC16185@garage.freebsd.pl> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: [REPORT] ZFS panic on recent 7-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: Mon, 19 Mar 2007 03:16:24 -0000 On 2007-03-18 at 14:42, Pawel Jakub Dawidek wrote: > You can't use recent HEAD, because of tegge's recent changes that break > API/ABI. You need to have HEAD from before tegge's changes. Ah, that sorted things out for me as well. I did get a "kmem_malloc(X): kmem_map too small: Y total allocated"-panic, is that still something that should be ignored? It also looks like 'zpool list' shows the wrong(?) size and available info if showing a raidz-pool: (ad1-3 512MB disks) # zpool create test raidz ad1 ad2 ad3 # zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT test 1.48G 157K 1.48G 0% ONLINE - # df -ht zfs Filesystem Size Used Avail Capacity Mounted on test 980M 32K 980M 0% /test # dd if=/dev/random of=/test/temp bs=1M count=512 512+0 records in 512+0 records out 536870912 bytes transferred in 40.188660 secs (13358766 bytes/sec) # zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT test 1.48G 773M 747M 50% ONLINE - # df -ht zfs Filesystem Size Used Avail Capacity Mounted on test 980M 515M 466M 53% /test It could be argued that it shows the correct amount that is consumed with redundant information, but when using a mirror instead, output is more as expected: # zpool destroy test # zpool create test mirror ad1 ad2 # zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT test 504M 88K 504M 0% ONLINE - # df -ht zfs Filesystem Size Used Avail Capacity Mounted on test 472M 32K 472M 0% /test It could be that this is how it should be, but I think it is a bit confusing, it could also be that it is fixed in perforce, but I couldn't find anything in the log or found out how to check out a recent copy of the code. Thanks for the brilliant work on porting zfs, keep it up! -- Ståle Kristoffersen staalebk@ifi.uio.no