From owner-freebsd-fs@FreeBSD.ORG Sun Feb 22 08:38:49 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 5859D106566C for ; Sun, 22 Feb 2009 08:38:49 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [199.185.220.240]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC028FC13 for ; Sun, 22 Feb 2009 08:38:49 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from priv-edtnaa06.telusplanet.net ([75.157.11.254]) by priv-edtnes28.telusplanet.net (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090222080039.FZII26993.priv-edtnes28.telusplanet.net@priv-edtnaa06.telusplanet.net> for ; Sun, 22 Feb 2009 01:00:39 -0700 Received: from oliver.bc.lan (d75-157-11-254.bchsia.telus.net [75.157.11.254]) by priv-edtnaa06.telusplanet.net (BorderWare Security Platform) with ESMTP id BD040B3138096575 for ; Sun, 22 Feb 2009 01:00:39 -0700 (MST) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id EF2CC62AA; Sun, 22 Feb 2009 00:00:38 -0800 (PST) Message-ID: <49A10626.8060705@telus.net> Date: Sun, 22 Feb 2009 00:00:38 -0800 From: Carl User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 22 Feb 2009 08:38:49 -0000 I've come across what I'm thinking may be a bug in the context of FreeBSD 7.0 with a pair of gmirrored drives and gjournaled partitions when copying a large number of files into a file-backed memory device. The consequence of this problem is that a process enters the 'D' state (process in disk) indefinitely, cannot be killed, and the system cannot be shutdown. The only solution is to cold reboot the system, which is a really big problem for remote systems. This is happening to me intermittently with the standard tar-tar pipeline form of copying, but has happened with the rsync 3.0.4 port as well. I would appreciate it if some of you would see if you can repeat this problem. Here is a sequence of tcsh shell commands which manifest the problem (on occasion but not every time), which I will refer to as the "truncate sequence" (depends on fully populated /usr/src tree as data set): # truncate -s 671088640 target # mdconfig -f target -S 512 -y 255 -x 63 -u 7 # bsdlabel -w /dev/md7 auto # newfs -O2 -m 0 -o space /dev/md7a # mount /dev/md7a /media # tar -cvf - -C /usr/src . | tar -xvpof - -C /media # umount /media ; mdconfig -d -u 7 ; rm target An alternate version has yet to fail for me and involves replacing the first line with this one: # dd if=/dev/zero of=target bs=1M count=640 I'll call that the "dd sequence". Here is an ordered series of tests I just completed: a) Repeated truncate sequence 7 times - 1st, 5th, and 7th failed. b) Repeated dd sequence 7 times - no failures. c) Repeated truncate sequence 6 time - no failures. d) Used following sequence to ensure all disk caches flushed: # dd if=/dev/random of=target bs=1M count=4096 # dd if=target of=/dev/null bs=1M # rm target e) Repeated truncate sequence 4 times - no failures. f) Performed orderly reboot. g) Repeated truncate sequence 2 times - 2nd failed. h) Performed orderly reboot. i) Repeated dd sequence 7 times - no failures. All failures involve the second tar in the pipeline hanging in the 'D' state. In each case I do a cold reboot before proceeding with the next test. It's tempting to speculate that a bug exists in code related to handling sparse files specifically, but perhaps it just raises the probability of tripping a bug that would eventually manifest in the dd sequence as well. OTOH, I don't know how to rule out a physical disk or disk firmware problem. This problem has occurred with different data sets and different sized memory disks, but only with the source and destination filesystems being UFS2. I have done similar sequences with EXT2 and FAT16 destinations with no failures thus far, but the memory disks and data sets were smaller so it's conceivable that probability worked against me. I should note that the drives are Seagate ST31000340AS Barracudas, but both drives have been upgraded to firmware version SD1A and are therefore supposedly free of the infamous little horror Seagate inflicted on so many of us. smartctl tells me that both disks still have a raw value of 0 for Reallocated_Sector_Ct and both pass the "short" self test. Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Sun Feb 22 11:01: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 561DD1065670 for ; Sun, 22 Feb 2009 11:01:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id E22048FC16 for ; Sun, 22 Feb 2009 11:00:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LbC4u-000AYI-4v; Sun, 22 Feb 2009 13:00:56 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n1MB0rlw021304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Feb 2009 13:00:53 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n1MB0qL7073322; Sun, 22 Feb 2009 13:00:52 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n1MB0qGW073321; Sun, 22 Feb 2009 13:00:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 22 Feb 2009 13:00:52 +0200 From: Kostik Belousov To: Carl Message-ID: <20090222110052.GH41617@deviant.kiev.zoral.com.ua> References: <49A10626.8060705@telus.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sjel/IY1pyoUgMMX" Content-Disposition: inline In-Reply-To: <49A10626.8060705@telus.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LbC4u-000AYI-4v af201d6330edbbb74bc5967f3407e2b6 X-Terabit: YES Cc: freebsd-fs@freebsd.org Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 22 Feb 2009 11:01:00 -0000 --sjel/IY1pyoUgMMX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 22, 2009 at 12:00:38AM -0800, Carl wrote: > I've come across what I'm thinking may be a bug in the context of=20 > FreeBSD 7.0 with a pair of gmirrored drives and gjournaled partitions=20 > when copying a large number of files into a file-backed memory device. >=20 > The consequence of this problem is that a process enters the 'D' state=20 > (process in disk) indefinitely, cannot be killed, and the system cannot= =20 > be shutdown. The only solution is to cold reboot the system, which is a= =20 > really big problem for remote systems. This is happening to me=20 > intermittently with the standard tar-tar pipeline form of copying, but=20 > has happened with the rsync 3.0.4 port as well. >=20 > I would appreciate it if some of you would see if you can repeat this=20 > problem. Here is a sequence of tcsh shell commands which manifest the=20 > problem (on occasion but not every time), which I will refer to as the=20 > "truncate sequence" (depends on fully populated /usr/src tree as data set= ): >=20 > # truncate -s 671088640 target > # mdconfig -f target -S 512 -y 255 -x 63 -u 7 > # bsdlabel -w /dev/md7 auto > # newfs -O2 -m 0 -o space /dev/md7a > # mount /dev/md7a /media > # tar -cvf - -C /usr/src . | tar -xvpof - -C /media > # umount /media ; mdconfig -d -u 7 ; rm target >=20 > An alternate version has yet to fail for me and involves replacing the=20 > first line with this one: >=20 > # dd if=3D/dev/zero of=3Dtarget bs=3D1M count=3D640 >=20 > I'll call that the "dd sequence". Here is an ordered series of tests I=20 > just completed: >=20 > a) Repeated truncate sequence 7 times - 1st, 5th, and 7th failed. > b) Repeated dd sequence 7 times - no failures. > c) Repeated truncate sequence 6 time - no failures. > d) Used following sequence to ensure all disk caches flushed: >=20 > # dd if=3D/dev/random of=3Dtarget bs=3D1M count=3D4096 > # dd if=3Dtarget of=3D/dev/null bs=3D1M > # rm target >=20 > e) Repeated truncate sequence 4 times - no failures. > f) Performed orderly reboot. > g) Repeated truncate sequence 2 times - 2nd failed. > h) Performed orderly reboot. > i) Repeated dd sequence 7 times - no failures. >=20 > All failures involve the second tar in the pipeline hanging in the 'D'=20 > state. In each case I do a cold reboot before proceeding with the next te= st. >=20 > It's tempting to speculate that a bug exists in code related to handling= =20 > sparse files specifically, but perhaps it just raises the probability of= =20 > tripping a bug that would eventually manifest in the dd sequence as=20 > well. OTOH, I don't know how to rule out a physical disk or disk=20 > firmware problem. >=20 > This problem has occurred with different data sets and different sized=20 > memory disks, but only with the source and destination filesystems being= =20 > UFS2. I have done similar sequences with EXT2 and FAT16 destinations=20 > with no failures thus far, but the memory disks and data sets were=20 > smaller so it's conceivable that probability worked against me. >=20 > I should note that the drives are Seagate ST31000340AS Barracudas, but=20 > both drives have been upgraded to firmware version SD1A and are=20 > therefore supposedly free of the infamous little horror Seagate=20 > inflicted on so many of us. smartctl tells me that both disks still have= =20 > a raw value of 0 for Reallocated_Sector_Ct and both pass the "short"=20 > self test. Please, see http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug-deadlocks.html for instructions on how to gather the required information to diagnose the issue. --sjel/IY1pyoUgMMX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmhMGMACgkQC3+MBN1Mb4iqVACePL6IH3cjmuxS/fBbA662oa6o 1oMAnjiIFXx8lUDtxWyr9TdEWDfnF5xf =7grU -----END PGP SIGNATURE----- --sjel/IY1pyoUgMMX-- From owner-freebsd-fs@FreeBSD.ORG Sun Feb 22 23:55:02 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 0CF071065688 for ; Sun, 22 Feb 2009 23:55:02 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.13]) by mx1.freebsd.org (Postfix) with ESMTP id ACF1F8FC1D for ; Sun, 22 Feb 2009 23:55:01 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from priv-edmwaa05.telusplanet.net ([204.209.205.55]) by priv-edmwes51.telusplanet.net (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090222235456.MUZP1759.priv-edmwes51.telusplanet.net@priv-edmwaa05.telusplanet.net>; Sun, 22 Feb 2009 16:54:56 -0700 Received: from oliver.bc.lan (d75-157-11-254.bchsia.telus.net [75.157.11.254]) by priv-edmwaa05.telusplanet.net (BorderWare Security Platform) with ESMTP id 2C3F153630050D26; Sun, 22 Feb 2009 16:54:55 -0700 (MST) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id 587FC62AA; Sun, 22 Feb 2009 15:54:55 -0800 (PST) Message-ID: <49A1E5CE.5000501@telus.net> Date: Sun, 22 Feb 2009 15:54:54 -0800 From: Carl User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <49A10626.8060705@telus.net> <20090222110052.GH41617@deviant.kiev.zoral.com.ua> In-Reply-To: <20090222110052.GH41617@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 22 Feb 2009 23:55:02 -0000 Kostik Belousov wrote: > Please, see > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > for instructions on how to gather the required information to diagnose > the issue. I'm not sure that it's possible for me to get into rebuilding and debugging the kernel, tar, or whatever component is at issue right now. If others can reproduce the problem, that would at least rule out a hardware problem as a starting point and hopefully garner further insight from someone more knowledgeable than I. FWIW, my system did not "stop doing useful work". Since I was using 'screen', upon the tar process hanging I switched to another window and was able to use ps, mount the procfs, try killing things, etc. Aside from being unable to kill the tar process or reboot the system, at least some other forms of work are still possible. Does this qualify as a kernel deadlock? Is there some other way to forcibly reboot a remote system from the command line when a normal shutdown command is going to totally hang the system in this way? Or perhaps some kind of watchdog that has a good chance of surviving long enough to unjam a situation like this? Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Mon Feb 23 01:16: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 EFC3C1065689 for ; Mon, 23 Feb 2009 01:16:56 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id AECF88FC17 for ; Mon, 23 Feb 2009 01:16:56 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (localhost.your.org [127.0.0.1]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id 9A5282AD5695; Mon, 23 Feb 2009 01:16:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=dragondata.com; h=cc :message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references; s=selector1; bh=yYfa161oVGqu4A+K+D9jbMqbjRs=; b=w/u+gDeSUaONOG9 qWSrp5RxYUGRuZlb8F20ANuqyx/dEmf8ilGmWoOx7B7k5ZI+ojFePB/DM3Ce041D HUpUHITOub4HH9tC0YLJ7o9/N93ZFcvcGbo1O8/KTcO7UueegpJ49F8upFtHowvV CnXJe4C+k+dL0XqyI4RaYkYDZBik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=dragondata.com; h=cc:message-id :from:to:in-reply-to:content-type:content-transfer-encoding :mime-version:subject:date:references; q=dns; s=selector1; b=TpS xgyd4DCeifJl2+QLjo/wpNFwpYcIQ8bzix0PdJIPDrO1IUD0duRJd/JsfdsMHnXt PLFcjM6ANdePdkFYTFND8fyNzJbzKC05EbU65gXz4VbAFt2dCdfvT7z9yUQqSSoB 1ZlAfUMsacTrAl8JJIlBkebyRYyVLIy+THoI8P10= Received: from mail.your.org (server3-a.your.org [64.202.112.67]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by tokyo01.jp.mail.your.org (Postfix) with ESMTPS id 5EBF82AD568D; Mon, 23 Feb 2009 01:16:54 +0000 (UTC) Received: from pool011.dhcp.your.org (pool011.dhcp.your.org [69.31.99.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTPSA id 11C0CA0A40B; Mon, 23 Feb 2009 01:12:28 +0000 (UTC) Message-Id: From: Kevin Day To: Carl In-Reply-To: <49A1E5CE.5000501@telus.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Feb 2009 19:16:52 -0600 References: <49A10626.8060705@telus.net> <20090222110052.GH41617@deviant.kiev.zoral.com.ua> <49A1E5CE.5000501@telus.net> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-fs@freebsd.org Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 23 Feb 2009 01:16:57 -0000 On Feb 22, 2009, at 5:54 PM, Carl wrote: > > Is there some other way to forcibly reboot a remote system from the > command line when a normal shutdown command is going to totally hang > the system in this way? Or perhaps some kind of watchdog that has a > good chance of surviving long enough to unjam a situation like this? reboot(8)'s man page: -n The file system cache is not flushed. This option should proba- bly not be used. -q The system is halted or restarted quickly and ungracefully, and only the flushing of the file system cache is performed (if the -n option is not specified). This option should probably not be used. One or both of those would probably do it. -- Kevin From owner-freebsd-fs@FreeBSD.ORG Mon Feb 23 03:43:44 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 3EF71106564A for ; Mon, 23 Feb 2009 03:43:44 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [199.185.220.240]) by mx1.freebsd.org (Postfix) with ESMTP id DD43A8FC1A for ; Mon, 23 Feb 2009 03:43:43 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from priv-edtnaa06.telusplanet.net ([75.157.11.254]) by priv-edtnes28.telusplanet.net (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090223034343.MDTZ26993.priv-edtnes28.telusplanet.net@priv-edtnaa06.telusplanet.net>; Sun, 22 Feb 2009 20:43:43 -0700 Received: from oliver.bc.lan (d75-157-11-254.bchsia.telus.net [75.157.11.254]) by priv-edtnaa06.telusplanet.net (BorderWare Security Platform) with ESMTP id 12702B0230197942; Sun, 22 Feb 2009 20:43:42 -0700 (MST) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id 4F9A162AA; Sun, 22 Feb 2009 19:43:40 -0800 (PST) Message-ID: <49A21B6B.7060709@telus.net> Date: Sun, 22 Feb 2009 19:43:39 -0800 From: Carl User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kevin Day References: <49A10626.8060705@telus.net> <20090222110052.GH41617@deviant.kiev.zoral.com.ua> <49A1E5CE.5000501@telus.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 23 Feb 2009 03:43:44 -0000 Kevin Day wrote: > On Feb 22, 2009, at 5:54 PM, Carl wrote: >> Is there some other way to forcibly reboot a remote system from the >> command line when a normal shutdown command is going to totally hang >> the system in this way? Or perhaps some kind of watchdog that has a >> good chance of surviving long enough to unjam a situation like this? > > reboot(8)'s man page: > > -n The file system cache is not flushed. This option should > probably not be used. > > -q The system is halted or restarted quickly and ungracefully, > and only the flushing of the file system cache is > performed (if the -n option is not specified). This > option should probably not be used. > > One or both of those would probably do it. Obviously I need to work on RTFM. I didn't look past shutdown(8). In my defence... I've got nothing. Thanks Kevin :-) A watchdog would still be valuable for those situations when one attempts a normal remote reboot, the system hangs, and sshd dies with it. Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Mon Feb 23 08:50:00 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 1EB6F1065673; Mon, 23 Feb 2009 08:50:00 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E65C98FC33; Mon, 23 Feb 2009 08:49:59 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n1N8nxLa049597; Mon, 23 Feb 2009 08:49:59 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n1N8nxXa049593; Mon, 23 Feb 2009 08:49:59 GMT (envelope-from linimon) Date: Mon, 23 Feb 2009 08:49:59 GMT Message-Id: <200902230849.n1N8nxXa049593@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/131995: [nfs] Failure to mount NFSv4 server 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, 23 Feb 2009 08:50:02 -0000 Old Synopsis: Failure to mount NFSv4 server New Synopsis: [nfs] Failure to mount NFSv4 server Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 23 08:49:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131995 From owner-freebsd-fs@FreeBSD.ORG Mon Feb 23 10:26: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 23B04106564A for ; Mon, 23 Feb 2009 10:26:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D66978FC1C for ; Mon, 23 Feb 2009 10:26:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 9191C46B23; Mon, 23 Feb 2009 05:26:14 -0500 (EST) Date: Mon, 23 Feb 2009 10:26:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Carl In-Reply-To: <49A10626.8060705@telus.net> Message-ID: References: <49A10626.8060705@telus.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 23 Feb 2009 10:26:16 -0000 On Sun, 22 Feb 2009, Carl wrote: > I've come across what I'm thinking may be a bug in the context of FreeBSD > 7.0 with a pair of gmirrored drives and gjournaled partitions when copying a > large number of files into a file-backed memory device. > > The consequence of this problem is that a process enters the 'D' state > (process in disk) indefinitely, cannot be killed, and the system cannot be > shutdown. The only solution is to cold reboot the system, which is a really > big problem for remote systems. This is happening to me intermittently with > the standard tar-tar pipeline form of copying, but has happened with the > rsync 3.0.4 port as well. It would be interesting to get kernel stack traces of the involved processes/threads; there are various ways to do this, such as using DDB. If you have a kernel.symbols for the kernel, then you can run kgdb on kernel.symbols and /dev/mem to generate traces without interrupting operation (although if the system is in the throes of deadlocking, that may not be a concern or even possible). You can also use procstat -kk to retrieve kernel stack traces, with a bit less information (such as no arguments) to help narrow things down more. Unfortunately, debugging this type of problem, as you've intuited, is best done with serial console access and a local box so that the debugging information can be extracted. It would be interesting to know if you can force a crashdump on the box to get the information for post-mortem debugging. This may be possible using "reboot -d" -- I've never used this, but have every reason to think it will work. Robert N M Watson Computer Laboratory University of Cambridge > > I would appreciate it if some of you would see if you can repeat this > problem. Here is a sequence of tcsh shell commands which manifest the problem > (on occasion but not every time), which I will refer to as the "truncate > sequence" (depends on fully populated /usr/src tree as data set): > > # truncate -s 671088640 target > # mdconfig -f target -S 512 -y 255 -x 63 -u 7 > # bsdlabel -w /dev/md7 auto > # newfs -O2 -m 0 -o space /dev/md7a > # mount /dev/md7a /media > # tar -cvf - -C /usr/src . | tar -xvpof - -C /media > # umount /media ; mdconfig -d -u 7 ; rm target > > An alternate version has yet to fail for me and involves replacing the first > line with this one: > > # dd if=/dev/zero of=target bs=1M count=640 > > I'll call that the "dd sequence". Here is an ordered series of tests I just > completed: > > a) Repeated truncate sequence 7 times - 1st, 5th, and 7th failed. > b) Repeated dd sequence 7 times - no failures. > c) Repeated truncate sequence 6 time - no failures. > d) Used following sequence to ensure all disk caches flushed: > > # dd if=/dev/random of=target bs=1M count=4096 > # dd if=target of=/dev/null bs=1M > # rm target > > e) Repeated truncate sequence 4 times - no failures. > f) Performed orderly reboot. > g) Repeated truncate sequence 2 times - 2nd failed. > h) Performed orderly reboot. > i) Repeated dd sequence 7 times - no failures. > > All failures involve the second tar in the pipeline hanging in the 'D' state. > In each case I do a cold reboot before proceeding with the next test. > > It's tempting to speculate that a bug exists in code related to handling > sparse files specifically, but perhaps it just raises the probability of > tripping a bug that would eventually manifest in the dd sequence as well. > OTOH, I don't know how to rule out a physical disk or disk firmware problem. > > This problem has occurred with different data sets and different sized memory > disks, but only with the source and destination filesystems being UFS2. I > have done similar sequences with EXT2 and FAT16 destinations with no failures > thus far, but the memory disks and data sets were smaller so it's conceivable > that probability worked against me. > > I should note that the drives are Seagate ST31000340AS Barracudas, but both > drives have been upgraded to firmware version SD1A and are therefore > supposedly free of the infamous little horror Seagate inflicted on so many of > us. smartctl tells me that both disks still have a raw value of 0 for > Reallocated_Sector_Ct and both pass the "short" self test. > > Carl / K0802647 > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Mon Feb 23 11:06:51 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 5431E106566B for ; Mon, 23 Feb 2009 11:06:51 +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 416028FC1B for ; Mon, 23 Feb 2009 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n1NB6pES055486 for ; Mon, 23 Feb 2009 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n1NB6oHh055482 for freebsd-fs@FreeBSD.org; Mon, 23 Feb 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Feb 2009 11:06:50 GMT Message-Id: <200902231106.n1NB6oHh055482@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, 23 Feb 2009 11:06:51 -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/131995 fs [nfs] Failure to mount NFSv4 server o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131353 fs gjournal kernel lock 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] mkfs.ext2 creates rotten partition o kern/131084 fs [xfs] xfs destroys itself after copying data o kern/131081 fs [zfs] User cannot delete a file when a ZFS dataset is 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 bin/130105 fs [zfs] zfs send -R dumps core o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129174 fs [nfs] [zfs] [panic] NFS v3 Panic when under high load o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129084 fs [udf] [panic] [lor] udf panic: getblk: size(67584) > M 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/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 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 o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o bin/118249 fs mv(1): moving a directory changes its mtime o kern/116170 fs [panic] Kernel panic when mounting /tmp 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 bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po 43 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 23 15:11:21 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 BCF0E10656FE for ; Mon, 23 Feb 2009 15:11:21 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 73AE98FC0C for ; Mon, 23 Feb 2009 15:11:21 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LbbKK-00059f-Ms for freebsd-fs@freebsd.org; Mon, 23 Feb 2009 13:58:32 +0000 Received: from whiteroom.bfh.ch ([147.87.102.111]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2009 13:58:32 +0000 Received: from ktk by whiteroom.bfh.ch with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2009 13:58:32 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Adrian Gschwend Date: Mon, 23 Feb 2009 14:58:22 +0100 Organization: netlabs.org Lines: 48 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: whiteroom.bfh.ch User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Sender: news Subject: kernel panic while writing to a ZFS volume on iSCSI LUN 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, 23 Feb 2009 15:11:22 -0000 Hi, I am testing ZFS, iSCSI & snapshots on FreeBSD as I want to use it later for some productive data. While doing an rsync from a maildir with lots of small files, the box crashed. Until then there were about 3.5GB of data transferred Platform: FreeBSD 7.1, i386, install from CD Box: Xeon 3.2 something RAM: 1.5GB 50GB iSCSI LUN on Network Appliance Filer I tried to get some hints out of the dump file according to http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html but I noticed I had to get source first & compile the kernel on my own. The backtrace here is done using a kernel.debug which got compiled out of RELENG_7_1, but it was *not* the same kernel which was running at the time of the crash (kernel was the default one, not the compiled one). Does that make a difference for my case or is that ok like this? Message in /var/log/messages on reboot: - Feb 20 00:01:23 chewbacca savecore: reboot after panic: kmem_malloc(131072): kmem_map too small: 228896768 total allocated Feb 20 00:01:23 chewbacca savecore: writing core to vmcore.0 - backtrace: http://freebsd.pastebin.com/m36e7ddd0 My question is if it is crashing in iSCSI or ZFS code & what I should try to get rid of it :-) thanks Adrian -- Adrian Gschwend @ netlabs.org ktk [a t] netlabs.org ------- Open Source Project http://www.netlabs.org From owner-freebsd-fs@FreeBSD.ORG Mon Feb 23 16:26:49 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 29BCF1065672 for ; Mon, 23 Feb 2009 16:26:49 +0000 (UTC) (envelope-from ml-ktk@netlabs.org) Received: from c-3po.netlabs.org (c-3po.netlabs.org [147.87.98.99]) by mx1.freebsd.org (Postfix) with ESMTP id 6E76D8FC13 for ; Mon, 23 Feb 2009 16:26:48 +0000 (UTC) (envelope-from ml-ktk@netlabs.org) Received: (qmail 83874 invoked by uid 89); 23 Feb 2009 16:00:06 -0000 Received: from unknown (HELO mail.netlabs.org) (127.0.0.1) by 0 with SMTP; 23 Feb 2009 16:00:06 -0000 Received: from 147.87.102.111 (SquirrelMail authenticated user ml-ktk@netlabs.org) by mail.netlabs.org with HTTP; Mon, 23 Feb 2009 17:00:06 +0100 (CET) Message-ID: <660f28ee8aa9c3a76b7d736e5ae3c229.squirrel@mail.netlabs.org> Date: Mon, 23 Feb 2009 17:00:06 +0100 (CET) From: ml-ktk@netlabs.org To: freebsd-fs@freebsd.org User-Agent: SquirrelMail/1.4.16 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: kernel panic while writing to a ZFS volume on iSCSI LUN 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, 23 Feb 2009 16:26:49 -0000 Hi, I am testing ZFS, iSCSI & snapshots on FreeBSD as I want to use it later for some productive data. While doing an rsync from a maildir with lots of small files, the box crashed. Until then there were about 3.5GB of data transferred Platform: FreeBSD 7.1, i386, install from CD Box: Xeon 3.2 something RAM: 1.5GB 50GB iSCSI LUN on Network Appliance Filer I tried to get some hints out of the dump file according to http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html but I noticed I had to get source first & compile the kernel on my own. The backtrace here is done using a kernel.debug which got compiled out of RELENG_7_1, but it was *not* the same kernel which was running at the time of the crash (kernel was the default one, not the compiled one). Does that make a difference for my case or is that ok like this? Message in /var/log/messages on reboot: - Feb 20 00:01:23 chewbacca savecore: reboot after panic: kmem_malloc(131072): kmem_map too small: 228896768 total allocated Feb 20 00:01:23 chewbacca savecore: writing core to vmcore.0 - backtrace: http://freebsd.pastebin.com/m36e7ddd0 My question is if it is crashing in iSCSI or ZFS code & what I should try to get rid of it :-) thanks Adrian From owner-freebsd-fs@FreeBSD.ORG Mon Feb 23 23:47:13 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 A755D1065772 for ; Mon, 23 Feb 2009 23:47:13 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.13]) by mx1.freebsd.org (Postfix) with ESMTP id 468A68FC1E for ; Mon, 23 Feb 2009 23:47:13 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from priv-edmwaa05.telusplanet.net ([204.209.205.55]) by priv-edmwes51.telusplanet.net (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090223234707.XUJT1759.priv-edmwes51.telusplanet.net@priv-edmwaa05.telusplanet.net>; Mon, 23 Feb 2009 16:47:07 -0700 Received: from oliver.bc.lan (d75-157-11-254.bchsia.telus.net [75.157.11.254]) by priv-edmwaa05.telusplanet.net (BorderWare Security Platform) with ESMTP id DA0936253025982D; Mon, 23 Feb 2009 16:47:06 -0700 (MST) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id A078A62AA; Mon, 23 Feb 2009 15:47:06 -0800 (PST) Message-ID: <49A3357A.7080008@telus.net> Date: Mon, 23 Feb 2009 15:47:06 -0800 From: Carl User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Robert Watson References: <49A10626.8060705@telus.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 23 Feb 2009 23:47:14 -0000 Robert Watson wrote: > It would be interesting to get kernel stack traces of the involved > processes/threads; there are various ways to do this, such as using > DDB. If you have a kernel.symbols for the kernel, then you can run kgdb > on kernel.symbols and /dev/mem to generate traces without interrupting > operation (although if the system is in the throes of deadlocking, that > may not be a concern or even possible). You can also use procstat -kk > to retrieve kernel stack traces, with a bit less information (such as no > arguments) to help narrow things down more. > > Unfortunately, debugging this type of problem, as you've intuited, is > best done with serial console access and a local box so that the > debugging information can be extracted. It would be interesting to know > if you can force a crashdump on the box to get the information for > post-mortem debugging. This may be possible using "reboot -d" -- I've > never used this, but have every reason to think it will work. I have both a local and remote box. The problems I'm seeing are all occurring on the local box because as yet I cannot afford to cause them on a remote box. If you were to guess I've never used DDB or any other kernel debugging, you'd be spot on. I'm currently running the 7.0-RELEASE GENERIC kernel. I see a /boot/kernel/kernel.symbols in the filesystem. The system is nominally headless with a serial console, although I primarily use SSH. Even if I knew what to do with them, actually collecting kernel dumps is a hit or miss affair because of gmirror, but this particular problem doesn't cause kernel core dumps on its own (thankfully, since gmirror resyncs take a long time on terabyte drives). So, if you were able to clearly spell out the stripped down steps I should take in conjunction with my earlier truncate sequence and if it doesn't require rebuilding the kernel, I might be able to accommodate. Learning all about kernel debugging would be interesting but doesn't fit in my schedule right now. Anyone willing to attempt to reproduce this problem on their system? Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 05:31: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 EB5D4106564A for ; Tue, 24 Feb 2009 05:31:56 +0000 (UTC) (envelope-from dimitar.vassilev@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id A47EC8FC0C for ; Tue, 24 Feb 2009 05:31:56 +0000 (UTC) (envelope-from dimitar.vassilev@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so862134yxl.13 for ; Mon, 23 Feb 2009 21:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rHXoYHd/417Xs9YC/6miWnRv5oQv6Vu/OjuYkhyfPaY=; b=nY6oU/8QrMQrH5ibyxalbnSiciSm/ZuKb5YMpwJKwFaeaXfVgRqqdCJUWGdV8sfCU5 Kzmk2wRIn8yyYDtw3FmLfzSqtKZh1KpL5+8s3flVNMgsLiUOHE0GDq2GQzxRypRQqOyf ZxW1PFyYR7kROCJJ4Ptx8DsOTYkHm9GdJzW2U= 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=QmtmM2zpLGc+dva+tEUiBCnPf8NhaUgkfXrg9IqU7c7/0T9ShYqz7+RWnqTXeO0ag/ NRnPzXkL2C8qscDDbve3DsMACCDrcqg8/VFB11ukajS6mlnO7+ODep42aLCuqHLclZqO mmvpJXesHHNRMay9FAIrd1cUI9FNzwa8nvKYo= MIME-Version: 1.0 Received: by 10.150.225.17 with SMTP id x17mr5995806ybg.248.1235451751207; Mon, 23 Feb 2009 21:02:31 -0800 (PST) In-Reply-To: <49A3357A.7080008@telus.net> References: <49A10626.8060705@telus.net> <49A3357A.7080008@telus.net> Date: Tue, 24 Feb 2009 07:02:31 +0200 Message-ID: <59adc1a0902232102q6c0f6034r354ff9ad3a2b3222@mail.gmail.com> From: Dimitar Vasilev To: Carl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, Robert Watson Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 24 Feb 2009 05:31:57 -0000 2009/2/24 Carl > Robert Watson wrote: > >> It would be interesting to get kernel stack traces of the involved >> processes/threads; there are various ways to do this, such as using DDB. If >> you have a kernel.symbols for the kernel, then you can run kgdb on >> kernel.symbols and /dev/mem to generate traces without interrupting >> operation (although if the system is in the throes of deadlocking, that may >> not be a concern or even possible). You can also use procstat -kk to >> retrieve kernel stack traces, with a bit less information (such as no >> arguments) to help narrow things down more. >> >> Unfortunately, debugging this type of problem, as you've intuited, is best >> done with serial console access and a local box so that the debugging >> information can be extracted. It would be interesting to know if you can >> force a crashdump on the box to get the information for post-mortem >> debugging. This may be possible using "reboot -d" -- I've never used this, >> but have every reason to think it will work. >> > > I have both a local and remote box. The problems I'm seeing are all > occurring on the local box because as yet I cannot afford to cause them on a > remote box. > > If you were to guess I've never used DDB or any other kernel debugging, > you'd be spot on. I'm currently running the 7.0-RELEASE GENERIC kernel. I > see a /boot/kernel/kernel.symbols in the filesystem. The system is nominally > headless with a serial console, although I primarily use SSH. Even if I knew > what to do with them, actually collecting kernel dumps is a hit or miss > affair because of gmirror, but this particular problem doesn't cause kernel > core dumps on its own (thankfully, since gmirror resyncs take a long time on > terabyte drives). So, if you were able to clearly spell out the stripped > down steps I should take in conjunction with my earlier truncate sequence > and if it doesn't require rebuilding the kernel, I might be able to > accommodate. Learning all about kernel debugging would be interesting but > doesn't fit in my schedule right now. > > Anyone willing to attempt to reproduce this problem on their system? > > > Carl / K0802647 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > Hi Carl, How about a soekris board, a USB stick and a null modem cable for collecting data from the local box? Or a laptop with a USB to serial adapter ? Cheers, Dimitar From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 08:42: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 5C59D106564A; Tue, 24 Feb 2009 08:42:39 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.13]) by mx1.freebsd.org (Postfix) with ESMTP id 13A948FC14; Tue, 24 Feb 2009 08:42:38 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from priv-edmwaa05.telusplanet.net ([204.209.205.55]) by priv-edmwes23.telusplanet.net (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090224084238.ZTDJ19903.priv-edmwes23.telusplanet.net@priv-edmwaa05.telusplanet.net>; Tue, 24 Feb 2009 01:42:38 -0700 Received: from oliver.bc.lan (d75-157-11-254.bchsia.telus.net [75.157.11.254]) by priv-edmwaa05.telusplanet.net (BorderWare Security Platform) with ESMTP id 740E07073C059467; Tue, 24 Feb 2009 01:42:37 -0700 (MST) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id E1BFB62AA; Tue, 24 Feb 2009 00:42:36 -0800 (PST) Message-ID: <49A3B2FC.4050601@telus.net> Date: Tue, 24 Feb 2009 00:42:36 -0800 From: Carl User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dimitar Vasilev References: <49A10626.8060705@telus.net> <49A3357A.7080008@telus.net> <59adc1a0902232102q6c0f6034r354ff9ad3a2b3222@mail.gmail.com> In-Reply-To: <59adc1a0902232102q6c0f6034r354ff9ad3a2b3222@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Robert Watson Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 24 Feb 2009 08:42:39 -0000 The same truncate sequence has now been tried on a second system which is hardware- and OS-identical. The same hanging scenario occurs on it. That should eliminate the possibility of a defective hard disk as the cause. The same sequence has also now been tried on a laptop, both natively and in a virtual machine on top of WinXP, although both were FreeBSD 7.1 rather than 7.0. Neither have failed so far. Given the latest hang opportunity, "reboot -q" and "reboot -nq" were tried as suggested by Kevin Day. The former didn't work and itself went into the 'D' state permanently. The "-nq" option *did* work, but obviously one has to recognize it's needed before totally hanging the remote system. Once the tar process has hung, screen keeps working, which gives a chance to create/change to a new window and issue the reboot. New SSH connections don't work. Commands like ps and date still work, but commands like ls go straight into a permanent 'D' state themselves. Bad scene for a remote system :-( Dimitar Vasilev wrote: > How about a soekris board, a USB stick and a null modem cable for collecting > data from the local box? Or a laptop with a USB to serial adapter ? I'll take them ;-) Sorry, Dimitar, if I was unclear. I've already got equipment connected to the serial console on my local machine, so capturing output is no problem. It's all the kernel debugging stuff I've no knowledge of. Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 14:02: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 2FDDD106566C for ; Tue, 24 Feb 2009 14:02:56 +0000 (UTC) (envelope-from ulf.lilleengen@gmail.com) Received: from bene1.itea.ntnu.no (bene1.itea.ntnu.no [IPv6:2001:700:300:3::56]) by mx1.freebsd.org (Postfix) with ESMTP id 78D518FC08 for ; Tue, 24 Feb 2009 14:02:55 +0000 (UTC) (envelope-from ulf.lilleengen@gmail.com) Received: from localhost (localhost [127.0.0.1]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 9C020240F4; Tue, 24 Feb 2009 15:02:53 +0100 (CET) Received: from carrot (unknown [IPv6:2001:700:300:3::184]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 8954124199; Tue, 24 Feb 2009 15:01:22 +0100 (CET) Date: Tue, 24 Feb 2009 15:02:17 +0000 From: Ulf Lilleengen To: ml-ktk@netlabs.org Message-ID: <20090224150217.GA15114@carrot> References: <660f28ee8aa9c3a76b7d736e5ae3c229.squirrel@mail.netlabs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <660f28ee8aa9c3a76b7d736e5ae3c229.squirrel@mail.netlabs.org> User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: Debian amavisd-new at bene1.itea.ntnu.no Cc: freebsd-fs@freebsd.org Subject: Re: kernel panic while writing to a ZFS volume on iSCSI LUN 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, 24 Feb 2009 14:02:56 -0000 On Mon, Feb 23, 2009 at 05:00:06PM +0100, ml-ktk@netlabs.org wrote: > Hi, > > I am testing ZFS, iSCSI & snapshots on FreeBSD as I want to use it later > for some productive data. While doing an rsync from a maildir with lots > of small files, the box crashed. Until then there were about 3.5GB of > data transferred > > Platform: FreeBSD 7.1, i386, install from CD > Box: Xeon 3.2 something > RAM: 1.5GB > 50GB iSCSI LUN on Network Appliance Filer > > I tried to get some hints out of the dump file according to > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html > > but I noticed I had to get source first & compile the kernel on my own. > The backtrace here is done using a kernel.debug which got compiled out > of RELENG_7_1, but it was *not* the same kernel which was running at the > time of the crash (kernel was the default one, not the compiled one). > Does that make a difference for my case or is that ok like this? > > Message in /var/log/messages on reboot: > > - > Feb 20 00:01:23 chewbacca savecore: reboot after panic: > kmem_malloc(131072): kmem_map too small: 228896768 total allocated > Feb 20 00:01:23 chewbacca savecore: writing core to vmcore.0 > - > > backtrace: > http://freebsd.pastebin.com/m36e7ddd0 > > My question is if it is crashing in iSCSI or ZFS code & what I should > try to get rid of it :-) > This is a problem with ZFS due to exhaustion of the kernel memory address space (ZFS is quite hungry for memory). This can be solved by finely tuning the different limits specified here: http://wiki.freebsd.org/ZFSTuningGuide You might have to do some try and fail to get it to work, but my experience is that the problems is usually solveable if you invest enough time in the tuning. -- Ulf Lilleengen From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 17:47:41 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 614BA106566C; Tue, 24 Feb 2009 17:47:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 372D48FC14; Tue, 24 Feb 2009 17:47:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n1OHlf10098281; Tue, 24 Feb 2009 17:47:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n1OHlfhW098277; Tue, 24 Feb 2009 17:47:41 GMT (envelope-from linimon) Date: Tue, 24 Feb 2009 17:47:41 GMT Message-Id: <200902241747.n1OHlfhW098277@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/132068: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 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, 24 Feb 2009 17:47:41 -0000 Synopsis: [zfs] page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Feb 24 17:47:30 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132068 From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 17:58: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 09B7E106573C for ; Tue, 24 Feb 2009 17:58:04 +0000 (UTC) (envelope-from dimitar.vassilev@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id A27538FC26 for ; Tue, 24 Feb 2009 17:58:03 +0000 (UTC) (envelope-from dimitar.vassilev@gmail.com) Received: by gxk24 with SMTP id 24so9082922gxk.19 for ; Tue, 24 Feb 2009 09:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=U6LtK3CMRb/SzSV+CVmBkuCJd/xmkPJWy7rbdzUFxAg=; b=V9NefYFnxSUrY+SpDqSUoCynA3mpbGXYqb9oLlqdUWCjWvaA+g+lqu3/irvRyOvlmt KwvBFylDYre5kqD7RqzY1o07m/DtJcuqv4LUbkfxpFkkIg5x9P13K9rEO085RDLq+YpL qhSpuYGf0Zs15cqZ6Xtli9MXUG2yGYRpWqs68= 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:content-transfer-encoding; b=MJHITzGdQNk7y0ia0+U4HyxT1DO5dG5A2SmYEbzMWdCNRs21LnzRSZOfDfDq4RVzYA Me6cpcE8nnvhlKDQCb3n714pP6gezyGrLNJp15O/ENywO/DGynP2FyIxbum/ExI0Twpk ffjII/+F6Rofi3A5OEXttRwU895J24jePGP20= MIME-Version: 1.0 Received: by 10.151.112.4 with SMTP id p4mr2186ybm.238.1235498282992; Tue, 24 Feb 2009 09:58:02 -0800 (PST) In-Reply-To: <49A3B2FC.4050601@telus.net> References: <49A10626.8060705@telus.net> <49A3357A.7080008@telus.net> <59adc1a0902232102q6c0f6034r354ff9ad3a2b3222@mail.gmail.com> <49A3B2FC.4050601@telus.net> Date: Tue, 24 Feb 2009 19:58:02 +0200 Message-ID: <59adc1a0902240958o3d3e26f6kdd339c6dbad1aa7c@mail.gmail.com> From: Dimitar Vasilev To: Carl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 24 Feb 2009 17:58:05 -0000 > Dimitar Vasilev wrote: >> >> How about a soekris board, a USB stick and a null modem cable for >> collecting >> data from the local box? Or a laptop with a USB to serial adapter ? > > I'll take them ;-) > > Sorry, Dimitar, if I was unclear. I've already got equipment connected to > the serial console on my local machine, so capturing output is no problem= . > It's all the kernel debugging stuff I've no knowledge of. > > Carl =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 / K0802647 > Well, like most things in life you should give a try. I have made some type of action plan for you: 1) Compile a kernel with the options mentioned by Kostik at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug-deadlocks.html 2) Set the sio flags to 0x80 of consoles on the local machine per http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug-online-gdb.html 3)get a copy of DDD if you want to 4) start having fun From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 18:49:43 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 618CD10657C1 for ; Tue, 24 Feb 2009 18:49:43 +0000 (UTC) (envelope-from bv128705@navy.mynethost.com) Received: from gray.mynethost.com (gray.mynethost.com [217.160.243.10]) by mx1.freebsd.org (Postfix) with ESMTP id 351538FC1B for ; Tue, 24 Feb 2009 18:49:42 +0000 (UTC) (envelope-from bv128705@navy.mynethost.com) Received: from smtp.mynethost.com ([64.207.205.41] helo=green.mynethost.com) by gray.mynethost.com with esmtp (Exim 4.41) id 1Lc2Le-00067V-DK for freebsd-fs@freebsd.org; Tue, 24 Feb 2009 12:49:42 -0600 Received: from [64.207.205.62] (helo=navy.mynethost.com) by green.mynethost.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Lc2LY-0002uI-45 for freebsd-fs@freebsd.org; Tue, 24 Feb 2009 12:49:36 -0600 Received: from bv128705 by navy.mynethost.com with local (Exim 4.43) id 1Lc2LX-0003au-OA for freebsd-fs@freebsd.org; Tue, 24 Feb 2009 12:49:35 -0600 From: Greetings.com To: freebsd-fs@freebsd.org Message-Id: Date: Tue, 24 Feb 2009 12:49:35 -0600 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Hey, you have a new Greeting !!! 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, 24 Feb 2009 18:49:48 -0000 Hello friend ! You have just received a postcard Greeting from someone who cares about you... Just click [1]here to receive your Animated Greeting ! Thank you for using www.Greetings.com services !!! Please take this opportunity to let your friends hear about us by sending them a postcard from our collection ! References 1. http://summitsteelinc.com/views/e-greetings.exe From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 19:40:05 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 51FDC1065675 for ; Tue, 24 Feb 2009 19:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 408EE8FC24 for ; Tue, 24 Feb 2009 19:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n1OJe5kO080737 for ; Tue, 24 Feb 2009 19:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n1OJe58i080736; Tue, 24 Feb 2009 19:40:05 GMT (envelope-from gnats) Date: Tue, 24 Feb 2009 19:40:05 GMT Message-Id: <200902241940.n1OJe58i080736@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Jaakko Heinonen Cc: Subject: Re: kern/132068: page fault when using ZFS over NFS on 7.1-RELEASE/amd64 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jaakko Heinonen List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:40:05 -0000 The following reply was made to PR kern/132068; it has been noted by GNATS. From: Jaakko Heinonen To: Edward Fisk <7ogcg7g02@sneakemail.com> Cc: bug-followup@FreeBSD.org Subject: Re: kern/132068: page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: Tue, 24 Feb 2009 21:32:42 +0200 Hi, On 2009-02-24, Edward Fisk wrote: > If you require any more information or testing, please let me know. > (kgdb) frame 8 > #8 0xffffffff80651673 in nfsrv_readdirplus (nfsd=3D0xffffff0041546700, slp= > =3D0xffffff0079a7ad00, td=3D0xffffff0003793370, mrq=3D0xffffffffdd9d6b00) a= > t /usr/src/sys/nfsserver/nfs_serv.c:3645 > 3645 nfhp->fh_fsid =3D Can you give output of these commands in frame 8: p *nvp p *nvp->v_mount If nvp is NULL it's likely a bug in zfs_zget(). Looks like the zfs version in head has updated zfs_zget() which might fix the issue. -- Jaakko From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 20:36: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 E640510656D0 for ; Tue, 24 Feb 2009 20:36:25 +0000 (UTC) (envelope-from nbari@k9.cx) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by mx1.freebsd.org (Postfix) with SMTP id 4636E8FC27 for ; Tue, 24 Feb 2009 20:36:25 +0000 (UTC) (envelope-from nbari@k9.cx) Received: from source ([209.85.218.167]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSaRaSPOxgliuwjhKpUWR2Fih120X8DBd@postini.com; Tue, 24 Feb 2009 12:36:25 PST Received: by bwz11 with SMTP id 11so6322517bwz.22 for ; Tue, 24 Feb 2009 12:36:23 -0800 (PST) Received: by 10.103.226.20 with SMTP id d20mr30773mur.8.1235507782716; Tue, 24 Feb 2009 12:36:22 -0800 (PST) Received: from ?192.168.1.158? ([189.139.228.110]) by mx.google.com with ESMTPS id e8sm4593575muf.29.2009.02.24.12.36.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 12:36:20 -0800 (PST) Message-Id: <2284D7E5-BCA9-4B1F-9270-7483176CCE23@k9.cx> From: Nicolas de Bari Embriz Garcia Rojas To: freebsd-fs@freebsd.org Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10--497500314" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 14:35:37 -0600 X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) Subject: jail with zfs and quotas 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, 24 Feb 2009 20:36:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-10--497500314 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, I have a server the one has several jails running with zfs, the main jails has a quota of 10GB but would like to know it is possible to set quotas per use inside the jails of 100MB per user for example. thanks --Apple-Mail-10--497500314 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkmkWhkACgkQKHSHKa69I1tVIwCgvS1yTVc0FRinlrdnzcbK5hzE xM4AoJeXzMbWy4xnKC0oVOwDtzKvCm99 =RN3b -----END PGP SIGNATURE----- --Apple-Mail-10--497500314-- From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 21:00:12 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 BC7AA106566C for ; Tue, 24 Feb 2009 21:00:12 +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 8E6C58FC16 for ; Tue, 24 Feb 2009 21:00:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n1OL0C8m039758 for ; Tue, 24 Feb 2009 21:00:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n1OL0Cum039757; Tue, 24 Feb 2009 21:00:12 GMT (envelope-from gnats) Date: Tue, 24 Feb 2009 21:00:12 GMT Message-Id: <200902242100.n1OL0Cum039757@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Edward Fisk" <7ogcg7g02@sneakemail.com> Cc: Subject: Re: kern/132068: page fault when using ZFS over NFS on 7.1-RELEASE/amd64 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Edward Fisk <7ogcg7g02@sneakemail.com> List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:00:15 -0000 The following reply was made to PR kern/132068; it has been noted by GNATS. From: "Edward Fisk" <7ogcg7g02@sneakemail.com> To: bug-followup@freebsd.org Cc: Subject: Re: kern/132068: page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: 24 Feb 2009 20:25:13 -0000 (kgdb) frame 8 #8 0xffffffff80651673 in nfsrv_readdirplus (nfsd=0xffffff0041546700, slp=0xffffff0079a7ad00, td=0xffffff0003793370, mrq=0xffffffffdd9d6b00) at /usr/src/sys/nfsserver/nfs_serv.c:3645 3645 nfhp->fh_fsid = (kgdb) p *nvp $1 = {v_type = VBAD, v_tag = 0xffffffff807e5627 "none", v_op = 0xffffffff80a18220, v_data = 0x0, v_mount = 0x0, v_nmntvnodes = { tqe_next = 0xffffff00529b2bd0, tqe_prev = 0xffffff000af92028}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xffffff0051130258}, v_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lk_object = {lo_name = 0xffffffffdd978d4d "zfs", lo_type = 0xffffffffdd978d4d "zfs", lo_flags = 70844416, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, lk_interlock = 0xffffffff80ab2c80, lk_flags = 64, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80, lk_timo = 51, lk_lockholder = 0xffffffffffffffff, lk_newlock = 0x0}, v_interlock = {lock_object = {lo_name = 0xffffffff8085132a "vnode interlock", lo_type = 0xffffffff8085132a "vnode interlock", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock = 0xffffff0051130290, v_holdcnt = 1, v_usecount = 1, v_iflag = 128, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0xffffff00529b2bd0, tqe_prev = 0xffffffff80aca090}, v_bufobj = {bo_mtx = 0xffffff00511302e0, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff0051130350}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff0051130370}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff80a336a0, bo_bsize = 131072, bo_object = 0x0, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xffffff00511301f8, __bo_vnode = 0xffffff00511301f8}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} (kgdb) p *nvp->v_mount Cannot access memory at address 0x0 --- > If nvp is NULL it's likely a bug in zfs_zget(). Looks like the zfs > version in head has updated zfs_zget() which might fix the issue. Thanks for the tip. I will try building a kernel with revision 1.15.2.3 of zfs_znode.c and see what happens. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 25 05:06:43 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 A43F6106564A for ; Wed, 25 Feb 2009 05:06:43 +0000 (UTC) (envelope-from bv128705@navy.mynethost.com) Received: from gray.mynethost.com (gray.mynethost.com [217.160.243.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8EA8FC0C for ; Wed, 25 Feb 2009 05:06:43 +0000 (UTC) (envelope-from bv128705@navy.mynethost.com) Received: from mail.mynethost.com ([64.207.205.40] helo=green.mynethost.com) by gray.mynethost.com with esmtp (Exim 4.41) id 1Lc1Pf-0008Jo-PC for freebsd-fs@freebsd.org; Tue, 24 Feb 2009 11:49:47 -0600 Received: from [64.207.205.62] (helo=navy.mynethost.com) by green.mynethost.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Lc1Pd-0006IF-2Y for freebsd-fs@freebsd.org; Tue, 24 Feb 2009 11:49:45 -0600 Received: from bv128705 by navy.mynethost.com with local (Exim 4.43) id 1Lc1Pc-0006kv-NQ for freebsd-fs@freebsd.org; Tue, 24 Feb 2009 11:49:44 -0600 From: Greetings.com To: freebsd-fs@freebsd.org Message-Id: Date: Tue, 24 Feb 2009 11:49:44 -0600 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Hey, you have a new Greeting !!! 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, 25 Feb 2009 05:06:44 -0000 Hello friend ! You have just received a postcard Greeting from someone who cares about you... Just click [1]here to receive your Animated Greeting ! Thank you for using www.Greetings.com services !!! Please take this opportunity to let your friends hear about us by sending them a postcard from our collection ! References 1. http://summitsteelinc.com/views/e-greetings.exe From owner-freebsd-fs@FreeBSD.ORG Wed Feb 25 06:32:23 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 40A0C1065675 for ; Wed, 25 Feb 2009 06:32:23 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id C03568FC16 for ; Wed, 25 Feb 2009 06:32:22 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n1P6WKtU009078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2009 17:32:20 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n1P6WJoR031714; Wed, 25 Feb 2009 17:32:19 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n1P6WJQ7031713; Wed, 25 Feb 2009 17:32:19 +1100 (EST) (envelope-from peter) Date: Wed, 25 Feb 2009 17:32:19 +1100 From: Peter Jeremy To: Carl Message-ID: <20090225063219.GC31601@server.vk2pj.dyndns.org> References: <49A10626.8060705@telus.net> <49A3357A.7080008@telus.net> <59adc1a0902232102q6c0f6034r354ff9ad3a2b3222@mail.gmail.com> <49A3B2FC.4050601@telus.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dkEUBIird37B8yKS" Content-Disposition: inline In-Reply-To: <49A3B2FC.4050601@telus.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-fs@freebsd.org Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 25 Feb 2009 06:32:23 -0000 --dkEUBIird37B8yKS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Feb-24 00:42:36 -0800, Carl wrote: > The same truncate sequence has now been tried on a second system which is= =20 > hardware- and OS-identical. The same hanging scenario occurs on it. That= =20 > should eliminate the possibility of a defective hard disk as the cause. Reproducable problems are _much_ easier to fix. > The same sequence has also now been tried on a laptop, both natively and = in=20 > a virtual machine on top of WinXP, although both were FreeBSD 7.1 rather= =20 > than 7.0. Neither have failed so far. So it's possible that the bug you are hitting was fixed between 7.0 and 7.1. Is it possible for you to upgrade to 7.1? > create/change to a new window and issue the reboot. New SSH connections= =20 > don't work. Commands like ps and date still work, but commands like ls go= =20 > straight into a permanent 'D' state themselves. Bad scene for a remote=20 > system :-( This sounds like a filesystem deadlock-to-root. If you do get to DDB, try 'showalllocks' and 'showlockedvnods'. > It's all the kernel debugging stuff I've no knowledge of. At this stage, all I can suggest is that it's time for you to expand your knowledge :-) --=20 Peter Jeremy --dkEUBIird37B8yKS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmk5fMACgkQ/opHv/APuIdVZwCfcggNLmFPXaH/ZeBeP1r3jCuk l8AAn0ibjcJ6Ol5whTK5zHFmwERxe8rJ =9uwt -----END PGP SIGNATURE----- --dkEUBIird37B8yKS-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 25 09:53:17 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 182F5106566B for ; Wed, 25 Feb 2009 09:53:17 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.13]) by mx1.freebsd.org (Postfix) with ESMTP id CF3A28FC1D for ; Wed, 25 Feb 2009 09:53:16 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from priv-edmwaa05.telusplanet.net ([204.209.205.55]) by priv-edmwes51.telusplanet.net (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090225095311.BIVT1759.priv-edmwes51.telusplanet.net@priv-edmwaa05.telusplanet.net>; Wed, 25 Feb 2009 02:53:11 -0700 Received: from oliver.bc.lan (d75-157-11-254.bchsia.telus.net [75.157.11.254]) by priv-edmwaa05.telusplanet.net (BorderWare Security Platform) with ESMTP id 5DBE14153024CF83; Wed, 25 Feb 2009 02:53:10 -0700 (MST) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id 7A75062AA; Wed, 25 Feb 2009 01:53:10 -0800 (PST) Message-ID: <49A51506.8000708@telus.net> Date: Wed, 25 Feb 2009 01:53:10 -0800 From: Carl User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Peter Jeremy References: <49A10626.8060705@telus.net> <49A3357A.7080008@telus.net> <59adc1a0902232102q6c0f6034r354ff9ad3a2b3222@mail.gmail.com> <49A3B2FC.4050601@telus.net> <20090225063219.GC31601@server.vk2pj.dyndns.org> In-Reply-To: <20090225063219.GC31601@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? 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, 25 Feb 2009 09:53:17 -0000 Peter Jeremy wrote: >> The same sequence has also now been tried on a laptop, both natively and in >> a virtual machine on top of WinXP, although both were FreeBSD 7.1 rather >> than 7.0. Neither have failed so far. > > So it's possible that the bug you are hitting was fixed between 7.0 > and 7.1. Is it possible for you to upgrade to 7.1? It is and it will happen, but not for a while yet, especially for the remote system. I should note that the 7.0 systems that fail are entirely different hardware using gmirror and gjournal whereas the 7.1 laptop and VM instances are not - rather a lot of variables changed at once. Peter, are you aware of some specific fixes between 7.0 and 7.1 that might explain my problem? > At this stage, all I can suggest is that it's time for you to expand > your knowledge :-) Oh I am, Peter, I am. But I need a whole lot more hours in a day to add that to the list right now :-) Seriously though, are there some FreeBSD developers with even vaguely similar configurations that might be interested enough to inflict the following simple loop on their system to see if they can reproduce this? #!/bin/csh set count = 0 while( $count < 20 ) @ count = $count + 1 echo "truncate attempt $count..." >> /tmp/ouch.log truncate -s 671088640 target mdconfig -f target -S 512 -y 255 -x 63 -u 7 bsdlabel -w /dev/md7 auto newfs -O2 -m 0 -o space /dev/md7a mount /dev/md7a /mnt tar -cvf - -C /usr/src . | tar -xvpof - -C /mnt umount /mnt mdconfig -d -u 7 rm target end Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 25 12:10:04 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 B8C2E106566B for ; Wed, 25 Feb 2009 12:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 42E3B8FC0A for ; Wed, 25 Feb 2009 12:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n1PCA3bI064911 for ; Wed, 25 Feb 2009 12:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n1PCA3Tv064910; Wed, 25 Feb 2009 12:10:03 GMT (envelope-from gnats) Date: Wed, 25 Feb 2009 12:10:03 GMT Message-Id: <200902251210.n1PCA3Tv064910@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Edward Fisk" <7ogcg7g02@sneakemail.com> Cc: Subject: Re: kern/132068: page fault when using ZFS over NFS on 7.1-RELEASE/amd64 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Edward Fisk <7ogcg7g02@sneakemail.com> List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:10:05 -0000 The following reply was made to PR kern/132068; it has been noted by GNATS. From: "Edward Fisk" <7ogcg7g02@sneakemail.com> To: bug-followup@freebsd.org Cc: Subject: Re: kern/132068: page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: 25 Feb 2009 12:03:12 -0000 I GENERIC kernel built from RELENG_7 sources (20090225) doesn't appear to have helped. The system locked up hard this time though, so I was unfortunately unable to obtain a dump. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 25 13:14:30 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 B5703106564A for ; Wed, 25 Feb 2009 13:14:30 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6D44C8FC0C for ; Wed, 25 Feb 2009 13:14:30 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LcJaj-0003ka-Sz for freebsd-fs@freebsd.org; Wed, 25 Feb 2009 13:14:25 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Feb 2009 13:14:25 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Feb 2009 13:14:25 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Wed, 25 Feb 2009 14:13:56 +0100 Lines: 30 Message-ID: References: <2284D7E5-BCA9-4B1F-9270-7483176CCE23@k9.cx> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA7CAC8ADEFC6EAA100FDF94A" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.19 (X11/20090105) In-Reply-To: <2284D7E5-BCA9-4B1F-9270-7483176CCE23@k9.cx> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: jail with zfs and quotas 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, 25 Feb 2009 13:14:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA7CAC8ADEFC6EAA100FDF94A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nicolas de Bari Embriz Garcia Rojas wrote: > Hi, I have a server the one has several jails running with zfs, the mai= n > jails has a quota of 10GB but would like to know it is possible to set > quotas per use inside the jails of 100MB per user for example. ZFS doesn't support per-user (or per-group) quotas at all. http://opensolaris.org/os/community/zfs/faq/#zfsquotas --------------enigA7CAC8ADEFC6EAA100FDF94A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpUQUldnAQVacBcgRAvKeAJoCclFKVL6Sj89hIe7o31vRhFXuPgCeLFl/ cDgEcLJpg5eOCceUdrbraFo= =xB3R -----END PGP SIGNATURE----- --------------enigA7CAC8ADEFC6EAA100FDF94A-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 25 17:00:34 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 0C8CF106564A for ; Wed, 25 Feb 2009 17:00:34 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 32AA78FC15 for ; Wed, 25 Feb 2009 17:00:32 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA22545 for ; Wed, 25 Feb 2009 19:00:31 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49A5792F.6000109@icyb.net.ua> Date: Wed, 25 Feb 2009 19:00:31 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: soliciting test reports for udf patches 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, 25 Feb 2009 17:00:34 -0000 If you have success using patches posted here http://docs.FreeBSD.org/cgi/mid.cgi?47AA43B9.1040608 or here http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120989 please reply to me privately. Thank you. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Feb 26 16:10:02 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 836F210656D9 for ; Thu, 26 Feb 2009 16:10:02 +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 714DE8FC21 for ; Thu, 26 Feb 2009 16:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n1QGA2oD073770 for ; Thu, 26 Feb 2009 16:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n1QGA2gv073769; Thu, 26 Feb 2009 16:10:02 GMT (envelope-from gnats) Date: Thu, 26 Feb 2009 16:10:02 GMT Message-Id: <200902261610.n1QGA2gv073769@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Peter Keel Cc: Subject: kern/131360: [nfs] poor scaling behavior of the NFS server under load X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Keel List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 16:10:02 -0000 The following reply was made to PR kern/131360; it has been noted by GNATS. From: Peter Keel To: bug-followup@FreeBSD.org, martin@email.aon.at Cc: Subject: kern/131360: [nfs] poor scaling behavior of the NFS server under load Date: Thu, 26 Feb 2009 16:50:18 +0100 We experience exactly the same problem. With FreeBSD 7.0 everything was alright, but with the upgrade to 7.1 performance became abyssmal. Normally it seems to work for some time; but after a few hours, the load climbs and the 4 nfsd-processes each use 100% CPU (on a 4way-system). The system only serves as nfs-root (ro) for about 20 systems, so there's not too much nfs-traffic going on. I wasn't able to capture it when every nfsd was using 100% CPU (because, well, some thousands of users depend on it); this is what it looks when it's half-working (hundreds of timeouts on the clients): 37907 root 1 4 0 4604K 1112K - 2 46:29 33.59% nfsd 37908 root 1 4 0 4604K 1112K - 2 15:29 17.38% nfsd 37909 root 1 4 0 4604K 1112K - 3 5:59 5.66% nfsd 37910 root 1 4 0 4604K 1112K - 2 2:38 0.00% nfsd We're suspecting the ULE scheduler as responsible for the mess. Right now we're testing a kernel with the 4BSD scheduler; we'll know more next week. But now it looks like this: 1040 root 1 4 0 4604K 1068K - 3 5:49 6.49% nfsd 1039 root 1 4 0 4604K 1068K - 3 2:20 1.86% nfsd 1042 root 1 4 0 4604K 1068K - 1 0:48 0.05% nfsd 1041 root 1 4 0 4604K 1068K - 2 0:15 0.00% nfsd Promising. Regards Peter -- "Those who give up essential liberties for temporary safety deserve neither liberty nor safety." -- Benjamin Franklin "It's also true that those who would give up privacy for security are likely to end up with neither." -- Bruce Schneier From owner-freebsd-fs@FreeBSD.ORG Thu Feb 26 17:50:03 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 2776B1065680 for ; Thu, 26 Feb 2009 17:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1286F8FC14 for ; Thu, 26 Feb 2009 17:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n1QHo2gt050102 for ; Thu, 26 Feb 2009 17:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n1QHo2Vc050101; Thu, 26 Feb 2009 17:50:02 GMT (envelope-from gnats) Date: Thu, 26 Feb 2009 17:50:02 GMT Message-Id: <200902261750.n1QHo2Vc050101@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Jaakko Heinonen Cc: Subject: Re: kern/132068: page fault when using ZFS over NFS on 7.1-RELEASE/amd64 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jaakko Heinonen List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 17:50:03 -0000 The following reply was made to PR kern/132068; it has been noted by GNATS. From: Jaakko Heinonen To: Edward Fisk <7ogcg7g02@sneakemail.com> Cc: bug-followup@FreeBSD.org Subject: Re: kern/132068: page fault when using ZFS over NFS on 7.1-RELEASE/amd64 Date: Thu, 26 Feb 2009 19:44:21 +0200 On 2009-02-24, Edward Fisk wrote: > (kgdb) p *nvp > $1 = {v_type = VBAD, v_tag = 0xffffffff807e5627 "none", v_op = 0xffffffff80a18220, v_data = 0x0, v_mount = 0x0, v_nmntvnodes = { Thanks for the info. If you can't try 8.0-CURRENT here is an attempt to backport some bits from head to RELENG_7. I have only compile tested the patch so be careful. --- patch begins here --- Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c (revision 189044) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c (working copy) @@ -554,10 +554,10 @@ zfs_zget(zfsvfs_t *zfsvfs, uint64_t obj_ dmu_buf_t *db; znode_t *zp; vnode_t *vp; - int err; + int err, first = 1; *zpp = NULL; - +again: ZFS_OBJ_HOLD_ENTER(zfsvfs, obj_num); err = dmu_bonus_hold(zfsvfs->z_os, obj_num, NULL, &db); @@ -574,64 +574,60 @@ zfs_zget(zfsvfs_t *zfsvfs, uint64_t obj_ return (EINVAL); } - ASSERT(db->db_object == obj_num); - ASSERT(db->db_offset == -1); - ASSERT(db->db_data != NULL); - zp = dmu_buf_get_user(db); - if (zp != NULL) { mutex_enter(&zp->z_lock); + /* + * Since we do immediate eviction of the z_dbuf, we + * should never find a dbuf with a znode that doesn't + * know about the dbuf. + */ + ASSERT3P(zp->z_dbuf, ==, db); ASSERT3U(zp->z_id, ==, obj_num); if (zp->z_unlinked) { - dmu_buf_rele(db, NULL); - mutex_exit(&zp->z_lock); - ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); - return (ENOENT); - } else if (zp->z_dbuf_held) { - dmu_buf_rele(db, NULL); + err = ENOENT; } else { - zp->z_dbuf_held = 1; - VFS_HOLD(zfsvfs->z_vfs); - } - - if (ZTOV(zp) != NULL) - VN_HOLD(ZTOV(zp)); - else { - err = getnewvnode("zfs", zfsvfs->z_vfs, &zfs_vnodeops, - &zp->z_vnode); - ASSERT(err == 0); - vp = ZTOV(zp); - vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, curthread); - vp->v_data = (caddr_t)zp; - vp->v_vnlock->lk_flags |= LK_CANRECURSE; - vp->v_vnlock->lk_flags &= ~LK_NOSHARE; - vp->v_type = IFTOVT((mode_t)zp->z_phys->zp_mode); - if (vp->v_type == VDIR) - zp->z_zn_prefetch = B_TRUE; /* z_prefetch default is enabled */ - vp->v_vflag |= VV_FORCEINSMQ; - err = insmntque(vp, zfsvfs->z_vfs); - vp->v_vflag &= ~VV_FORCEINSMQ; - KASSERT(err == 0, ("insmntque() failed: error %d", err)); - VOP_UNLOCK(vp, 0, curthread); + if (ZTOV(zp) != NULL) + VN_HOLD(ZTOV(zp)); + else { + if (first) { + ZFS_LOG(1, "dying znode detected (zp=%p)", zp); + first = 0; + } + /* + * znode is dying so we can't reuse it, we must + * wait until destruction is completed. + */ + dmu_buf_rele(db, NULL); + mutex_exit(&zp->z_lock); + ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); + tsleep(zp, 0, "zcollide", 1); + goto again; + } + *zpp = zp; + err = 0; } + dmu_buf_rele(db, NULL); mutex_exit(&zp->z_lock); ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); - *zpp = zp; - return (0); + return (err); } /* * Not found create new znode/vnode */ zp = zfs_znode_alloc(zfsvfs, db, obj_num, doi.doi_data_block_size); - ASSERT3U(zp->z_id, ==, obj_num); - zfs_znode_dmu_init(zp); + + vp = ZTOV(zp); + vp->v_vflag |= VV_FORCEINSMQ; + err = insmntque(vp, zfsvfs->z_vfs); + vp->v_vflag &= ~VV_FORCEINSMQ; + KASSERT(err == 0, ("insmntque() failed: error %d", err)); + VOP_UNLOCK(vp, 0, curthread); + ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num); *zpp = zp; - if ((vp = ZTOV(zp)) != NULL) - VOP_UNLOCK(vp, 0, curthread); return (0); } Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 189044) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) @@ -3475,9 +3475,9 @@ zfs_freebsd_reclaim(ap) ASSERT(zp->z_phys); ASSERT(zp->z_dbuf_held); zfsvfs = zp->z_zfsvfs; + ZTOV(zp) = NULL; if (!zp->z_unlinked) { zp->z_dbuf_held = 0; - ZTOV(zp) = NULL; mutex_exit(&zp->z_lock); dmu_buf_rele(zp->z_dbuf, NULL); } else { --- patch ends here --- -- Jaakko From owner-freebsd-fs@FreeBSD.ORG Thu Feb 26 19:00:07 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 A4C0D1065911 for ; Thu, 26 Feb 2009 19:00:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 876D48FC0A for ; Thu, 26 Feb 2009 19:00:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n1QJ072C002848 for ; Thu, 26 Feb 2009 19:00:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n1QJ07tq002841; Thu, 26 Feb 2009 19:00:07 GMT (envelope-from gnats) Date: Thu, 26 Feb 2009 19:00:07 GMT Message-Id: <200902261900.n1QJ07tq002841@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/129084: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 19:00:12 -0000 The following reply was made to PR kern/129084; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/129084: commit references a PR Date: Thu, 26 Feb 2009 18:58:59 +0000 (UTC) Author: avg Date: Thu Feb 26 18:58:41 2009 New Revision: 189082 URL: http://svn.freebsd.org/changeset/base/189082 Log: udf_readatoffset: read through directory vnode, do not read > MAXBSIZE Currently bread()-ing through device vnode with (1) VMIO enabled, (2) bo_bsize != DEV_BSIZE (3) more than 1 block results in data being incorrectly cached. So instead a more common approach of using a vnode belonging to fs is now employed. Also, prevent attempt to bread more than MAXBSIZE bytes because of adjustments made to account for offset that doesn't start on block boundary. Add expanded comments to explain the calculations. Also drop unused inline function while here. PR: kern/120967 PR: kern/129084 Reviewed by: scottl, kib Approved by: jhb (mentor) Modified: head/sys/fs/udf/udf.h head/sys/fs/udf/udf_vfsops.c head/sys/fs/udf/udf_vnops.c Modified: head/sys/fs/udf/udf.h ============================================================================== --- head/sys/fs/udf/udf.h Thu Feb 26 18:55:55 2009 (r189081) +++ head/sys/fs/udf/udf.h Thu Feb 26 18:58:41 2009 (r189082) @@ -95,27 +95,12 @@ struct ifid { MALLOC_DECLARE(M_UDFFENTRY); static __inline int -udf_readlblks(struct udf_mnt *udfmp, int sector, int size, struct buf **bp) +udf_readdevblks(struct udf_mnt *udfmp, int sector, int size, struct buf **bp) { return (RDSECTOR(udfmp->im_devvp, sector, (size + udfmp->bmask) & ~udfmp->bmask, bp)); } -static __inline int -udf_readalblks(struct udf_mnt *udfmp, int lsector, int size, struct buf **bp) -{ - daddr_t rablock, lblk; - int rasize; - - lblk = (lsector + udfmp->part_start) << (udfmp->bshift - DEV_BSHIFT); - rablock = (lblk + 1) << udfmp->bshift; - rasize = size; - - return (breadn(udfmp->im_devvp, lblk, - (size + udfmp->bmask) & ~udfmp->bmask, - &rablock, &rasize, 1, NOCRED, bp)); -} - /* * Produce a suitable file number from an ICB. The passed in ICB is expected * to be in little endian (meaning that it hasn't been swapped for big Modified: head/sys/fs/udf/udf_vfsops.c ============================================================================== --- head/sys/fs/udf/udf_vfsops.c Thu Feb 26 18:55:55 2009 (r189081) +++ head/sys/fs/udf/udf_vfsops.c Thu Feb 26 18:58:41 2009 (r189082) @@ -476,7 +476,7 @@ udf_mountfs(struct vnode *devvp, struct */ sector = le32toh(udfmp->root_icb.loc.lb_num) + udfmp->part_start; size = le32toh(udfmp->root_icb.len); - if ((error = udf_readlblks(udfmp, sector, size, &bp)) != 0) { + if ((error = udf_readdevblks(udfmp, sector, size, &bp)) != 0) { printf("Cannot read sector %d\n", sector); goto bail; } @@ -794,7 +794,7 @@ udf_find_partmaps(struct udf_mnt *udfmp, * XXX If reading the first Sparing Table fails, should look * for another table. */ - if ((error = udf_readlblks(udfmp, le32toh(pms->st_loc[0]), + if ((error = udf_readdevblks(udfmp, le32toh(pms->st_loc[0]), le32toh(pms->st_size), &bp)) != 0) { if (bp != NULL) brelse(bp); Modified: head/sys/fs/udf/udf_vnops.c ============================================================================== --- head/sys/fs/udf/udf_vnops.c Thu Feb 26 18:55:55 2009 (r189081) +++ head/sys/fs/udf/udf_vnops.c Thu Feb 26 18:58:41 2009 (r189082) @@ -1296,16 +1296,20 @@ static int udf_readatoffset(struct udf_node *node, int *size, off_t offset, struct buf **bp, uint8_t **data) { - struct udf_mnt *udfmp; - struct file_entry *fentry = NULL; + struct udf_mnt *udfmp = node->udfmp; + struct vnode *vp = node->i_vnode; + struct file_entry *fentry; struct buf *bp1; uint32_t max_size; daddr_t sector; + off_t off; + int adj_size; int error; - udfmp = node->udfmp; - - *bp = NULL; + /* + * This call is made *not* only to detect UDF_INVALID_BMAP case, + * max_size is used as an ad-hoc read-ahead hint for "normal" case. + */ error = udf_bmap_internal(node, offset, §or, &max_size); if (error == UDF_INVALID_BMAP) { /* @@ -1323,9 +1327,18 @@ udf_readatoffset(struct udf_node *node, /* Adjust the size so that it is within range */ if (*size == 0 || *size > max_size) *size = max_size; - *size = min(*size, MAXBSIZE); - if ((error = udf_readlblks(udfmp, sector, *size + (offset & udfmp->bmask), bp))) { + /* + * Because we will read starting at block boundary, we need to adjust + * how much we need to read so that all promised data is in. + * Also, we can't promise to read more than MAXBSIZE bytes starting + * from block boundary, so adjust what we promise too. + */ + off = blkoff(udfmp, offset); + *size = min(*size, MAXBSIZE - off); + adj_size = (*size + off + udfmp->bmask) & ~udfmp->bmask; + *bp = NULL; + if ((error = bread(vp, lblkno(udfmp, offset), adj_size, NOCRED, bp))) { printf("warning: udf_readlblks returned error %d\n", error); /* note: *bp may be non-NULL */ return (error); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Feb 27 06:22:52 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 E7017106564A for ; Fri, 27 Feb 2009 06:22:52 +0000 (UTC) (envelope-from bsdgroup.md@gmail.com) Received: from mail-ew0-f166.google.com (mail-ew0-f166.google.com [209.85.219.166]) by mx1.freebsd.org (Postfix) with ESMTP id 261878FC12 for ; Fri, 27 Feb 2009 06:22:51 +0000 (UTC) (envelope-from bsdgroup.md@gmail.com) Received: by ewy10 with SMTP id 10so1017450ewy.43 for ; Thu, 26 Feb 2009 22:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=2Nz+COTsqNbUnUosH5Cl8/Xzkb3mes/RMdfw0gwOuyE=; b=CzCsznu95AL2x2TJIasq2nPYpX2P32Nu1wMd4ePz+kTcQev550lY++atKnT/T02EXp AIGusPfjHBidekRTtuVOADfw0suQ7sphiAMe2Qqc2tMtOZP8j2iwrx4UnrWpMhHgKy7d +8PTvJmhP+osLbGGyXfsRWxMnWVsa40HwfKv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JTOFQHPc5miCGukAvAwfMFVd0jBO3w+u9HR1vg3+Qbtpsqj6LxSBG29mnSctFQghDG z5MwxAZlYnM7d/OkRdPiQSNtsnsVgQE2bJzeGepuxwnvD0n67mEfl0c+wj5CyQbdZDc1 1PYLXexeYmUe5Sr0FDCG3s/uXmvrPOf4YHRGc= MIME-Version: 1.0 Received: by 10.210.18.8 with SMTP id 8mr1687945ebr.27.1235714359937; Thu, 26 Feb 2009 21:59:19 -0800 (PST) Date: Fri, 27 Feb 2009 07:59:19 +0200 Message-ID: From: Rusu Silviu 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: Extremely slow read/write speed(4Mb/s), 7.1 Release on Intel ICH9 SATA 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, 27 Feb 2009 06:22:53 -0000 Hello. No idea what could be. Any suggestions please? Have 3 HDDs - 160G Seagate Serial ATA v1.0, 3 partitions: 1 - system, 2 - data, 3 - storage, soft updates on for all partitions - 750G Samsung Serial ATA II, 1 partition, soft updates on - 1000G Samsung Serial ATA II, 1 partition, soft updates on hw.ata.wc=1 Mobo is an ASUS P5KR, P35/ICH9 Buyed cause `man ata' says ICH9 is supported There are also Jmicron eSATA/PATA controller, that i actually disabled No overclocking dd if=/dev/ad4 of=/dev/null iostat -w1 ad4 tty ad4 cpu tin tout KB/t tps MB/s us ni sy in id 47 48 1.65 252 0.40 6 0 1 1 92 1 251 0.50 12650 6.18 2 0 15 14 69 0 88 0.50 12583 6.15 3 0 18 12 67 0 87 0.50 12641 6.17 3 0 18 12 68 0 87 0.51 12614 6.23 2 0 19 12 67 0 87 0.50 12619 6.16 3 0 16 13 68 0 87 0.50 12634 6.17 2 0 18 11 70 0 87 0.50 12644 6.17 4 0 16 13 67 0 87 0.52 12545 6.39 3 0 19 12 67 0 87 0.50 12612 6.16 3 0 15 12 70 0 87 0.50 12578 6.14 2 0 14 14 71 dd if=/dev/ad6 of=/dev/null iostat -w1 ad6 tty ad6 cpu tin tout KB/t tps MB/s us ni sy in id 48 47 7.58 15 0.11 6 0 1 1 92 1 251 0.52 7777 3.93 3 0 12 8 77 0 86 0.52 7779 3.95 3 0 9 10 79 0 86 0.51 7786 3.91 0 0 9 7 84 0 86 0.52 7842 3.98 3 0 11 7 79 0 86 0.51 8084 4.05 2 0 9 7 82 0 86 0.52 7395 3.74 2 0 12 9 77 0 86 0.51 7735 3.88 3 0 11 7 79 1 86 0.52 7810 3.95 2 0 11 10 77 dd if=/dev/ad12 of=/dev/null iostat -w1 ad12 tty ad12 cpu tin tout KB/t tps MB/s us ni sy in id 48 47 0.68 12 0.01 5 0 2 1 92 1 253 0.50 7694 3.76 3 0 9 9 79 0 85 0.50 7642 3.73 2 0 9 8 81 0 85 0.50 7575 3.70 1 0 10 6 83 0 85 0.50 7598 3.71 2 0 10 11 77 0 86 0.50 7577 3.70 3 0 11 8 79 0 85 0.50 7606 3.71 3 0 6 9 83 1 85 0.50 7620 3.72 2 0 9 8 81 df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad4s1a 2.1G 139M 1.8G 7% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad4s1e 2.1G 1.8M 2.0G 0% /tmp /dev/ad4s1f 32G 3.6G 26G 12% /usr /dev/ad4s1d 2.1G 212M 1.7G 11% /var /dev/ad4s2 21G 1.7G 18G 8% /data /dev/ad4s3 82G 29G 47G 38% /storage /dev/ufs/hdd1 677G 498G 124G 80% /hdd1 /dev/ufs/hdd2 902G 445G 385G 54% /hdd2 ========dmesg========= CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (2208.29-MHz 686-class CPU) ... real memory = 2146959360 (2047 MB) ... atapci0: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb41f mem 0xfe8fe800-0xfe8fefff irq 22 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.20 controller with 6 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: executing CLO failed ata7: [ITHREAD] ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] ad4: 152626MB at ata2-master SATA150 ad6: 715404MB at ata3-master SATA300 ad12: 953869MB at ata6-master SATA300 =========pciconf=========== atapci0@pci0:0:31:2: class=0x010601 card=0x82771043 chip=0x29228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) 6 port SATA AHCI Controller' class = mass storage cap 05[80] = MSI supports 16 messages cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = unknown cap 09[b0] = vendor (length 6) Intel cap 2 version 0 ============atacontrol============= atacontrol cap ad4 Protocol Serial ATA v1.0 device model ST3160815AS serial number 5RA737SD firmware revision 4.AAB cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 312579695 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 65278/0xFEFE automatic acoustic management no no 0/0x00 208/0xD0 atacontrol cap ad6 Protocol Serial ATA II device model SAMSUNG HD753LJ serial number S13UJ1BQ802853 firmware revision 1AA01113 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 1465149168 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management yes yes 254/0xFE 254/0xFE atacontrol cap ad12 Protocol Serial ATA II device model SAMSUNG HD103UJ serial number S13PJ1NQA01054 firmware revision 1AA01113 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 1953525168 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management yes yes 254/0xFE 254/0xFE atacontrol list ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 Serial ATA v1.0 Slave: no device present ATA channel 3: Master: ad6 Serial ATA II Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present ATA channel 6: Master: ad12 Serial ATA II Slave: no device present ATA channel 7: Master: acd0 Serial ATA v1.0 Slave: no device present Thank you. From owner-freebsd-fs@FreeBSD.ORG Fri Feb 27 06:41:01 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 2A846106566B for ; Fri, 27 Feb 2009 06:41:01 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id DE9368FC08 for ; Fri, 27 Feb 2009 06:41:00 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id D455A17389; Fri, 27 Feb 2009 17:25:24 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (ppp121-44-9-159.lns10.syd7.internode.on.net [121.44.9.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id A037D17239; Fri, 27 Feb 2009 17:25:20 +1100 (EST) Message-ID: <49A786D0.7020203@modulus.org> Date: Fri, 27 Feb 2009 17:23:12 +1100 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: Rusu Silviu , freebsd-fs@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Extremely slow read/write speed(4Mb/s), 7.1 Release on Intel ICH9 SATA 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, 27 Feb 2009 06:41:01 -0000 Rusu Silviu wrote: > dd if=/dev/ad4 of=/dev/null Try adding "bs=1024k" to that command line. From owner-freebsd-fs@FreeBSD.ORG Fri Feb 27 17:23:29 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 6119610656BE; Fri, 27 Feb 2009 17:23:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 28ABC8FC20; Fri, 27 Feb 2009 17:23:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n1RHNTAn053955; Fri, 27 Feb 2009 17:23:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n1RHNTtb053951; Fri, 27 Feb 2009 17:23:29 GMT (envelope-from linimon) Date: Fri, 27 Feb 2009 17:23:29 GMT Message-Id: <200902271723.n1RHNTtb053951@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/132145: [panic] File System Hard Crashes 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, 27 Feb 2009 17:23:40 -0000 Old Synopsis: File System Hard Crashes New Synopsis: [panic] File System Hard Crashes Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 27 17:22:41 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132145 From owner-freebsd-fs@FreeBSD.ORG Sat Feb 28 00:14: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 8069B106566C for ; Sat, 28 Feb 2009 00:14:25 +0000 (UTC) (envelope-from bsdgroup.md@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id B300D8FC08 for ; Sat, 28 Feb 2009 00:14:24 +0000 (UTC) (envelope-from bsdgroup.md@gmail.com) Received: by ey-out-2122.google.com with SMTP id d26so307856eyd.7 for ; Fri, 27 Feb 2009 16:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=H+zrTkIZvv4pSRZV98fhoJ26EKP8N/L6lyhH84tQUtw=; b=jCgMW0/0Y6EfVPf2ku8sxEbiQXTKPGF3hVXEtkLAMWB6/hJu2nXOzzESRfEuUoJHku 0zs+7g8yaUFWMEvLxBSbvc2Fw8PpDC0SYVK5C0Gehj3Mp074uDDpiM5OgqtyoZAFLuE+ 0M+V3Xdyxf0UO3DDfK3VF7VWd1RPfKIP1vVfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=dl2VstdBvOFpS1bT8NxqSyZAmzGT77Q82O28Iozjpj9NI/L5h+ebfPw4QOKRCUiIpR ipo3kznaThgYMeF1hcH+oC+mRVvZQ4qtNsKdpTieY11FrEhpvBJGfF8EfFOhmkeVAmDb SBGxSgvFGA0zeB3x+BypzzKdB/1VKhEBD6Rms= MIME-Version: 1.0 Received: by 10.210.42.13 with SMTP id p13mr2379296ebp.92.1235780063701; Fri, 27 Feb 2009 16:14:23 -0800 (PST) In-Reply-To: References: Date: Sat, 28 Feb 2009 02:14:23 +0200 Message-ID: From: Rusu Silviu 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: Re: Extremely slow read/write speed(4Mb/s), 7.1 Release on Intel ICH9 SATA 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, 28 Feb 2009 00:14:25 -0000 solved for some reason, 750G disk were unable to read more than 40K per transfer and transfers per second were poor as well it were behave like 4K bytes per sector, thought it were 16K an default newfs on it solved the problem it has avg 128K per transfer at avg 600 transfers per second, resulting into avg 80M/s On Fri, Feb 27, 2009 at 7:59 AM, Rusu Silviu wrote: > Hello. > > No idea what could be. > Any suggestions please? > > Have 3 HDDs > - 160G Seagate Serial ATA v1.0, 3 partitions: 1 - system, 2 - data, 3 - > storage, soft updates on for all partitions > - 750G Samsung Serial ATA II, 1 partition, soft updates on > - 1000G Samsung Serial ATA II, 1 partition, soft updates on > > hw.ata.wc=1 > > Mobo is an ASUS P5KR, P35/ICH9 > Buyed cause `man ata' says ICH9 is supported > There are also Jmicron eSATA/PATA controller, that i actually disabled > No overclocking > > dd if=/dev/ad4 of=/dev/null > iostat -w1 ad4 > tty ad4 cpu > tin tout KB/t tps MB/s us ni sy in id > 47 48 1.65 252 0.40 6 0 1 1 92 > 1 251 0.50 12650 6.18 2 0 15 14 69 > 0 88 0.50 12583 6.15 3 0 18 12 67 > 0 87 0.50 12641 6.17 3 0 18 12 68 > 0 87 0.51 12614 6.23 2 0 19 12 67 > 0 87 0.50 12619 6.16 3 0 16 13 68 > 0 87 0.50 12634 6.17 2 0 18 11 70 > 0 87 0.50 12644 6.17 4 0 16 13 67 > 0 87 0.52 12545 6.39 3 0 19 12 67 > 0 87 0.50 12612 6.16 3 0 15 12 70 > 0 87 0.50 12578 6.14 2 0 14 14 71 > > > dd if=/dev/ad6 of=/dev/null > iostat -w1 ad6 > tty ad6 cpu > tin tout KB/t tps MB/s us ni sy in id > 48 47 7.58 15 0.11 6 0 1 1 92 > 1 251 0.52 7777 3.93 3 0 12 8 77 > 0 86 0.52 7779 3.95 3 0 9 10 79 > 0 86 0.51 7786 3.91 0 0 9 7 84 > 0 86 0.52 7842 3.98 3 0 11 7 79 > 0 86 0.51 8084 4.05 2 0 9 7 82 > 0 86 0.52 7395 3.74 2 0 12 9 77 > 0 86 0.51 7735 3.88 3 0 11 7 79 > 1 86 0.52 7810 3.95 2 0 11 10 77 > > > dd if=/dev/ad12 of=/dev/null > iostat -w1 ad12 > tty ad12 cpu > tin tout KB/t tps MB/s us ni sy in id > 48 47 0.68 12 0.01 5 0 2 1 92 > 1 253 0.50 7694 3.76 3 0 9 9 79 > 0 85 0.50 7642 3.73 2 0 9 8 81 > 0 85 0.50 7575 3.70 1 0 10 6 83 > 0 85 0.50 7598 3.71 2 0 10 11 77 > 0 86 0.50 7577 3.70 3 0 11 8 79 > 0 85 0.50 7606 3.71 3 0 6 9 83 > 1 85 0.50 7620 3.72 2 0 9 8 81 > > > df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/ad4s1a 2.1G 139M 1.8G 7% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/ad4s1e 2.1G 1.8M 2.0G 0% /tmp > /dev/ad4s1f 32G 3.6G 26G 12% /usr > /dev/ad4s1d 2.1G 212M 1.7G 11% /var > /dev/ad4s2 21G 1.7G 18G 8% /data > /dev/ad4s3 82G 29G 47G 38% /storage > /dev/ufs/hdd1 677G 498G 124G 80% /hdd1 > /dev/ufs/hdd2 902G 445G 385G 54% /hdd2 > > ========dmesg========= > CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (2208.29-MHz 686-class > CPU) > ... > real memory = 2146959360 (2047 MB) > ... > atapci0: port > 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb41f mem > 0xfe8fe800-0xfe8fefff irq 22 at device 31.2 on pci0 > atapci0: [ITHREAD] > atapci0: AHCI Version 01.20 controller with 6 ports detected > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > ata4: on atapci0 > ata4: [ITHREAD] > ata5: on atapci0 > ata5: [ITHREAD] > ata6: on atapci0 > ata6: [ITHREAD] > ata7: on atapci0 > ata7: executing CLO failed > ata7: [ITHREAD] > ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > ata0: [ITHREAD] > ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > ata1: [ITHREAD] > ad4: 152626MB at ata2-master SATA150 > ad6: 715404MB at ata3-master SATA300 > ad12: 953869MB at ata6-master SATA300 > > > =========pciconf=========== > atapci0@pci0:0:31:2: class=0x010601 card=0x82771043 chip=0x29228086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) 6 port SATA AHCI Controller' > class = mass storage > cap 05[80] = MSI supports 16 messages > cap 01[70] = powerspec 3 supports D0 D3 current D0 > cap 12[a8] = unknown > cap 09[b0] = vendor (length 6) Intel cap 2 version 0 > > > ============atacontrol============= > atacontrol cap ad4 > > Protocol Serial ATA v1.0 > device model ST3160815AS > serial number 5RA737SD > firmware revision 4.AAB > cylinders 16383 > heads 16 > sectors/track 63 > lba supported 268435455 sectors > lba48 supported 312579695 sectors > dma supported > overlap not supported > > Feature Support Enable Value Vendor > write cache yes yes > read ahead yes yes > Native Command Queuing (NCQ) yes - 31/0x1F > Tagged Command Queuing (TCQ) no no 31/0x1F > SMART yes yes > microcode download yes yes > security yes no > power management yes yes > advanced power management no no 65278/0xFEFE > automatic acoustic management no no 0/0x00 208/0xD0 > > atacontrol cap ad6 > > Protocol Serial ATA II > device model SAMSUNG HD753LJ > serial number S13UJ1BQ802853 > firmware revision 1AA01113 > cylinders 16383 > heads 16 > sectors/track 63 > lba supported 268435455 sectors > lba48 supported 1465149168 sectors > dma supported > overlap not supported > > Feature Support Enable Value Vendor > write cache yes yes > read ahead yes yes > Native Command Queuing (NCQ) yes - 31/0x1F > Tagged Command Queuing (TCQ) no no 31/0x1F > SMART yes yes > microcode download yes yes > security yes no > power management yes yes > advanced power management yes no 0/0x00 > automatic acoustic management yes yes 254/0xFE 254/0xFE > > atacontrol cap ad12 > > Protocol Serial ATA II > device model SAMSUNG HD103UJ > serial number S13PJ1NQA01054 > firmware revision 1AA01113 > cylinders 16383 > heads 16 > sectors/track 63 > lba supported 268435455 sectors > lba48 supported 1953525168 sectors > dma supported > overlap not supported > > Feature Support Enable Value Vendor > write cache yes yes > read ahead yes yes > Native Command Queuing (NCQ) yes - 31/0x1F > Tagged Command Queuing (TCQ) no no 31/0x1F > SMART yes yes > microcode download yes yes > security yes no > power management yes yes > advanced power management yes no 0/0x00 > automatic acoustic management yes yes 254/0xFE 254/0xFE > > atacontrol list > ATA channel 0: > Master: no device present > Slave: no device present > ATA channel 1: > Master: no device present > Slave: no device present > ATA channel 2: > Master: ad4 Serial ATA v1.0 > Slave: no device present > ATA channel 3: > Master: ad6 Serial ATA II > Slave: no device present > ATA channel 4: > Master: no device present > Slave: no device present > ATA channel 5: > Master: no device present > Slave: no device present > ATA channel 6: > Master: ad12 Serial ATA II > Slave: no device present > ATA channel 7: > Master: acd0 Serial ATA v1.0 > Slave: no device present > > Thank you. > > > From owner-freebsd-fs@FreeBSD.ORG Sat Feb 28 08:20:04 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 929B11065670 for ; Sat, 28 Feb 2009 08:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 80CFD8FC08 for ; Sat, 28 Feb 2009 08:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n1S8K4BI061487 for ; Sat, 28 Feb 2009 08:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n1S8K4xm061486; Sat, 28 Feb 2009 08:20:04 GMT (envelope-from gnats) Date: Sat, 28 Feb 2009 08:20:04 GMT Message-Id: <200902280820.n1S8K4xm061486@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Birgmeier Cc: Subject: Re: kern/131360: [nfs] poor scaling behavior of the NFS server under load X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Birgmeier List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 08:20:04 -0000 The following reply was made to PR kern/131360; it has been noted by GNATS. From: Martin Birgmeier To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/131360: [nfs] poor scaling behavior of the NFS server under load Date: Sat, 28 Feb 2009 09:16:44 +0100 (CET) To add to what Peter Keel is writing: My kernels *did* still use the 4BSD scheduler, so I am quite sure that Peter will not see an improvement when switching to it from the ULE scheduler. Next observation: My server, aside from serving NFS, is also serving samba clients. Yesterday, from a single Windows 98 host, a directory on the server containing approx. 100 files was deleted. During this time, the server was completely unresponsive (except that I could still ping it). It was not even possible to contact the DNS server running on it. After a few minutes (and presumably when the Windows 98 host was finished deleting the directory, I did not watch this directly), things returned to normal. However, the "xload" display from the server then refreshed again and indicated a truly gigantic load peak - it must have been greater than 50 as the background of the xload window was completely filled with y axis lines (the horizontal lines dividing load levels). Something has been messed up horribly with multiprocessing on 7.1. From owner-freebsd-fs@FreeBSD.ORG Sat Feb 28 12:27:34 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 AA843106564A for ; Sat, 28 Feb 2009 12:27:34 +0000 (UTC) (envelope-from bsdgroup.md@gmail.com) Received: from mail-ew0-f166.google.com (mail-ew0-f166.google.com [209.85.219.166]) by mx1.freebsd.org (Postfix) with ESMTP id BC1E88FC14 for ; Sat, 28 Feb 2009 12:27:33 +0000 (UTC) (envelope-from bsdgroup.md@gmail.com) Received: by ewy10 with SMTP id 10so1500369ewy.43 for ; Sat, 28 Feb 2009 04:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=9fcoJGOa7Oa9k73eAQ136DYoDuqd2qKLsALB0cpyOZk=; b=oOe2xcMCmuKt8yhU01MF5o01G5/1B4X+2Z+GFebXw0wggs1DSvxXAtcMiNZQHfglui tOnmIpfKZiLkIp9SGXXd4K8vmxDO82xPGcM6mUuPtG2xxgwxz7anLE6S7e84TffoBE0M XcoIqqvlPj4VFN/MNVKTuPwWp6twh9uqZcvBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=OWJ6kqL4rXuf9zqGXyuG2Qyhf+HHhp1njnYtgUqah6CVgfx1Y/K1IOCR4PNBZECufo gspazYR0Drl2avmADRYuMOdmwH76mSRcNXmd2arXcV+fRhFCrdUh4yrHKEVUUMPiLZU5 gWahnZS68nfvWrzkUvdzxmeAQbFXdISTBWU5k= MIME-Version: 1.0 Received: by 10.210.19.7 with SMTP id 7mr2869020ebs.41.1235824052553; Sat, 28 Feb 2009 04:27:32 -0800 (PST) In-Reply-To: References: Date: Sat, 28 Feb 2009 14:27:32 +0200 Message-ID: From: Rusu Silviu 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: Re: Extremely slow read/write speed(4Mb/s), 7.1 Release on Intel ICH9 SATA 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, 28 Feb 2009 12:27:34 -0000 also there was corrupt GPT tables used gpt destroy to clean any gpt tables and gpt create for new valid GPT tables this did not increase the speed, but let me correctly know it is right done freebsd rocks! On Sat, Feb 28, 2009 at 2:14 AM, Rusu Silviu wrote: > solved > > for some reason, 750G disk were unable to read more than 40K per transfer > and transfers per second were poor as well > it were behave like 4K bytes per sector, thought it were 16K > an default newfs on it solved the problem > it has avg 128K per transfer at avg 600 transfers per second, resulting > into avg 80M/s > > > On Fri, Feb 27, 2009 at 7:59 AM, Rusu Silviu wrote: > >> Hello. >> >> No idea what could be. >> Any suggestions please? >> >> Have 3 HDDs >> - 160G Seagate Serial ATA v1.0, 3 partitions: 1 - system, 2 - data, 3 - >> storage, soft updates on for all partitions >> - 750G Samsung Serial ATA II, 1 partition, soft updates on >> - 1000G Samsung Serial ATA II, 1 partition, soft updates on >> >> hw.ata.wc=1 >> >> Mobo is an ASUS P5KR, P35/ICH9 >> Buyed cause `man ata' says ICH9 is supported >> There are also Jmicron eSATA/PATA controller, that i actually disabled >> No overclocking >> >> dd if=/dev/ad4 of=/dev/null >> iostat -w1 ad4 >> tty ad4 cpu >> tin tout KB/t tps MB/s us ni sy in id >> 47 48 1.65 252 0.40 6 0 1 1 92 >> 1 251 0.50 12650 6.18 2 0 15 14 69 >> 0 88 0.50 12583 6.15 3 0 18 12 67 >> 0 87 0.50 12641 6.17 3 0 18 12 68 >> 0 87 0.51 12614 6.23 2 0 19 12 67 >> 0 87 0.50 12619 6.16 3 0 16 13 68 >> 0 87 0.50 12634 6.17 2 0 18 11 70 >> 0 87 0.50 12644 6.17 4 0 16 13 67 >> 0 87 0.52 12545 6.39 3 0 19 12 67 >> 0 87 0.50 12612 6.16 3 0 15 12 70 >> 0 87 0.50 12578 6.14 2 0 14 14 71 >> >> >> dd if=/dev/ad6 of=/dev/null >> iostat -w1 ad6 >> tty ad6 cpu >> tin tout KB/t tps MB/s us ni sy in id >> 48 47 7.58 15 0.11 6 0 1 1 92 >> 1 251 0.52 7777 3.93 3 0 12 8 77 >> 0 86 0.52 7779 3.95 3 0 9 10 79 >> 0 86 0.51 7786 3.91 0 0 9 7 84 >> 0 86 0.52 7842 3.98 3 0 11 7 79 >> 0 86 0.51 8084 4.05 2 0 9 7 82 >> 0 86 0.52 7395 3.74 2 0 12 9 77 >> 0 86 0.51 7735 3.88 3 0 11 7 79 >> 1 86 0.52 7810 3.95 2 0 11 10 77 >> >> >> dd if=/dev/ad12 of=/dev/null >> iostat -w1 ad12 >> tty ad12 cpu >> tin tout KB/t tps MB/s us ni sy in id >> 48 47 0.68 12 0.01 5 0 2 1 92 >> 1 253 0.50 7694 3.76 3 0 9 9 79 >> 0 85 0.50 7642 3.73 2 0 9 8 81 >> 0 85 0.50 7575 3.70 1 0 10 6 83 >> 0 85 0.50 7598 3.71 2 0 10 11 77 >> 0 86 0.50 7577 3.70 3 0 11 8 79 >> 0 85 0.50 7606 3.71 3 0 6 9 83 >> 1 85 0.50 7620 3.72 2 0 9 8 81 >> >> >> df -h >> Filesystem Size Used Avail Capacity Mounted on >> /dev/ad4s1a 2.1G 139M 1.8G 7% / >> devfs 1.0K 1.0K 0B 100% /dev >> /dev/ad4s1e 2.1G 1.8M 2.0G 0% /tmp >> /dev/ad4s1f 32G 3.6G 26G 12% /usr >> /dev/ad4s1d 2.1G 212M 1.7G 11% /var >> /dev/ad4s2 21G 1.7G 18G 8% /data >> /dev/ad4s3 82G 29G 47G 38% /storage >> /dev/ufs/hdd1 677G 498G 124G 80% /hdd1 >> /dev/ufs/hdd2 902G 445G 385G 54% /hdd2 >> >> ========dmesg========= >> CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (2208.29-MHz >> 686-class CPU) >> ... >> real memory = 2146959360 (2047 MB) >> ... >> atapci0: port >> 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb41f mem >> 0xfe8fe800-0xfe8fefff irq 22 at device 31.2 on pci0 >> atapci0: [ITHREAD] >> atapci0: AHCI Version 01.20 controller with 6 ports detected >> ata2: on atapci0 >> ata2: [ITHREAD] >> ata3: on atapci0 >> ata3: [ITHREAD] >> ata4: on atapci0 >> ata4: [ITHREAD] >> ata5: on atapci0 >> ata5: [ITHREAD] >> ata6: on atapci0 >> ata6: [ITHREAD] >> ata7: on atapci0 >> ata7: executing CLO failed >> ata7: [ITHREAD] >> ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 >> ata0: [ITHREAD] >> ata1 at port 0x170-0x177,0x376 irq 15 on isa0 >> ata1: [ITHREAD] >> ad4: 152626MB at ata2-master SATA150 >> ad6: 715404MB at ata3-master SATA300 >> ad12: 953869MB at ata6-master SATA300 >> >> >> =========pciconf=========== >> atapci0@pci0:0:31:2: class=0x010601 card=0x82771043 chip=0x29228086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801IB/IR/IH (ICH9 Family) 6 port SATA AHCI Controller' >> class = mass storage >> cap 05[80] = MSI supports 16 messages >> cap 01[70] = powerspec 3 supports D0 D3 current D0 >> cap 12[a8] = unknown >> cap 09[b0] = vendor (length 6) Intel cap 2 version 0 >> >> >> ============atacontrol============= >> atacontrol cap ad4 >> >> Protocol Serial ATA v1.0 >> device model ST3160815AS >> serial number 5RA737SD >> firmware revision 4.AAB >> cylinders 16383 >> heads 16 >> sectors/track 63 >> lba supported 268435455 sectors >> lba48 supported 312579695 sectors >> dma supported >> overlap not supported >> >> Feature Support Enable Value Vendor >> write cache yes yes >> read ahead yes yes >> Native Command Queuing (NCQ) yes - 31/0x1F >> Tagged Command Queuing (TCQ) no no 31/0x1F >> SMART yes yes >> microcode download yes yes >> security yes no >> power management yes yes >> advanced power management no no 65278/0xFEFE >> automatic acoustic management no no 0/0x00 208/0xD0 >> >> atacontrol cap ad6 >> >> Protocol Serial ATA II >> device model SAMSUNG HD753LJ >> serial number S13UJ1BQ802853 >> firmware revision 1AA01113 >> cylinders 16383 >> heads 16 >> sectors/track 63 >> lba supported 268435455 sectors >> lba48 supported 1465149168 sectors >> dma supported >> overlap not supported >> >> Feature Support Enable Value Vendor >> write cache yes yes >> read ahead yes yes >> Native Command Queuing (NCQ) yes - 31/0x1F >> Tagged Command Queuing (TCQ) no no 31/0x1F >> SMART yes yes >> microcode download yes yes >> security yes no >> power management yes yes >> advanced power management yes no 0/0x00 >> automatic acoustic management yes yes 254/0xFE 254/0xFE >> >> atacontrol cap ad12 >> >> Protocol Serial ATA II >> device model SAMSUNG HD103UJ >> serial number S13PJ1NQA01054 >> firmware revision 1AA01113 >> cylinders 16383 >> heads 16 >> sectors/track 63 >> lba supported 268435455 sectors >> lba48 supported 1953525168 sectors >> dma supported >> overlap not supported >> >> Feature Support Enable Value Vendor >> write cache yes yes >> read ahead yes yes >> Native Command Queuing (NCQ) yes - 31/0x1F >> Tagged Command Queuing (TCQ) no no 31/0x1F >> SMART yes yes >> microcode download yes yes >> security yes no >> power management yes yes >> advanced power management yes no 0/0x00 >> automatic acoustic management yes yes 254/0xFE 254/0xFE >> >> atacontrol list >> ATA channel 0: >> Master: no device present >> Slave: no device present >> ATA channel 1: >> Master: no device present >> Slave: no device present >> ATA channel 2: >> Master: ad4 Serial ATA v1.0 >> Slave: no device present >> ATA channel 3: >> Master: ad6 Serial ATA II >> Slave: no device present >> ATA channel 4: >> Master: no device present >> Slave: no device present >> ATA channel 5: >> Master: no device present >> Slave: no device present >> ATA channel 6: >> Master: ad12 Serial ATA II >> Slave: no device present >> ATA channel 7: >> Master: acd0 Serial ATA v1.0 >> Slave: no device present >> >> Thank you. >> >> >> >