From owner-freebsd-fs@FreeBSD.ORG Sun Jan 23 01:06:07 2011 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 04B31106566B; Sun, 23 Jan 2011 01:06:07 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6D9618FC0A; Sun, 23 Jan 2011 01:06:06 +0000 (UTC) Received: by wwf26 with SMTP id 26so2892987wwf.31 for ; Sat, 22 Jan 2011 17:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=azvfVCZqQRrTWDD+sgNx/m3FQba3ntgnkkD+lVs4Im0=; b=kw56uffmScqYt09n++RyEGqVoU9XBRkxeThavqgRycLRrPpALOW4iN5wXf8fL/0knc Tko0iw38m8xV4YQ8IKbEcfqsYRF4+le3H8oN65gGhZInt6WOIhoaXyEP20SUpNFAbPW+ DSMeok4FSGq8hE00nm5+9bJpvQnNENq/aTcOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=mmd1du7xY6FjN+K2wnaRNO5xEFqU2UZaouCqD61klSOPFGw+3+XQ8LpaYFdu1TSwhP +RJev3iD8kO3iU+Mr+/wMcFgkOTDGozNIoQx2CufwuIE263m+cdE+Sg9OAlAAdp1IJ7n Nv8EwPLoFexfkC+FnQ4V5GStdqMDSAjrCAOxI= MIME-Version: 1.0 Received: by 10.216.29.71 with SMTP id h49mr2193463wea.46.1295744765434; Sat, 22 Jan 2011 17:06:05 -0800 (PST) Received: by 10.216.254.226 with HTTP; Sat, 22 Jan 2011 17:06:05 -0800 (PST) Date: Sat, 22 Jan 2011 17:06:05 -0800 Message-ID: From: Garrett Cooper To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Concerns over shim-layers for ZFS and kernel/userland namespace pollution 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, 23 Jan 2011 01:06:07 -0000 Hi Pawel, I've been trying to get rid of the time.h pollution in sys/time.h for POSIX conformance and I've run into a bit of a roadblock (referring to sys/cddl/compat/opensolaris/sys/time.h): 1. The clock_gettime call in gethrtime() can fail and the failure itself isn't captured. 2. The calls in many case assume userland behavior, being "return value", not "return errno, assign value to address passed in" 3. AFAICT the calls shouldn't be calling the clock_gettime syscall interface from userland; they should be calling the clock_gettime interface. I could be partly wrong here, but if so then some additional hacking will need to be made to pull in time.h as that's where clock_gettime must be defined according to our manpages and POSIX. There might be another preexisting KPI that can be used in its place. I haven't looked outside of that header for now. Comments on my above statements are more than welcome. Thanks, -Garrett From owner-freebsd-fs@FreeBSD.ORG Sun Jan 23 04:51:51 2011 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 F1869106566C; Sun, 23 Jan 2011 04:51:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 606D78FC0C; Sun, 23 Jan 2011 04:51:51 +0000 (UTC) Received: by wyf19 with SMTP id 19so3116186wyf.13 for ; Sat, 22 Jan 2011 20:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JmBgd/w5Q03mYSmQDjj6aaCFQxwcOZID3woiR2a/MT0=; b=hxXT+68T3BPKj2NMAl33yL3lrBF7Sv87d1gJKetIgaHjV8NT30iSEcfTABvx84wIPW NfkDGXFNKoLDaln0FLo/niO2fuooZZdvtEd4EWoZfYqbEQUUtGx5ysoKC7TV9db9SVwk NiRJu07PsSIbo2i1VOhWlhFKJDqTTOOQo11BE= 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=Ref9oedfE5Z8Hg5nYOHNYAi/CjGmmL9mbVM4hzB88R9s8ZKkCzCjC12r22Rq+5hTeV 3J0hWZqKpYPvfqH0yOj/4H0S32tGr+oSWRwNrROsjqobv2TbtqwQts2IPiwSjSzHfxg5 Fmv1myQqRn7pxroNGKIdV67J7b5VbrimedofI= MIME-Version: 1.0 Received: by 10.216.141.75 with SMTP id f53mr2332358wej.16.1295758310340; Sat, 22 Jan 2011 20:51:50 -0800 (PST) Received: by 10.216.254.226 with HTTP; Sat, 22 Jan 2011 20:51:50 -0800 (PST) In-Reply-To: References: Date: Sat, 22 Jan 2011 20:51:50 -0800 Message-ID: From: Garrett Cooper To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Concerns over shim-layers for ZFS and kernel/userland namespace pollution 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, 23 Jan 2011 04:51:52 -0000 On Sat, Jan 22, 2011 at 5:06 PM, Garrett Cooper wrote: > Hi Pawel, > =A0 =A0I've been trying to get rid of the time.h pollution in sys/time.h > for POSIX conformance and I've run into a bit of a roadblock > (referring to sys/cddl/compat/opensolaris/sys/time.h): > =A0 =A01. The clock_gettime call in gethrtime() can fail and the failure > itself isn't captured. > =A0 =A02. The calls in many case assume userland behavior, being "return > value", not "return errno, assign value to address passed in" > =A0 =A03. AFAICT the calls shouldn't be calling the clock_gettime syscall > interface from userland; they should be calling the clock_gettime > interface. I could be partly wrong here, but if so then some > additional hacking will need to be made to pull in time.h as that's > where clock_gettime must be defined according to our manpages and > POSIX. There might be another preexisting KPI that can be used in its > place. > =A0 =A0I haven't looked outside of that header for now. > =A0 =A0Comments on my above statements are more than welcome. Nevermind. It looks like I missed the #ifdef _KERNEL ... #else ... #endif lines. It would be nice if the KPIs were consistent with FreeBSD KPIs, but that's less of an issue I suppose. Thanks, -Garrett From owner-freebsd-fs@FreeBSD.ORG Sun Jan 23 13:13:31 2011 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 66BA8106566C for ; Sun, 23 Jan 2011 13:13:31 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id E42B38FC1B for ; Sun, 23 Jan 2011 13:13:30 +0000 (UTC) Received: from Octa64 (octa64.tdx.co.uk [62.13.130.232]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/Kp) with ESMTP id p0NDDSH0066125; Sun, 23 Jan 2011 13:13:28 GMT Date: Sun, 23 Jan 2011 13:14:08 +0000 From: Karl Pielorz To: Bruce Cran Message-ID: <1032CC037935BA2DC2E60A4F@Octa64> In-Reply-To: <20110122172714.00002274@unknown> References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> <20110122172714.00002274@unknown> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 23 Jan 2011 13:13:31 -0000 --On 22 January 2011 17:27 +0000 Bruce Cran wrote: > sysutils/fio supports that: just add "fsync=x" to the > configuration file and it'll send a request to the OS to flush the data > to disk every x blocks. That's great - thanks! - I'll check into that and test what exactly the "Enable drive write cache" option does (i.e. if it's all or nothing). Thanks, -Karl From owner-freebsd-fs@FreeBSD.ORG Sun Jan 23 19:10:38 2011 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 328F41065675; Sun, 23 Jan 2011 19:10:38 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 08F2B8FC17; Sun, 23 Jan 2011 19:10:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0NJAbFo018892; Sun, 23 Jan 2011 19:10:37 GMT (envelope-from kib@freefall.freebsd.org) Received: (from kib@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0NJAbaU018853; Sun, 23 Jan 2011 19:10:37 GMT (envelope-from kib) Date: Sun, 23 Jan 2011 19:10:37 GMT Message-Id: <201101231910.p0NJAbaU018853@freefall.freebsd.org> To: k0802647@telus.net, kib@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-fs@FreeBSD.org From: kib@FreeBSD.org Cc: Subject: Re: amd64/154228: md getting stuck in wdrain 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, 23 Jan 2011 19:10:38 -0000 Synopsis: md getting stuck in wdrain state State-Changed-From-To: open->feedback State-Changed-By: kib State-Changed-When: Sun Jan 23 19:08:34 UTC 2011 State-Changed-Why: Apparently, the suspension of the filesystem failed to finish, causing all writers on the filesystem to block. To diagnose the cause, we need the information specified at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: kib Responsible-Changed-When: Sun Jan 23 19:08:34 UTC 2011 Responsible-Changed-Why: UFS issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=154228 From owner-freebsd-fs@FreeBSD.ORG Sun Jan 23 22:16:56 2011 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 835E0106566B for ; Sun, 23 Jan 2011 22:16:56 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 13FC58FC0C for ; Sun, 23 Jan 2011 22:16:56 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 3D3CFE8311; Sun, 23 Jan 2011 22:16:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=H7WzPtitn0Cu 9dj3dTOkxgDOY0c=; b=BiRaAyUVlTvPwWjKMwAwZxGynDq9ynhKFVTiE2U0M7Kf VVEgH/kx60qIr4MOQUd5cxnpUGPMUHalNyVXZZq+Br3OOkkAr+f+di7AoE2jXzGF kVitwUDLnRBC/FjBaHzavOFAV6/lY/UAACvLKmuRfLshirUo0F98kFifQFM5lOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=Vynw6L m021I1FKn0ctciViBoNuAyhHEp1A+z1l+trGbG4usuKUe6GA7aWXli7NFanoRmlS 5HyHq9QWu7bwkh4VQv1OTuW5ma7r35v5VL90khc+s8MetbfuhiLlLPmdfBtz8t2X b30Gnpm+aGwkfL2CgWkZB4SDBzh9u6GYKFm7A= Received: from unknown (client-86-23-95-6.brhm.adsl.virginmedia.com [86.23.95.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id DD2FEE8310; Sun, 23 Jan 2011 22:16:54 +0000 (GMT) Date: Sun, 23 Jan 2011 22:16:51 +0000 From: Bruce Cran To: Karl Pielorz Message-ID: <20110123221651.000037f2@unknown> In-Reply-To: <1032CC037935BA2DC2E60A4F@Octa64> References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> <20110122172714.00002274@unknown> <1032CC037935BA2DC2E60A4F@Octa64> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 23 Jan 2011 22:16:56 -0000 On Sun, 23 Jan 2011 13:14:08 +0000 Karl Pielorz wrote: > That's great - thanks! - I'll check into that and test what exactly > the "Enable drive write cache" option does (i.e. if it's all or > nothing). You might also find http://brad.livejournal.com/2116715.html interesting. -- Bruce Cran From owner-freebsd-fs@FreeBSD.ORG Sun Jan 23 23:50:11 2011 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 8DB031065693 for ; Sun, 23 Jan 2011 23:50:11 +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 7D89C8FC15 for ; Sun, 23 Jan 2011 23:50:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0NNoBfc016578 for ; Sun, 23 Jan 2011 23:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0NNoB2o016577; Sun, 23 Jan 2011 23:50:11 GMT (envelope-from gnats) Date: Sun, 23 Jan 2011 23:50:11 GMT Message-Id: <201101232350.p0NNoB2o016577@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Carl Cc: Subject: Re: kern/154228: [md] md getting stuck in wdrain state X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carl List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 23:50:11 -0000 The following reply was made to PR kern/154228; it has been noted by GNATS. From: Carl To: bug-followup@FreeBSD.org, k0802647@telus.net Cc: Subject: Re: kern/154228: [md] md getting stuck in wdrain state Date: Sun, 23 Jan 2011 15:08:15 -0800 Now I owe a friend a beer. His assertion was that in submitting this bug report I would incur a request to use a debugger myself, and this despite me being an end user reporting a problem on a production system in a remote location which other people depend on. While it would be an interesting and educational distraction to rebuild the kernel and deadlock a production system a few more times, I trust it's understood why that can't happen. As such, I thought it would be helpful to provide the above script so FreeBSD developers with more systems at their disposal might try to reproduce the problem. Any chance of that happening? Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 03:26:29 2011 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 F4139106566B for ; Mon, 24 Jan 2011 03:26:28 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 9D1708FC08 for ; Mon, 24 Jan 2011 03:26:28 +0000 (UTC) Received: (qmail 12005 invoked by uid 399); 24 Jan 2011 03:26:26 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Jan 2011 03:26:26 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D3CF161.8040906@FreeBSD.org> Date: Sun, 23 Jan 2011 19:26:25 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Carl References: <201101232350.p0NNoB2o016577@freefall.freebsd.org> In-Reply-To: <201101232350.p0NNoB2o016577@freefall.freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/154228: [md] md getting stuck in wdrain 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, 24 Jan 2011 03:26:29 -0000 On 01/23/2011 15:50, Carl wrote: > The following reply was made to PR kern/154228; it has been noted by GNATS. > > From: Carl > To: bug-followup@FreeBSD.org, k0802647@telus.net > Cc: > Subject: Re: kern/154228: [md] md getting stuck in wdrain state > Date: Sun, 23 Jan 2011 15:08:15 -0800 > > Now I owe a friend a beer. Make it a good one. :) > His assertion was that in submitting this bug > report I would incur a request to use a debugger myself, and this > despite me being an end user reporting a problem on a production system > in a remote location which other people depend on. > > While it would be an interesting and educational distraction to rebuild > the kernel and deadlock a production system a few more times, I trust > it's understood why that can't happen. As such, I thought it would be > helpful to provide the above script so FreeBSD developers with more > systems at their disposal might try to reproduce the problem. Any chance > of that happening? Is there _any_ chance of it? Maybe. However experience says that problems like the one you're reporting are generally very environment dependent, and if no one has jumped at the opportunity yet then it's not likely to happen, or at least not soon. Not to put too fine a point on it, but doing your part in situations like this is part of the "cost" of "free" software. Good luck, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 08:43:14 2011 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 6215A106564A for ; Mon, 24 Jan 2011 08:43:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0B21C8FC0C for ; Mon, 24 Jan 2011 08:43:13 +0000 (UTC) Received: (qmail 4982 invoked by uid 399); 24 Jan 2011 08:43:13 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Jan 2011 08:43:13 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D3D3B9F.5030609@FreeBSD.org> Date: Mon, 24 Jan 2011 00:43:11 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Carl References: <201101232350.p0NNoB2o016577@freefall.freebsd.org> <4D3CF161.8040906@FreeBSD.org> <4D3D3215.3090907@telus.net> In-Reply-To: <4D3D3215.3090907@telus.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/154228: [md] md getting stuck in wdrain 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, 24 Jan 2011 08:43:14 -0000 On 01/24/2011 00:02, Carl wrote: > On 2011-01-23 7:26 PM, Doug Barton wrote: >> Not to put too fine a point on it, but doing your part in situations >> like this is part of the "cost" of "free" software. > > Believe it or not, I'd actually thought I _was_ doing my part when I > spent all that time testing and trying to craft a script to make the > situation reproducible. I did what was possible in my situation. There is no doubt your bug report was one of the better ones. > I really am truly grateful for the "free" software, but if the "cost" is > a choice between nuking a production system or not bothering to spend > time submitting bug reports containing as much information as is > obtainable, which one will the end user choose? I know plenty of folks > that would say that's a trick question and that the correct answer is to > not use the "free" software. My turn to sharpen the point - wielding the > "free" argument as a club is a bit much when end users are willingly > doing what they can to help. I think you misunderstand the situation. I'm not wielding anything as a club. I'm merely pointing out that what you seem to be insisting WE do to help you may be beyond what we are willing or able to do. If that's not enough to satisfy your needs you may be forced into a difficult decision. Meanwhile, you have a developer who is willing to spend his time, effort, and energy; free of charge; to assist you. I wish you the best of luck. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 09:07:24 2011 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 6B5E9106564A for ; Mon, 24 Jan 2011 09:07:24 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (outbound02.telus.net [199.185.220.221]) by mx1.freebsd.org (Postfix) with ESMTP id 08E808FC08 for ; Mon, 24 Jan 2011 09:07:23 +0000 (UTC) Received: from edtncm04 ([199.185.220.240]) by priv-edtnes28.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20110124080230.NBLB5658.priv-edtnes28.telusplanet.net@edtncm04> for ; Mon, 24 Jan 2011 01:02:30 -0700 Received: from oliver.bc.lan ([66.183.53.162]) by edtncm04 with bizsmtp id zL1d1f02E3VzCbE01L1dNk; Mon, 24 Jan 2011 01:01:38 -0700 X-Authority-Analysis: v=1.1 cv=94BYi3n8JE47UgRSiUh6aHGUk/xWnKFVSisjRvp+HfU= c=1 sm=1 a=MGbHYUDQL-gA:10 a=8nJEP1OIZ-IA:10 a=HNgjH8kF64GtJ7EcXKEMsQ==:17 a=b-LS6SbR6C7Mba5yoyIA:9 a=XisQc-lSch3uDrgabt3Lqy5salEA:4 a=wPNLvfGTeEIA:10 a=HNgjH8kF64GtJ7EcXKEMsQ==:117 Received: from [10.111.111.113] (unknown [10.111.111.113]) by oliver.bc.lan (Postfix) with ESMTP id F41A66455; Mon, 24 Jan 2011 00:02:29 -0800 (PST) Message-ID: <4D3D3215.3090907@telus.net> Date: Mon, 24 Jan 2011 00:02:29 -0800 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Doug Barton References: <201101232350.p0NNoB2o016577@freefall.freebsd.org> <4D3CF161.8040906@FreeBSD.org> In-Reply-To: <4D3CF161.8040906@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/154228: [md] md getting stuck in wdrain 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, 24 Jan 2011 09:07:24 -0000 On 2011-01-23 7:26 PM, Doug Barton wrote: > Not to put too fine a point on it, but doing your part in situations > like this is part of the "cost" of "free" software. Believe it or not, I'd actually thought I _was_ doing my part when I spent all that time testing and trying to craft a script to make the situation reproducible. I did what was possible in my situation. I really am truly grateful for the "free" software, but if the "cost" is a choice between nuking a production system or not bothering to spend time submitting bug reports containing as much information as is obtainable, which one will the end user choose? I know plenty of folks that would say that's a trick question and that the correct answer is to not use the "free" software. My turn to sharpen the point - wielding the "free" argument as a club is a bit much when end users are willingly doing what they can to help. Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 10:09:21 2011 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 04904106566B for ; Mon, 24 Jan 2011 10:09:21 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.55]) by mx1.freebsd.org (Postfix) with ESMTP id 973818FC0C for ; Mon, 24 Jan 2011 10:09:20 +0000 (UTC) Received: from edmwcm03 ([204.209.205.55]) by priv-edmwes25.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20110124100919.YAZC742.priv-edmwes25.telusplanet.net@edmwcm03> for ; Mon, 24 Jan 2011 03:09:19 -0700 Received: from oliver.bc.lan ([66.183.53.162]) by edmwcm03 with bizsmtp id zN6N1f02s3VzCbE01N6Nql; Mon, 24 Jan 2011 03:06:23 -0700 X-Authority-Analysis: v=1.1 cv=y2j5x4kY+Lyhu6kVyASq4pugM8YAKLenHn/w+ql3X6Q= c=1 sm=1 a=MGbHYUDQL-gA:10 a=8nJEP1OIZ-IA:10 a=HNgjH8kF64GtJ7EcXKEMsQ==:17 a=g06IQFZI_z-UbtRBpvoA:9 a=sTOaRc8IF58FNzPbc-8A:7 a=-He0Gf78bRx0WFch-MqMwGd8ZP4A:4 a=wPNLvfGTeEIA:10 a=HNgjH8kF64GtJ7EcXKEMsQ==:117 Received: from [10.111.111.113] (unknown [10.111.111.113]) by oliver.bc.lan (Postfix) with ESMTP id 75C786455; Mon, 24 Jan 2011 02:09:18 -0800 (PST) Message-ID: <4D3D4FCE.9020108@telus.net> Date: Mon, 24 Jan 2011 02:09:18 -0800 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Doug Barton References: <201101232350.p0NNoB2o016577@freefall.freebsd.org> <4D3CF161.8040906@FreeBSD.org> <4D3D3215.3090907@telus.net> <4D3D3B9F.5030609@FreeBSD.org> In-Reply-To: <4D3D3B9F.5030609@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/154228: [md] md getting stuck in wdrain 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, 24 Jan 2011 10:09:21 -0000 On 2011-01-24 12:43 AM, Doug Barton wrote: > I think you misunderstand the situation. I'm not wielding anything as a > club. I'm merely pointing out that what you seem to be insisting WE do > to help you may be beyond what we are willing or able to do. I think you'll find I wasn't insisting on anything, although I will confess that seeing the near instantaneous flip from bug report state "open" to "feedback" accompanied by a "you debug it, end user" is a wee bit discouraging when one has already done what seemed possible. > Meanwhile, you have a developer who is willing to spend his > time, effort, and energy; free of charge; to assist you. I do appreciate that, Doug :-) I wish I had a copy of that production system so I could take advantage. From the reports I've found, this particular bug has been present in FreeBSD versions going back at least to 5.0. I've seen it myself back in 7.0 as well. The md device does not appear to me to be safe to use for file-backed memory devices. Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 11:07:00 2011 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 B1D2A10656B4 for ; Mon, 24 Jan 2011 11:07:00 +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 7C01E8FC26 for ; Mon, 24 Jan 2011 11:07:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0OB702K077797 for ; Mon, 24 Jan 2011 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0OB6xjn077795 for freebsd-fs@FreeBSD.org; Mon, 24 Jan 2011 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Jan 2011 11:06:59 GMT Message-Id: <201101241106.p0OB6xjn077795@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, 24 Jan 2011 11:07:00 -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 -------------------------------------------------------------------------------- f kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153847 fs [nfs] [panic] Kernel panic from incorrect m_free in nf o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153584 fs [ext2fs] [patch] Performance fix and cleanups for BSD o kern/153552 fs [zfs] zfsboot from 8.2-RC1 freeze at boot time o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152488 fs [tmpfs] [patch] mtime of file updated when only inode o kern/152079 fs [msdosfs] [patch] Small cleanups from the other NetBSD o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o kern/151845 fs [smbfs] [patch] smbfs should be upgraded to support Un o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149022 fs [hang] File system operations hangs with suspfs state o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server o kern/146375 fs [nfs] [patch] Typos in macro variables names in sys/fs s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an o bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c o kern/144458 fs [nfs] [patch] nfsd fails as a kld p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142914 fs [zfs] ZFS performance degradation over time o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero 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 o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [ffs] [snapshot] System crashes when manipulat o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o bin/94635 fs snapinfo(8)/libufs only works for disk-backed filesyst o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 219 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 12:54:09 2011 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 81C9A106564A for ; Mon, 24 Jan 2011 12:54:09 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB4B8FC0A for ; Mon, 24 Jan 2011 12:54:08 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A549445CA6; Mon, 24 Jan 2011 13:54:06 +0100 (CET) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C142A45C9B; Mon, 24 Jan 2011 13:54:01 +0100 (CET) Date: Mon, 24 Jan 2011 13:53:51 +0100 From: Pawel Jakub Dawidek To: Bruce Cran Message-ID: <20110124125351.GL1700@garage.freebsd.pl> References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> <20110122172714.00002274@unknown> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bAr+fMtvBxbbbkvl" Content-Disposition: inline In-Reply-To: <20110122172714.00002274@unknown> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 24 Jan 2011 12:54:09 -0000 --bAr+fMtvBxbbbkvl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 22, 2011 at 05:27:14PM +0000, Bruce Cran wrote: > On Sat, 22 Jan 2011 15:51:21 +0000 > Karl Pielorz wrote: >=20 > > I'll have a look at those - I'm more interested in finding a tool > > that will write data both with, and without the "don't cache this" > > flag(s) set - to see if the performance is the same (you would hope > > that regardless of the BIOS setting that writing entirely data that's > > marked not to be cached, the performance would 'sink' back down to a > > sedate 12Mbytes/sec) - if it doesn't, something is lying somewhere :) >=20 > sysutils/fio supports that: just add "fsync=3Dx" to the > configuration file and it'll send a request to the OS to flush the data > to disk every x blocks. My guess (based on option name) is that it will perform fsync(2) every x blocks, which has nothing to do with disk write cache. Most file systems (unfortunately UFS is one of them) simply ignores existance of disk write caches. In Mac OS X you can find F_FULLFSYNC flag to fcntl(2) which is suppose to ask underlying disk to flush its cache. fsync(2) don't do that for UFS, but it does that for ZFS. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --bAr+fMtvBxbbbkvl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk09dl4ACgkQForvXbEpPzSKrQCg+jOX9lX8ho3yf2F/L01+SbQi yTEAoLREzy5dzV3T2kMcxB1kroU59+Kg =vAsD -----END PGP SIGNATURE----- --bAr+fMtvBxbbbkvl-- From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 14:22:49 2011 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 5DEC6106566B for ; Mon, 24 Jan 2011 14:22:49 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3216F8FC12 for ; Mon, 24 Jan 2011 14:22:48 +0000 (UTC) Received: by iyb26 with SMTP id 26so4157994iyb.13 for ; Mon, 24 Jan 2011 06:22:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.34.65 with SMTP id k1mr4826792ibd.9.1295877351493; Mon, 24 Jan 2011 05:55:51 -0800 (PST) Received: by 10.231.59.142 with HTTP; Mon, 24 Jan 2011 05:55:51 -0800 (PST) In-Reply-To: <20110122111045.GA59117@icarus.home.lan> References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> Date: Mon, 24 Jan 2011 14:55:51 +0100 Message-ID: From: Olivier Smedts To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 24 Jan 2011 14:22:49 -0000 Hello, 2011/1/22 Jeremy Chadwick : > On Sat, Jan 22, 2011 at 10:39:13AM +0000, Karl Pielorz wrote: >> I've a small HP server I've been using recently (an NL36). I've got >> ZFS setup on it, and it runs quite nicely. >> >> I was using the server for zeroing some drives the other day - and >> noticed that a: >> >> =A0dd if=3D/dev/zero of=3D/dev/ada0 bs=3D2m >> >> Gives around 12Mbyte/sec throughput when that's all that's running >> on the machine. >> >> Looking in the BIOS is a "Enabled drive write cache" option - which >> was set to 'No'. Changing it to 'Yes' - I now get around >> 90-120Mbyte/sec doing the same thing. >> >> Knowing all the issues with IDE drives and write caches - is there >> any way of telling if this would be safe to enable with ZFS? (i.e. >> if the option is likely to be making the drive completely ignore >> flush requests?) - or if it's still honouring the various 'write >> through' options if set on data to be written? >> >> I'm presuming DD won't by default be writing the data with the >> 'flush' bit set - as it probably doesn't know about it. >> >> Is there anyway of testing this? (say using some tool to write the >> data using either lots of 'cache flush' or 'write through' stuff) - >> and seeing if the performance drops back to nearer the 12Mbyte/sec? >> >> I've not enabled the option with the ZFS drives in the machine - I >> suppose I could test it. >> >> Write performance on the unit isn't that bad [it's not stunning] - >> though with 4 drives in a mirrored set - it probably helps hide some >> of the impact this option might have. > > I'm stating the below with the assumption that you have SATA disks with > some form of AHCI-based controller (possibly Intel ICHxx or ESBx > on-board), and *not* a hardware RAID controller with cache/RAM of its > own: > > Keep write caching *enabled* in the system BIOS. =A0ZFS will take care of > any underlying "issues" in the case the system abruptly loses power > (hard disk cache contents lost), since you're using ZFS mirroring. =A0The > same would apply if you were using raidz{1,2}, but not if you were using > ZFS on a single device (no mirroring/raidz). =A0In that scenario, expect > data loss; but the same could be said of any non-journalling filesystem. Could you explain this behavior ? I don't see why ZFS would not ask a single disk to flush its caches like in a mirror/raidz. It's necessary for the ZIL, and to avoid FS corruption. > I have no idea why your BIOS setting for this option was disabled. =A0I d= o > not know if it's the factory default either; you would have to talk to > HP about that, or spend the time figuring out who was in the system BIOS > last and how/if/why they messed around (the number of possibilities for > why the option is disabled are endless). > > You can use bonnie++ (ports/benchmarks/bonnie++) if you wish to do > throughput and/or benchmark testing of sorts. > > -- > | Jeremy Chadwick =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 jdc@parodius.com | > | Parodius Networking =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.parodius.com/ | > | UNIX Systems Administrator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mountain = View, CA, USA | > | Making life hard for others since 1977. =A0 =A0 =A0 =A0 =A0 =A0 =A0 PGP= 4BD6C0CB | > > _______________________________________________ > 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" > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 14:42:39 2011 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 9A088106564A for ; Mon, 24 Jan 2011 14:42:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 44B198FC08 for ; Mon, 24 Jan 2011 14:42:38 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta13.westchester.pa.mail.comcast.net with comcast id zSiP1f00B27AodY5DSifbW; Mon, 24 Jan 2011 14:42:39 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta19.westchester.pa.mail.comcast.net with comcast id zSid1f00f2tehsa3fSiddM; Mon, 24 Jan 2011 14:42:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0D9A09B427; Mon, 24 Jan 2011 06:42:36 -0800 (PST) Date: Mon, 24 Jan 2011 06:42:36 -0800 From: Jeremy Chadwick To: Olivier Smedts Message-ID: <20110124144236.GA19500@icarus.home.lan> References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 24 Jan 2011 14:42:39 -0000 On Mon, Jan 24, 2011 at 02:55:51PM +0100, Olivier Smedts wrote: > 2011/1/22 Jeremy Chadwick : > > On Sat, Jan 22, 2011 at 10:39:13AM +0000, Karl Pielorz wrote: > >> I've a small HP server I've been using recently (an NL36). I've got > >> ZFS setup on it, and it runs quite nicely. > >> > >> I was using the server for zeroing some drives the other day - and > >> noticed that a: > >> > >> dd if=/dev/zero of=/dev/ada0 bs=2m > >> > >> Gives around 12Mbyte/sec throughput when that's all that's running > >> on the machine. > >> > >> Looking in the BIOS is a "Enabled drive write cache" option - which > >> was set to 'No'. Changing it to 'Yes' - I now get around > >> 90-120Mbyte/sec doing the same thing. > >> > >> Knowing all the issues with IDE drives and write caches - is there > >> any way of telling if this would be safe to enable with ZFS? (i.e. > >> if the option is likely to be making the drive completely ignore > >> flush requests?) - or if it's still honouring the various 'write > >> through' options if set on data to be written? > >> > >> I'm presuming DD won't by default be writing the data with the > >> 'flush' bit set - as it probably doesn't know about it. > >> > >> Is there anyway of testing this? (say using some tool to write the > >> data using either lots of 'cache flush' or 'write through' stuff) - > >> and seeing if the performance drops back to nearer the 12Mbyte/sec? > >> > >> I've not enabled the option with the ZFS drives in the machine - I > >> suppose I could test it. > >> > >> Write performance on the unit isn't that bad [it's not stunning] - > >> though with 4 drives in a mirrored set - it probably helps hide some > >> of the impact this option might have. > > > > I'm stating the below with the assumption that you have SATA disks with > > some form of AHCI-based controller (possibly Intel ICHxx or ESBx > > on-board), and *not* a hardware RAID controller with cache/RAM of its > > own: > > > > Keep write caching *enabled* in the system BIOS. ZFS will take care of > > any underlying "issues" in the case the system abruptly loses power > > (hard disk cache contents lost), since you're using ZFS mirroring. The > > same would apply if you were using raidz{1,2}, but not if you were using > > ZFS on a single device (no mirroring/raidz). In that scenario, expect > > data loss; but the same could be said of any non-journalling filesystem. > > Could you explain this behavior ? I don't see why ZFS would not ask a > single disk to flush its caches like in a mirror/raidz. It's necessary > for the ZIL, and to avoid FS corruption. What seems to be "missing" from the discussion is that in the case of an abrupt power failure, the in-kernel caching mechanisms (regardless of filesystem (ZFS vs. UFS, etc.)) are all lost, in addition to any data that's within a hard disk's on-PCB memory cache. AFAIK, ZFS flushes its caches to disk at set intervals. The term "flush" means many different things. fsync(2), for example, behaves differently on UFS than it does on ZFS. People think that "flush" means "guarantee the data written was written to disk", but ensuring an actual ATA/SCSI command completes **and** has had its data written to the platters is an entirely different beast (IMO) than "flush kernel buffers to disk and hope for the best". In the case of ZFS, why would all data be written to the disk every single time there's a write(2) operation? Performance-wise that makes absolutely no sense. So there is absolutely going to be a "window of failure" that can happen, and mirroring/raidz can recover from that, as a result of the checksum "stuff". With single disks, all I've seen are read/write errors which can't be repaired. "zpool status" will actually show what files got affected as a result of the issue, though sometimes "zpool scrub" needs to be run before this can be detected. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 14:57:44 2011 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 97585106564A for ; Mon, 24 Jan 2011 14:57:44 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 361AB8FC15 for ; Mon, 24 Jan 2011 14:57:43 +0000 (UTC) Received: from HexaDeca64.dmpriest.net.uk (HPQuadro64.dmpriest.net.uk [62.13.130.30]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/Kp) with ESMTP id p0OEvefD091633 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 24 Jan 2011 14:57:40 GMT Date: Mon, 24 Jan 2011 14:56:48 +0000 From: Karl Pielorz To: Bruce Cran Message-ID: In-Reply-To: <20110123221651.000037f2@unknown> References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> <20110122172714.00002274@unknown> <1032CC037935BA2DC2E60A4F@Octa64> <20110123221651.000037f2@unknown> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 24 Jan 2011 14:57:44 -0000 --On 23 January 2011 22:16 +0000 Bruce Cran wrote: > You might also find http://brad.livejournal.com/2116715.html > interesting. Ok, the utility provided via the Blog reports zero errors when run from both UFS, and ZFS with the BIOS set to 'Enabled drive write cache: No'. Flip the BIOS to 'Yes' - for UFS, things get messy (as you'd kind of expect) - the file system gets trashed (enough that autoboot / background checking fails), and you can't complete the test because the test file doesn't exist after reboot (side effect of softupdates I'd guess). For ZFS the test still completes - with 'zero errors'. Checking via 'camcontrol' - the BIOS option 'Enabled drive write cache' just seems to affect the 'Write cache enable' features on the drive, i.e. " test# camcontrol identify ada0 | grep -E "(Feature)|(cache)" Feature Support Enabled Value Vendor write cache yes no flush cache yes yes " And with it set to 'Yes' in the BIOS: " test# camcontrol identify ada0 | grep -E "(Feature)|(cache)" Feature Support Enabled Value Vendor write cache yes yes flush cache yes yes " So in a very round-the-houses way, that's all it appears to change... Guess it's nice to have the option. I'd also guess whilst enabling it for ZFS is good, having it enabled for UFS is slightly dangerous (and that by enabling it machine wide you may trash the UFS file systems on that machine if it suffers a catastrophic power outage). -Karl From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 15:10:13 2011 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 CB760106564A for ; Mon, 24 Jan 2011 15:10:13 +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 B754B8FC08 for ; Mon, 24 Jan 2011 15:10:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0OFADau040004 for ; Mon, 24 Jan 2011 15:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0OFADTv040002; Mon, 24 Jan 2011 15:10:13 GMT (envelope-from gnats) Date: Mon, 24 Jan 2011 15:10:13 GMT Message-Id: <201101241510.p0OFADTv040002@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Olivier Certner Cc: Subject: kern/136944: [ffs] [lor] bufwait/snaplk (fsync) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Olivier Certner List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 15:10:14 -0000 The following reply was made to PR kern/136944; it has been noted by GNATS. From: Olivier Certner To: bug-followup@freebsd.org Cc: Subject: kern/136944: [ffs] [lor] bufwait/snaplk (fsync) Date: Mon, 24 Jan 2011 16:07:54 +0100 Hi, A small mail to confirm that this problem is still present on 9.0-CURRENT-201101. Also, I reproduce other related LORs below. They can be triggered by performing a 'dump -L' on a UFS file system. The '-L' flag of 'dump' causes it to perform a snapshot of the file system to dump before reading data from it. lock order reversal: 1st 0xfffffe0019815bd8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 2nd 0xffffff80f5db1f98 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2659 3rd 0xfffffe0003bc2db8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xd42 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 ffs_snapshot() at ffs_snapshot+0x1c16 ffs_mount() at ffs_mount+0x5eb vfs_donmount() at vfs_donmount+0xf6b nmount() at nmount+0x63 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8006a015c, rsp = 0x7fffffffe3a8, rbp = 0x7fffffffedeb --- lock order reversal: 1st 0xffffff80f5c6af78 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2659 2nd 0xfffffe0003c37d30 snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2261 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xd42 ffs_copyonwrite() at ffs_copyonwrite+0x189 ffs_geom_strategy() at ffs_geom_strategy+0x1ba bufwrite() at bufwrite+0x10c ffs_update() at ffs_update+0x1a3 ffs_fsync() at ffs_fsync+0x43 fsync() at fsync+0x148 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (95, FreeBSD ELF64, fsync), rip = 0x800856d5c, rsp = 0x7fffffffe128, rbp = 0x800c8c0d0 --- lock order reversal: 1st 0xfffffe0003c37d30 snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:301 2nd 0xfffffe0019815bd8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1616 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xd42 ffs_snapremove() at ffs_snapremove+0xe7 ffs_truncate() at ffs_truncate+0x635 ufs_inactive() at ufs_inactive+0x243 vinactive() at vinactive+0x72 vputx() at vputx+0x386 vn_close() at vn_close+0x118 vn_closefile() at vn_closefile+0x5a _fdrop() at _fdrop+0x23 closef() at closef+0x5b fdfree() at fdfree+0x1b4 exit1() at exit1+0x2f5 sys_exit() at sys_exit+0xe syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (1, FreeBSD ELF64, sys_exit), rip = 0x8006f18cc, rsp = 0x7fffffffe1b8, rbp = 0x404ed0 --- Thanks, Olivier Certner From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 15:21:08 2011 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 03EF1106564A for ; Mon, 24 Jan 2011 15:21:08 +0000 (UTC) (envelope-from numisemis@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 87AAB8FC15 for ; Mon, 24 Jan 2011 15:21:07 +0000 (UTC) Received: by ewy24 with SMTP id 24so1931857ewy.13 for ; Mon, 24 Jan 2011 07:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=xkRzTgQKEy2bEwFvU4U1UmfB0qNjAZcrDAvsDJyH03Q=; b=MrQ+K3CfrMGnaLJGBA+qPYrhx3iEQijikRw0yzMOkde0wNO5zert+1vEymnwTqnS7f pFv2TFc5QvutNdoSG4ANCeIaqvWquHd6LGYeLKI65EJSgd32L0476bHmlphnq6Wfl4om Egywtr+7e0z2dqjbnAsi8QZDtjdWgHk3zN/2o= 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=DG1yKfXNKxxNcIYhlKMef5CqEjwjVj+GeW1LRxOwic/HjkePvNKvRUTitjZrAYG6dq iSLO7gLwVFBRPDpiFfGdoQ/Btx+lZ8FjlL3UA9MISfUCVAYuVMeWG30ib/GLx5iLX4MO NVPu7ccOhL9EwLrgiWxVEpxYYLTLyzUYJj/KU= MIME-Version: 1.0 Received: by 10.213.32.18 with SMTP id a18mr4999229ebd.60.1295882114226; Mon, 24 Jan 2011 07:15:14 -0800 (PST) Received: by 10.213.112.141 with HTTP; Mon, 24 Jan 2011 07:15:13 -0800 (PST) In-Reply-To: References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> <20110124144236.GA19500@icarus.home.lan> Date: Mon, 24 Jan 2011 16:15:13 +0100 Message-ID: From: =?UTF-8?Q?=C5=A0imun_Mikecin?= To: Jeremy Chadwick , freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Write cache, is write cache, is write cache? 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, 24 Jan 2011 15:21:08 -0000 2011/1/24 =C5=A0imun Mikecin > 2011/1/24 Jeremy Chadwick > >> The term "flush" means many different things. fsync(2), for example, >> behaves differently on UFS than it does on ZFS. People think that >> "flush" means "guarantee the data written was written to disk", but >> ensuring an actual ATA/SCSI command completes **and** has had its data >> written to the platters is an entirely different beast (IMO) than "flush >> kernel buffers to disk and hope for the best". >> > > AFAIK, BIO_FLUSH should complete when data was written to disk (not > before), or in the case of battery backed cache: when data was written to > battery backed cache. > AFAIK, ZFS doesn't only "flush kernel buffers" (like UFS does), but also > executes BIO_FLUSH every X seconds (X=3D5 if my memory serves me well). S= o, > you shouldn't loose data that was written before BIO_FLUSH executed. > > With single disks, all I've seen are read/write errors which can't be > >> repaired. "zpool status" will actually show what files got affected as >> a result of the issue, though sometimes "zpool scrub" needs to be run >> before this can be detected. > > > Adding redudancy does make your data safer, but if everything is working = as > explained, sudden power-loss shouldn't be the cause of those errors even > with single disks. Correct me if you think that I'm mistaken. > Well, when I think more about it, those errors might be from writing to dis= k after last call to BIO_FLUSH. So you loose last 5 seconds at most. Not something worth writing home about considering the performance advantage yo= u get by enabling write cache. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 15:34:19 2011 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 D4841106564A for ; Mon, 24 Jan 2011 15:34:19 +0000 (UTC) (envelope-from numisemis@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 636F38FC18 for ; Mon, 24 Jan 2011 15:34:18 +0000 (UTC) Received: by eyf6 with SMTP id 6so1937411eyf.13 for ; Mon, 24 Jan 2011 07:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BWbLHNCvNsFxf9QO9BiE95b9TWkwa7JHPC2gGWdZrkM=; b=BfAuaVz4YKM8FsZQ1BGts8VyBtwLBNsvHRem2foH/O1PB1mULy8/29dmkTi7LhkWUy JXRUj8u533l99lZCrTKoB6jHmq6HY01kiyf6Zfj0AGAHjocqbcs2l3Wsl4/oCgVYwtUt zBr4/QdMVD8dSsjncuLNiDubwOIHFzHdntqgI= 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=AhYJu+RDSXR+EBqgp4akqKaJmhqzHNellhmoo18r+xHfcHi8wybNLIZrCUsU/Mlvna EDm9hLnj+6DAh0km49ruiIHP0shQ4Z+nTrgg6+ZShDs1i9Dr7B8mAtxevelhjPuafhSO cg5DgT+BxtzQPCdykqMmyEdZ24fkzYneqfd3E= MIME-Version: 1.0 Received: by 10.213.31.146 with SMTP id y18mr4944442ebc.99.1295881750987; Mon, 24 Jan 2011 07:09:10 -0800 (PST) Received: by 10.213.112.141 with HTTP; Mon, 24 Jan 2011 07:09:10 -0800 (PST) In-Reply-To: <20110124144236.GA19500@icarus.home.lan> References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> <20110124144236.GA19500@icarus.home.lan> Date: Mon, 24 Jan 2011 16:09:10 +0100 Message-ID: From: =?ISO-8859-2?Q?=A9imun_Mikecin?= To: Jeremy Chadwick , freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Write cache, is write cache, is write cache? 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, 24 Jan 2011 15:34:19 -0000 2011/1/24 Jeremy Chadwick > The term "flush" means many different things. fsync(2), for example, > behaves differently on UFS than it does on ZFS. People think that > "flush" means "guarantee the data written was written to disk", but > ensuring an actual ATA/SCSI command completes **and** has had its data > written to the platters is an entirely different beast (IMO) than "flush > kernel buffers to disk and hope for the best". > AFAIK, BIO_FLUSH should complete when data was written to disk (not before), or in the case of battery backed cache: when data was written to battery backed cache. AFAIK, ZFS doesn't only "flush kernel buffers" (like UFS does), but also executes BIO_FLUSH every X seconds (X=5 if my memory serves me well). So, you shouldn't loose data that was written before BIO_FLUSH executed. With single disks, all I've seen are read/write errors which can't be > repaired. "zpool status" will actually show what files got affected as > a result of the issue, though sometimes "zpool scrub" needs to be run > before this can be detected. Adding redudancy does make your data safer, but if everything is working as explained, sudden power-loss shouldn't be the cause of those errors even with single disks. Correct me if you think that I'm mistaken. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 15:47:45 2011 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 9156C1065675 for ; Mon, 24 Jan 2011 15:47:45 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 218EE8FC0C for ; Mon, 24 Jan 2011 15:47:45 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 3EB00E8329; Mon, 24 Jan 2011 15:47:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=bkHgrSgTCOrJ 77ByL3dYPigomVo=; b=Wcd8heOn0abrfM4EKuu1nc3tH4NuhRbyzYfOgT50fPEh lTQIYkL757/2cppOvHnCGr3QQGFM3RNafqXBUCNQl07zkRUTR9iXmCQ6DDc6wp39 Ggp9ggGAmIFNApcjrw8/LUyMYlTrwDiLB9gi7gbBYrj1fPp0MPZhYiJM28+7WaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=ngTwxE GYGKXFlXxO7JXG9/tdurchzFQ8F3oAKF8UrCPzF6FVBvSIqqLu+sIFeeJjD5Tjye h6Uo+cg3R9n4x03D5Ee+kkAwOPonA7is1OevLuUtsE1m+Ju204GTRyNsTe1ScVAQ KBwzPHQURvIC1Ogahk4jIjvLE0c5uiKKVSu/I= Received: from unknown (client-86-23-95-6.brhm.adsl.virginmedia.com [86.23.95.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id EB22BE8324; Mon, 24 Jan 2011 15:47:43 +0000 (GMT) Date: Mon, 24 Jan 2011 15:47:37 +0000 From: Bruce Cran To: Jeremy Chadwick Message-ID: <20110124154737.000025c1@unknown> In-Reply-To: <20110124144236.GA19500@icarus.home.lan> References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> <20110124144236.GA19500@icarus.home.lan> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 24 Jan 2011 15:47:45 -0000 On Mon, 24 Jan 2011 06:42:36 -0800 Jeremy Chadwick wrote: > In the case of ZFS, why would all data be written to the disk every > single time there's a write(2) operation? Performance-wise that makes > absolutely no sense. So there is absolutely going to be a "window of > failure" that can happen, and mirroring/raidz can recover from that, > as a result of the checksum "stuff". Very few people would expect data to be on disk after every write(2), but they should expect it to be on disk after every fsync(2) - my understanding is that databases depend on that for correct operation. -- Bruce Cran From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 16:51:31 2011 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 9DA0E106566C for ; Mon, 24 Jan 2011 16:51:31 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2D88FC1D for ; Mon, 24 Jan 2011 16:51:31 +0000 (UTC) Received: by iyb26 with SMTP id 26so4303562iyb.13 for ; Mon, 24 Jan 2011 08:51:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.204 with SMTP id u12mr5068100ibu.109.1295887890562; Mon, 24 Jan 2011 08:51:30 -0800 (PST) Received: by 10.231.59.142 with HTTP; Mon, 24 Jan 2011 08:51:30 -0800 (PST) In-Reply-To: References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> <20110124144236.GA19500@icarus.home.lan> Date: Mon, 24 Jan 2011 17:51:30 +0100 Message-ID: From: Olivier Smedts To: =?UTF-8?Q?=C5=A0imun_Mikecin?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 24 Jan 2011 16:51:31 -0000 2011/1/24 =C5=A0imun Mikecin : > 2011/1/24 Jeremy Chadwick > >> The term "flush" means many different things. =C2=A0fsync(2), for exampl= e, >> behaves differently on UFS than it does on ZFS. =C2=A0People think that >> "flush" means "guarantee the data written was written to disk", but >> ensuring an actual ATA/SCSI command completes **and** has had its data >> written to the platters is an entirely different beast (IMO) than "flush >> kernel buffers to disk and hope for the best". >> > > AFAIK, BIO_FLUSH should complete when data was written to disk (not befor= e), > or in the case of battery backed cache: when data was written to battery > backed cache. > AFAIK, ZFS doesn't only "flush kernel buffers" (like UFS does), but also > executes BIO_FLUSH every X seconds (X=3D5 if my memory serves me well). S= o, > you shouldn't loose data that was written before BIO_FLUSH executed. I thought ZFS also took care of executing BIO_FLUSH after each write to ZIL, because every bit in ZFS expect writes to be ordered, and some specific writes to be synced to platters, else your FS is gone if ZIL is corrupted in some way. The way ZFS works is the reason there's fsck-like repair tool for it. Of course, this does not work if you don't use a propre controller or disk, but it should behave that way for most, no ? > =C2=A0 With single disks, all I've seen are read/write errors which can't= be > >> repaired. =C2=A0"zpool status" will actually show what files got affecte= d as >> a result of the issue, though sometimes "zpool scrub" needs to be run >> before this can be detected. > > > Adding redudancy does make your data safer, but if everything is working = as > explained, sudden power-loss shouldn't be the cause of those errors even > with single disks. Correct me if you think that I'm mistaken. > _______________________________________________ > 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" > --=20 Olivier Smedts=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 =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 =C2=A0 ASCII ri= bbon campaign ( ) e-mail: olivier@gid0.org=C2=A0 =C2=A0 =C2=A0 =C2=A0 - against HTML email & = vCards=C2=A0 X www: http://www.gid0.org=C2=A0 =C2=A0 - against proprietary attachments / \ =C2=A0 "Il y a seulement 10 sortes de gens dans le monde : =C2=A0 ceux qui comprennent le binaire, =C2=A0 et ceux qui ne le comprennent pas." From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 16:52:20 2011 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 C84AE1065670 for ; Mon, 24 Jan 2011 16:52:20 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 975F58FC13 for ; Mon, 24 Jan 2011 16:52:20 +0000 (UTC) Received: by iyb26 with SMTP id 26so4304377iyb.13 for ; Mon, 24 Jan 2011 08:52:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.15.194 with SMTP id l2mr5080740iba.34.1295887939509; Mon, 24 Jan 2011 08:52:19 -0800 (PST) Received: by 10.231.59.142 with HTTP; Mon, 24 Jan 2011 08:52:19 -0800 (PST) In-Reply-To: References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> <20110124144236.GA19500@icarus.home.lan> Date: Mon, 24 Jan 2011 17:52:19 +0100 Message-ID: From: Olivier Smedts To: =?UTF-8?Q?=C5=A0imun_Mikecin?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? 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, 24 Jan 2011 16:52:21 -0000 2011/1/24 Olivier Smedts : > 2011/1/24 =C5=A0imun Mikecin : >> 2011/1/24 Jeremy Chadwick >> >>> The term "flush" means many different things. =C2=A0fsync(2), for examp= le, >>> behaves differently on UFS than it does on ZFS. =C2=A0People think that >>> "flush" means "guarantee the data written was written to disk", but >>> ensuring an actual ATA/SCSI command completes **and** has had its data >>> written to the platters is an entirely different beast (IMO) than "flus= h >>> kernel buffers to disk and hope for the best". >>> >> >> AFAIK, BIO_FLUSH should complete when data was written to disk (not befo= re), >> or in the case of battery backed cache: when data was written to battery >> backed cache. >> AFAIK, ZFS doesn't only "flush kernel buffers" (like UFS does), but also >> executes BIO_FLUSH every X seconds (X=3D5 if my memory serves me well). = So, >> you shouldn't loose data that was written before BIO_FLUSH executed. > > I thought ZFS also took care of executing BIO_FLUSH after each write > to ZIL, because every bit in ZFS expect writes to be ordered, and some > specific writes to be synced to platters, else your FS is gone if ZIL > is corrupted in some way. The way ZFS works is the reason there's *no* > fsck-like repair tool for it. Of course, this does not work if you > don't use a propre controller or disk, but it should behave that way > for most, no ? > >> =C2=A0 With single disks, all I've seen are read/write errors which can'= t be >> >>> repaired. =C2=A0"zpool status" will actually show what files got affect= ed as >>> a result of the issue, though sometimes "zpool scrub" needs to be run >>> before this can be detected. >> >> >> Adding redudancy does make your data safer, but if everything is working= as >> explained, sudden power-loss shouldn't be the cause of those errors even >> with single disks. Correct me if you think that I'm mistaken. >> _______________________________________________ >> 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" >> > > > > -- > Olivier Smedts=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 =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 =C2=A0 ASCII ri= bbon campaign ( ) > e-mail: olivier@gid0.org=C2=A0 =C2=A0 =C2=A0 =C2=A0 - against HTML email = & vCards=C2=A0 X > www: http://www.gid0.org=C2=A0 =C2=A0 - against proprietary attachments /= \ > > =C2=A0 "Il y a seulement 10 sortes de gens dans le monde : > =C2=A0 ceux qui comprennent le binaire, > =C2=A0 et ceux qui ne le comprennent pas." > --=20 Olivier Smedts=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 =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 =C2=A0 ASCII ri= bbon campaign ( ) e-mail: olivier@gid0.org=C2=A0 =C2=A0 =C2=A0 =C2=A0 - against HTML email & = vCards=C2=A0 X www: http://www.gid0.org=C2=A0 =C2=A0 - against proprietary attachments / \ =C2=A0 "Il y a seulement 10 sortes de gens dans le monde : =C2=A0 ceux qui comprennent le binaire, =C2=A0 et ceux qui ne le comprennent pas." From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 17:35:37 2011 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 95FC61065672; Mon, 24 Jan 2011 17:35:37 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from mta02.eastlink.ca (mta02.eastlink.ca [24.224.136.13]) by mx1.freebsd.org (Postfix) with ESMTP id 597DB8FC1B; Mon, 24 Jan 2011 17:35:37 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ip04.eastlink.ca ([unknown] [24.222.39.52]) by mta02.eastlink.ca (Sun Java(tm) System Messaging Server 7.3-11.01 64bit (built Sep 1 2009)) with ESMTP id <0LFJ005L6FJCDQO0@mta02.eastlink.ca>; Mon, 24 Jan 2011 13:35:36 -0400 (AST) X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=zW4qkwwpA+AM09VaNOLkucDBqffYZTwBSaEYifkV/P4= c=1 sm=1 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=yyzBcIw5vhwbnQXkPe0A:9 a=uH0dH9mmWQZiZe6IFGgA:7 a=michDidowGc3YoJd9MvY-sMSc5wA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=ZjIqTmGINkQKjhCx/60B3Q==:117 Received: from blk-222-10-85.eastlink.ca (HELO server7.acsi.ca) ([24.222.10.85]) by ip04.eastlink.ca with ESMTP; Mon, 24 Jan 2011 13:35:36 -0400 Received: from server7.acsi.ca ([192.168.9.7]) by server7.acsi.ca ([192.168.9.7]) with mapi; Mon, 24 Jan 2011 13:35:24 -0400 From: Chris Forgeron To: Chris Forgeron , Pawel Jakub Dawidek Date: Mon, 24 Jan 2011 13:35:23 -0400 Thread-topic: My ZFS v28 Testing Experience Thread-index: AcuzcbzI9prO2K7/S8SCrzq+LoNNtAG9aPPAAGEYbsA= Message-id: References: <20101213214556.GC2038@garage.freebsd.pl> <20110113223125.GA2330@garage.freebsd.pl> In-reply-to: Accept-Language: en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Cc: "freebsd-fs@freebsd.org" , "freebsd-current@freebsd.org" Subject: RE: My ZFS v28 Testing Experience 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, 24 Jan 2011 17:35:37 -0000 Unfortunately, this didn't make a difference. There is no signifigant change in the benchmarks with the new compile. I do have a lot of CPU power at hand, so it doesn't look to be bound there at all. Possibly, that's one of the issues. I'm running 2 new Xeon X5660's so there's 6x2 (12) physical, 12x2 (24) virtual cores present to FreeBSD. How well is scheduling being handled on this processor architecture? At this stage, I can't say with any confidence that it _is_ ZFS at fault here, because I'm involving NFS and the ix driver substantially. I just know that NFS to a ZFS share on Solaris 11 Express is wildly faster than FreeBSD 9.0, regardless of tweaks. Now, there may be some extra debug within the NFS code that is the issue here, I'm not sure at this stage. I could also play with iSCSI instead, or the raw ZFS filesystem instead, but my needs involve NFS+ZFS, so that's my main test environment. I'm not using the new NFSv4 code. Let me know if there is something you'd like to test or know more about on my setup - I'll be running FreeBSD for about a week on this box (finishing up some last bits of work that I need it for), then I'm back to Solaris 11 Express for the next few months. I may end up having to build a separate box so I'm more easily able to test this configuration. I'd like to say with more confidence where the speed is going, because I feel FreeBSD deserves to be top-notch, and right now I'm only raising issues that aren't exact enough to work on. -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Chris Forgeron Sent: Saturday, January 22, 2011 3:09 PM To: Pawel Jakub Dawidek Cc: freebsd-fs@freebsd.org; freebsd-current@freebsd.org Subject: RE: My ZFS v28 Testing Experience >Before we go any further could you please confirm that you commented out this line in sys/modules/zfs/Makefile: > > CFLAGS+=-DDEBUG=1 > >This turns all kind of ZFS debugging and slows it down a lot, but for the correctness testing is invaluable. This will >be turned off once we import ZFS into FreeBSD-CURRENT. Ah! I did not do this. My bad, I've made the edit, and will be recompiling today to see the differences this makes. I will also clone my disk, turn witness and full debug back on, and then try and find out where my problems importing a pool with multiple cache/log devices comes from. It's quite possible it's not hanging, just taking forever, and I'm impatient and not letting it sit for a n hour to see if it completes. Will report back once I have numbers. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 20:40:09 2011 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 05963106564A for ; Mon, 24 Jan 2011 20:40:09 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B560C8FC14 for ; Mon, 24 Jan 2011 20:40:08 +0000 (UTC) Received: by qyk36 with SMTP id 36so4339636qyk.13 for ; Mon, 24 Jan 2011 12:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=3sd9nOP+OBdRlCBKVNFu3j9J3Sg85gU+bU/IElY1FVg=; b=ul/kEoyZ/S06b4Ln8sempqQ32+7HJ7fB/8DZv7yffb0ZvHiyi4y7NeJWPrFf7XpVYq nxtn9aDmplG2WVCrLXp7824TMlI1qd3Ni2VePbubkYcu6ktebDaK6XlQ0j+MPxzURq9q ZBNT9fM6FNLfK4RQ9drumt0Oht3vWA5FL5sZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KR0ZH4Q9CZk7gGSQJMVwFV31yrot/1CKZbhEPq4Sews7zOus0dZ38o1NuwRj0Zo36Q GIU1+myUcgp12JMXKfvh7f31HS9T4ejhpXw0LoWMUNUE3gGov4knH+YcyZQWAD0hWGPq bwYo8f32M3QEY6DizPhKj5C6RZ6jH/4EklMok= MIME-Version: 1.0 Received: by 10.229.192.149 with SMTP id dq21mr4254463qcb.57.1295900186566; Mon, 24 Jan 2011 12:16:26 -0800 (PST) Received: by 10.229.245.135 with HTTP; Mon, 24 Jan 2011 12:16:26 -0800 (PST) Date: Mon, 24 Jan 2011 21:16:26 +0100 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [zfs] panic on import after a crash 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, 24 Jan 2011 20:40:09 -0000 Hi, after a system freeze, my FreeBSD 8-PRERELEASE does not boot anymore: a ZFS only install on one ssd. so i take my 9-CURRENT usb key (snapshot from nov 2010) and i go fixit. kldload /dist/boot/kernel/opensolaris.ko kldload /dist/boot/kernel/zfs.ko zpool import mypool and bam: http://img684.imageshack.us/img684/9225/panict.jpg it can be reproduced every time and i don't know what can i do now, any help would be appreciated. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 24 21:53:06 2011 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 B002F1065675; Mon, 24 Jan 2011 21:53:06 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 067FE8FC18; Mon, 24 Jan 2011 21:53:05 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p0OLr1fZ068979; Mon, 24 Jan 2011 23:53:01 +0200 (EET) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4D3DF4B8.4050901@ukr.net> Date: Mon, 24 Jan 2011 23:52:56 +0200 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Cc: freebsd-geom@freebsd.org Subject: [ZFS] How to change the geom label for a disk without losing data in the ZFS pool? 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, 24 Jan 2011 21:53:06 -0000 I just changed the "label: disk6" on "label: disk5" # zpool replace -f tank ad18p1 /dev/gpt/disk5 invalid vdev specification the following errors must be manually repaired: /dev/gpt/disk5 is part of active pool 'tank' # zpool upgrade This system is currently running ZFS pool version 14. All pools are formatted using this version. # zfs upgrade This system is currently running ZFS filesystem version 3. # zpool status pool: tank state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 ad18p1 OFFLINE 0 0 0 errors: No known data errors # gpart list ad18 Geom name: ad18 fwheads: 16 fwsectors: 63 last: 1465149134 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ad18p1 Mediasize: 750156339712 (699G) Sectorsize: 512 Mode: r0w0e0 rawuuid: 562396c8-25ab-11e0-9a58-00e04d7b690c rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b label: disk5 length: 750156339712 offset: 17408 type: freebsd-zfs index: 1 end: 1465149134 start: 34 Consumers: 1. Name: ad18 Mediasize: 750156374016 (699G) Sectorsize: 512 Mode: r0w0e0 -- Vladislav V. Prodan VVP24-UANIC +38[067]4584408 +38[099]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Tue Jan 25 00:00:25 2011 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 D735810656A8 for ; Tue, 25 Jan 2011 00:00:25 +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 9F8AD8FC1E for ; Tue, 25 Jan 2011 00:00:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0P00Pg3005653 for ; Tue, 25 Jan 2011 00:00:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0P00P2b005642; Tue, 25 Jan 2011 00:00:25 GMT (envelope-from gnats) Date: Tue, 25 Jan 2011 00:00:25 GMT Message-Id: <201101250000.p0P00P2b005642@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Matuska Cc: Subject: Re: kern/146941: [zfs] [panic] Kernel Double Fault - Happens constantly X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:00:25 -0000 The following reply was made to PR kern/146941; it has been noted by GNATS. From: Martin Matuska To: bug-followup@FreeBSD.org, martin.minkus@punz.co.nz Cc: Subject: Re: kern/146941: [zfs] [panic] Kernel Double Fault - Happens constantly Date: Tue, 25 Jan 2011 00:58:02 +0100 I have a similiar problem with 8.2-RC on two SuperMicro 6026T-3RF servers with 24GB RAM, but it happens randomly on heavy ZFS usage. Is the server a SuperMicro? Dmesg looks very like a SuperMicro server with LSI SAS controller. From owner-freebsd-fs@FreeBSD.ORG Tue Jan 25 00:10:14 2011 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 2DD7D1065673 for ; Tue, 25 Jan 2011 00:10:14 +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 034378FC08 for ; Tue, 25 Jan 2011 00:10:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0P0ADFm018018 for ; Tue, 25 Jan 2011 00:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0P0ADcT018017; Tue, 25 Jan 2011 00:10:13 GMT (envelope-from gnats) Date: Tue, 25 Jan 2011 00:10:13 GMT Message-Id: <201101250010.p0P0ADcT018017@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Matuska Cc: Subject: Re: kern/146941: [zfs] [panic] Kernel Double Fault - Happens constantly X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:10:14 -0000 The following reply was made to PR kern/146941; it has been noted by GNATS. From: Martin Matuska To: bug-followup@FreeBSD.org, martin.minkus@punz.co.nz Cc: Subject: Re: kern/146941: [zfs] [panic] Kernel Double Fault - Happens constantly Date: Tue, 25 Jan 2011 01:06:41 +0100 Sorry, didn't see this was vmware :) From owner-freebsd-fs@FreeBSD.ORG Tue Jan 25 07:52:41 2011 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 9683210656B7 for ; Tue, 25 Jan 2011 07:52:41 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 50AF08FC14 for ; Tue, 25 Jan 2011 07:52:40 +0000 (UTC) Received: by qwj9 with SMTP id 9so4815709qwj.13 for ; Mon, 24 Jan 2011 23:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=/y0g7dke2sypanjHMZCiHqGxfDqPQx/YmYMk+gQ3Gdk=; b=fTeuChq7yFoGgL06STsdBOykBX0egrmig7Zy0qnkr/vHvKnYycD8XZyjKACvnBlNEq HEpogsTsv00EhiTDJcb4xP+wlLE7HOAoFunvU+Uhe+uPFf1G/yxLvoIXOdKoyhY2+N9e xe8XW2Ond8HUzQDMngE0feIIcfKrmIjAt4JQE= 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:content-transfer-encoding; b=n704PIrDTL9nWkAQRKgpNe4NbRTOzMxEaORJTO2HiNRXu33qDUlFCInncIlZiXMhGU k6TKMjgke7zgi42Yft59MHWP2acgMEtDIY+MWxSriLqagVSjyShPfRDTj2VC/dceZcPv KfBpBsEJLzZYfEFAEBrH8/GDd8bp4HhAFkWy8= MIME-Version: 1.0 Received: by 10.229.95.193 with SMTP id e1mr4527974qcn.171.1295941960475; Mon, 24 Jan 2011 23:52:40 -0800 (PST) Received: by 10.229.245.135 with HTTP; Mon, 24 Jan 2011 23:52:40 -0800 (PST) In-Reply-To: References: Date: Tue, 25 Jan 2011 08:52:40 +0100 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [zfs] panic on import after a crash 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, 25 Jan 2011 07:52:41 -0000 2011/1/24 Micka=EBl Maillot : > Hi, > > after a system freeze, my FreeBSD 8-PRERELEASE does not boot anymore: > a ZFS only install on one ssd. > so i take my 9-CURRENT usb key (snapshot from nov 2010) and i go fixit. > kldload /dist/boot/kernel/opensolaris.ko > kldload /dist/boot/kernel/zfs.ko > zpool import mypool > and bam: > http://img684.imageshack.us/img684/9225/panict.jpg > it can be reproduced every time > and i don't know what can i do now, any help would be appreciated. > it's look it a RAM corruption (i'll run a memtest). why i try to import the pool on openindiana oi_148 it say: myssd FAULTED corrupted data and zpool import: cannot import 'myssd': one or more devices is currently unavailable From owner-freebsd-fs@FreeBSD.ORG Tue Jan 25 12:07:58 2011 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 0E2EF1065670 for ; Tue, 25 Jan 2011 12:07:58 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8C7228FC08 for ; Tue, 25 Jan 2011 12:07:57 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p0PBovlS013847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jan 2011 12:50:58 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p0PBohhP054426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 12:50:43 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id p0PBoh8I044362; Tue, 25 Jan 2011 12:50:43 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p0PBohpp044361; Tue, 25 Jan 2011 12:50:43 +0100 (CET) (envelope-from ticso) Date: Tue, 25 Jan 2011 12:50:43 +0100 From: Bernd Walter To: Karl Pielorz Message-ID: <20110125115042.GL36904@cicely7.cicely.de> References: <1ABA88EDF84B6472579216FE@Octa64> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ABA88EDF84B6472579216FE@Octa64> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 12:07:58 -0000 On Sat, Jan 22, 2011 at 10:39:13AM +0000, Karl Pielorz wrote: > > Hi, > > I've a small HP server I've been using recently (an NL36). I've got ZFS > setup on it, and it runs quite nicely. > > I was using the server for zeroing some drives the other day - and noticed > that a: > > dd if=/dev/zero of=/dev/ada0 bs=2m > > Gives around 12Mbyte/sec throughput when that's all that's running on the > machine. > > Looking in the BIOS is a "Enabled drive write cache" option - which was set > to 'No'. Changing it to 'Yes' - I now get around 90-120Mbyte/sec doing the > same thing. > > Knowing all the issues with IDE drives and write caches - is there any way > of telling if this would be safe to enable with ZFS? (i.e. if the option is > likely to be making the drive completely ignore flush requests?) - or if > it's still honouring the various 'write through' options if set on data to > be written? > > I'm presuming DD won't by default be writing the data with the 'flush' bit > set - as it probably doesn't know about it. > > Is there anyway of testing this? (say using some tool to write the data > using either lots of 'cache flush' or 'write through' stuff) - and seeing > if the performance drops back to nearer the 12Mbyte/sec? > > I've not enabled the option with the ZFS drives in the machine - I suppose > I could test it. > > Write performance on the unit isn't that bad [it's not stunning] - though > with 4 drives in a mirrored set - it probably helps hide some of the impact > this option might have. You are not testing real world performance with dd. Let me explain. You write in 2MB chunks, but those are splitted into smaller chunks. I don't know how big, but lets say 64k - maybe it's bigger with ada driver. I also don't know if those chunks are written at the same time, but also let asumme they are not and your values also say they are not. So for the drive it sees requests to write 64k at once. If the drive has write cache enabled it directly returns, if the cache is not enabled then it waits for the physical write to take place. Now the drive gets the next 64k - if the cache is enabled it directly returns - if the cache is not enabled it has to wait a complete disk rotation to write the data, since the blocks to be written just passed the head during the last write. The situation is that with cache you write the whole track in one roation, while writing without cache it takes multiple rotations. This limits the speed to one write per rotation, which is for a 10krpm drive with 64k writes 640Mbyte per minute, or 11Mbyte/s. Now the good side is that with ada you have command queueing, which means that the OS doesn't need to wait for a write to take place before issuing the next one - it can issue multiple write requests. So in the end you can fill up a whole track with outstanding data, the drive can write a whole track at once and every write call just waits in parallel. But with dd you write to the raw device, so there is no caching done by any filesystem and requests are serialized to the drive - therefor you won't see any benefit from NCQ as there are no multiple outstanding write requests known by the OS. I think msdosfs can't really use that feature, but UFS can, so with command queueing you can almost get the write cache performance without the risks. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-fs@FreeBSD.ORG Tue Jan 25 13:23:03 2011 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 191421065675 for ; Tue, 25 Jan 2011 13:23:03 +0000 (UTC) (envelope-from marco@tolstoy.tols.org) Received: from tolstoy.tols.org (tolstoy.tols.org [IPv6:2a02:898:0:20::57:1]) by mx1.freebsd.org (Postfix) with ESMTP id A37FF8FC0A for ; Tue, 25 Jan 2011 13:23:02 +0000 (UTC) Received: from tolstoy.tols.org (localhost [127.0.0.1]) by tolstoy.tols.org (8.14.4/8.14.4) with ESMTP id p0PDMwnY097885 for ; Tue, 25 Jan 2011 13:22:58 GMT (envelope-from marco@tolstoy.tols.org) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at tolstoy.tols.org Received: (from marco@localhost) by tolstoy.tols.org (8.14.4/8.14.4/Submit) id p0PDMwaE097884 for freebsd-fs@freebsd.org; Tue, 25 Jan 2011 14:22:58 +0100 (CET) (envelope-from marco) Date: Tue, 25 Jan 2011 14:22:58 +0100 From: Marco van Tol To: FreeBSD FS Message-ID: <20110125132258.GB94845@tolstoy.tols.org> Mail-Followup-To: FreeBSD FS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on tolstoy.tols.org Subject: runtime nfs mount options for existing mounts 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, 25 Jan 2011 13:23:03 -0000 Hi there, I hope I didn't overlook anything while trying to find out the answer to this question myself. I am running 8.2-PRERELEASE from Tue Nov 30 21:45:14 CET 2010. How would I find out about the current mount options for an existing NFS mount on an NFS client? For example, if I mount an NFS file system using: mount -t nfs -o rw,rsize=32768,wsize=32768,readahead=2 rhost:path node Suppose time goes by and I forgot what I used to mount the filesystem, how can I find out what the rsize, wsize and readahead are for the existing mount? (On another OS the settings are printed when just typing mount without any other options, which I find usefull in some circumstances) Thanks in advance, Marco van Tol -- Ik heb een hekel aan bumper-klevers, vanochtend zat er weer een voor me. From owner-freebsd-fs@FreeBSD.ORG Tue Jan 25 16:49:35 2011 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 19278106564A for ; Tue, 25 Jan 2011 16:49:35 +0000 (UTC) (envelope-from dppascual@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7D2B8FC1C for ; Tue, 25 Jan 2011 16:49:34 +0000 (UTC) Received: by qyk36 with SMTP id 36so5294448qyk.13 for ; Tue, 25 Jan 2011 08:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=wMyseWoBpOGGFIcKuznRPLKhe2daGEt6/LatbeGAqeY=; b=NAxVncf+hkMHKQfOTGHXKds0MW4gI6ZyRd96Zb7KNWph0FvUz83xTn9Jh01m2pmoXZ wSslwR2U8v1TScH5Pr6cuQDguB/GJc0sqf8arFTwl+7B+kzpNbl5eUsSgHFdFWc15CJC kyD/9dRpwBYF5nYjMoWnC1G2FQyhXjM+psAcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VeAUS49fjlodD/ttEjj/qWghZ+PNS9xetrMntFSOGQzP56IOE0S2Lmq50FUbTbCjiu +mBCC1RFObuEqEFY3IcJIe03O4FFBPQlLD74ZMT85n5D5EB4nzHm5shg1RQq+6qHPTM2 oh4KUSDolUQtxOxIUur3SxiKX+5st4gMzdhME= MIME-Version: 1.0 Received: by 10.229.213.80 with SMTP id gv16mr4989165qcb.181.1295972760978; Tue, 25 Jan 2011 08:26:00 -0800 (PST) Received: by 10.220.122.165 with HTTP; Tue, 25 Jan 2011 08:26:00 -0800 (PST) Date: Tue, 25 Jan 2011 17:26:00 +0100 Message-ID: From: Dani To: freebsd-fs@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: questions HAST 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, 25 Jan 2011 16:49:35 -0000 Hi, I am a student of the Polytechnic University of Madrid, I am doing a project based on FreeBSD storage server, in particular, I am using HAST. I've been reading the wiki (http://wiki.freebsd.org/HAST), but I have doubts about the replication and synchronization operation . Could you tell me where to get more detailed information about this aspect? If it isn't possible, could you give me more detail about the process of some write operation through HAST managed devices? Thanks in advance. Regards, Dani From owner-freebsd-fs@FreeBSD.ORG Wed Jan 26 10:40:06 2011 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 D6F01106566C for ; Wed, 26 Jan 2011 10:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C6C8F8FC0A for ; Wed, 26 Jan 2011 10:40:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0QAe6b0097967 for ; Wed, 26 Jan 2011 10:40:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0QAe6Gq097964; Wed, 26 Jan 2011 10:40:06 GMT (envelope-from gnats) Date: Wed, 26 Jan 2011 10:40:06 GMT Message-Id: <201101261040.p0QAe6Gq097964@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/154228: 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: Wed, 26 Jan 2011 10:40:06 -0000 The following reply was made to PR kern/154228; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154228: commit references a PR Date: Wed, 26 Jan 2011 10:34:28 +0000 (UTC) Author: kib Date: Wed Jan 26 10:34:21 2011 New Revision: 217880 URL: http://svn.freebsd.org/changeset/base/217880 Log: Treat async buffer writes from the gjournal switcher thread the same as from syncer. We shall not sleep on running buffer space when suspending. Reproduced and tested by: pho PR: kern/154228 MFC after: 1 week Modified: head/sys/geom/journal/g_journal.c Modified: head/sys/geom/journal/g_journal.c ============================================================================== --- head/sys/geom/journal/g_journal.c Wed Jan 26 10:08:37 2011 (r217879) +++ head/sys/geom/journal/g_journal.c Wed Jan 26 10:34:21 2011 (r217880) @@ -3033,6 +3033,7 @@ g_journal_switcher(void *arg) int error; mp = arg; + curthread->td_pflags |= TDP_NORUNNINGBUF; for (;;) { g_journal_switcher_wokenup = 0; error = tsleep(&g_journal_switcher_state, PRIBIO, "jsw:wait", _______________________________________________ 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 Thu Jan 27 14:39:25 2011 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 9A9A6106564A for ; Thu, 27 Jan 2011 14:39:25 +0000 (UTC) (envelope-from canevet@embl.fr) Received: from emblmta1.embl.fr (emblmta1.embl.fr [193.49.43.176]) by mx1.freebsd.org (Postfix) with ESMTP id 39EDB8FC12 for ; Thu, 27 Jan 2011 14:39:24 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.60,386,1291590000"; d="asc'?scan'208";a="979951" Received: from unknown (HELO [172.26.15.11]) ([172.26.15.11]) by emblmta1.embl.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 27 Jan 2011 15:09:30 +0100 From: =?ISO-8859-1?Q?Micka=EBl_Can=E9vet?= To: freebsd-fs@freebsd.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-2xaiYGlh5RXWT4RpndOg" Date: Thu, 27 Jan 2011 15:09:35 +0100 Message-ID: <1296137375.27843.11.camel@pc286.embl.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Subject: "rpc mount export: RPC: Can't decode result" when export list is to long X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:39:25 -0000 --=-2xaiYGlh5RXWT4RpndOg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I have a configured a FreeBSD 8.2RC2 exporting 200+ ZFS volumes with NFS. If I just set sharenfs=3D"on" on server, I can do a 'showmount -e' on my Client (CentOS 5.5), but if a put a list of 7 or more hosts in the sharenfs command, the 'showmount -e' on the client returns "rpc mount export: RPC: Can't decode result" and so automount does not work. Is there some kind of limitation of export list ? Thank you, Micka=C3=ABl --=-2xaiYGlh5RXWT4RpndOg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1BfJ8ACgkQZjBmN5Hi/YaLjgCfXLVl9NHWmaYFAIOrcgiOeqjd jJsAn3MRLm0GZH/mIiOmtmMJq8BuHjXh =j+G0 -----END PGP SIGNATURE----- --=-2xaiYGlh5RXWT4RpndOg-- From owner-freebsd-fs@FreeBSD.ORG Thu Jan 27 15:17:07 2011 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 3010A1065670 for ; Thu, 27 Jan 2011 15:17:07 +0000 (UTC) (envelope-from canevet@embl.fr) Received: from emblmta1.embl.fr (emblmta1.embl.fr [193.49.43.176]) by mx1.freebsd.org (Postfix) with ESMTP id B64088FC12 for ; Thu, 27 Jan 2011 15:17:06 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.60,386,1291590000"; d="asc'?scan'208";a="980642" Received: from unknown (HELO [172.26.15.11]) ([172.26.15.11]) by emblmta1.embl.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 27 Jan 2011 16:17:05 +0100 From: =?ISO-8859-1?Q?Micka=EBl_Can=E9vet?= To: Weldon Godfrey In-Reply-To: <46cfac53-03f5-4f3f-a34a-a4a504af31b0@email.android.com> References: <1296137375.27843.11.camel@pc286.embl.fr> <46cfac53-03f5-4f3f-a34a-a4a504af31b0@email.android.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-p1Hhg2nZR8e3+AJ4TpRL" Date: Thu, 27 Jan 2011 16:17:10 +0100 Message-ID: <1296141430.27843.16.camel@pc286.embl.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Cc: freebsd-fs@freebsd.org Subject: Re: "rpc mount export: RPC: Can't decode result" when export list is to long X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 15:17:07 -0000 --=-p1Hhg2nZR8e3+AJ4TpRL Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thank you for you quick answer. I tested with 'sysctl vfs.nfsrv.maxthreads=3D20' and even 'sysctl vfs.nfsrv.maxthreads=3D1000' (though I'm not sure it's reasonable), but I still have the problem. Moreover, sysctl vfs.nfsrv.threads stays to 4 (maybe it goes up, then down before I can notice anything)... I noticed that if I wait a few minutes, showmount -e works once, then fails again. Somebody has another idea ? Micka=C3=ABl On Thu, 2011-01-27 at 08:50 -0600, Weldon Godfrey wrote: > did you up maxthreads for nfs on the server? the default us only 4. the= re is a sysctl tunable. you can change it without restarting server or nfs= d and will take effect. place it in /etc/sysctl.conf so it does it at boot= up >=20 > "Micka=C3=ABl Can=C3=A9vet" wrote: >=20 > >Hi, > > > >I have a configured a FreeBSD 8.2RC2 exporting 200+ ZFS volumes with > >NFS. If I just set sharenfs=3D"on" on server, I can do a 'showmount -e' > >on > >my Client (CentOS 5.5), but if a put a list of 7 or more hosts in the > >sharenfs command, the 'showmount -e' on the client returns "rpc mount > >export: RPC: Can't decode result" and so automount does not work. > > > >Is there some kind of limitation of export list ? > > > >Thank you, > >Micka=C3=ABl >=20 --=-p1Hhg2nZR8e3+AJ4TpRL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1BjHYACgkQZjBmN5Hi/Yb9/gCfcEiTBdg3PV671jmB2rFjL1v3 GlUAoKXkmVwvMDUqMdKLPgHhPskZ+DUY =MpfQ -----END PGP SIGNATURE----- --=-p1Hhg2nZR8e3+AJ4TpRL-- From owner-freebsd-fs@FreeBSD.ORG Fri Jan 28 22:04:48 2011 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 74CDD106566C for ; Fri, 28 Jan 2011 22:04:48 +0000 (UTC) (envelope-from z_serg_2000@mail.ru) Received: from f68.mail.ru (f68.mail.ru [217.69.129.107]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4608FC0A for ; Fri, 28 Jan 2011 22:04:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Type:Reply-To:Date:Mime-Version:Subject:To:From; bh=qwo0ITb4MSgnqLEmyy/2FiDTIc1KTU7LDog3IQkXVXk=; b=ZZ0LyvM+LEKo4yJy2YZA6ZhXNCJAd/qIgzfDNLjzW8XwyhvVaUdIm69g005lKu01Zj5b2WkdLm8WJ7VVAMvQB9tWidjlmkAjkM+65qz6TgRySHw8jvBj/xpDIlkHLFM+; Received: from mail by f68.mail.ru with local id 1PiwQw-0007Xk-00 for freebsd-fs@freebsd.org; Sat, 29 Jan 2011 01:04:46 +0300 Received: from [94.28.207.238] by win.mail.ru with HTTP; Sat, 29 Jan 2011 01:04:46 +0300 From: Serg Z To: freebsd-fs Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [94.28.207.238] Date: Sat, 29 Jan 2011 01:04:46 +0300 Message-Id: X-Spam: Not detected X-Mras: Ok Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Count of mounting filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Serg Z List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 22:04:48 -0000 Hello! How many filesystems I can mount? What limits count of mounting filesystem? Serg From owner-freebsd-fs@FreeBSD.ORG Fri Jan 28 22:47:07 2011 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 E1DCB1065673 for ; Fri, 28 Jan 2011 22:47:07 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id A0E258FC0A for ; Fri, 28 Jan 2011 22:47:07 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p0SMl5ME084050 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 28 Jan 2011 17:47:06 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D43475D.5050008@sentex.net> Date: Fri, 28 Jan 2011 17:46:53 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Subject: ZFS help! 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, 28 Jan 2011 22:47:08 -0000 I had just added another set of disks to my zfs array. It looks like the drive cage with the new drives is faulty. I had added a couple of files to the main pool, but not much. Is there any way to restore the pool below ? I have a lot of files on ad0,1,4,6 and ada4,5,6,7 and perhaps one file on the new drives in the bad cage. # zpool status -v pool: tank1 state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scrub: none requested config: NAME STATE READ WRITE CKSUM tank1 UNAVAIL 0 0 0 insufficient replicas raidz1 ONLINE 0 0 0 ad0 ONLINE 0 0 0 ad1 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada4 ONLINE 0 0 0 ada5 ONLINE 0 0 0 ada6 ONLINE 0 0 0 ada7 ONLINE 0 0 0 raidz1 UNAVAIL 0 0 0 insufficient replicas ada0 UNAVAIL 0 0 0 cannot open ada1 UNAVAIL 0 0 0 cannot open ada2 UNAVAIL 0 0 0 cannot open ada3 UNAVAIL 0 0 0 cannot open ---Mike From owner-freebsd-fs@FreeBSD.ORG Fri Jan 28 23:01:13 2011 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 B27961065670 for ; Fri, 28 Jan 2011 23:01:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7598FC12 for ; Fri, 28 Jan 2011 23:01:13 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAP3ZQk2DaFvO/2dsb2JhbACEFKFiqxqQZ4Ejgzh0BIUYhw8 X-IronPort-AV: E=Sophos;i="4.60,394,1291611600"; d="scan'208";a="108863611" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 28 Jan 2011 18:01:12 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6A67BB3F95; Fri, 28 Jan 2011 18:01:12 -0500 (EST) Date: Fri, 28 Jan 2011 18:01:12 -0500 (EST) From: Rick Macklem To: =?utf-8?Q?Micka=C3=ABl_Can=C3=A9vet?= Message-ID: <1761895428.1056373.1296255672375.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1296137375.27843.11.camel@pc286.embl.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: "rpc mount export: RPC: Can't decode result" when export list is to long X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 23:01:13 -0000 > Hi, > > I have a configured a FreeBSD 8.2RC2 exporting 200+ ZFS volumes with > NFS. If I just set sharenfs="on" on server, I can do a 'showmount -e' > on > my Client (CentOS 5.5), but if a put a list of 7 or more hosts in the > sharenfs command, the 'showmount -e' on the client returns "rpc mount > export: RPC: Can't decode result" and so automount does not work. > > Is there some kind of limitation of export list ? > Well, "showmount -e" queries the server's mountd. I don't know of a limitation (except maybe the maximum size of a UDP datagram), but as far as I am aware, it will only report entries in /etc/exports. Your email would suggest otherwise and since I'm not up to speed w.r.t. how ZFS's sharenfs command works, I can't help... You might want to try putting the exported file systems in /etc/exports instead. I'm also a bit surprized that automount cares what the mountd protocol thinks is exported but, again, I'm not up to speed on what automount actually does. Sorry I can't be of more help, rick From owner-freebsd-fs@FreeBSD.ORG Fri Jan 28 23:08:26 2011 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 61290106567A for ; Fri, 28 Jan 2011 23:08:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2114A8FC25 for ; Fri, 28 Jan 2011 23:08:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAFvbQk2DaFvO/2dsb2JhbACEFKFiqzKQZ4Ejgzh0BIUYhw8 X-IronPort-AV: E=Sophos;i="4.60,394,1291611600"; d="scan'208";a="107598668" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 28 Jan 2011 18:08:25 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2AEEBB3F27; Fri, 28 Jan 2011 18:08:25 -0500 (EST) Date: Fri, 28 Jan 2011 18:08:25 -0500 (EST) From: Rick Macklem To: Marco van Tol Message-ID: <496514462.1056535.1296256105160.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110125132258.GB94845@tolstoy.tols.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: FreeBSD FS Subject: Re: runtime nfs mount options for existing mounts 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, 28 Jan 2011 23:08:26 -0000 > > How would I find out about the current mount options for an existing > NFS > mount on an NFS client? > > For example, if I mount an NFS file system using: > mount -t nfs -o rw,rsize=32768,wsize=32768,readahead=2 rhost:path node > > Suppose time goes by and I forgot what I used to mount the filesystem, > how can I find out what the rsize, wsize and readahead are for the > existing mount? > > (On another OS the settings are printed when just typing mount without > any other options, which I find usefull in some circumstances) > I don't think you can get this stuff out of the FreeBSD kernel right now. (I was hoping someone else was going to answer, but no one did:-) As to whether or not it should, I think it would be a nice feature, but I've got a lot of other stuff on my plate right now. I think it would take some sort of extension to the nmount(2) syscall or maybe a new syscall + noew VFS_xxx() op. I can say that, if someone else came up with the syscall/VFS changes, I could easily implement a function in the NFS client that generates the name/value pairs like nmount() uses. (There is currently a function that basically does that for the old mount() and I think a slightly modified version of that would do it. However, I haven't actually tried it.:-) Anyone feel like an nmount() related project to do this? rick From owner-freebsd-fs@FreeBSD.ORG Sat Jan 29 00:10:58 2011 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 8994D1065673 for ; Sat, 29 Jan 2011 00:10:58 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id C4B5C8FC15 for ; Sat, 29 Jan 2011 00:10:57 +0000 (UTC) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep15-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110129001056.BPGS1633.viefep15-int.chello.at@edge01.upcmail.net>; Sat, 29 Jan 2011 01:10:56 +0100 Received: from pinky ([213.46.23.80]) by edge01.upcmail.net with edge id 1CAs1g00n1jgp3H01CAurE; Sat, 29 Jan 2011 01:10:56 +0100 X-SourceIP: 213.46.23.80 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Marco van Tol" , "Rick Macklem" References: <496514462.1056535.1296256105160.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 29 Jan 2011 01:10:52 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <496514462.1056535.1296256105160.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Opera Mail/11.01 (Win32) X-Cloudmark-Analysis: v=1.1 cv=JvXQbuMnWGQeb488dJ7w43Du7THgE+O7ieb9U20/rjk= c=1 sm=0 a=FrWdF4c4Z5wA:10 a=bgpUlknNv7MA:10 a=kj9zAlcOel0A:10 a=BOkMkCL_MedZw7oRCcIA:9 a=jkVLrHDAuUwi-Jkmqq84AaF-JzoA:4 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: FreeBSD FS Subject: Re: runtime nfs mount options for existing mounts 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, 29 Jan 2011 00:10:58 -0000 On Sat, 29 Jan 2011 00:08:25 +0100, Rick Macklem wrote: >> >> How would I find out about the current mount options for an existing >> NFS >> mount on an NFS client? >> >> For example, if I mount an NFS file system using: >> mount -t nfs -o rw,rsize=32768,wsize=32768,readahead=2 rhost:path node >> >> Suppose time goes by and I forgot what I used to mount the filesystem, >> how can I find out what the rsize, wsize and readahead are for the >> existing mount? >> >> (On another OS the settings are printed when just typing mount without >> any other options, which I find usefull in some circumstances) >> > I don't think you can get this stuff out of the FreeBSD kernel right now. > (I was hoping someone else was going to answer, but no one did:-) > > As to whether or not it should, I think it would be a nice feature, but > I've got a lot of other stuff on my plate right now. > > I think it would take some sort of extension to the nmount(2) syscall or > maybe a new syscall + noew VFS_xxx() op. > > I can say that, if someone else came up with the syscall/VFS changes, I > could easily implement a function in the NFS client that generates the > name/value pairs like nmount() uses. (There is currently a function that > basically does that for the old mount() and I think a slightly modified > version of that would do it. However, I haven't actually tried it.:-) > > Anyone feel like an nmount() related project to do this? > > rick Linux gives this with nfsstat -m. Also when wsize/rsize is negotiated between server/client you can see the used value with that. Ronald. From owner-freebsd-fs@FreeBSD.ORG Sat Jan 29 04:46:37 2011 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 8786B106566B for ; Sat, 29 Jan 2011 04:46:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 10A748FC08 for ; Sat, 29 Jan 2011 04:46:36 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0T4kWhY030228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Jan 2011 15:46:32 +1100 Date: Sat, 29 Jan 2011 15:46:32 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem In-Reply-To: <496514462.1056535.1296256105160.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: <20110129144348.T967@besplex.bde.org> References: <496514462.1056535.1296256105160.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD FS Subject: Re: runtime nfs mount options for existing mounts 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, 29 Jan 2011 04:46:37 -0000 On Fri, 28 Jan 2011, Rick Macklem wrote: >> How would I find out about the current mount options for an existing >> NFS >> mount on an NFS client? > I don't think you can get this stuff out of the FreeBSD kernel right now. > (I was hoping someone else was going to answer, but no one did:-) > > As to whether or not it should, I think it would be a nice feature, but > I've got a lot of other stuff on my plate right now. > > I think it would take some sort of extension to the nmount(2) syscall or > maybe a new syscall + noew VFS_xxx() op. nmount() doesn't do this. It only mounts, and only copies out error messages. (Despite having a horrible uio interface, it never uses uiomove() and uses copyin() to fetch its args). > I can say that, if someone else came up with the syscall/VFS changes, I > could easily implement a function in the NFS client that generates the > name/value pairs like nmount() uses. (There is currently a function that > basically does that for the old mount() and I think a slightly modified > version of that would do it. However, I haven't actually tried it.:-) Old mount(2) doesn't do this. All mount(8) just use statfs(2). statfs() just returns the old mount flags and a couple of other broken things (async and sync i/o counts) that are used mainly by mount -v. > Anyone feel like an nmount() related project to do this? Hopefully statfs(2) would not become as horrible as nmount(2). statfs() wants to return a fix-ed size structure. Fix-size structs and a limited set of flags options are much easier to work with than strings. Despite, or because of its horribleness, nmount(2) still can't handle basic parsing like "-u -o current,..." or "-o fstab,...", or support userland parsing of "-o current", and and has horrible messes for parsing negative options. Such parsing belongs in userland where it was (although "-u -o current" has never really worked, for the same reason that "mount -v" has never really worked -- there is no way to determine mount options from userland except for ones in statfs()'s flags. However, the kernel knows all the current mount options and could support "-u -o current,..." if it had any clue about parsing. That alone wouldn't be very useful though, since parsing of fstabs clearly belongs in userland only, and the userland parser needs to handle "-o current" too, to properly merge it with "-o fstab" and other options (in any order, with cancellations...). This shows that no parsing in the kernel for nmount() is useful. Once all the current options are exported to userland, for printing in mount -v and merging with "-o current", the userland parser needs to understand the format of _all_ of them well enough merge them with other command-line options. The format cannot be completely-free-format strings, like nmount() can handle now if it has parsing code for a "free" format somewhere. The merge also requires userland knowing a complete list of options for the current file system (since for example, the absense of a positive option should be equivalent to the presence of the corresponding negative option. nmount() has had mounds of bugs from getting this wrong for the absent "rw" option being equivalent to a present "noro" and not having a flag to distinguish between an absent "rw" and a present "noro"). Once userland understands the format, it can do all the parsing and present the results to the kernel in a canonical form so that the kernel doesn't need to do much parsing (e.g., it doesn't need to convert "nonofoo" to the absense of "foo", or worry about N-tuple negatives, or discard duplicates, or cancel "foo" with "nofoo"... Instead of the uio interface for nmount(), I would have used a single string, with contents like a mount(8) command line with 1 single space as the only field separator. The general case would be hard to parse, but pre-parsing by mount utilities would give a canonical form and could use special field separators if the space field separator turns out to be a problem. The string passed by the mount utilities must contain all the options that don't have their default settings, since it is all that will come back for mount -v to prettyprint and mount -o -current to reparse. Hopefully, sysctls are enough for retrieving the current options and the supported options and their default settings. All of this could be done more easily and hackishly by a utility like nfsstat doing lots of sysctls to retrieve the options. It's a bit surprising that nfsstat doesn't already do this, since nfs has more nonstandard options than most file systems, and many of them can already be determined without the kernel having any way to report them directly, by watching network statistics. (I often get confused by messing up the tcp/udp option and r/wsize options and looking at network statistics is the only way that I know of of determining what I mis-set them to.) Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Jan 29 10:30:06 2011 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 1C4A81065674 for ; Sat, 29 Jan 2011 10:30:06 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 965BF8FC14 for ; Sat, 29 Jan 2011 10:30:05 +0000 (UTC) Received: by bwz12 with SMTP id 12so4081093bwz.13 for ; Sat, 29 Jan 2011 02:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=+DnuSuqpt9wE08Ar59IwjEO5K1uJ6gJrFcV2WMWqP8I=; b=HI96FoyfLH9/AgdQUW8AZGa45QR522i/CQv01pD24iO3GdM8YKmYT2BjzOflVPgTMO rR9aJpBzDR6iBKeBsIqnnDlG1uvh3x092avhxkxsNIkqr9DeVE+0+xXucWTUAequLeQe UDoByJZhD2JdqeADrkbYbL6NJx6/KWQsz6PvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=SL844dkub5NNmJh3Pl1exDeIQW9ZrbKHr04+ldcbHQkPc5/NGlxzDaBXZUbyKx3kE7 oJieDAzAieJMH+xxK7/XQ7t6bOAPmBi2mWxt2FYE9vlzlB/tCJXih896An7Lg5Y15ClS 2q6/Amf0RJwRjUeazKeJTunIOpst3ydY5qCl0= MIME-Version: 1.0 Received: by 10.204.72.20 with SMTP id k20mr3299297bkj.184.1296297004129; Sat, 29 Jan 2011 02:30:04 -0800 (PST) Sender: artemb@gmail.com Received: by 10.204.49.13 with HTTP; Sat, 29 Jan 2011 02:30:04 -0800 (PST) Date: Sat, 29 Jan 2011 02:30:04 -0800 X-Google-Sender-Auth: jSKLG_wCLhCDD0ZKMxR86iFhJEQ Message-ID: From: Artem Belevich To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Subject: ZFS: clock_t overflow in l2arc_feed_thread 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, 29 Jan 2011 10:30:06 -0000 Hi, I'm using ZFS v15 on RELENG_8/amd64 box. Some time back I've noticed that after a while ZFS starts to consume 100% of CPU time on one of the cores. After a bit of digging it appears that the problem is due to an integer overflow. On amd64 (as wel as most other FreeBSD platforms) clock_t is a signed 32-bit integer. On OpenSolaris clock_t is long. In compat/opensolaris/sys/time.h LBOLT is defined as #define LBOLT ((gethrtime() * hz) / NANOSEC) With HZ=1000 LBOLT overflows clock_t variables when uptime reaches ~24days. This affects l2arc_write_interval() which calculates the time when L2ARC feed thread should be woken up. The end result is that for the next 24 days l2arc_feed_thread no longer sleeps as long as it should have. Changing clock_t to a larger type globally looks somewhat risky to me. It's probably easier to change those few places in ZFS code that use clock_t to uint64_t instead. In case someone is interested, I've posted my patch here: http://pastebin.com/Q2T3x2AB --Artem From owner-freebsd-fs@FreeBSD.ORG Sat Jan 29 15:36:44 2011 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 A1B08106566B for ; Sat, 29 Jan 2011 15:36:44 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id 35F128FC17 for ; Sat, 29 Jan 2011 15:36:44 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 6084F13838D; Sat, 29 Jan 2011 16:36:43 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AtCQ43WVSDiK; Sat, 29 Jan 2011 16:36:41 +0100 (CET) Received: from [192.168.1.43] (bband-dyn5.178-40-80.t-com.sk [178.40.80.5]) by mail.vx.sk (Postfix) with ESMTPSA id C9C8A13837B; Sat, 29 Jan 2011 16:36:40 +0100 (CET) Message-ID: <4D443407.7010604@FreeBSD.org> Date: Sat, 29 Jan 2011 16:36:39 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Artem Belevich References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------010203040206090602080803" Cc: freebsd-fs Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread 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, 29 Jan 2011 15:36:44 -0000 This is a multi-part message in MIME format. --------------010203040206090602080803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I agree to you that we have different types and this may be an issue but I disagree to your patch. clock_t is not signed (int64_t) and this can be done in a much easier (and cleaner way) without touching the code, see attached patch. Dňa 29.01.2011 11:30, Artem Belevich wrote / napísal(a) > Hi, > > I'm using ZFS v15 on RELENG_8/amd64 box. Some time back I've noticed > that after a while ZFS starts to consume 100% of CPU time on one of > the cores. After a bit of digging it appears that the problem is due > to an integer overflow. > > On amd64 (as wel as most other FreeBSD platforms) clock_t is a signed > 32-bit integer. On OpenSolaris clock_t is long. > > In compat/opensolaris/sys/time.h LBOLT is defined as > #define LBOLT ((gethrtime() * hz) / NANOSEC) > > With HZ=1000 LBOLT overflows clock_t variables when uptime reaches > ~24days. This affects l2arc_write_interval() which calculates the time > when L2ARC feed thread should be woken up. The end result is that for > the next 24 days l2arc_feed_thread no longer sleeps as long as it > should have. > > Changing clock_t to a larger type globally looks somewhat risky to me. > It's probably easier to change those few places in ZFS code that use > clock_t to uint64_t instead. > > In case someone is interested, I've posted my patch here: > http://pastebin.com/Q2T3x2AB > > --Artem > _______________________________________________ > 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" --------------010203040206090602080803 Content-Type: text/x-patch; name="opensolaris_types.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="opensolaris_types.patch" --- sys/cddl/compat/opensolaris/sys/types.h.orig 2011-01-29 16:25:48.857709276 +0100 +++ sys/cddl/compat/opensolaris/sys/types.h 2011-01-29 16:26:03.219594069 +0100 @@ -29,6 +29,9 @@ #ifndef _OPENSOLARIS_SYS_TYPES_H_ #define _OPENSOLARIS_SYS_TYPES_H_ +typedef long clock_t; +#define _CLOCK_T_DECLARED + /* * This is a bag of dirty hacks to keep things compiling. */ --------------010203040206090602080803-- From owner-freebsd-fs@FreeBSD.ORG Sat Jan 29 16:37:42 2011 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 379C5106566B for ; Sat, 29 Jan 2011 16:37:42 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id E47898FC17 for ; Sat, 29 Jan 2011 16:37:41 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PjDnw-0004Wm-L6 for freebsd-fs@freebsd.org; Sat, 29 Jan 2011 17:37:40 +0100 Received: from cpe-188-129-82-107.dynamic.amis.hr ([188.129.82.107]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 29 Jan 2011 17:37:40 +0100 Received: from ivoras by cpe-188-129-82-107.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 29 Jan 2011 17:37:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Sat, 29 Jan 2011 17:37:28 +0100 Lines: 14 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-82-107.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: Subject: Re: Count of mounting filesystem 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, 29 Jan 2011 16:37:42 -0000 On 28/01/2011 23:04, Serg Z wrote: > Hello! > > How many filesystems I can mount? > What limits count of mounting filesystem? Short answer is "too large to bother". I once did 14,000 mount points just for fun, and it still wasn't the limit: http://ivoras.net/blog/tree/2009-10-20.the-night-of-1000-jails.html I think the real limit would be available memory to hold the file system structures. From owner-freebsd-fs@FreeBSD.ORG Sat Jan 29 17:28:02 2011 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 9C6801065670 for ; Sat, 29 Jan 2011 17:28:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 398F58FC0C for ; Sat, 29 Jan 2011 17:28:01 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0THRueU018966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jan 2011 04:27:59 +1100 Date: Sun, 30 Jan 2011 04:27:56 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Martin Matuska In-Reply-To: <4D443407.7010604@FreeBSD.org> Message-ID: <20110130041141.G30713@besplex.bde.org> References: <4D443407.7010604@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-386676537-1296322076=:30713" Cc: freebsd-fs Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread 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, 29 Jan 2011 17:28:02 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-386676537-1296322076=:30713 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 29 Jan 2011, Martin Matuska wrote: > I agree to you that we have different types and this may be an issue but > I disagree to your patch. > clock_t is not signed (int64_t) and this can be done in a much easier > (and cleaner way) without touching the code, see attached patch. clock_t should be not signed (int32_t), i.e. uint32_t. This is quite broken in FreeBSD, although it was almost correct in 4.4BSD-Lite ( clock_t was always unsigned long there). Now there is the following mess: amd64/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... = */ arm/include/_types.h:typedef=09__uint32_t=09__clock_t;=09=09/* clock()... *= / i386/include/_types.h:typedef=09unsigned long=09__clock_t;=09=09/* clock().= =2E. */ ia64/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... *= / mips/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... *= / powerpc/include/_types.h:typedef=09__uint32_t=09__clock_t;=09=09/* clock().= =2E. */ sparc64/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()..= =2E */ sun4v/include/_types.h:typedef=09__int32_t=09__clock_t;=09=09/* clock()... = */ I think the unsignedness 64-bit arches regressed by copying a bug from NetBSD via alpha. NetBSD had to fix hundreds or thousands of longs in old BSD since the size of long is too fuzzy for ABIs once long is actually longer than int (> 32 bits) although still not long (! > register width), and seems to have broken the unsignedness when changing the type. > D=C5=88a 29.01.2011 11:30, Artem Belevich wrote / nap=C3=ADsal(a) >> Hi, >> >> I'm using ZFS v15 on RELENG_8/amd64 box. Some time back I've noticed >> that after a while ZFS starts to consume 100% of CPU time on one of >> the cores. After a bit of digging it appears that the problem is due >> to an integer overflow. >> >> On amd64 (as wel as most other FreeBSD platforms) clock_t is a signed >> 32-bit integer. On OpenSolaris clock_t is long. I don't know how declaring it as long for cddl works when it is not long in FreeBSD. Pehraps because FreeBSD doesn't really use clock_t. Also, long on i386 is just 32 bits, so I don't see how declaring clock_t as long helps in general. Declaring it as uint32_t might delay the overflow from 24.5 days to 49 days. Bruce --0-386676537-1296322076=:30713-- From owner-freebsd-fs@FreeBSD.ORG Sat Jan 29 19:06:37 2011 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 874E11065670; Sat, 29 Jan 2011 19:06:37 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E02FB8FC08; Sat, 29 Jan 2011 19:06:36 +0000 (UTC) Received: by bwz12 with SMTP id 12so4284270bwz.13 for ; Sat, 29 Jan 2011 11:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QfBrEKpzjgCloH2uRaJEgk58MtFIVuCqJm8g4aGL/jM=; b=K9B+p+cMbeNepwamVKyQ3w5kKVMO7wSpF81ZveTyJebNFGkk+u0MqH/1xUbRaO9oie 7Jirs+wsTWmCjWR4RkgWLD1mmaXIyZQ2SV0oruWsJpXiS1MoJA+6j2pucJZ1aN+a4MkV 64mt3TttMJEG6Pxgea3qp+pzeUKA1EPA2kuAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=txmPUYRflSkd8tWybzma+DU8u6vuDF3/wtv1Vo+MUcvPlArqTZGp+Lz+LYsh/Nrc2N ByYw3UTZUbdrHt7aNTwmC58sJOTRrbB0rFPMeQpezu1EX3dY2LUzgZ7jZpPaOZFegosY pBRJpdH+40W5ceTo3WL27a4YMD/c0h/QR2hYA= MIME-Version: 1.0 Received: by 10.204.33.73 with SMTP id g9mr3658166bkd.157.1296327995606; Sat, 29 Jan 2011 11:06:35 -0800 (PST) Sender: artemb@gmail.com Received: by 10.204.49.13 with HTTP; Sat, 29 Jan 2011 11:06:35 -0800 (PST) In-Reply-To: <4D443407.7010604@FreeBSD.org> References: <4D443407.7010604@FreeBSD.org> Date: Sat, 29 Jan 2011 11:06:35 -0800 X-Google-Sender-Auth: q7srke4mrqGQ2xyVVxtL4gJIAow Message-ID: From: Artem Belevich To: Martin Matuska Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread 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, 29 Jan 2011 19:06:37 -0000 On Sat, Jan 29, 2011 at 7:36 AM, Martin Matuska wrote: > I agree to you that we have different types and this may be an issue but > I disagree to your patch. > clock_t is not signed (int64_t) and this can be done in a much easier > (and cleaner way) without touching the code, see attached patch. I like the minimalism of your patch. It should fix the overflow on LP64, but it would still be there on i386. To avoid this particular problem we need int64_t even on 32-bit platforms. Either that, or we should change the way we emulate solaris' LBOLT in FreeBSD. Another concern I have is with this patch we'll end up with parts of kernel compiled with 32-bit clock_t and other parts build with 64-bit clock_t. If someone passes a pointer to clock_t between these two classes of code, we'll have a problem. --Artem From owner-freebsd-fs@FreeBSD.ORG Sat Jan 29 20:17:27 2011 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 49F381065696 for ; Sat, 29 Jan 2011 20:17:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0880B8FC14 for ; Sat, 29 Jan 2011 20:17:26 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAMcERE2DaFvO/2dsb2JhbACEFKFYqwCPd4Ejgzd0BIUThw4 X-IronPort-AV: E=Sophos;i="4.60,397,1291611600"; d="scan'208";a="108932542" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 29 Jan 2011 15:17:25 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EFEF9B3F21; Sat, 29 Jan 2011 15:17:25 -0500 (EST) Date: Sat, 29 Jan 2011 15:17:25 -0500 (EST) From: Rick Macklem To: =?utf-8?Q?Micka=C3=ABl_Can=C3=A9vet?= Message-ID: <715248679.1071311.1296332245920.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: "rpc mount export: RPC: Can't decode result" when export list is to long X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 20:17:27 -0000 Oops, I should have looked at the sources... In mountd.c it limits the RPC size to 8800 for UDP and 9000 for TCP. (UDPMSGSIZE and RPC_MAXDATASIZE respectively) You could increase this by changing: svc_dg_create(...,0, 0); else svc_vc_create(...,RPC_MAXDATASIZE, RPC_MAXDATASIZE); to svc_dg_create(..., 63 * 1024, 63 * 1024); else svc_vc_create(..., 200 * 1024, 200 * 1024); in mountd.c But... The Linux client might set a smaller limit in its client side RPC library anyhow. Again, I am surprised that the Linux automount checks the exports reported via mountd, but??? Did you check to see if the mounts work manually? (That would confirm if they are exported ok.) rick ps: UDP datagrams are limited to 64K, but since I can't remember if that size includes the UDP header, I went with 63K. For TCP it is limited to 256K in the RPC library and to a somewhat lower value with the default kern.ipc.maxsockbuf. (Basically what the kernel sets sb_max_adj to.) From owner-freebsd-fs@FreeBSD.ORG Sat Jan 29 20:29:29 2011 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 30C30106564A for ; Sat, 29 Jan 2011 20:29:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id DF5C18FC15 for ; Sat, 29 Jan 2011 20:29:28 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAC8HRE2DaFvO/2dsb2JhbACEFaFYqxCPeIEjgzd0BIUThw4 X-IronPort-AV: E=Sophos;i="4.60,397,1291611600"; d="scan'208";a="108933086" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 29 Jan 2011 15:29:28 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1453DB3F25; Sat, 29 Jan 2011 15:29:28 -0500 (EST) Date: Sat, 29 Jan 2011 15:29:28 -0500 (EST) From: Rick Macklem To: Bruce Evans Message-ID: <10004544.1071580.1296332968025.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110129144348.T967@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: FreeBSD FS Subject: Re: runtime nfs mount options for existing mounts 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, 29 Jan 2011 20:29:29 -0000 > > I can say that, if someone else came up with the syscall/VFS > > changes, I > > could easily implement a function in the NFS client that generates > > the > > name/value pairs like nmount() uses. (There is currently a function > > that > > basically does that for the old mount() and I think a slightly > > modified > > version of that would do it. However, I haven't actually tried > > it.:-) > > Old mount(2) doesn't do this. All mount(8) just use statfs(2). > statfs() > just returns the old mount flags and a couple of other broken things > (async and sync i/o counts) that are used mainly by mount -v. > All I was trying to say here was that the NFS client(s) already have a function that turns the flags, etc in the old mount args into the name/value pairs used by nmount() so that the old mount() still works. I believe that this function could return the mount options (set as flag bits in the nfs variant of the kernel mount structure, etc) as nmount() style name/value pairs if there was a way to get them to userland. (It could be done as yet another flag for nfssvc() if no other file system needs this capability.) rick From owner-freebsd-fs@FreeBSD.ORG Sat Jan 29 20:43:43 2011 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 8EBEE106564A for ; Sat, 29 Jan 2011 20:43:43 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 3FC818FC19 for ; Sat, 29 Jan 2011 20:43:43 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PjHe2-000897-Ad for freebsd-fs@freebsd.org; Sat, 29 Jan 2011 21:43:42 +0100 Received: from 81-174-44-253.dynamic.ngi.it ([81.174.44.253]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 29 Jan 2011 21:43:42 +0100 Received: from lapo by 81-174-44-253.dynamic.ngi.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 29 Jan 2011 21:43:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Lapo Luchini Date: Sat, 29 Jan 2011 21:43:34 +0100 Lines: 24 Message-ID: <4D447BF6.6000105@lapo.it> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <4AEEDB3B.5020600@quip.cz> <4AF46CA9.1040904@quip.cz> <9bbcef730911061101h5356d2acob2ac8791afe112@mail.gmail.com> <4AF5D611.7060408@quip.cz> <9bbcef730911071242m5ad91720xcccb7586c6848ffd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 81-174-44-253.dynamic.ngi.it User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 In-Reply-To: <9bbcef730911071242m5ad91720xcccb7586c6848ffd@mail.gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=C8F252FB; url=http://www.lapo.it/pgpkey.txt Cc: freebsd-stable@freebsd.org Subject: Re: Performance issues with 8.0 ZFS and sendfile/lighttpd 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, 29 Jan 2011 20:43:43 -0000 Ivan Voras wrote: > 2009/11/7 Miroslav Lachman <000.fbsd@quip.cz>: >> And as you noted, read, write, fault, total and percent are not updated on >> machine with ZFS, so I can't compare it with UFS2 based machine. >> Is this bug in top fixed in 8.x? Will you file a PR? (you know more about FS >> related things than me :]) > > Not much... it depends on from where the stats are collected - there > is a fair bit of file system infrastructure that ZFS bypasses and if > these stats come from it, they cannot be collected. Any news about that? I can see it's not in 8.1-RELEASE, but I didn't check in any later release (yet). Should we file a PR not to forget about that? Is the following patch safe to apply? http://people.freebsd.org/~avg/zfs-ru.diff -- Lapo Luchini - http://lapo.it/ “X-rays will prove to be a hoax.” (Lord Kelvin, 1883)