From owner-freebsd-fs@FreeBSD.ORG Sun Dec 16 12:13:20 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9E0BD0F for ; Sun, 16 Dec 2012 12:13:20 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id D439C8FC0A for ; Sun, 16 Dec 2012 12:13:19 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 0603EF019CD; Sun, 16 Dec 2012 13:13:17 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 19.0270] X-CRM114-CacheID: sfid-20121216_13131_4F8E0903 X-CRM114-Status: Good ( pR: 19.0270 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sun Dec 16 13:13:17 2012 X-DSPAM-Confidence: 0.9960 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50cdbadd817965918320430 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, >+On, 0.00069, MFC, 0.00096, UTC, 0.00099, wrote+>>, 0.00168, >>+>, 0.00185, wrote+>, 0.00225, >+>, 0.00359, >+>, 0.00359, In-Reply-To*mail.gmail.com>, 0.00395, References*mail.gmail.com>, 0.00416, References*fsn.hu>, 0.00426, References*fsn.hu>, 0.00426, the+code, 0.00426, >+And, 0.00426, >>+On, 0.00461, svn, 0.00461, revision, 0.00503, can+I, 0.00503, 11+29, 0.00552, wrote, 0.00592, wrote, 0.00592, stack, 0.00613, wrote+>>>, 0.00613, I+get, 0.00669, >>>+>>>, 0.00690, X-Spambayes-Classification: ham; 0.00 Received: from [192.168.3.2] (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id F2DE3F019BE; Sun, 16 Dec 2012 13:13:15 +0100 (CET) Message-ID: <50CDBAD9.6010406@fsn.hu> Date: Sun, 16 Dec 2012 13:13:13 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Damien Fleuriot Subject: Re: zfs panic, solaris_assert References: <50CC86D4.2070502@fsn.hu> <50CC8AE5.5070804@fsn.hu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 12:13:20 -0000 On 12/15/2012 10:05 PM, Damien Fleuriot wrote: > On 15 December 2012 15:36, Attila Nagy wrote: >> On 12/15/2012 03:19 PM, Attila Nagy wrote: >>> Hi, >>> >>> Since running svn revision r243704 I get frequent panics: >>> panic: solaris assert: sa.sa_magic == 0x2F505A (0x4f22a8ed == 0x2f505a), >>> file: >>> /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, >>> line: 597 >>> cpuid = 0 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >>> kdb_backtrace() at kdb_backtrace+0x37 >>> panic() at panic+0x1ce >>> assfail3() at assfail3+0x29 >>> zfs_space_delta_cb() at zfs_space_delta_cb+0xbe >>> dmu_objset_userquota_get_ids() at dmu_objset_userquota_get_ids+0x142 >>> dnode_sync() at dnode_sync+0xc5 >>> dmu_objset_sync_dnodes() at dmu_objset_sync_dnodes+0x5d >>> dmu_objset_sync() at dmu_objset_sync+0x17f >>> dsl_pool_sync() at dsl_pool_sync+0xca >>> spa_sync() at spa_sync+0x34a >>> txg_sync_thread() at txg_sync_thread+0x139 >>> fork_exit() at fork_exit+0x11f >>> fork_trampoline() at fork_trampoline+0xe >>> --- trap 0, rip = 0, rsp = 0xffffff90231accf0, rbp = 0 --- >>> >>> I can't tell whether it's the data or the code. If the latter, is this >>> fixed in later revisions? >>> If it's the file system, what can I do with this? >>> >> It seems this is introduced with the following mega-MFC: >> r243674 | mm | 2012-11-29 15:05:04 +0100 (Thu, 29 Nov 2012) | 223 lines >> > For what it's worth, running on amd64 with 4gb ram: > 10-CURRENT r244183: Thu Dec 13 15:35:28 UTC 2012 > > And not experiencing ZFS/solaris problems. > > Loader tunables: > vm.kmem_size="3072M" > vfs.zfs.arc_min="128M" > vfs.zfs.arc_max="2048M" I think it's related to the load and/or the on disk data. From owner-freebsd-fs@FreeBSD.ORG Sun Dec 16 12:21:43 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 313D8DF1 for ; Sun, 16 Dec 2012 12:21:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0518FC0A for ; Sun, 16 Dec 2012 12:21:42 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA13989; Sun, 16 Dec 2012 14:21:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TkDDv-00030C-Ak; Sun, 16 Dec 2012 14:21:39 +0200 Message-ID: <50CDBCD0.5070305@FreeBSD.org> Date: Sun, 16 Dec 2012 14:21:36 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Attila Nagy Subject: Re: zfs panic, solaris_assert References: <50CC86D4.2070502@fsn.hu> In-Reply-To: <50CC86D4.2070502@fsn.hu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 12:21:43 -0000 on 15/12/2012 16:19 Attila Nagy said the following: > Hi, > > Since running svn revision r243704 I get frequent panics: > panic: solaris assert: sa.sa_magic == 0x2F505A (0x4f22a8ed == 0x2f505a), > file: > /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, > line: 597 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x1ce > assfail3() at assfail3+0x29 > zfs_space_delta_cb() at zfs_space_delta_cb+0xbe > dmu_objset_userquota_get_ids() at dmu_objset_userquota_get_ids+0x142 > dnode_sync() at dnode_sync+0xc5 > dmu_objset_sync_dnodes() at dmu_objset_sync_dnodes+0x5d > dmu_objset_sync() at dmu_objset_sync+0x17f > dsl_pool_sync() at dsl_pool_sync+0xca > spa_sync() at spa_sync+0x34a > txg_sync_thread() at txg_sync_thread+0x139 > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff90231accf0, rbp = 0 --- > > I can't tell whether it's the data or the code. If the latter, is this fixed in > later revisions? > If it's the file system, what can I do with this? Nobody's sure. Do you have a crash dump? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sun Dec 16 12:23:11 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE692E77; Sun, 16 Dec 2012 12:23:11 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id E10C98FC0C; Sun, 16 Dec 2012 12:23:10 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 278EDF01A25; Sun, 16 Dec 2012 13:23:09 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 15.4854] X-CRM114-CacheID: sfid-20121216_13230_4C1EEC5C X-CRM114-Status: Good ( pR: 15.4854 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sun Dec 16 13:23:09 2012 X-DSPAM-Confidence: 0.9940 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50cdbd2d863401035295428 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, wrote+>, 0.00225, >>+>>, 0.00405, >>+>>, 0.00405, References*fsn.hu>, 0.00426, the+code, 0.00426, >>+I, 0.00426, svn, 0.00461, revision, 0.00503, can+I, 0.00503, To*FreeBSD.org>, 0.00552, wrote, 0.00592, stack, 0.00613, References*FreeBSD.org>, 0.00613, I+get, 0.00669, >+Not, 0.00690, >+Do, 0.00690, >>+Hi, 0.00690, it's+the, 0.00735, it's+the, 0.00735, >+on, 0.00787, panics, 0.00787, this?, 0.00847, =+0, 0.00861, =+0, 0.00861, in+>>, 0.01000, X-Spambayes-Classification: ham; 0.00 Received: from [192.168.3.2] (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id DD0A8F01A18; Sun, 16 Dec 2012 13:23:07 +0100 (CET) Message-ID: <50CDBD2A.2010504@fsn.hu> Date: Sun, 16 Dec 2012 13:23:06 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: zfs panic, solaris_assert References: <50CC86D4.2070502@fsn.hu> <50CDBCD0.5070305@FreeBSD.org> In-Reply-To: <50CDBCD0.5070305@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 12:23:11 -0000 On 12/16/2012 01:21 PM, Andriy Gapon wrote: > on 15/12/2012 16:19 Attila Nagy said the following: >> Hi, >> >> Since running svn revision r243704 I get frequent panics: >> panic: solaris assert: sa.sa_magic == 0x2F505A (0x4f22a8ed == 0x2f505a), >> file: >> /data/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c, >> line: 597 >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> kdb_backtrace() at kdb_backtrace+0x37 >> panic() at panic+0x1ce >> assfail3() at assfail3+0x29 >> zfs_space_delta_cb() at zfs_space_delta_cb+0xbe >> dmu_objset_userquota_get_ids() at dmu_objset_userquota_get_ids+0x142 >> dnode_sync() at dnode_sync+0xc5 >> dmu_objset_sync_dnodes() at dmu_objset_sync_dnodes+0x5d >> dmu_objset_sync() at dmu_objset_sync+0x17f >> dsl_pool_sync() at dsl_pool_sync+0xca >> spa_sync() at spa_sync+0x34a >> txg_sync_thread() at txg_sync_thread+0x139 >> fork_exit() at fork_exit+0x11f >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip = 0, rsp = 0xffffff90231accf0, rbp = 0 --- >> >> I can't tell whether it's the data or the code. If the latter, is this fixed in >> later revisions? >> If it's the file system, what can I do with this? > Nobody's sure. > Do you have a crash dump? > Not yet. From owner-freebsd-fs@FreeBSD.ORG Sun Dec 16 12:28:54 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 386E9BC for ; Sun, 16 Dec 2012 12:28:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8B78FC16 for ; Sun, 16 Dec 2012 12:28:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA14025; Sun, 16 Dec 2012 14:28:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TkDKr-00030i-L5; Sun, 16 Dec 2012 14:28:49 +0200 Message-ID: <50CDBE80.7080308@FreeBSD.org> Date: Sun, 16 Dec 2012 14:28:48 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tom Subject: Re: zfs: is it possible to set metaslab_debug to 1? References: <50CCA8B8.7010808@bsdunix.ch> In-Reply-To: <50CCA8B8.7010808@bsdunix.ch> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 12:28:54 -0000 on 15/12/2012 18:43 Tom said the following: > Hi, > > Is it possible to set metaslab_debug to 1 on freebsd without recompiling: > usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c > > /* > * Metaslab debugging: when set, keeps all space maps in core to verify > frees. > */ > static int metaslab_debug = 0; > > Is this even possible on FreeBSD? It often helps with ZFS perfomance > issues on Solaris with lots of ram. kgdb -w set metaslab_debug=1 Were you looking for something like this? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sun Dec 16 14:47:37 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 74C5029E; Sun, 16 Dec 2012 14:47:37 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 26CDD8FC0A; Sun, 16 Dec 2012 14:47:36 +0000 (UTC) Received: from conversation.bsdunix.ch (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 7DE3714BBC; Sun, 16 Dec 2012 14:47:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by conversation.bsdunix.ch (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FPFniepm5gi; Sun, 16 Dec 2012 14:47:35 +0000 (UTC) Received: from toms-saftbook.home (177-185.107-92.cust.bluewin.ch [92.107.185.177]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTPSA id CB73314BB9; Sun, 16 Dec 2012 14:47:34 +0000 (UTC) Message-ID: <50CDDF06.2030309@bsdunix.ch> Date: Sun, 16 Dec 2012 15:47:34 +0100 From: Tom User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: zfs: is it possible to set metaslab_debug to 1? References: <50CCA8B8.7010808@bsdunix.ch> <50CDBE80.7080308@FreeBSD.org> In-Reply-To: <50CDBE80.7080308@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 14:47:37 -0000 Am 16.12.12 13:28, schrieb Andriy Gapon: > on 15/12/2012 18:43 Tom said the following: >> Hi, >> >> Is it possible to set metaslab_debug to 1 on freebsd without recompiling: >> usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c >> >> /* >> * Metaslab debugging: when set, keeps all space maps in core to verify >> frees. >> */ >> static int metaslab_debug = 0; >> >> Is this even possible on FreeBSD? It often helps with ZFS perfomance >> issues on Solaris with lots of ram. > > kgdb -w > set metaslab_debug=1 > > Were you looking for something like this? > > Yes, exactly Thank you. Regards, Tom From owner-freebsd-fs@FreeBSD.ORG Mon Dec 17 11:06:43 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D533983 for ; Mon, 17 Dec 2012 11:06:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 40BE38FC21 for ; Mon, 17 Dec 2012 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBHB6h4r023433 for ; Mon, 17 Dec 2012 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBHB6g0k023431 for freebsd-fs@FreeBSD.org; Mon, 17 Dec 2012 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Dec 2012 11:06:42 GMT Message-Id: <201212171106.qBHB6g0k023431@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 Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 11:06:43 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/174372 fs [zfs] Pagefault appears to be related to ZFS o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/174060 fs [ext2fs] Ext2FS system crashes (buffer overflow?) o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool o kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165923 fs [nfs] Writing to NFS-backed mmapped files fails if flu o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p 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/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/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 bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small 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 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/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/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa 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 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/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 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 f 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 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/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/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/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/139407 fs [smbfs] [panic] smb mount causes system crash if remot 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/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/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha 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 kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance 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/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 o kern/116583 fs [ffs] [hang] System freezes for short time when using 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 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/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 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/36566 fs [smbfs] System reboot with dead smb mount and umount 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 294 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Dec 17 12:37:30 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F1A013B; Mon, 17 Dec 2012 12:37:30 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [176.9.45.25]) by mx1.freebsd.org (Postfix) with ESMTP id BF07D8FC0C; Mon, 17 Dec 2012 12:37:29 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id AB7605B45; Mon, 17 Dec 2012 13:37:28 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id tuZedWX2gHtn; Mon, 17 Dec 2012 13:37:23 +0100 (CET) Received: from [10.9.8.1] (188-167-78-15.dynamic.chello.sk [188.167.78.15]) by mail.vx.sk (Postfix) with ESMTPSA id 02E2D5B39; Mon, 17 Dec 2012 13:37:22 +0100 (CET) Message-ID: <50CF1202.9070805@FreeBSD.org> Date: Mon, 17 Dec 2012 13:37:22 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE References: <50C9AFC6.6080902@FreeBSD.org> <50CA1639.1010409@FreeBSD.org> In-Reply-To: <50CA1639.1010409@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 12:37:30 -0000 On 13.12.2012 18:54, Andriy Gapon wrote: > on 13/12/2012 19:46 olivier said the following: >> Thanks. I'll be sure to follow your suggestions next time this happens. >> >> I have a naive question/suggestion though. I see from browsing past discussions on >> ZFS problems that it has been suggested a number of times that problems that >> appear to originate in ZFS in fact come from lower layers; in particular because >> of driver bugs or disks in the process of failing. It seems that it can take a lot >> of time to troubleshoot such problems. I accept that ZFS behavior correctly leaves >> dealing with timeouts to lower layers, but it seems to me that the ZFS layer would >> be a great place to warn the user about issues and provide some information to >> troubleshoot them. >> >> For example, if some I/O requests get lost because of a buggy driver, the driver >> itself might not be the best place to identify those lost requests. But perhaps we >> could have a compile time option in ZFS code that spits out a warning if it gets >> stuck waiting for a particular request to come back for more than say 10 seconds, >> and identifies the problematic disk? I'm sure there would be cases where these >> warnings would be unwarranted, and I imagine that changes in the code to provide >> such warnings would impact performance; so one certainly would not want that code >> active by default. But someone in my position could certainly recompile the kernel >> with a ZFS debugging option turned on to figure out the problem. >> >> I understand that ZFS code comes from upstream, and that you guys probably want to >> keep FreeBSD-specific changes minimal. If that's a big problem, even just a patch >> provided "as such" that does not make it into the FreeBSD code base might be >> extremely useful. I wish I could help write something like that, but I know very >> little about the kernel or ZFS. I would certainly be willing to help with testing. > Google for "zfs deadman". This is already committed upstream and I think that it > is imported into FreeBSD, but I am not sure... Maybe it's imported just into the > vendor area and is not merged yet. > So, when enabled this logic would panic a system as a way of letting know that > something is wrong. You can read in the links why panic was selected for this job. > > And speaking FreeBSD-centric - I think that our CAM layer would be a perfect place > to detect such issues in non-ZFS-specific way. > I can try to merge the ZFS deadman stuff (r242732) to HEAD, but I guess this will be something for a 1-month MFC period. Afterwards, a 9-STABLE patch can be easily created. https://www.illumos.org/issues/3246 https://hg.openindiana.org/upstream/illumos/illumos-gate/rev/921a99998bb4 Cheers, mm -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-fs@FreeBSD.ORG Mon Dec 17 12:57:31 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2E59CD7; Mon, 17 Dec 2012 12:57:31 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 92D258FC17; Mon, 17 Dec 2012 12:57:30 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so4587583lah.13 for ; Mon, 17 Dec 2012 04:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8mwtH2xHw8BLf+pBELb9zOvsnhHDLl/4FwJP1KNCong=; b=Gsy+W4Arbe3eqFBZXdVwfx+vXx4UW7x7xIcOiB2Hr56nJ/FRJGi7lfx7kXflPCL5N5 xP+GEsgMaGC/CYsZ0AFB4z6ftgQDe8GUB4zX15XZRb284fLiyK8naopSIAL+QlWdem+W 1qFJsEusimajab/j1R2iiO8c8ORJBiXYlHuZ62rXdaijv5Ifx8MBTTtO8tiOc8ssBZp1 DPYptH4RaQUjdv4H/u1nJh1iVGPpCRpbgcYM1G2rVXNJLYx81JLML9FnASHVEQXTSI0h vEPgLqlqCEH/4T2azv0ZYkGkeIfzVf+0xqvgYv2nDuIiFFQg1HQJg9bXFGwaCev33Dpg 8O9Q== Received: by 10.112.44.135 with SMTP id e7mr5920253lbm.55.1355749049271; Mon, 17 Dec 2012 04:57:29 -0800 (PST) Received: from [192.168.1.129] ([91.196.229.122]) by mx.google.com with ESMTPS id pm16sm4880860lab.8.2012.12.17.04.57.26 (version=SSLv3 cipher=OTHER); Mon, 17 Dec 2012 04:57:28 -0800 (PST) Message-ID: <50CF16B0.9090104@gmail.com> Date: Mon, 17 Dec 2012 14:57:20 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> <50C8DC8E.1080204@FreeBSD.org> <50C9AD2C.7000301__8690.12248372219$1355394383$gmane$org@FreeBSD.org> In-Reply-To: <50C9AD2C.7000301__8690.12248372219$1355394383$gmane$org@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 12:57:31 -0000 13.12.2012 12:25, Andriy Gapon: > on 12/12/2012 21:35 Dimitry Andric said the following: >> Especially the recursive spa_load and traverse_visitbp calls are scary, >> because that can grow out of hand very quickly. It is probably tricky >> to remove the recursion... > > Re-entering spa_load once is normal and is expected. > traverse_visitbp is also expected to recurse depending on data layout. > So yeah, it's probably even trickier than teaching clang to allocate smaller stack > frames ;-) I hit this one again, but this time my world and kernel are compiled with stock gcc. Pictures 3 to 5: https://picasaweb.google.com/104021007361271711472/I386ZfsDoubleFault This happens on mounting root after unclean shutdown. I fixed my pool with booting amd64 kernel, after this i386 kernel starts fine. Maybe it's just time to accept that ZFS on i386 is not stable? Current handbook elaborates on ZFS like it's known to work on i386. -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Mon Dec 17 21:44:21 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7C94E23 for ; Mon, 17 Dec 2012 21:44:21 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 75D9B8FC15 for ; Mon, 17 Dec 2012 21:44:21 +0000 (UTC) Received: (qmail 5046 invoked by uid 0); 17 Dec 2012 21:44:14 -0000 Received: from 67.206.184.86 by rms-us005 with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 17 Dec 2012 16:44:11 -0500 From: "Dieter BSD" Message-ID: <20121217214413.263570@gmx.com> MIME-Version: 1.0 Subject: FFS - Still using rotational delay with modern disks? To: freebsd-fs@freebsd.org,freebsd-performance@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: eve9cJEH3zOlNR3dAHAh+cZ+IGRvb0Ci X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:44:21 -0000 The newfs man page says: -a maxcontig Specify the maximum number of contiguous blocks that will be laid out before forcing a rotational delay.  The default value is 16. See tunefs(8) for more details on how to set this option. Is this still a good idea with modern drives where the number of sectors per track varies, and no one but the manufacturer knows how many sectors a particular track has? [1] Skipping sectors could unnecessarily force a seek to the next track, thus hurting rather than helping performance. I have to wonder if FreeBSD even supports any hard drives that don't use zone bit recording? The tunefs man page does not mention this parameter. [1] http://en.wikipedia.org/wiki/Zone_bit_recording From owner-freebsd-fs@FreeBSD.ORG Mon Dec 17 22:20:30 2012 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8673857C; Mon, 17 Dec 2012 22:20:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 666CD8FC18; Mon, 17 Dec 2012 22:20:28 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA00155; Tue, 18 Dec 2012 00:20:26 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tkj2v-0005rx-Up; Tue, 18 Dec 2012 00:20:25 +0200 Message-ID: <50CF9AA9.1030808@FreeBSD.org> Date: Tue, 18 Dec 2012 00:20:25 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Volodymyr Kostyrko Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> <50C8DC8E.1080204@FreeBSD.org> <50C9AD2C.7000301__8690.12248372219$1355394383$gmane$org@FreeBSD.org> <50CF16B0.9090104@gmail.com> In-Reply-To: <50CF16B0.9090104@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:20:30 -0000 on 17/12/2012 14:57 Volodymyr Kostyrko said the following: > 13.12.2012 12:25, Andriy Gapon: >> on 12/12/2012 21:35 Dimitry Andric said the following: >>> Especially the recursive spa_load and traverse_visitbp calls are scary, >>> because that can grow out of hand very quickly. It is probably tricky >>> to remove the recursion... >> >> Re-entering spa_load once is normal and is expected. >> traverse_visitbp is also expected to recurse depending on data layout. >> So yeah, it's probably even trickier than teaching clang to allocate smaller >> stack >> frames ;-) > > I hit this one again, but this time my world and kernel are compiled with stock > gcc. Pictures 3 to 5: > > https://picasaweb.google.com/104021007361271711472/I386ZfsDoubleFault > > This happens on mounting root after unclean shutdown. I fixed my pool with > booting amd64 kernel, after this i386 kernel starts fine. > > Maybe it's just time to accept that ZFS on i386 is not stable? Current handbook > elaborates on ZFS like it's known to work on i386. Yes, it is known to work. It's been already mentioned many times that ZFS works much better on amd64. It's up to a (potential) user to understand limitations of i386 and to decide whether to use ZFS, in what situations and how. You may want to consider using KSTACK_PAGES=4 in your kernel configuration. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Dec 17 23:24:02 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4491B8C; Mon, 17 Dec 2012 23:24:02 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id 9CC588FC0C; Mon, 17 Dec 2012 23:24:02 +0000 (UTC) Received: from eureka.lemis.com (1032.x.rootbsd.net [208.86.224.149]) by w3.lemis.com (Postfix) with ESMTP id 5B8643B86E; Mon, 17 Dec 2012 23:23:55 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 46911F7952; Tue, 18 Dec 2012 10:23:51 +1100 (EST) Date: Tue, 18 Dec 2012 10:23:51 +1100 From: Greg 'groggy' Lehey To: Dieter BSD Subject: Re: FFS - Still using rotational delay with modern disks? Message-ID: <20121217232351.GB26067@eureka.lemis.com> References: <20121217214413.263570@gmx.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tjCHc7DPkfUGtrlw" Content-Disposition: inline In-Reply-To: <20121217214413.263570@gmx.com> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-fs@freebsd.org, freebsd-performance@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 23:24:02 -0000 --tjCHc7DPkfUGtrlw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Monday, 17 December 2012 at 16:44:11 -0500, Dieter BSD wrote: > The newfs man page says: > > -a maxcontig > Specify the maximum number of contiguous blocks that will be laid > out before forcing a rotational delay. =A0The default value is 16. > See tunefs(8) for more details on how to set this option. > > Is this still a good idea with modern drives where the number of > sectors per track varies, and no one but the manufacturer knows how > many sectors a particular track has? No. It looks as if this, and also a number of comments in sys/ufs/ffs/fs.h and sys/ufs/ffs/ffs_alloc.c, are leftovers from the Olden Days. The value isn't used anywhere that I can see. Unless somebody can show that I'm wrong, I'd suggest that this is a documentation issue that I can take a look at. Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --tjCHc7DPkfUGtrlw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDPqYYACgkQIubykFB6QiMTdgCgnSbwTAVdmMhQmevW58pQkzfa 6YEAmwSLbiObOc/9ezYwrh6RS+yE9Hsh =f3VJ -----END PGP SIGNATURE----- --tjCHc7DPkfUGtrlw-- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 18 00:03:33 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1AD7D4BF; Tue, 18 Dec 2012 00:03:33 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7D08FC0A; Tue, 18 Dec 2012 00:03:32 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id o19so3035553qap.14 for ; Mon, 17 Dec 2012 16:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qz71msNQFazbcqcGtH2NkC2rVE1x7F8bbEGAE7bcvdQ=; b=wxiGDQfAYXhfnPAPChoB1Xpt2q/ndixfKnMC8ae1f2o/HX7YP5hBMbaQZhVAX5Q2YT 3+hGapdbaXPio1DlOJNF/9Hs15sKegYHrnDlVafPO+Fkx5Wa3I9kwYsr637oxZPCW2uZ 4Ly2aqqj0lpQgcSPi4pe6VWQPt4f7o93CbYyvfUCciG7pFVrhZCKx9eNcP/oMINEKITH yQPzqW/qvL+rAyhXRY5ZqHfCMGhqJ5ugWzjFP4XQpsBvELUAa2eZv9rkaQgtlknRAJhT lEFvhc4pA5o43RPSk8VEQjzsXkaboEuGalTNGYUMcQgqMWxOUJOaizCa+r3ThBFXa4u+ kpvA== MIME-Version: 1.0 Received: by 10.49.74.10 with SMTP id p10mr37391qev.35.1355788609895; Mon, 17 Dec 2012 15:56:49 -0800 (PST) Received: by 10.229.78.96 with HTTP; Mon, 17 Dec 2012 15:56:49 -0800 (PST) In-Reply-To: <20121217232351.GB26067@eureka.lemis.com> References: <20121217214413.263570@gmx.com> <20121217232351.GB26067@eureka.lemis.com> Date: Tue, 18 Dec 2012 02:56:49 +0300 Message-ID: Subject: Re: FFS - Still using rotational delay with modern disks? From: Sergey Kandaurov To: "Greg 'groggy' Lehey" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, freebsd-performance@freebsd.org, Dieter BSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 00:03:33 -0000 On 18 December 2012 03:23, Greg 'groggy' Lehey wrote: > On Monday, 17 December 2012 at 16:44:11 -0500, Dieter BSD wrote: >> The newfs man page says: >> >> -a maxcontig >> Specify the maximum number of contiguous blocks that will be laid >> out before forcing a rotational delay. The default value is 16. >> See tunefs(8) for more details on how to set this option. >> >> Is this still a good idea with modern drives where the number of >> sectors per track varies, and no one but the manufacturer knows how >> many sectors a particular track has? > > No. > > It looks as if this, and also a number of comments in sys/ufs/ffs/fs.h > and sys/ufs/ffs/ffs_alloc.c, are leftovers from the Olden Days. The > value isn't used anywhere that I can see. Unless somebody can show > that I'm wrong, I'd suggest that this is a documentation issue that I > can take a look at. [performance@ list trimmed] I'm not sure about this. In UFS fs_maxcontig controls fs_contigsumsize during newfs, both saved in superblock, and fs_contigsumsize is widely used throughout FFS. sblock.fs_maxcontig = maxcontig; if (sblock.fs_maxcontig < sblock.fs_maxbsize / sblock.fs_bsize) { sblock.fs_maxcontig = sblock.fs_maxbsize / sblock.fs_bsize; printf("Maxcontig raised to %d\n", sblock.fs_maxbsize); } if (sblock.fs_maxcontig > 1) sblock.fs_contigsumsize = MIN(sblock.fs_maxcontig,FS_MAXCONTIG); For ext2 this is instead "reconstructed" in the in-memory sblock copy in mountfs(). /* * Calculate the maximum contiguous blocks and size of cluster summary * array. In FFS this is done by newfs; however, the superblock * in ext2fs doesn't have these variables, so we can calculate * them here. */ ump->um_e2fs->e2fs_maxcontig = MAX(1, MAXPHYS / ump->um_e2fs->e2fs_bsize); if (ump->um_e2fs->e2fs_maxcontig > 0) ump->um_e2fs->e2fs_contigsumsize = MIN(ump->um_e2fs->e2fs_maxcontig, EXT2_MAXCONTIG); else ump->um_e2fs->e2fs_contigsumsize = 0; -- wbr, pluknet From owner-freebsd-fs@FreeBSD.ORG Tue Dec 18 00:12:35 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF62D906; Tue, 18 Dec 2012 00:12:35 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id BE8B88FC13; Tue, 18 Dec 2012 00:12:35 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id qBI0CW0c098207; Mon, 17 Dec 2012 16:12:32 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201212180012.qBI0CW0c098207@chez.mckusick.com> To: Sergey Kandaurov Subject: Re: FFS - Still using rotational delay with modern disks? In-reply-to: Date: Mon, 17 Dec 2012 16:12:32 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: Greg 'groggy' Lehey , freebsd-fs@freebsd.org, Dieter BSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 00:12:36 -0000 > Date: Tue, 18 Dec 2012 02:56:49 +0300 > Subject: Re: FFS - Still using rotational delay with modern disks? > From: Sergey Kandaurov > To: "Greg 'groggy' Lehey" > Cc: freebsd-fs@freebsd.org, freebsd-performance@freebsd.org, > Dieter BSD > > On 18 December 2012 03:23, Greg 'groggy' Lehey wrote: > > On Monday, 17 December 2012 at 16:44:11 -0500, Dieter BSD wrote: > >> The newfs man page says: > >> > >> -a maxcontig > >> Specify the maximum number of contiguous blocks that will be laid > >> out before forcing a rotational delay. The default value is 16. > >> See tunefs(8) for more details on how to set this option. > >> > >> Is this still a good idea with modern drives where the number of > >> sectors per track varies, and no one but the manufacturer knows how > >> many sectors a particular track has? > > > > No. > > > > It looks as if this, and also a number of comments in sys/ufs/ffs/fs.h > > and sys/ufs/ffs/ffs_alloc.c, are leftovers from the Olden Days. The > > value isn't used anywhere that I can see. Unless somebody can show > > that I'm wrong, I'd suggest that this is a documentation issue that I > > can take a look at. > > [performance@ list trimmed] > > I'm not sure about this. > In UFS fs_maxcontig controls fs_contigsumsize during newfs, both saved > in superblock, and fs_contigsumsize is widely used throughout FFS. > > sblock.fs_maxcontig = maxcontig; > if (sblock.fs_maxcontig < sblock.fs_maxbsize / sblock.fs_bsize) { > sblock.fs_maxcontig = sblock.fs_maxbsize / sblock.fs_bsize; > printf("Maxcontig raised to %d\n", sblock.fs_maxbsize); > } > if (sblock.fs_maxcontig > 1) > sblock.fs_contigsumsize = MIN(sblock.fs_maxcontig,FS_MAXCONTIG); > > > For ext2 this is instead "reconstructed" in the in-memory sblock copy > in mountfs(). > > /* > * Calculate the maximum contiguous blocks and size of cluster summary > * array. In FFS this is done by newfs; however, the superblock > * in ext2fs doesn't have these variables, so we can calculate > * them here. > */ > ump->um_e2fs->e2fs_maxcontig = MAX(1, MAXPHYS / > ump->um_e2fs->e2fs_bsize); > if (ump->um_e2fs->e2fs_maxcontig > 0) > ump->um_e2fs->e2fs_contigsumsize = > MIN(ump->um_e2fs->e2fs_maxcontig, EXT2_MAXCONTIG); > else > ump->um_e2fs->e2fs_contigsumsize = 0; > > -- > wbr, > pluknet Maxcontig is still in the filesystem. However, it is generally overridden (i.e., ignored) when clustering and dynamic block reallocation are in effect which they are by default and have been since some time early in the 1990's. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Tue Dec 18 03:47:17 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D6B192C; Tue, 18 Dec 2012 03:47:17 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id B45328FC17; Tue, 18 Dec 2012 03:47:13 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBI3l0Mu012903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2012 14:47:01 +1100 Date: Tue, 18 Dec 2012 14:47:00 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kirk McKusick Subject: Re: FFS - Still using rotational delay with modern disks? In-Reply-To: <201212180012.qBI0CW0c098207@chez.mckusick.com> Message-ID: <20121218142218.A1023@besplex.bde.org> References: <201212180012.qBI0CW0c098207@chez.mckusick.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=fev1UDsF c=1 sm=1 a=aqK3YMQvoDsA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=vz6LxnPcZksA:10 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=L6tdpFjRAAAA:8 a=UnnwDxOAFml7KjqtybAA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=SV7veod9ZcQA:10 a=RZHap4myAk8A:10 a=L8WxzNrgCeLs9fR2:21 a=ll_fA1kdA-roJnY7:21 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: Greg 'groggy' Lehey , freebsd-fs@FreeBSD.org, Dieter BSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 03:47:17 -0000 On Mon, 17 Dec 2012, Kirk McKusick wrote: >> Date: Tue, 18 Dec 2012 02:56:49 +0300 >> Subject: Re: FFS - Still using rotational delay with modern disks? >> From: Sergey Kandaurov >> To: "Greg 'groggy' Lehey" >> Cc: freebsd-fs@freebsd.org, freebsd-performance@freebsd.org, >> Dieter BSD >> >> On 18 December 2012 03:23, Greg 'groggy' Lehey wrote: >>> On Monday, 17 December 2012 at 16:44:11 -0500, Dieter BSD wrote: >>>> The newfs man page says: >>>> >>>> -a maxcontig >>>> Specify the maximum number of contiguous blocks that will be laid >>>> out before forcing a rotational delay. The default value is 16. >>>> See tunefs(8) for more details on how to set this option. >>>> >>>> Is this still a good idea with modern drives where the number of >>>> sectors per track varies, and no one but the manufacturer knows how >>>> many sectors a particular track has? >>> >>> No. >>> >>> It looks as if this, and also a number of comments in sys/ufs/ffs/fs.h >>> and sys/ufs/ffs/ffs_alloc.c, are leftovers from the Olden Days. The >>> value isn't used anywhere that I can see. Unless somebody can show >>> that I'm wrong, I'd suggest that this is a documentation issue that I >>> can take a look at. My version (only) fixes the comments about it in ffs_alloc.c >> [performance@ list trimmed] >> >> I'm not sure about this. >> In UFS fs_maxcontig controls fs_contigsumsize during newfs, both saved >> in superblock, and fs_contigsumsize is widely used throughout FFS. >> ... Yes, fs_maxcontig is used a lot in newfs for initializing fs_contigsumsize, which is used a lot in ffs. > Maxcontig is still in the filesystem. However, it is generally overridden > (i.e., ignored) when clustering and dynamic block reallocation are in > effect which they are by default and have been since some time early in > the 1990's. fs_maxcontig is always ignored except in newfs (and in fsck_ffs, presumably for reconstructing fs_contigsumsize), and in dumpfs and growfs for printing it. Here is my fix for ffs_alloc.c. It removes the only reference to it in the kernel outside of ffs/fs.h. FS_MAXCONTIG there is also only used in newfs and fsck_ffs, and the larger comment attached to it is wronger because it gives more details about things that aren't done any more. @ Index: ffs_alloc.c @ =================================================================== @ RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_alloc.c,v @ retrieving revision 1.121 @ diff -u -2 -r1.121 ffs_alloc.c @ --- ffs_alloc.c 16 Jun 2004 09:47:25 -0000 1.121 @ +++ ffs_alloc.c 2 Jan 2012 05:52:39 -0000 @ @@ -1010,5 +1062,6 @@ @ * Select the desired position for the next block in a file. The file is @ * logically divided into sections. The first section is composed of the @ - * direct blocks. Each additional section contains fs_maxbpg blocks. @ + * direct blocks and the next fs_maxbpg blocks. Each additional section @ + * contains fs_maxbpg blocks. @ * @ * If no blocks have been allocated in the first section, the policy is to @ @@ -1022,12 +1075,11 @@ @ * continues until a cylinder group with greater than the average number @ * of free blocks is found. If the allocation is for the first block in an @ - * indirect block, the information on the previous allocation is unavailable; @ + * indirect block or the previous block is a hole, then the information on @ + * the previous allocation is unavailable; @ * here a best guess is made based upon the logical block number being @ * allocated. @ * @ * If a section is already partially allocated, the policy is to @ - * contiguously allocate fs_maxcontig blocks. The end of one of these @ - * contiguous blocks and the beginning of the next is laid out @ - * contiguously if possible. @ + * allocate blocks contiguously within the section if possible. @ */ @ ufs2_daddr_t Some the above might only apply with the following unrelated changes to the code. These changes are: - something about getting more contiguity across cylinder groups. IIRC, the old version unnecessarily skips some blocks when starting a new cg. This gives an unnecessarily large seek from the previous cg and later more discontiguity than necessary when the hole is filled in. Not very important. To test this, write a very large file on a new file system and check that all of its blocks are as contiguous as possible. This extends my previous changes which give contiguity across the first indirect block. Maximal contiguity across cg's is relatively unimportant since the cg rarely changes, but it easier to ensure than maximal contiguity across further indirect blocks. - use the cgdmin() macro and not its expansion. @ @@ -1039,12 +1091,18 @@ @ { @ struct fs *fs; @ - int cg; @ - int avgbfree, startcg; @ + int avgbfree, cg, firstsection, newsection, startcg; @ @ fs = ip->i_fs; @ - if (indx % fs->fs_maxbpg == 0 || bap[indx - 1] == 0) { @ - if (lbn < NDADDR + NINDIR(fs)) { @ + if (lbn < NDADDR + fs->fs_maxbpg) { @ + firstsection = 1; @ + newsection = 0; @ + } else { @ + firstsection = 0; @ + newsection = ((lbn - NDADDR) % fs->fs_maxbpg == 0); @ + } @ + if (indx == 0 || bap[indx - 1] == 0 || newsection) { @ + if (firstsection) { @ cg = ino_to_cg(fs, ip->i_number); @ - return (fs->fs_fpg * cg + fs->fs_frag); @ + return (cgdmin(fs, cg)); @ } @ /* @ @@ -1052,8 +1110,17 @@ @ * unused data blocks. @ */ @ - if (indx == 0 || bap[indx - 1] == 0) @ - startcg = @ - ino_to_cg(fs, ip->i_number) + lbn / fs->fs_maxbpg; @ - else @ + if (indx == 0 || bap[indx - 1] == 0) { @ + cg = ino_to_cg(fs, ip->i_number) + @ + (lbn - NDADDR) / fs->fs_maxbpg; @ + if (!newsection) { @ + /* @ + * Actually, use our best guess if the @ + * section is not new. @ + */ @ + cg %= fs->fs_ncg; @ + return (cgdmin(fs, cg)); @ + } @ + startcg = cg; @ + } else @ startcg = dtog(fs, bap[indx - 1]) + 1; @ startcg %= fs->fs_ncg; @ @@ -1062,16 +1129,13 @@ @ if (fs->fs_cs(fs, cg).cs_nbfree >= avgbfree) { @ fs->fs_cgrotor = cg; @ - return (fs->fs_fpg * cg + fs->fs_frag); @ + return (cgdmin(fs, cg)); @ } @ for (cg = 0; cg <= startcg; cg++) @ if (fs->fs_cs(fs, cg).cs_nbfree >= avgbfree) { @ fs->fs_cgrotor = cg; @ - return (fs->fs_fpg * cg + fs->fs_frag); @ + return (cgdmin(fs, cg)); @ } @ return (0); @ } @ - /* @ - * We just always try to lay things out contiguously. @ - */ @ return (bap[indx - 1] + fs->fs_frag); @ } @ @@ -1095,5 +1159,5 @@ @ if (lbn < NDADDR + NINDIR(fs)) { @ cg = ino_to_cg(fs, ip->i_number); @ - return (fs->fs_fpg * cg + fs->fs_frag); @ + return (cgdmin(fs, cg)); @ } @ /* @ @@ -1111,10 +1175,10 @@ @ if (fs->fs_cs(fs, cg).cs_nbfree >= avgbfree) { @ fs->fs_cgrotor = cg; @ - return (fs->fs_fpg * cg + fs->fs_frag); @ + return (cgdmin(fs, cg)); @ } @ for (cg = 0; cg <= startcg; cg++) @ if (fs->fs_cs(fs, cg).cs_nbfree >= avgbfree) { @ fs->fs_cgrotor = cg; @ - return (fs->fs_fpg * cg + fs->fs_frag); @ + return (cgdmin(fs, cg)); @ } @ return (0); Bruce From owner-freebsd-fs@FreeBSD.ORG Tue Dec 18 09:36:51 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5148010E for ; Tue, 18 Dec 2012 09:36:51 +0000 (UTC) (envelope-from jg@internetx.com) Received: from mx1.internetx.com (mx1.internetx.com [62.116.129.39]) by mx1.freebsd.org (Postfix) with ESMTP id 038D18FC1B for ; Tue, 18 Dec 2012 09:36:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.internetx.com (Postfix) with ESMTP id 2CAF94C4D528 for ; Tue, 18 Dec 2012 10:26:47 +0100 (CET) X-Virus-Scanned: InterNetX GmbH amavisd-new at ix-mailer.internetx.de Received: from mx1.internetx.com ([62.116.129.39]) by localhost (ix-mailer.internetx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDw9k3B+NLhF for ; Tue, 18 Dec 2012 10:26:45 +0100 (CET) Received: from [192.168.100.26] (pizza.internetx.de [62.116.129.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.internetx.com (Postfix) with ESMTPSA id 017D34C4D531 for ; Tue, 18 Dec 2012 10:26:44 +0100 (CET) Message-ID: <50D036D7.4040206@internetx.com> Date: Tue, 18 Dec 2012 10:26:47 +0100 From: Juergen Gotteswinter User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: HAST + ZFS Problem Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: jg@internetx.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 09:36:51 -0000 Hello, Currently I try to realize a Filer Setup, based up on FreeBSD 9 with Carp, HAST and ZFS. Failover etc works fine so far, but when I start writing data on the ZFS device the following error pops up continuously: Dec 17 14:59:06 filer1 hastd[2211]: [disk7] (primary) Remote request failed (Operation not supported by device): FLUSH. Dec 17 14:59:06 filer1 hastd[2205]: [disk5] (primary) Remote request failed (Operation not supported by device): FLUSH. Dec 17 14:59:06 filer1 hastd[2202]: [disk4] (primary) Remote request failed (Operation not supported by device): FLUSH. Dec 17 14:59:06 filer1 hastd[2193]: [disk1] (primary) Remote request failed (Operation not supported by device): FLUSH. Dec 17 14:59:06 filer1 hastd[2220]: [disk10] (primary) Remote request failed (Operation not supported by device): FLUSH. Dec 17 14:59:06 filer1 hastd[2208]: [disk6] (primary) Remote request failed (Operation not supported by device): FLUSH. Dec 17 14:59:06 filer1 hastd[2193]: [disk1] (primary) Local request failed (Operation not supported by device): FLUSH. Dec 17 14:59:06 filer1 hastd[2199]: [disk3] (primary) Local request failed (Operation not supported by device): FLUSH. Dec 17 14:59:06 filer1 hastd[2208]: [disk6] (primary) Local request failed (Operation not supported by device): FLUSH. Dec 17 14:59:06 filer1 hastd[2220]: [disk10] (primary) Local request failed (Operation not supported by device): FLUSH. Dec 17 14:59:06 filer1 hastd[2217]: [disk9] (primary) Local request failed (Operation not supported by device): FLUSH. Dec 17 14:59:06 filer1 hastd[2196]: [disk2] (primary) Remote request failed (Operation not supported by device): FLUSH. I already found threads where setting vfs.zfs.vdev.bio_flush_disable=1 seemed to fix this, for me it had no effect. Also i tried setting metaflush off in hast.conf, which doesnt change anything, too Hardware Platform is a Dell Poweredge R515, with Perc H700 Controller (configured to 10 Raid-0 Devices to get the single Disks). Any Ideas how to fix this? Cheers, Juergen From owner-freebsd-fs@FreeBSD.ORG Wed Dec 19 04:14:15 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC2B070F for ; Wed, 19 Dec 2012 04:14:15 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by mx1.freebsd.org (Postfix) with ESMTP id 51AC78FC0C for ; Wed, 19 Dec 2012 04:14:14 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id n10so1363092lbo.36 for ; Tue, 18 Dec 2012 20:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=yQ3S3+jtLcwB4mUyzE3AdRZMRIN6iFsmd1ypYAh6LDI=; b=g4NMIlX/QE0mIkEAngQIqykyI4zNXXg+seioj0HxdugmIC9lTQPEhOxDJPaPGgoUm1 fKQd+oguxhg0bjhHnivLdP14vZDjw1+IJvk/xFAs36mps/0JqTmGPRVSKR35Ayy3B5GD Y70y1T2N+DFSEqqiw1IYxbK8feFlZmN34ND3Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=yQ3S3+jtLcwB4mUyzE3AdRZMRIN6iFsmd1ypYAh6LDI=; b=dIWxKRYgWy0XG6KcZvOdbtijqNf3wcnLC9c93hg7uMcLfCBpgbD4tEzW53sC9TN17x xJAQBtlzwHr7i7utvSPm1ac2EF5Lo2n0oT8oBby1CaOMspnWF0vXPPvKgx2IoxD/rLEw /riBDKnNiR5p3DDTD8IHe+pNJQUlPhYWXWBT27V4oR8KKlmRMoF36O3V7cLA85WdX3ab 97edmDAYSPwAzPpoAWmg+0tT3btxtJzoUG5KSOAakctuRtQmB5/XxQo/HQ8EGqqV7eds cqRnQEuszJPeg14wY8iYSAZWd8bie7XCcWSG1J8fCBE+OVKduh6MRRNILg4CA4B4IGIK aO7w== Received: by 10.152.144.130 with SMTP id sm2mr3972692lab.49.1355890452949; Tue, 18 Dec 2012 20:14:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.162.100 with HTTP; Tue, 18 Dec 2012 20:13:42 -0800 (PST) From: Eitan Adler Date: Tue, 18 Dec 2012 23:13:42 -0500 Message-ID: Subject: What are the limits for FFS file systems and assorted questions To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmgaRcl4Z8dmLX6UFQlR6wV05EXUPiGkrxlYzN/qrG3miZL2lOLA1Ud2xTrXsrSPksnY8B3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 04:14:15 -0000 Can anyone provide an up to date answer for the following: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ffs-limits Are the bugs listed still bugs? http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#mount-foreign-fs Is this completely true? Should it be updated? http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#alternate-directory-layout Does this still deserve to be listed as a FAQ? -- Eitan Adler From owner-freebsd-fs@FreeBSD.ORG Wed Dec 19 10:59:32 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5D1976F for ; Wed, 19 Dec 2012 10:59:32 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by mx1.freebsd.org (Postfix) with ESMTP id 2B50B8FC13 for ; Wed, 19 Dec 2012 10:59:31 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id m15so1468318lah.28 for ; Wed, 19 Dec 2012 02:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xQ73qHyoMQorm+UVkTyrPginjmX/BdeTalA8TpE9Xe8=; b=PQz594JD8LTsxaMkJEBHEQmnkw8/lxa7J+/WBHry5L3Uug4X/d4fyurq9rWUryGtlh 9zAnAisDvGGiV8In2QtHs04aKb3tPPF3vR68qGqTHvzMofGhuW/T2oIZcDmGMNtRi6Cp V8r05AMtWohTX3Ieu81470qQcbA9mYGTHIP8RX7G+UxPQc5Ek00IgXvefAhUEFagjHtQ iuGY6R8APCgDgK9SuzamVIPEEzWiS927sE0qP5GoOKsWve3gdypSD3eIA5QHywBCHDoQ uNX+UuaC+unLKykFwDe/3IaukOiPVfBS0NxtJSpkvk8e7A6C+G1kHfG5eeHtpxPLzWSc 8uPA== X-Received: by 10.152.146.39 with SMTP id sz7mr2332390lab.28.1355914770684; Wed, 19 Dec 2012 02:59:30 -0800 (PST) Received: from [192.168.50.105] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id v7sm1976866lbj.13.2012.12.19.02.59.28 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 02:59:29 -0800 (PST) Message-ID: <50D19E13.8020609@gmail.com> Date: Wed, 19 Dec 2012 11:59:31 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: jg@internetx.com, freebsd-fs@freebsd.org Subject: Re: HAST + ZFS Problem References: <50D036D7.4040206@internetx.com> In-Reply-To: <50D036D7.4040206@internetx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:59:32 -0000 Juergen Gotteswinter schreef: > Hello, > > Currently I try to realize a Filer Setup, based up on FreeBSD 9 with > Carp, HAST and ZFS. Failover etc works fine so far, but when I start > writing data on the ZFS device the following error pops up continuously: > > Dec 17 14:59:06 filer1 hastd[2211]: [disk7] (primary) Remote request > failed (Operation not supported by device): FLUSH. > Dec 17 14:59:06 filer1 hastd[2205]: [disk5] (primary) Remote request > failed (Operation not supported by device): FLUSH. > Dec 17 14:59:06 filer1 hastd[2202]: [disk4] (primary) Remote request > failed (Operation not supported by device): FLUSH. > Dec 17 14:59:06 filer1 hastd[2193]: [disk1] (primary) Remote request > failed (Operation not supported by device): FLUSH. > Dec 17 14:59:06 filer1 hastd[2220]: [disk10] (primary) Remote request > failed (Operation not supported by device): FLUSH. > Dec 17 14:59:06 filer1 hastd[2208]: [disk6] (primary) Remote request > failed (Operation not supported by device): FLUSH. > Dec 17 14:59:06 filer1 hastd[2193]: [disk1] (primary) Local request > failed (Operation not supported by device): FLUSH. > Dec 17 14:59:06 filer1 hastd[2199]: [disk3] (primary) Local request > failed (Operation not supported by device): FLUSH. > Dec 17 14:59:06 filer1 hastd[2208]: [disk6] (primary) Local request > failed (Operation not supported by device): FLUSH. > Dec 17 14:59:06 filer1 hastd[2220]: [disk10] (primary) Local request > failed (Operation not supported by device): FLUSH. > Dec 17 14:59:06 filer1 hastd[2217]: [disk9] (primary) Local request > failed (Operation not supported by device): FLUSH. > Dec 17 14:59:06 filer1 hastd[2196]: [disk2] (primary) Remote request > failed (Operation not supported by device): FLUSH. > > > I already found threads where setting vfs.zfs.vdev.bio_flush_disable=1 > seemed to fix this, for me it had no effect. Also i tried setting > metaflush off in hast.conf, which doesnt change anything, too > > > Hardware Platform is a Dell Poweredge R515, with Perc H700 Controller > (configured to 10 Raid-0 Devices to get the single Disks). > > Any Ideas how to fix this? > > Cheers, > > Juergen > _______________________________________________ > 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" I am no expert on this, but nobody answered, so i will try. :D It seems to be a known issue is FreeBSD 9.0 i found the following on the net. ################## start r225832 has been merged to 9-STABLE on 4 Jan 2012 as r229509 and you shouldn't observe 'FLUSH: Operation not supported by device' constantly repeating. If you do this is very strange and you should recheck your build. Please provide the output of ident /sbin/hastd command. JK> and hast.conf configuration from both machines: JK> I've decided to put metaflush option on every single level just to be JK> sure. No effect. No need in disabling metaflush in your case. It will disable automatically after the first attempt failed. #################### end FreeBSD 9.0 was also released in january!, but i can not tell if this patch has made it into release 9.0 I think it does not. So if time permits, maybe try FreeBSD 9.1 which will proberbly be released any time now! regards and best wishes Johan Hendriks Neuteboom Automatisering From owner-freebsd-fs@FreeBSD.ORG Wed Dec 19 15:10:44 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C199802 for ; Wed, 19 Dec 2012 15:10:44 +0000 (UTC) (envelope-from matt.churchyard@userve.net) Received: from av.userve.net (antivirus.userve.net [217.196.1.11]) by mx1.freebsd.org (Postfix) with ESMTP id F03D28FC14 for ; Wed, 19 Dec 2012 15:10:43 +0000 (UTC) X-ASG-Debug-ID: 1355928762-4588c36a0001-3nHGF7 Received: from smtp-outbound.userve.net ([192.168.101.15]) by av.userve.net with ESMTP id P8eueQ7f1kFaZlvE for ; Wed, 19 Dec 2012 14:52:42 +0000 (GMT) X-Barracuda-Envelope-From: matt.churchyard@userve.net Received: from usd-group.com (titan.userve.net [217.196.1.2]) by smtp-outbound.userve.net (8.14.5/8.14.5) with ESMTP id qBJEqfTa095782 for ; Wed, 19 Dec 2012 14:52:41 GMT (envelope-from matt.churchyard@userve.net) Content-class: urn:content-classes:message X-Barracuda-Apparent-Source-IP: 217.196.1.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: ZFS: cache_flush_disable Date: Wed, 19 Dec 2012 14:52:40 -0000 X-ASG-Orig-Subj: ZFS: cache_flush_disable X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <36B5948F85049844985F24A1CE55B2CBEB980A@USDSERVER.usd.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ZFS: cache_flush_disable thread-index: Ac3d9AHohhiRQi1WSeOWYVHPRSdIXA== From: "Matt Churchyard" To: X-Barracuda-Connect: UNKNOWN[192.168.101.15] X-Barracuda-Start-Time: 1355928762 X-Barracuda-URL: http://antivirus.userve.net:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at userve.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.117464 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:10:44 -0000 Can anyone give some knowledgeable info on the vfs.zfs.cache_flush_disable variable?=20 There's a lot of talk going on in the FreeBSD forums about how to get the best performance but no-one really knows exactly what these settings do (searching the net doesn't really find anyone who knows either). There's a lot of mis-information going around as well and so I'd like to start trying to get some concrete information if possible. I'd like to know 1) What this setting actually does 2) If it's safe assuming you have battery backed ZIL (e.g. supercap SSD) I am under the impression it controls whether ZFS asks disks to flush their caches or not. However, there's an entire function in zil.c (zil_add_block) that is skipped when this flag is set. I'm not sure what this function does but it seems to do more than just flush caches? Regarding question 2, if this variable affects flushing of pool disks, not just the ZIL, I can imagine a scenario where ZFS flushes a transaction to the pool, but a power loss occurs while some of that data is still sat in the disk cache. Usually ZFS would flush the cache and only assume the write was complete at that point. Assuming it affects all disks, is it possible to turn off write cache per disk? I have seen hw.ata.wc but I'm not sure this still applies and if it does it'll affect the ZIL which you'd want to leave enabled if it was protected. -- Matt From owner-freebsd-fs@FreeBSD.ORG Wed Dec 19 17:07:45 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E459FFA for ; Wed, 19 Dec 2012 17:07:45 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 6B36D8FC13 for ; Wed, 19 Dec 2012 17:07:45 +0000 (UTC) Received: from conversation.bsdunix.ch (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id E208D13996; Wed, 19 Dec 2012 17:07:43 +0000 (UTC) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by conversation.bsdunix.ch (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKp_93lf5OoQ; Wed, 19 Dec 2012 17:07:43 +0000 (UTC) Received: from toms-saftbook.home (177-185.107-92.cust.bluewin.ch [92.107.185.177]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTPSA id DC65C13993; Wed, 19 Dec 2012 17:07:42 +0000 (UTC) Message-ID: <50D1F45E.3010402@bsdunix.ch> Date: Wed, 19 Dec 2012 18:07:42 +0100 From: Tom User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: ZFS: cache_flush_disable References: <36B5948F85049844985F24A1CE55B2CBEB980A@USDSERVER.usd.local> In-Reply-To: <36B5948F85049844985F24A1CE55B2CBEB980A@USDSERVER.usd.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: matt.churchyard@userve.net X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:07:46 -0000 Hi Matt, Am 19.12.12 15:52, schrieb Matt Churchyard: > Can anyone give some knowledgeable info on the > vfs.zfs.cache_flush_disable variable? > There's a lot of talk going on in the FreeBSD forums about how to get > the best performance but no-one really knows exactly what these settings > do (searching the net doesn't really find anyone who knows either). > There's a lot of mis-information going around as well and so I'd like to > start trying to get some concrete information if possible. > > I'd like to know > > 1) What this setting actually does > 2) If it's safe assuming you have battery backed ZIL (e.g. supercap SSD) > > I am under the impression it controls whether ZFS asks disks to flush > their caches or not. > However, there's an entire function in zil.c (zil_add_block) that is > skipped when this flag is set. I'm not sure what this function does but > it seems to do more than just flush caches? vfs.zfs.cache_flush_disable equitable of zfs_nocacheflush on solaris. >From the Oracle Documentation (http://docs.oracle.com/cd/E26502_01/html/E29022/chapterzfs-6.html) ZFS is designed to work with storage devices that manage a disk-level cache. ZFS commonly asks the storage device to ensure that data is safely placed on stable storage by requesting a cache flush. For JBOD storage, this works as designed and without problems. For many NVRAM-based storage arrays, a performance problem might occur if the array takes the cache flush request and actually does something with it, rather than ignoring it. Some storage arrays flush their large caches despite the fact that the NVRAM protection makes those caches as good as stable storage. ZFS issues infrequent flushes (every 5 second or so) after the uberblock updates. The flushing infrequency is fairly inconsequential so no tuning is warranted here. ZFS also issues a flush every time an application requests a synchronous write (O_DSYNC, fsync, NFS commit, and so on). The completion of this type of flush is waited upon by the application and impacts performance. Greatly so, in fact. From a performance standpoint, this neutralizes the benefits of having an NVRAM-based storage..... Afaik this can also affect scsi controllers with it's own flush algorithm. Some controllers just ignore these scsi flush commands but some of them not. Other systems are storage arrays because they have an battery backed cache. > > Regarding question 2, if this variable affects flushing of pool disks, > not just the ZIL, I can imagine a scenario where ZFS flushes a > transaction to the pool, but a power loss occurs while some of that data > is still sat in the disk cache. Usually ZFS would flush the cache and > only assume the write was complete at that point. > Assuming it affects all disks, is it possible to turn off write cache > per disk? I have seen hw.ata.wc but I'm not sure this still applies and > if it does it'll affect the ZIL which you'd want to leave enabled if it > was protected. Cache flushing is commonly done as part of the ZIL operations. This should answer your question: http://thr3ads.net/zfs-discuss/2011/02/582087-Understanding-directio-O_DSYNC-and-zfs_nocacheflush-on-ZFS Regards, Tom From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 02:23:36 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA7A7127 for ; Thu, 20 Dec 2012 02:23:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id ACABE8FC14 for ; Thu, 20 Dec 2012 02:23:36 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id n16so2848546oag.37 for ; Wed, 19 Dec 2012 18:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=YFy3WySDLTmeOnjiTnCu8onAgSbPIqAR5WjO4CBgic8=; b=wSdGpEBWZaC/YHSJzlX3KqHUZHtYS8ooB0zAC/UHFZPsECayAErfrdifx+eAfv/w7M c3whF5lFE58eeSpmyRLCtBYfFcHhLsD3RyJYx2CP/B3lK8j6AHXM4vuSq8gHgQCs/22V ptr+6ARCtECTwFfd9xVmC8RS8ZPs4EQ6I04pDuIGvKE+R5cGUhzM+Hq1amg5eLysqAv7 uC5j27/TT9pF0k3pdE+6htWcyWKqYW5Ef84hkrEqArxIROQDO5MpIiNksdVcN4JzZ339 aFOeMYgdWHgBO57y+84M/3vjXNY/nBG65YEFEr2HJM7P0ldwPERaE0RkSngbSPf6NM+S 64lA== MIME-Version: 1.0 Received: by 10.60.25.227 with SMTP id f3mr6796656oeg.17.1355970210130; Wed, 19 Dec 2012 18:23:30 -0800 (PST) Received: by 10.76.143.33 with HTTP; Wed, 19 Dec 2012 18:23:29 -0800 (PST) Date: Wed, 19 Dec 2012 18:23:29 -0800 Message-ID: Subject: umount -f broken again [with devfs/NFS] From: Garrett Cooper To: FreeBSD FS Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 02:23:37 -0000 Ran into this with a build of CURRENT 2 week or so old version of CURRENT (gjb's livecd) and while unmounting devfs with a week old build: # umount -f /ifs umount: unmount of /ifs failed: Device busy # uname -a FreeBSD wf158.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r+5a05236: Wed Dec 12 17:35:14 PST 2012 root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 My gut reaction is that some recently changes to VFS probably broke this (a couple week old 9-STABLE build just hangs on an NFS mountpoint that's gone out to lunch). Thanks, -Garrett From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 02:29:29 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EADA1D7 for ; Thu, 20 Dec 2012 02:29:29 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6028FC0C for ; Thu, 20 Dec 2012 02:29:29 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2847223oag.27 for ; Wed, 19 Dec 2012 18:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D9H7y52irUVZtagW7qyCKeIZ/re2Us2fTnxLn7hoigo=; b=dppe6oekJCQm4L5IV9YuN43xksZ/7TCTCm5+fXCOm0ObdKr0giqb/vWKp34OS+r4Fh IgqdpmSCALu8VMGXKbKP3iSQlFSr7T/xQFVCN7DOHDIgVLb8Fs/sR5XN1/IVUCieeS9b BY5vjsPLnRzHWiUC9XQPCTKu3cuSkdSsZ9QPd5xATjUUubBvkJdobJ8gs5peheEm/JOT I1RjEnFog+BgqvarjOE/rgsw0nh+wKuxhymnZkKDui9ont13bRTi1jyiOYgQYPNsf++r eCD2KI8wo/BUdaftF9n9Z4CZKaqjtNctbJC/Ecf9ewwJSuVENoaDvrt95xuvdj1OLIGB qYtQ== MIME-Version: 1.0 Received: by 10.182.95.205 with SMTP id dm13mr6833137obb.9.1355970563560; Wed, 19 Dec 2012 18:29:23 -0800 (PST) Received: by 10.76.143.33 with HTTP; Wed, 19 Dec 2012 18:29:23 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Dec 2012 18:29:23 -0800 Message-ID: Subject: Re: umount -f broken again [with devfs/NFS] From: Garrett Cooper To: FreeBSD FS Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 02:29:29 -0000 On Wed, Dec 19, 2012 at 6:23 PM, Garrett Cooper wrote: > Ran into this with a build of CURRENT 2 week or so old version of > CURRENT (gjb's livecd) and while unmounting devfs with a week old > build: > > # umount -f /ifs > umount: unmount of /ifs failed: Device busy > # uname -a > FreeBSD wf158.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3 > r+5a05236: Wed Dec 12 17:35:14 PST 2012 > root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 > > My gut reaction is that some recently changes to VFS probably > broke this (a couple week old 9-STABLE build just hangs on an NFS > mountpoint that's gone out to lunch). Interesting. Killed a "rogue mergemaster" instance and I noticed that the umount -f command I had going on the 9-STABLE box is still hung in newnfs state BUT the mountpoint is gone: load: 0.11 cmd: umount 91115 [newnfs] 521.60r 0.00u 0.09s 0% 1440k load: 0.11 cmd: umount 91115 [newnfs] 521.64r 0.00u 0.09s 0% 1440k load: 0.11 cmd: umount 91115 [newnfs] 521.68r 0.00u 0.09s 0% 1440k load: 0.11 cmd: umount 91115 [newnfs] 521.72r 0.00u 0.09s 0% 1440k $ mount | grep /mnt/temp || echo "not found" not found $ ps auxww | grep umount | grep -v grep root 91114 0.0 0.0 40152 2512 11 I+ 6:15PM 0:00.03 sudo umount -f /mnt/temp root 91115 0.0 0.0 9872 1456 11 D+ 6:15PM 0:00.10 umount -f /mnt/temp $ uname -a FreeBSD forza.west.isilon.com 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r+2fd0a57: Mon Dec 3 12:02:18 PST 2012 gcooper@forza.west.isilon.com:/usr/obj/usr/src/sys/FORZA amd64 I'm going to restart the box in a minute (have to swap out some hardware), but I thought this was kind of strange. Thanks, -Garrett From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 10:26:25 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39DC93E9; Thu, 20 Dec 2012 10:26:25 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:56bf:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3AF8FC0A; Thu, 20 Dec 2012 10:26:24 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:56bf:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3YRpzC1zC0zM2J; Thu, 20 Dec 2012 11:26:15 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.7.1 tignes.restart.be 3YRpzC1zC0zM2J DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1355999175; bh=ZDw2hnBeEUxClCR8cepBkNQOJ8Ea5uAwySxAs3lV7nw=; h=Date:From:To:CC:Subject:References:In-Reply-To; z=Date:=20Thu,=2020=20Dec=202012=2011:26:14=20+0100|From:=20Henri=2 0Hennebert=20|To:=20Andriy=20Gapon=20|CC:=20fs@freebsd.org|Subject:=20Re:=20clang=20compiled=20kern el=20panic=20when=20mounting=20zfs=20root=20on=20i386|References:= 20<50b37d46.8584440a.735c.ffffb4e6@mx.google.com>=20<2012112617165 8.GD3013@kib.kiev.ua>=20<20121127071243.D1255@besplex.bde.org>=20< 20121129232944.GQ3013@kib.kiev.ua>=20<50b8a9c5.e64dec0a.1d88.133a@ mx.google.com>=20<20121130164715.GW3013@kib.kiev.ua>=20<50b9cf0c.0 fd9650a.5bbf.ffffb9b3@mx.google.com>=20<20121203224132.GJ3013@kib. kiev.ua>=20<50C880D7.1040907@gmail.com>=20<50C8DC8E.1080204@FreeBS D.org>=20<50C9AD2C.7000301__8690.12248372219$1355394383$gmane$org@ FreeBSD.org>=20<50CF16B0.9090104@gmail.com>=20<50CF9AA9.1030808@Fr eeBSD.org>|In-Reply-To:=20<50CF9AA9.1030808@FreeBSD.org>; b=RNEtT/I1wadnZYz51pi4xuBA2h3zGWXOUNMSjGtl1iNhDC/sMiIHjWkLP3NJIr/MJ g4c0VJZF9lSxfeQL8IPt5TYYK1M6ENyTKzi3OIZVDaKFpW2BRauJ8vS1zSCD9zERDw wtFHu+zWZ0gbn7ShZIFFVPDpmSnG2ioXj67BfsU0= Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:56bf:1:2::]) (authenticated bits=0) by restart.be (8.14.5/8.14.5) with ESMTP id qBKAQEai068321; Thu, 20 Dec 2012 11:26:14 +0100 (CET) (envelope-from hlh@restart.be) Message-ID: <50D2E7C6.1030201@restart.be> Date: Thu, 20 Dec 2012 11:26:14 +0100 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: clang compiled kernel panic when mounting zfs root on i386 References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> <50C8DC8E.1080204@FreeBSD.org> <50C9AD2C.7000301__8690.12248372219$1355394383$gmane$org@FreeBSD.org> <50CF16B0.9090104@gmail.com> <50CF9AA9.1030808@FreeBSD.org> In-Reply-To: <50CF9AA9.1030808@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 10:26:25 -0000 On 12/17/2012 23:20, Andriy Gapon wrote: > on 17/12/2012 14:57 Volodymyr Kostyrko said the following: >> 13.12.2012 12:25, Andriy Gapon: >>> on 12/12/2012 21:35 Dimitry Andric said the following: >>>> Especially the recursive spa_load and traverse_visitbp calls are scary, >>>> because that can grow out of hand very quickly. It is probably tricky >>>> to remove the recursion... >>> >>> Re-entering spa_load once is normal and is expected. >>> traverse_visitbp is also expected to recurse depending on data layout. >>> So yeah, it's probably even trickier than teaching clang to allocate smaller >>> stack >>> frames ;-) >> >> I hit this one again, but this time my world and kernel are compiled with stock >> gcc. Pictures 3 to 5: >> >> https://picasaweb.google.com/104021007361271711472/I386ZfsDoubleFault >> >> This happens on mounting root after unclean shutdown. I fixed my pool with >> booting amd64 kernel, after this i386 kernel starts fine. >> >> Maybe it's just time to accept that ZFS on i386 is not stable? Current handbook >> elaborates on ZFS like it's known to work on i386. > > Yes, it is known to work. > > It's been already mentioned many times that ZFS works much better on amd64. > It's up to a (potential) user to understand limitations of i386 and to decide > whether to use ZFS, in what situations and how. > > You may want to consider using KSTACK_PAGES=4 in your kernel configuration. 'options KSTACK_PAGES=4' allow my 9.1-STABLE to mount the root fs from zfs. I think it whould be useful to add this trick to /usr/src/UPDATING for other i386 users. Thanks a lot Henri > From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 11:18:37 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 610CF2F5 for ; Thu, 20 Dec 2012 11:18:37 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 068238FC13 for ; Thu, 20 Dec 2012 11:18:36 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Tle9F-0002bO-RW for freebsd-fs@freebsd.org; Thu, 20 Dec 2012 12:18:45 +0100 Received: from mau.donbass.com ([92.242.127.250]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Dec 2012 12:18:45 +0100 Received: from c.kworr by mau.donbass.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Dec 2012 12:18:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Volodymyr Kostyrko Subject: Re: clang compiled kernel panic when mounting zfs root on i386 Date: Thu, 20 Dec 2012 13:18:22 +0200 Lines: 12 Message-ID: <50D2F3FE.1000509@gmail.com> References: <50b37d46.8584440a.735c.ffffb4e6@mx.google.com> <20121126171658.GD3013@kib.kiev.ua> <20121127071243.D1255@besplex.bde.org> <20121129232944.GQ3013@kib.kiev.ua> <50b8a9c5.e64dec0a.1d88.133a@mx.google.com> <20121130164715.GW3013@kib.kiev.ua> <50b9cf0c.0fd9650a.5bbf.ffffb9b3@mx.google.com> <20121203224132.GJ3013@kib.kiev.ua> <50C880D7.1040907@gmail.com> <50C8DC8E.1080204@FreeBSD.org> <50C9AD2C.7000301__8690.12248372219$1355394383$gmane$org@FreeBSD.org> <50CF16B0.9090104@gmail.com> <50CF9AA9.1030808__28729.3355250315$1355782864$gmane$org@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mau.donbass.com User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 In-Reply-To: <50CF9AA9.1030808__28729.3355250315$1355782864$gmane$org@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, Dimitry Andric , fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 11:18:37 -0000 18.12.2012 00:20, Andriy Gapon: > It's been already mentioned many times that ZFS works much better on amd64. > It's up to a (potential) user to understand limitations of i386 and to decide > whether to use ZFS, in what situations and how. > > You may want to consider using KSTACK_PAGES=4 in your kernel configuration. For last two fays my system seems stable on kernel compiled with KSTACK_PAGES=4 and WITH_CLANG_IS_CC. -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 18:08:25 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9B444E1 for ; Thu, 20 Dec 2012 18:08:25 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6E1848FC13 for ; Thu, 20 Dec 2012 18:08:24 +0000 (UTC) Received: by mail-da0-f42.google.com with SMTP id z17so1650093dal.1 for ; Thu, 20 Dec 2012 10:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/pFUvGNSRgwx6KJsVhfgQTQvU8LVanhk/U8wy2W+9zQ=; b=C1e5CoOamtgemIqbvtcWl8OIGu2DJ0mgL8mJ1PQuqf9S0TphxEh72UrWJbfBP9pScL DPwZVlAQb/hgl5ZskW1zOhB11wkUfBdnKNcfJDqvLamgZgRRLQSkvejUCCfJp09sH2Pt bVlG4RYGdsJ3xxSogN7vrrZ45htvzeimtwB8E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=/pFUvGNSRgwx6KJsVhfgQTQvU8LVanhk/U8wy2W+9zQ=; b=JbATeqL7L9PWonYDsSp4ZVPobf5svn8WDaX/TFX7ib9ovPL9GFtEl4ATBKjhG6CK9n Lw+LIVkXj08VprBIIMVAaAZchTXiU56RBwE4hLC7llXwTMSGc12o81evP5FDteE07oTz /zLCYZdxGOGxlWWtzceyTX6r4/tZlJKyCM9MgDU4fE3DMJDoHUEAhqeQeINts8GpMQHw CpyO3QFWDY+YVN0/pqGFeynnptPPT66SDF3FpGIa9Ayvr3Ye4gkvbYB+Z0eUCOoMihDy 6AgMJr5zNKgUFRf1pL6s4KX7tGf3vRzU77Nn6wQxIJLhuxa6KIsC8BioGfBzfW7mu1uZ 3mcw== MIME-Version: 1.0 Received: by 10.68.251.136 with SMTP id zk8mr31489221pbc.82.1356026898153; Thu, 20 Dec 2012 10:08:18 -0800 (PST) Received: by 10.68.58.106 with HTTP; Thu, 20 Dec 2012 10:08:18 -0800 (PST) Received: by 10.68.58.106 with HTTP; Thu, 20 Dec 2012 10:08:18 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Dec 2012 10:08:18 -0800 Message-ID: Subject: NFS Problems From: Tim Gustafson To: FreeBSD Filesystems X-Gm-Message-State: ALoCoQltBqccwwMMFZFicMij24zzf1r/EHBYtpL8qsSOL30gYAHxgupS7zTK66NVMc2BHvxCigij Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:08:25 -0000 Just yesterday, we moved our user home directories from a Sun file server to a FreeBSD file server. We've had a few hiccups and burps, but mostly things seem to be running OK right now. However, some of our Linux clients who are running Firefox are having problems, and I think I've narrowed it down to a problem with fcntl64() and I'm including a snippet of strace output from the Linux client below: stat64("/soe/tjg/.mozilla/firefox/105gir0j.default/places.sqlite", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 open("/soe/tjg/.mozilla/firefox/105gir0j.default/places.sqlite", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 31 fcntl64(31, F_GETFD) = 0 fcntl64(31, F_SETFD, FD_CLOEXEC) = 0 fstat64(31, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 clock_gettime(CLOCK_MONOTONIC, {4584, 334732510}) = 0 clock_gettime(CLOCK_MONOTONIC, {4584, 334902510}) = 0 clock_gettime(CLOCK_MONOTONIC, {4584, 335084510}) = 0 _llseek(31, 0, [0], SEEK_SET) = 0 read(31, "", 100) = 0 clock_gettime(CLOCK_MONOTONIC, {4584, 335584510}) = 0 fcntl64(31, 0xd /* F_??? */, 0xffde28b4) = -1 EIO (Input/output error) close(31) = 0 That last call to fcntl64() hangs for several seconds before moving on, and the fcntl64() function gets called on several different files (like the ,parentlock file, for example) and always takes a while and seemingly always reports the input/output error. Eventually a Firefox window does appear to the user, but it's totally non-responsive. I'd be happy to give the full strace output to anyone who's interested to see. If I set the nolock option on the nfs mount, Firefox starts successfully. lockd and statd are running on both the Linux client and the FreeBSD server. Any pointers as to what might be causing this? -- Tim Gustafson tjg@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 20:36:36 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A471FD1 for ; Thu, 20 Dec 2012 20:36:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 52BC58FC13 for ; Thu, 20 Dec 2012 20:36:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAIF201CDaFvO/2dsb2JhbAA9BQMOhiy3THOCHgEBAQMBAQEBIAQnIAsFFg4KAgINGQIpAQkmBggHBAEcBIdsBgymSpMXgSKLTAR6ghuBEwOIYop7gi6BHI8sgjZcgU81 X-IronPort-AV: E=Sophos;i="4.84,326,1355115600"; d="scan'208";a="5894632" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 20 Dec 2012 15:36:09 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 33448B3F48; Thu, 20 Dec 2012 15:36:09 -0500 (EST) Date: Thu, 20 Dec 2012 15:36:09 -0500 (EST) From: Rick Macklem To: Tim Gustafson Message-ID: <910429574.1528413.1356035769195.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: NFS Problems 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 - FF3.0 (Win)/6.0.10_GA_2692) Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 20:36:36 -0000 Tim Gustafson wrote: > Just yesterday, we moved our user home directories from a Sun file > server > to a FreeBSD file server. We've had a few hiccups and burps, but > mostly > things seem to be running OK right now. However, some of our Linux > clients > who are running Firefox are having problems, and I think I've narrowed > it > down to a problem with fcntl64() and I'm including a snippet of strace > output from the Linux client below: > > stat64("/soe/tjg/.mozilla/firefox/105gir0j.default/places.sqlite", > {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 > open("/soe/tjg/.mozilla/firefox/105gir0j.default/places.sqlite", > O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 31 > fcntl64(31, F_GETFD) = 0 > fcntl64(31, F_SETFD, FD_CLOEXEC) = 0 > fstat64(31, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 > clock_gettime(CLOCK_MONOTONIC, {4584, 334732510}) = 0 > clock_gettime(CLOCK_MONOTONIC, {4584, 334902510}) = 0 > clock_gettime(CLOCK_MONOTONIC, {4584, 335084510}) = 0 > _llseek(31, 0, [0], SEEK_SET) = 0 > read(31, "", 100) = 0 > clock_gettime(CLOCK_MONOTONIC, {4584, 335584510}) = 0 > fcntl64(31, 0xd /* F_??? */, 0xffde28b4) = -1 EIO (Input/output error) 0xd -> 13, which is F_SETLK64 I believe. > close(31) = 0 > > That last call to fcntl64() hangs for several seconds before moving > on, and > the fcntl64() function gets called on several different files (like > the > ,parentlock file, for example) and always takes a while and seemingly > always reports the input/output error. Eventually a Firefox window > does > appear to the user, but it's totally non-responsive. > > I'd be happy to give the full strace output to anyone who's interested > to > see. > > If I set the nolock option on the nfs mount, Firefox starts > successfully. > Sounds like you've solved your problem. Unless the same file is being locked concurrently by multiple clients, just use "nolock". > lockd and statd are running on both the Linux client and the FreeBSD > server. > These protocols are just a trainwreck looking for a place to happen, imho. (I don't know if the FreeBSD lockd supports 64bit locking or not?) If you need locking to work, I'd suggest you try NFSv4. > Any pointers as to what might be causing this? > If you really want to get lockd working, the starting point would be capturing packets when the problem occurs and taking a look at them in wireshark, to see exactly what is failing. (I suspect it's an NLM RPC, but...) rick > -- > > Tim Gustafson > tjg@soe.ucsc.edu > 831-459-5354 > Baskin Engineering, Room 313A > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 20:47:45 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA7AD32E for ; Thu, 20 Dec 2012 20:47:45 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8F88FC0C for ; Thu, 20 Dec 2012 20:47:45 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id bi1so2349195pad.36 for ; Thu, 20 Dec 2012 12:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tBWSD5+8urpc9GwlAd9DChF+ms74sBEmwk/ftNTAYBk=; b=W9y/r8k1H5qeV/ntvKfW5FvMOufJaMgPOthI4dof1E0VtX+uI6JtxiXDl4J2h91ITK VhwR2+l/cigQd/KDt1nuVGThJg2P6tEop+DG0Jk570VdkC0nrt8IIejPljhZRsWdP0oN xAXc3w/XpMv6IdT7C+lUeWzrrcJraDdWEDyGs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=tBWSD5+8urpc9GwlAd9DChF+ms74sBEmwk/ftNTAYBk=; b=G3qd/Dr1Z3M8XYK9I4K2/WmJGlhe77wwTHspjtaykxtauxLK/g3+2ZcZpznh1/GMWk RgIUV/J35CWeeVsNgov1fPsMMcdJwxO2iWGRyY5vAYXcfGt3eay/ZmiGkfCckpGaHynv LLpXdkQBx8e74HEsrw8Op6cNlHGhcBXo36bDgDvPrW5BqHs1OpKqxMfhOD8ReqoZkkV2 wYpipvzMX2fmzPebrL5FQamGIdGmTc4Q+TD/rI9Hdx43fPECbaaX27PVB8AcDDdKoOdj /6rdeF7rOhZL+OQ26axKTjGX3/EyP2Nyqq5OTOxc1Ss44aSyZPFIT/l9tcz7dPPFtbQS 4oKQ== MIME-Version: 1.0 Received: by 10.68.191.200 with SMTP id ha8mr33023511pbc.51.1356036464787; Thu, 20 Dec 2012 12:47:44 -0800 (PST) Received: by 10.68.58.106 with HTTP; Thu, 20 Dec 2012 12:47:44 -0800 (PST) In-Reply-To: <910429574.1528413.1356035769195.JavaMail.root@erie.cs.uoguelph.ca> References: <910429574.1528413.1356035769195.JavaMail.root@erie.cs.uoguelph.ca> Date: Thu, 20 Dec 2012 12:47:44 -0800 Message-ID: Subject: Re: NFS Problems From: Tim Gustafson To: Rick Macklem Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnXBjy7Y4wcKvVFYrVfICIyZ5jHPAPs7hU6uz23Pd0qvD2FddjYCaXihzoDR+7SpbCsusff Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 20:47:45 -0000 > If you need locking to work, I'd suggest you try NFSv4. I'd like to, but we have Macintosh clients as well, and Mac has had serious problems with NFSv4 in the past, specifically related to its Kerberos support. Is it possible to have an NFSv4 server without Kerberos? -- Tim Gustafson tjg@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 21:12:41 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CAAD539 for ; Thu, 20 Dec 2012 21:12:41 +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 BA0568FC0A for ; Thu, 20 Dec 2012 21:12:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAD1+01CDaFvO/2dsb2JhbABCAw6GLLdMc4IeAQEFI1YbDgoCAg0ZAlkGE4gTpmGTG4EijEqCG4ETA4hijSmQSII2XIIE X-IronPort-AV: E=Sophos;i="4.84,326,1355115600"; d="scan'208";a="5616174" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 20 Dec 2012 16:12:33 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CB0C1B3F15; Thu, 20 Dec 2012 16:12:33 -0500 (EST) Date: Thu, 20 Dec 2012 16:12:33 -0500 (EST) From: Rick Macklem To: Tim Gustafson Message-ID: <1477482293.1529544.1356037953815.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: NFS Problems 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 - FF3.0 (Win)/6.0.10_GA_2692) Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 21:12:41 -0000 Tim Gustafson wrote: > > If you need locking to work, I'd suggest you try NFSv4. > > I'd like to, but we have Macintosh clients as well, and Mac has had > serious problems with NFSv4 in the past, specifically related to its > Kerberos support. Is it possible to have an NFSv4 server without > Kerberos? > Yep. Using Kerberos for NFS is really orthogonal to NFSv4. The only reason some people tie the two together is that the NFSv4.0 RFC required support for RPCSEC_GSS (which is what sec=krb5 does). Although support for AUTH_SYS wasn't required I believe all NFSv4 servers do support it and I know it works for FreeBSD. Just do the mounts without sec=krb5 and you'll be using NFSv4.0 over AUTH_SYS (which is the old uid + gid list stuff NFS has always used). I haven't tested it, but the NFSv4.0 client in Lion was supposed to work ok. (I do know that the Leopard one didn't work well.) rick > -- > > Tim Gustafson > tjg@soe.ucsc.edu > 831-459-5354 > Baskin Engineering, Room 313A From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 22:10:01 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B2111AB for ; Thu, 20 Dec 2012 22:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 21A1F8FC0A for ; Thu, 20 Dec 2012 22:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBKMA1kg097370 for ; Thu, 20 Dec 2012 22:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBKMA0CG097366; Thu, 20 Dec 2012 22:10:00 GMT (envelope-from gnats) Date: Thu, 20 Dec 2012 22:10:00 GMT Message-Id: <201212202210.qBKMA0CG097366@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Yuri Subject: Re: kern/133174: [msdosfs] [patch] msdosfs must support multibyte international characters in file names X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Yuri List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 22:10:01 -0000 The following reply was made to PR kern/133174; it has been noted by GNATS. From: Yuri To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/133174: [msdosfs] [patch] msdosfs must support multibyte international characters in file names Date: Thu, 20 Dec 2012 13:54:09 -0800 9.1-STABLE doesn't have this patch. Need to merge it into 9.1. Yuri From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 22:34:34 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7682AFA3 for ; Thu, 20 Dec 2012 22:34:34 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1438FC14 for ; Thu, 20 Dec 2012 22:34:34 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id hz11so2386441pad.31 for ; Thu, 20 Dec 2012 14:34:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YlPKoQBZ3HNJ9R5uZBuBt3YTyvq3S/9nhKUhw5wgzZg=; b=KPHULQ7Cmf4CWTbHwOiv3Olz7xpA+wNdV45zY0NhH+jPkaDdh869lE0VTDJ82IEfo7 SsCA6kFyJ1A4QFqhilqKJW2zdCCyLlPW/kh4aZR+cJLxm5EEQf0Y1lv6ESpZ5QuLorXm YyQEv4A89hoWzA58PH7qli0S8IHGGPA0gQi1c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=YlPKoQBZ3HNJ9R5uZBuBt3YTyvq3S/9nhKUhw5wgzZg=; b=dqpjVXGQ5F2jcsEMVAGuI24Ru7k/9QG3re+kEK9I1ny3YB0i8xaNqo1IuGHntiNdsd rNNf2f8Z3Z9sAMEnxX2Vz9h7x8tanNHbsPSMiDtyx2Yryf+T/swHnvzNynPKOsfMEYAF 6JJayXVeci2zDnH4NIeDgA2Acqh9wRyamfPq/KwhKydhsQV+Oy3CBqnaAh02mCfHSbAo N5CHBCNhz/gQAXHkyMrycAPoNoaFhu21yG9eJnXMVvIaWl7Xz9FT0U0ruLzbzhFPeIl+ mEk+mzIKr8cNoTFgLMoIkdUAP2/nt7NsDsXA1kec165c3fZA7T6jPO1aogwd930VdPIH CL+w== MIME-Version: 1.0 Received: by 10.66.76.6 with SMTP id g6mr31410235paw.61.1356042868523; Thu, 20 Dec 2012 14:34:28 -0800 (PST) Received: by 10.68.58.106 with HTTP; Thu, 20 Dec 2012 14:34:28 -0800 (PST) In-Reply-To: <1477482293.1529544.1356037953815.JavaMail.root@erie.cs.uoguelph.ca> References: <1477482293.1529544.1356037953815.JavaMail.root@erie.cs.uoguelph.ca> Date: Thu, 20 Dec 2012 14:34:28 -0800 Message-ID: Subject: Re: NFS Problems From: Tim Gustafson To: Rick Macklem Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl3B9aqqRWAPHq5bxY74bfwuVpZ4M7X/cohKOZNm/9YUXlrXnIYGPPdKypbjSvkYcdP8Uzw Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 22:34:34 -0000 > Yep. Using Kerberos for NFS is really orthogonal to NFSv4. The only > reason some people tie the two together is that the NFSv4.0 RFC required > support for RPCSEC_GSS (which is what sec=krb5 does). Although support > for AUTH_SYS wasn't required I believe all NFSv4 servers do support it > and I know it works for FreeBSD. > > Just do the mounts without sec=krb5 and you'll be using NFSv4.0 over > AUTH_SYS (which is the old uid + gid list stuff NFS has always used). Ok, I'm trying to go down this path, but I'm running into some trouble. For my test, I am using a FreeBSD file server and a FreeBSD client. On the server, in /etc/rc.conf, I have: rpcbind_enable="yes" nfs_server_enable="yes" mountd_flags="-r -l" nfsd_enable="yes" mountd_enable="yes" rpc_lockd_enable="no" rpc_statd_enable="no" nfs_server_flags="-t -n 128" nfsv4_server_enable="yes" nfsuserd_enable="yes" And in /etc/exports, I have: V4: /export -network 192.168.0.0 -mask 255.255.255.0 And then on the client, in /etc/fstab, I have: server:/ /mnt nfs rw,nfsv4,late 0 0 I can mount /mnt with no problem, but when I change into that folder and attempt to do anything, either as the superuser or as a regular user, I get: tjg@client: cd /mnt/home/tjg tjg@client: touch foo touch: foo: Input/output error I know that it is "sorta" working, because if I attempt to cd to a folder that doesn't exist on the server, I get a different error: tjg@client: ls -al /mnt/home/tjg total 0 tjg@client: ls -al /mnt/home/foo ls: /mnt/home/foo: No such file or directory I'm sure that I'm missing a basic configuration option, but I can't find it. -- Tim Gustafson tjg@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 22:48:00 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10438424 for ; Thu, 20 Dec 2012 22:48:00 +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 BE74D8FC14 for ; Thu, 20 Dec 2012 22:47:59 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EACeV01CDaFvO/2dsb2JhbABCAw6GLLdMc4IeAQEEASNWBRYOCgICDRkCWQYTiA0GpWyTFYEijEqCG4ETA4hijSmQSII2XIIE X-IronPort-AV: E=Sophos;i="4.84,326,1355115600"; d="scan'208";a="5636577" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 20 Dec 2012 17:47:58 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 879A9B3F16; Thu, 20 Dec 2012 17:47:58 -0500 (EST) Date: Thu, 20 Dec 2012 17:47:58 -0500 (EST) From: Rick Macklem To: Tim Gustafson Message-ID: <1258576329.1531397.1356043678539.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: NFS Problems 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 - FF3.0 (Linux)/6.0.10_GA_2692) Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 22:48:00 -0000 Tim Gustafson wrote: > > Yep. Using Kerberos for NFS is really orthogonal to NFSv4. The only > > reason some people tie the two together is that the NFSv4.0 RFC > > required > > support for RPCSEC_GSS (which is what sec=krb5 does). Although > > support > > for AUTH_SYS wasn't required I believe all NFSv4 servers do support > > it > > and I know it works for FreeBSD. > > > > Just do the mounts without sec=krb5 and you'll be using NFSv4.0 over > > AUTH_SYS (which is the old uid + gid list stuff NFS has always > > used). > > Ok, I'm trying to go down this path, but I'm running into some > trouble. For my test, I am using a FreeBSD file server and a FreeBSD > client. On the server, in /etc/rc.conf, I have: > > rpcbind_enable="yes" > nfs_server_enable="yes" > mountd_flags="-r -l" > nfsd_enable="yes" > mountd_enable="yes" > rpc_lockd_enable="no" > rpc_statd_enable="no" > nfs_server_flags="-t -n 128" > nfsv4_server_enable="yes" > nfsuserd_enable="yes" > > And in /etc/exports, I have: > > V4: /export -network 192.168.0.0 -mask 255.255.255.0 > You must also export the /export file system. The "V4:" just pegs where the root is for NFSv4, it does not actually export any file systems. The /export line is the same as you would have for NFSv3. Something like: /export -alldirs -network 192.168.0.0 -mask 255.255.255.0 Check in /var/log/messages for any errors in /etc/exports. > And then on the client, in /etc/fstab, I have: > > server:/ /mnt nfs rw,nfsv4,late 0 0 > > I can mount /mnt with no problem, but when I change into that folder > and attempt to do anything, either as the superuser or as a regular > user, I get: > > tjg@client: cd /mnt/home/tjg > tjg@client: touch foo > touch: foo: Input/output error > > I know that it is "sorta" working, because if I attempt to cd to a > folder that doesn't exist on the server, I get a different error: > > tjg@client: ls -al /mnt/home/tjg > total 0 > tjg@client: ls -al /mnt/home/foo > ls: /mnt/home/foo: No such file or directory > > I'm sure that I'm missing a basic configuration option, but I can't > find it. > > -- > > Tim Gustafson > tjg@soe.ucsc.edu > 831-459-5354 > Baskin Engineering, Room 313A From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 23:15:20 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B04D1D0E for ; Thu, 20 Dec 2012 23:15:20 +0000 (UTC) (envelope-from rcartwri@asu.edu) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id 6BCA28FC18 for ; Thu, 20 Dec 2012 23:15:20 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id k13so5278612iea.8 for ; Thu, 20 Dec 2012 15:15:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=3agm1oT0nDMOLdSHyJkIu4+Vk5ymVArI8U8ETIRLwls=; b=PxiDVq8mwh9q8K7mA4I33HZyIlDxKoyh/2JsCyon4lDH0WGd7RWFpzc9bG9RGDbSVR /JFG3t0vnySR99KZPH2otRNjQffdzKqDaSqGpSk850HJd+cWwv+hjzX2bS8U4MyaDb0e z8XrnuEl04fvyym8D5qdkhe2TP/5q9ueB7JRHpTkd5WHuHW22e6SSRlN4xZjZ4QWKs5h GplDapzmeaHC+/Cm5DUB1sfTLIibiLnKFr0EZOjAOfMJA5dPG+8u1PXKdAFyy3JFxrDG BrnCN+QbxumX9bamH9voCFIXP2K5GAetG+gvNKouvR+gNpzQQ9HxXAzkETbCC1bb5pIz KEKQ== MIME-Version: 1.0 Received: by 10.42.54.211 with SMTP id s19mr10264272icg.34.1356045314037; Thu, 20 Dec 2012 15:15:14 -0800 (PST) Received: by 10.64.64.39 with HTTP; Thu, 20 Dec 2012 15:15:13 -0800 (PST) In-Reply-To: References: <50C9AFC6.6080902@FreeBSD.org> <50CA1639.1010409@FreeBSD.org> Date: Thu, 20 Dec 2012 16:15:13 -0700 Message-ID: Subject: Re: NFS/ZFS hangs after upgrading from 9.0-RELEASE to -STABLE From: "Reed A. Cartwright" To: olivier Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlsDrG1T9DjdWlSQK6Cy77+KjX1tdch9XZ3S/0wDu53tqhqTR6wpzi+bkpxb/FQS26MI99s Cc: freebsd-fs@freebsd.org, "freebsd-stable@freebsd.org" , Kashyap.Desai@lsi.com X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 23:15:20 -0000 I have also down graded to the MPS driver from 9.0. We've been running the server pretty heavily since then and no lockups have occurred since. It has been about a week. On Thu, Dec 13, 2012 at 11:14 PM, olivier wrote: > For what it's worth, I think I might have solved my problem by reverting to > an older version of the mps driver. I checked out a recent version of > 9-STABLE and reversed the changes in > http://svnweb.freebsd.org/base?view=revision&revision=230592 (perhaps there > was a simpler way of reverting to the older mps driver). So far so good, no > hang even when hammering the file system. > > This does not conclusively prove that the new LSI mps driver is at fault, > but that seems to be a likely explanation. > > Thanks to everybody who pointed me in the right direction. Hope this helps > others who run into similar problems with 9.1 > Olivier > > On Thu, Dec 13, 2012 at 10:14 AM, olivier wrote: > >> >> >> On Thu, Dec 13, 2012 at 9:54 AM, Andriy Gapon wrote: >> >>> Google for "zfs deadman". This is already committed upstream and I think >>> that it >>> is imported into FreeBSD, but I am not sure... Maybe it's imported just >>> into the >>> vendor area and is not merged yet. >>> >> >> Yes, that's exactly what I had in mind. The logic for panicking makes >> sense. >> As far as I can tell you're correct that deadman is in the vendor area but >> not merged. Any idea when it might make it into 9-STABLE? >> Thanks >> Olivier >> >> >> >> >>> So, when enabled this logic would panic a system as a way of letting know >>> that >>> something is wrong. You can read in the links why panic was selected for >>> this job. >>> >>> And speaking FreeBSD-centric - I think that our CAM layer would be a >>> perfect place >>> to detect such issues in non-ZFS-specific way. >>> >>> -- >>> Andriy Gapon >>> >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Reed A. Cartwright, PhD Assistant Professor of Genomics, Evolution, and Bioinformatics School of Life Sciences Center for Evolutionary Medicine and Informatics The Biodesign Institute Arizona State University From owner-freebsd-fs@FreeBSD.ORG Fri Dec 21 02:13:08 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06E8FC4 for ; Fri, 21 Dec 2012 02:13:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8FFF38FC12 for ; Fri, 21 Dec 2012 02:13:07 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAOLE01CDaFvO/2dsb2JhbAA8CRaGJLdNc4IeAQEBBAEBASAEJyALGxgRGQIEJQEJJgYIBwQBHASHcgykRZMMjFcBAQkHBAUGgw+BEwOIYoYlg1GBBYIugRyPLIMSgUcIFx4 X-IronPort-AV: E=Sophos;i="4.84,327,1355115600"; d="scan'208";a="5935735" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 20 Dec 2012 21:13:06 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 09222B3EFE; Thu, 20 Dec 2012 21:13:06 -0500 (EST) Date: Thu, 20 Dec 2012 21:13:06 -0500 (EST) From: Rick Macklem To: Gomes do Vale Victor Message-ID: <858457822.1533655.1356055985995.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <836B0731-DC60-40DF-8D9E-ADB9D3FD5AB5@gmail.com> Subject: Re: nfsv4 kerberized and gssname=root and allgsname MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1533654_1527068217.1356055985992" X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, Herbert Poeckl X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 02:13:08 -0000 ------=_Part_1533654_1527068217.1356055985992 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gomes do Vale Victor wrote: > Le 4 oct. 2012 =C3=A0 00:35, Rick Macklem a =C3=A9= crit : >=20 > > Ulysse 31 wrote: > >> 2012/9/29 Rick Macklem : > >>> Ulysse 31 wrote: > >>>> Hi all, > >>>> > >>>> I am actually working on a freebsd 9 backup server. > >>>> this server would backup the production server via kerberized > >>>> nfs4 > >>>> (since the old backup server, a linux one, was doing so). > >>>> we used on the old backup server a root/ kerberos identity, > >>>> which allows the backup server to access all the data. > >>>> I have followed the documentation found at : > >>>> > >>>> http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup > >>>> > >>>> done : > >>>> - added to kernel : > >>>> > >>>> options KGSSAPI > >>>> device crypto > >>>> > >>>> - added to rc.conf : > >>>> > >>>> nfs_client_enable=3D"YES" > >>>> rpc_lockd_enable=3D"YES" > >>>> rpc_statd_enable=3D"YES" > >>>> rpcbind_enable=3D"YES" > >>>> devfs_enable=3D"YES" > >>>> gssd_enable=3D"YES" > >>>> > >>>> - have done sysctl vfs.rpcsec.keytab_enctype=3D1 and added it to > >>>> /etc/sysctl.conf > >>>> > >>>> We used MIT kerberos implementation, since it is the one used on > >>>> all > >>>> our servers (mostly linux), and we have created and > >>>> /etc/krb5.keytab > >>>> containing the following keys : > >>>> host/ > >>>> nfs/ > >>>> root/ > >>>> > >>>> and, of course, i have used the available patch at : > >>>> http://people.freebsd.org/~rmacklem/rpcsec_gss-9.patch > >>>> > >>>> When i try to mount with the (B) method (the one of the google > >>>> wiki), > >>>> it works as expected, i mean, with a correct user credential, i > >>>> can > >>>> access to the user data. > >>>> But, when i try to access via the (C) method (the one that i need > >>>> in > >>>> order to do a full backup of the production storage server) i get > >>>> a > >>>> systematic kernel panic when launch the mount command. > >>>> The mount command looks to something like : mount -t nfs -o > >>>> nfsv4,sec=3Dkrb5i,gssname=3Droot,allgssname >>>> fqdn>: > > Just to confirm it, you are saying that exactly the same mount > > command, > > except without the "allgssname" option, doesn't crash? >=20 > No, in fact it's the same command with gssname=3Dnfs instead of > gssname=3Droot that does not crash. When I specify gssname=3Droot it > panics. > The same command with gssname=3Dnfs and allgssname together "works", > well should say mounts and don't crash because it does not allow > accessing as root to the nfs share since the netapp expects a > root/fqdn key to be used for that. > Don't know if this would give you an hint, I'm gonna test this patch. > tell me if you have other ideas. > For now we decided disabling kerberised nfs on the new FreeBSD backup > server in order to go on production with it without getting late. > Thanks for the help. >=20 > > > > That is weird, since when I look at the code, there shouldn't be any > > difference between the two mounts, up to the point where it crashes. > > > > The crash seems to indicate that nr_auth is bogus, but I can't see > > how/why that would happen. > > > > I have attached a patch which changes the way nr_auth is set and > > "might" > > help, although I doubt it. (It is untested, but if you want to try > > it, > > good luck with it.) > > > > I'll email again if I get something more solid figured out, rick > > > >>>> I have activated the kernel debugging stuff to get some infos, > >>>> here > >>>> is > >>>> the message : > >>>> > >>>> > >>>> Fatal trap 12: page fault while in kernel mode > >>>> cpuid =3D 0; apic id =3D 00 > >>>> fault virtual address =3D 0x368 > >>>> fault code =3D supervisor read data, page not present > >>>> instruction pointer =3D 0x20:0xffffffff80866ab7 > >>>> stack pointer =3D 0x28:0xffffff804aa39ce0 > >>>> frame pointer =3D 0x28:0xffffff804aa39d30 > >>>> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >>>> =3D DPL 0, pres 1, long 1, def32 0, gran 1 > >>>> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >>>> current process =3D 701 (mount_nfs) > >>>> trap number =3D 12 > >>>> panic: page fault > >>>> cpuid =3D 0 > >>>> KDB: stack backtrace: > >>>> #0 0xffffffff808ae486 at kdb_backtrace+0x66 > >>>> #1 0xffffffff8087885e at panic+0x1ce > >>>> #2 0xffffffff80b82380 at trap_fatal+0x290 > >>>> #3 0xffffffff80b826b8 at trap_pfault+0x1e8 > >>>> #4 0xffffffff80b82cbe at trap+0x3be > >>>> #5 0xffffffff80b6c57f at calltrap+0x8 > >>>> #6 0xffffffff80a78eda at rpc_gss_init+0x72a > >>>> #7 0xffffffff80a79cd6 at rpc_gss_refresh_auth+0x46 > >>>> #8 0xffffffff807a5a53 at newnfs_request+0x163 > >>>> #9 0xffffffff807bf0f7 at nfsrpc_getattrnovp+0xd7 > >>>> #10 0xffffffff807d9b29 at mountnfs+0x4e9 > >>>> #11 0xffffffff807db60a at nfs_mount+0x13ba > >>>> #12 0xffffffff809068fb at vfs_donmount+0x100b > >>>> #13 0xffffffff80907086 at sys_nmount+0x66 > >>>> #14 0xffffffff80b81c60 at amd64_syscall+0x540 > >>>> #15 0xffffffff80b6c867 at Xfast_syscall+0xf7 > >>>> Uptime: 2m31s > >>>> Dumping 97 out of 1002 MB:..17%..33%..50%..66%..83%..99% > >>>> > >>>> --------------------------------------------------------------------= ---- > >>>> > >>>> Does anyone as experience something similar ? is their a way to > >>>> correct that ? I finally have gotten around to testing the host based initiator credential stuff and I've attached the little patch that stops these crashes. They happen when the authentication fails for some reason. Remember that you must set vfs.rpcsec.keytab_enctype to the encryption type of the keytab entry (1 for dec-cbc-crc) for the rpcsec_gss-9.patch to work. I am working on a better patch that hopefully won't require this encryption type nonsense. The patch will probably be for stable/9 after the most recent gssd.c changes get committed. rick > >>>> Thanks for the help. > >>>> > >>> Well, you're probably the first person to try doing this in years. > >>> I > >>> did > >>> have it working about 4-5years ago. Welcome to the bleeding > >>> edge;-) > >>> > >>> Could you do the following w.r.t. above kernel: > >>> # cd /boot/nkernel (or wherever the kernel lives) > >>> # nm kernel | grep rpc_gss_init > >>> - add the offset 0x72a to the address for rpc_gss_init > >>> # addr2line -e kernel.symbols > >>> 0xXXX - the hex number above (address of rpc_gss_init+0x72a) > >>> - email me what it prints out, so I know where the crash is > >>> occurring > >>> > >>> You could also run the following command on the Linux server to > >>> capture > >>> packets during the mount attempt, then email me the xxx.pcap file > >>> so > >>> I > >>> can look at it in wireshark, to see what is happening before the > >>> crash. > >>> (I'm guessing nr_auth is somehow bogus, but that's just a > >>> guess.:-) > >>> # tcpdump -s 0 -w xxx.pcap host > >> > >> Hi, > >> > >> Sorry for the delay i was on travel and no working network > >> connection. > >> Back online for the rest of the week ^^. > >> Thanks for your help, here is what it prints out : > >> > >> root@bsdenc:/boot/kernel # nm kernel | grep rpc_gss_init > >> ffffffff80df07b0 r __set_sysinit_set_sym_svc_rpc_gss_init_sys_init > >> ffffffff80a787b0 t rpc_gss_init > >> ffffffff80a7a580 t svc_rpc_gss_init > >> ffffffff81127530 d svc_rpc_gss_init_sys_init > >> ffffffff80a7a3b0 T xdr_rpc_gss_init_res > >> root@bsdenc:/boot/kernel # addr2line -e kernel.symbols > >> 0xffffffff80a78eda > >> /usr/src/sys/rpc/rpcsec_gss/rpcsec_gss.c:772 > >> > >> > >> for the tcpdump from the linux server, i think you may are doing > >> reference to the production nfs server ? > >> if yes, unfortunately it is not linux, it is a netapp filer, so no > >> "real" root access on it (so no tcpdump available :s ). > >> if you were mentioning the old backup server (which is linux but > >> nfs > >> client), i cannot do unmount/mount on it since its production > >> (mountpoint always busy), but i can made a quick VM/testmachine > >> that > >> acts like the linux backup server and do a tcpdump from it. > >> Just let me know. Thanks again. > >> > >> -- > >> Ulysse31 > >> > >>> > >>> rick > >>> > >>>> -- > >>>> Ulysse31 > >>>> _______________________________________________ > >>>> 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" > > ------=_Part_1533654_1527068217.1356055985992 Content-Type: text/x-patch; name=gssname-krpc.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=gssname-krpc.patch LS0tIGZzL25mcy9uZnNfY29tbW9ua3JwYy5jLnNhdgkyMDEyLTEyLTIwIDE4OjI3OjAxLjAwMDAw MDAwMCAtMDUwMAorKysgZnMvbmZzL25mc19jb21tb25rcnBjLmMJMjAxMi0xMi0yMCAyMTowMzoy Mi4wMDAwMDAwMDAgLTA1MDAKQEAgLTQwOSwxMCArNDA5LDEyIEBAIG5mc19nZXRhdXRoKHN0cnVj dCBuZnNzb2NrcmVxICpucnAsIGludCAKIAkJaWYgKGNsbnRfcHJpbmNpcGFsID09IE5VTEwpCiAJ CQlhdXRoID0gcnBjX2dzc19zZWNmaW5kX2NhbGwobnJwLT5ucl9jbGllbnQsIGNyZWQsCiAJCQkg ICAgc3J2X3ByaW5jaXBhbCwgbWVjaF9vaWQsIHN2Yyk7Ci0JCWVsc2UKKwkJZWxzZSB7CiAJCQlh dXRoID0gcnBjX2dzc19zZWNjcmVhdGVfY2FsbChucnAtPm5yX2NsaWVudCwgY3JlZCwKIAkJCSAg ICBjbG50X3ByaW5jaXBhbCwgc3J2X3ByaW5jaXBhbCwgImtlcmJlcm9zdjUiLAogCQkJICAgIHN2 YywgTlVMTCwgTlVMTCwgTlVMTCk7CisJCQlyZXR1cm4gKGF1dGgpOworCQl9CiAJCWlmIChhdXRo ICE9IE5VTEwpCiAJCQlyZXR1cm4gKGF1dGgpOwogCQkvKiBmYWxsdGhyb3VnaCAqLwo= ------=_Part_1533654_1527068217.1356055985992-- From owner-freebsd-fs@FreeBSD.ORG Fri Dec 21 07:44:15 2012 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A335BF3E; Fri, 21 Dec 2012 07:44:15 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6B47C8FC0C; Fri, 21 Dec 2012 07:44:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBL7iFwS031674; Fri, 21 Dec 2012 07:44:15 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBL7iFrE031670; Fri, 21 Dec 2012 07:44:15 GMT (envelope-from eadler) Date: Fri, 21 Dec 2012 07:44:15 GMT Message-Id: <201212210744.qBL7iFrE031670@freefall.freebsd.org> To: yuri@tsoft.com, eadler@FreeBSD.org, freebsd-fs@FreeBSD.org From: eadler@FreeBSD.org Subject: Re: kern/133174: [msdosfs] [patch] msdosfs must support multibyte international characters in file names X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 07:44:15 -0000 Synopsis: [msdosfs] [patch] msdosfs must support multibyte international characters in file names State-Changed-From-To: closed->patched State-Changed-By: eadler State-Changed-When: Fri Dec 21 07:44:14 UTC 2012 State-Changed-Why: committed in HEAD, not STABLE - will this be MFCed? http://www.freebsd.org/cgi/query-pr.cgi?pr=133174 From owner-freebsd-fs@FreeBSD.ORG Fri Dec 21 08:48:43 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75D27B0D; Fri, 21 Dec 2012 08:48:43 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by mx1.freebsd.org (Postfix) with ESMTP id 153478FC0A; Fri, 21 Dec 2012 08:48:42 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id h2so4291238oag.7 for ; Fri, 21 Dec 2012 00:48:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4iXfWWEg7cGGBix/aMYx67RX9PYyibHd5VQ6PRRDwZk=; b=SX88f07WTEwYpoNU7vq48DfPl6BvndogRSCBohr9OAK9tT1UKHNW0J6LGblG7puT9d nLYkXGPRQh2JSyZ1zb4UXSYdDaFMrFtvRd3NC4bb1dyYIRONsVmbcoqfqF8I1enlJTON 4xt5FUnKVgKQTnjBaqebJfOJ0xmp22A+GspQ6eK85azPYpQGrkm0rv+PGlAgibAMhTZ2 ZVEarsFPePIqK6uNB3TA8Dg6SSbTmI2XGSe3d8MG3LddKQspywXIGw5pogbjvV1SEUUB zRZ0BJpAAhGWytmwIIxOwKJlfVSW0egIcTQ+D3A7WD56NHM50YalY3SKQp3SRKdyQKpr tbdA== MIME-Version: 1.0 Received: by 10.182.2.169 with SMTP id 9mr10533012obv.66.1356079716219; Fri, 21 Dec 2012 00:48:36 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 21 Dec 2012 00:48:36 -0800 (PST) In-Reply-To: <201212202210.qBKMA0CG097366@freefall.freebsd.org> References: <201212202210.qBKMA0CG097366@freefall.freebsd.org> Date: Fri, 21 Dec 2012 00:48:36 -0800 Message-ID: Subject: Re: kern/133174: [msdosfs] [patch] msdosfs must support multibyte international characters in file names From: Garrett Cooper To: Yuri Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, Kevin Lo , Xin LI X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 08:48:43 -0000 On Thu, Dec 20, 2012 at 2:10 PM, Yuri wrote: > The following reply was made to PR kern/133174; it has been noted by GNATS. > > From: Yuri > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/133174: [msdosfs] [patch] msdosfs must support multibyte > international characters in file names > Date: Thu, 20 Dec 2012 13:54:09 -0800 > > 9.1-STABLE doesn't have this patch. > Need to merge it into 9.1. CCing potentially interested parties. Thanks! -Garrett From owner-freebsd-fs@FreeBSD.ORG Sat Dec 22 22:50:44 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 925906C4 for ; Sat, 22 Dec 2012 22:50:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5F38FC16 for ; Sat, 22 Dec 2012 22:50:43 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAC041lCDaFvO/2dsb2JhbABBAw6GLLdoc4IeAQEFI1YbDgoCAg0ZAlkGE4gTozOReYEiizWBFYIbgRMDiGKNKpBIgjZcggQ X-IronPort-AV: E=Sophos;i="4.84,338,1355115600"; d="scan'208";a="6187679" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 22 Dec 2012 17:50:37 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 05D0BB4083; Sat, 22 Dec 2012 17:50:37 -0500 (EST) Date: Sat, 22 Dec 2012 17:50:36 -0500 (EST) From: Rick Macklem To: Tim Gustafson Message-ID: <887595941.1558313.1356216636966.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: NFS Problems 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 - FF3.0 (Linux)/6.0.10_GA_2692) Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 22:50:44 -0000 Tim Gustafson wrote: > > If you need locking to work, I'd suggest you try NFSv4. > > I'd like to, but we have Macintosh clients as well, and Mac has had > serious problems with NFSv4 in the past, specifically related to its > Kerberos support. Is it possible to have an NFSv4 server without > Kerberos? > > -- > > Tim Gustafson > tjg@soe.ucsc.edu > 831-459-5354 > Baskin Engineering, Room 313A Oh, and there was a patch applied to head on Jan. 31, 2012 (r230801) and MFC'd to stable/9 on Feb. 14, 2012 (r231633) that was related to NLM permission checking. If you don't have that patch (I can't remember what version of FreeBSD you said you were running), it might fix your NLM problem. rick