From owner-freebsd-fs@FreeBSD.ORG Sun Feb 3 14:55:07 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 55A1E6B5; Sun, 3 Feb 2013 14:55:07 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mx1.freebsd.org (Postfix) with ESMTP id 1113CA88; Sun, 3 Feb 2013 14:55:07 +0000 (UTC) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (Postfix) with ESMTP id 2512F46F; Sun, 3 Feb 2013 15:54:58 +0100 (CET) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from mail.wasikowski.net ([91.204.91.44]) by mail.wasikowski.net (scan.wasikowski.net [91.204.91.44]) (amavisd-new, port 10026) with ESMTP id f_7hc1LEVGUa; Sun, 3 Feb 2013 15:54:57 +0100 (CET) Received: from [192.168.168.2] (89-72-12-251.dynamic.chello.pl [89.72.12.251]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lukasz@wasikowski.net) by mail.wasikowski.net (Postfix) with ESMTPSA id BBB2F46B; Sun, 3 Feb 2013 15:54:57 +0100 (CET) Message-ID: <510E7A41.3070101@wasikowski.net> Date: Sun, 03 Feb 2013 15:54:57 +0100 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-jail@freebsd.org Subject: Problem with zfs mount all in jails X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 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: Sun, 03 Feb 2013 14:55:07 -0000 Hi, I've got a problem with automation of zfs mount in a jail. I'm using 9.1-STABLE r246099 and ezjail to manage jails. Each jail has it's own dataset, and I want to delegate another dataset(s) which can be managed from inside a jail. 1. Dataset for jail: # zfs list jinx/jails/jtest NAME USED AVAIL REFER MOUNTPOINT jinx/jails/jtest 50.7M 18.5G 1.59M /data/jails/jtest 2. Dataset for injail management: # zfs list jinx/jails/jtest/www NAME USED AVAIL REFER MOUNTPOINT jinx/jails/jtest/www 63K 18.5G 32K /data/www # zfs get jailed jinx/jails/jtest/www NAME PROPERTY VALUE SOURCE jinx/jails/jtest/www jailed on local 3. Some ezjail settings for this jail (/usr/local/etc/ezjail/jtest file): export jail_jtest_rootdir="/data/jails/jtest" export jail_jtest_mount_enable="YES" export jail_jtest_devfs_enable="YES" export jail_jtest_devfs_ruleset="devfsrules_jail" export jail_jtest_parameters="allow.mount.zfs=1 allow.mount=1 enforce_statfs=1 allow.raw_sockets=1" export jail_jtest_zfs_datasets="jinx/jails/jtest/www" 4. In jail's rc.conf zfs is enabled: # grep zfs /data/jails/jtest/etc/rc.conf zfs_enable="YES" 5. I start jail (service ezjail start) and got this: # jexec 1 zfs get mounted jinx/jails/jtest/www NAME PROPERTY VALUE SOURCE jinx/jails/jtest/www mounted no - But when I run: # jexec 1 service zfs start dataset gets mounted # jexec 1 zfs get mounted jinx/jails/jtest/www NAME PROPERTY VALUE SOURCE jinx/jails/jtest/www mounted yes - What am I missing? Why is zfs mount -a (which should be invoked by /etc/rc.d/zfs) not launched on jail start but works when I run zfs service manually? -- best regards, Lukasz Wasikowski From owner-freebsd-fs@FreeBSD.ORG Sun Feb 3 19:22:02 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35D24FEE for ; Sun, 3 Feb 2013 19:22:02 +0000 (UTC) (envelope-from krichy@cflinux.hu) Received: from pi.nmdps.net (pi.nmdps.net [IPv6:2a01:be00:10:201:0:80:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id F0912793 for ; Sun, 3 Feb 2013 19:22:01 +0000 (UTC) Received: from pi.nmdps.net (pi.nmdps.net [109.61.102.5]) (Authenticated sender: krichy@cflinux.hu) by pi.nmdps.net (Postfix) with ESMTPSA id 0D053833 for ; Sun, 3 Feb 2013 20:21:52 +0100 (CET) Date: Sun, 3 Feb 2013 20:21:52 +0100 (CET) From: Richard Kojedzinszky X-X-Sender: krichy@pi.nmdps.net To: freebsd-fs@freebsd.org Subject: mac_biba leak Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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, 03 Feb 2013 19:22:02 -0000 Dear freebsd-fs team, I am using 9-stable, and found that when using zfs and mac_biba loaded, some kind of memory leak is present, as vmstat shows increasing allocs for mac_biba. Is it possible that it is the same leak as one was with zfs+nfs? Regards, Kojedzinszky Richard From owner-freebsd-fs@FreeBSD.ORG Mon Feb 4 02:35:11 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A5884C49 for ; Mon, 4 Feb 2013 02:35:11 +0000 (UTC) (envelope-from giffunip@yahoo.com) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) by mx1.freebsd.org (Postfix) with SMTP id 23E84833 for ; Mon, 4 Feb 2013 02:35:10 +0000 (UTC) Received: from [98.139.212.147] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2013 02:32:34 -0000 Received: from [98.139.215.254] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2013 02:32:34 -0000 Received: from [127.0.0.1] by omp1067.mail.bf1.yahoo.com with NNFMP; 04 Feb 2013 02:32:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 436143.10915.bm@omp1067.mail.bf1.yahoo.com Received: (qmail 68588 invoked by uid 60001); 4 Feb 2013 02:32:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359945154; bh=14RC7nOYdMul2SlNDTso11jKS8EjxVfiFk8xEGdHNOs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qw6rU9L/T0AEhW9hluwDhmwynqMxzPq+3xvOAcjyO4DrKsb63FIDCNYU1cMq+WHC9C3ZuMtdlZ/WFIL8Dj+pkFMWDoshj/3I5AlcIpyK0kQZyWFjxixB1XtJshzoDS5q8Sa5L/Jp2V2hnQkTQIyXxng5vTLurJuaNQ5jlinD2IE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=O8Asd/Iw+ckmg0yBo7pL0LMHoSfh/90o3d0d1gKBt1ZFC3k2/o08L64pLt/5bbf/t4ixs6dfHuO5wxRHBdTsWDdnMYaXTGRi87oLBQxlm56pOhQXu+UBNYod8dJoBWJi9hfF5sMoppCss7Pi5hIiB5ihdoyIfydN4C1lnsCmfQ4=; X-YMail-OSG: vMbNGr0VM1kLe.G5cXdqJ.4W9J8HNAZmyPII2nZvHbW_0Fz pH2CWz5M8XVxQwN4CeQktL_TZzQYCDqnWiI1eClElMfVC6Wi7Whn1JQ5gj.h 12.9MuXrLuMoJFChk.6y1Da7cbr6ZzEiOCIe6G9G0p2TRA_QqUcVlYjxRbqH pibz1cTx92fZM37.TpkG_dzNagvLxQtiVi3AmaVF9_j2VZlEWZ0kqy2z9w1j GhqvOxZH.KLWBVhsqJnJ84tj8jn8MxPSlY06dZs8oIuPJF0lG5h5DGmYWIa3 Y3FJcy4Nbd3UI6Kp3pYV7xDhQSGbCSwSrUi7BTQ7867.QwTPf69YTE9q_S7E RBYbxS8uJdCy5UjWy0LqQbWSJjEbGjlY4IRySnYGuu5xi_fNFzaqS_KCdgdu oq9gTUKLcvqUfqe01qWYRxmqkJGlUZCJ4to285tWdqwRjZ_BMhxobNEjINkH kiO_daqgVAXqQRiQFHNl4z9OhTwyn_nDGRvJXWvSwcOzmEnUG53NoOan0DLT VjAQu_RAyuz7lM6fYLA-- Received: from [200.118.157.7] by web162105.mail.bf1.yahoo.com via HTTP; Sun, 03 Feb 2013 18:32:34 PST X-Rocket-MIMEInfo: 001.001, KE1vdmluZyB0aGUgZGlzY3Vzc2lvbiB0byBmcmVlYnNkLWZzKQoKSGVsbG87CgoKLS0tLS0gTWVzc2FnZ2lvIG9yaWdpbmFsZSAtLS0tLQo.IERhOiBCcnVjZSBFdmFuc8KgCj4gCi4uLgo.PiAgSnVzdCBhIG5vdGUgdGhhdCBjbGFuZyBhY3R1YWxseSB3YXJuZWQgYWJvdXQgdGhpcyBvbmUuCj4.ICBJdCBoYXMgYSBmZXcgbW9yZSBzaW1pbGFyIHdhcm5pbmdzIGZvciB1ZnMvZmZzIGNvZGUuCj4gCj4gSSB3b25kZXJlZCBob3cgdGhlIERJUCBtYWNybyBoaWQgdGhlIHdhcm5pbmcuCj7CoAoKVGhlIGNvbXBhcmkBMAEBAQE- X-RocketYMMF: giffunip X-Mailer: YahooMailWebService/0.8.131.499 References: <201302031716.r13HGXNP060303@svn.freebsd.org> <510E9D47.2030403@FreeBSD.org> <20130204062149.U2673@besplex.bde.org> Message-ID: <1359945154.62069.YahooMailNeo@web162105.mail.bf1.yahoo.com> Date: Sun, 3 Feb 2013 18:32:34 -0800 (PST) From: Pedro Giffuni Subject: Re: svn commit: r246289 - head/sys/ufs/ffs To: Bruce Evans , Andriy Gapon In-Reply-To: <20130204062149.U2673@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-fs@freebsd.org" , Kirk McKusick X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Pedro Giffuni List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 02:35:11 -0000 (Moving the discussion to freebsd-fs)=0A=0AHello;=0A=0A=0A----- Messaggio o= riginale -----=0A> Da: Bruce Evans=A0=0A> =0A...=0A>> Just a note that cla= ng actually warned about this one.=0A>> It has a few more similar warnings= for ufs/ffs code.=0A> =0A> I wondered how the DIP macro hid the warning.= =0A>=A0=0A=0AThe comparison is perfectly legal for UFS1 so perhaps=0Agcc gi= ves the "benefit of the doubt" to avoid false positives.=0A=0A>>> =A0 bloc= ks being freed against the value i_blocks. If the number of=0A>>> =A0 bloc= ks being freed exceeds i_blocks, just set i_blocks to zero.=0A>>> =0A>>> = =A0 Reported by: Pedro Giffuni (pfg@)=0A>>> =A0 MFC after:=A0 2 weeks=0A= > =0A> Perhaps the larger bugs pointed to this warning were lost in transla= tion:=0A> - di_blocks overflows for ffs1.=A0 This is now physically possibl= e.=0A> =A0 di_blocks has type int32_t, as required to match st_blocks in th= e old=0A> =A0 struct stat (both will overflow at the same point).=A0 Since = di_blocks=0A> =A0 counts DEV_BSIZE-blocks, overflow occurs at file size abo= ut 1TB for=0A> =A0 files without many holes.=0A> - st_blocks overflows for = the old stat() syscall.=A0 For the new stat()=0A> =A0 syscall, st_blocks ha= s type blkcnt_t =3D int64_t, so overflow is not=0A> =A0 physically possible= .=A0 But cvtstat() silently overflows when the=0A> =A0 64-bit st_blocks doe= sn't fit in the 32-bit one.=0A> - di_blocks for ffs2 has type uint64_t.=A0 = This has a sign mismatch with=0A> =A0 both the ffs1 di_blocks and blkcnt_t.= =A0 blkcnt_t is specified to be=0A> =A0 signed.=A0 i_blocks for ffs has the= same type as di_blocks for ffs2=0A> =A0 (unsigned ...), so it is mismatche= d too.=A0 The sign mismatches should=0A> =A0 cause more compiler warnings.= =A0 These would point to further overflow=0A> =A0 possibilities.=A0 However= , overflow is physically impossible even for=0A> =A0 va_bytes =3D i_blocks = * DEV_BSIZE.=A0 So there are no extra overflows=0A> =A0 from the sign misma= tches.=A0 Using the unsigned types just asks for=0A> =A0 more sign extensio= n bugs like the one fixed here.=0A> =0A> ext2fs has the same bug.=A0 It is = unnecessary in ext2fs, since there are=0A> no fragments so i_blocks can jus= t count in units of fs blocks and these=0A> are naturally limited by the fs= block type.=A0 The fs block type is=0A> uint32_t in ext2fs and int32_t in = ffs1.=A0 So ext2fs really needs an=0A> unsigned type for i_blocks to get an= extra bit without going to 64=0A> bits.=A0 shell-init: could not get curre= nt directory: No such file or=0A> directory.=A0 Avoiding overflow depends o= n st_blocks having more than 32+9=0A> value bits, so 32-bit stat() could st= ill overflow and needs a clamp.=0A> However, the disk format is to store i_= count in DEV_BSIZE units, so=0A> this doesn't work -- it has the same overf= low problem as cvtstat(),=0A> at 32 bits instead of 31.=0A> =0A> Limiting t= he file size to ~1TB is not a good fix for this, since 1TB=0A> non-sparse f= iles are not very common or useful, and the limit would=0A> also apply to s= parse files.=A0 So block allocators should check that=0A> i_blocks won't ov= erflow before increasing it.=0A>=A0=0A=0ASurely not anywhere near a complet= e solution but perhaps it wouldn't=0Abe incompatible=A0to change i_blocks a= nd friends to be unsigned in UFS1.=0AThat is=A0something that remains to be= completed in ext2fs, but according=0Ato fsx there=A0are bigger=A0problems = there at this time.=0A=0APedro. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 4 05:05:03 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3CC50351; Mon, 4 Feb 2013 05:05:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id C2CA5D58; Mon, 4 Feb 2013 05:05:02 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r1454nm5030756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 16:04:52 +1100 Date: Mon, 4 Feb 2013 16:04:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pedro Giffuni Subject: Re: svn commit: r246289 - head/sys/ufs/ffs In-Reply-To: <1359945154.62069.YahooMailNeo@web162105.mail.bf1.yahoo.com> Message-ID: <20130204155554.I932@besplex.bde.org> References: <201302031716.r13HGXNP060303@svn.freebsd.org> <510E9D47.2030403@FreeBSD.org> <20130204062149.U2673@besplex.bde.org> <1359945154.62069.YahooMailNeo@web162105.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-874308365-1359954289=:932" X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=RbTIkCRv c=1 sm=1 a=3vEzreLPZ8cA:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=Nw6HGA-A-RMA:10 a=HxwSwiba8RqU5nfzRA0A:9 a=45ClL6m2LaAA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: "freebsd-fs@freebsd.org" , Andriy Gapon , Kirk McKusick 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, 04 Feb 2013 05:05:03 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-874308365-1359954289=:932 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 3 Feb 2013, Pedro Giffuni wrote: > (Moving the discussion to freebsd-fs) >> Da: Bruce Evans=A0 >> > ... >>> Just a note that clang actually warned about this one. >>> It has a few more similar warnings for ufs/ffs code. >> >> I wondered how the DIP macro hid the warning. >> =A0 > > The comparison is perfectly legal for UFS1 so perhaps > gcc gives the "benefit of the doubt" to avoid false positives. >=20 >> Perhaps the larger bugs pointed to this warning were lost in translation= : >> - di_blocks overflows for ffs1.=A0 This is now physically possible. >> ... > Surely not anywhere near a complete solution but perhaps it wouldn't > be incompatible=A0to change i_blocks and friends to be unsigned in UFS1. > That is=A0something that remains to be completed in ext2fs, but according > to fsx there=A0are bigger=A0problems there at this time. That only gives 1 more bit, but 7 more are required (for the expansion factor MAXBSIZE / DEV_BSIZE =3D 2**7). More if someone increases MAXBSIZE. Bruce --0-874308365-1359954289=:932-- From owner-freebsd-fs@FreeBSD.ORG Mon Feb 4 11:06:43 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B3FA094E for ; Mon, 4 Feb 2013 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 A5C61CFF for ; Mon, 4 Feb 2013 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r14B6hTK028737 for ; Mon, 4 Feb 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r14B6hhv028735 for freebsd-fs@FreeBSD.org; Mon, 4 Feb 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Feb 2013 11:06:43 GMT Message-Id: <201302041106.r14B6hhv028735@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, 04 Feb 2013 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/175179 fs [zfs] ZFS may attach wrong device on move o kern/175071 fs [ufs] [panic] softdep_deallocate_dependencies: unrecov 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 f 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 p kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter 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 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 296 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 4 16:03:34 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 01947B70 for ; Mon, 4 Feb 2013 16:03:34 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by mx1.freebsd.org (Postfix) with ESMTP id 86C62639 for ; Mon, 4 Feb 2013 16:03:33 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MWdT3-1UU6WC28QV-00XsiY for ; Mon, 04 Feb 2013 17:03:27 +0100 Received: (qmail invoked by alias); 04 Feb 2013 16:03:27 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp028) with SMTP; 04 Feb 2013 17:03:27 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX1+5VDIdOpW5cENwgu60EcrKhlqveTlCSfIzW2baTP /2qjwW6T33xepm From: Christian Gusenbauer To: John Baldwin Subject: [SOLVED] Re: 9.1-stable crashes while copying data from a NFS mounted directory Date: Mon, 4 Feb 2013 17:05:31 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201301241805.57623.c47g@gmx.at> <20130124212212.GM2522@kib.kiev.ua> <201301241721.51102.jhb@freebsd.org> In-Reply-To: <201301241721.51102.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201302041705.31461.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: freebsd-fs@freebsd.org, yongari@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, 04 Feb 2013 16:03:34 -0000 On Thursday 24 January 2013 23:21:50 John Baldwin wrote: > On Thursday, January 24, 2013 4:22:12 pm Konstantin Belousov wrote: > > On Thu, Jan 24, 2013 at 09:50:52PM +0100, Christian Gusenbauer wrote: > > > On Thursday 24 January 2013 20:37:09 Konstantin Belousov wrote: > > > > On Thu, Jan 24, 2013 at 07:50:49PM +0100, Christian Gusenbauer wrote: > > > > > On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: > > > > > > On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov wrote: > > > > > > > On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer wrote: > > > > > > > > Hi! > > > > > > > > > > > > > > > > I'm using 9.1 stable svn revision 245605 and I get the panic > > > > > > > > below if I execute the following commands (as single user): > > > > > > > > > > > > > > > > # swapon -a > > > > > > > > # dumpon /dev/ada0s3b > > > > > > > > # mount -u / > > > > > > > > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > > > > > > > > # mount -t nfs -o rsize=32768 data:/multimedia /mnt > > > > > > > > # cp /mnt/Movies/test/a.m2ts /tmp > > > > > > > > > > > > > > > > then the system panics almost immediately. I'll attach the > > > > > > > > stack trace. > > > > > > > > > > > > > > > > Note, that I'm using jumbo frames (6144 byte) on a 1Gbit > > > > > > > > network, maybe that's the cause for the panic, because the > > > > > > > > bcopy (see stack frame #15) fails. > > > > > > > > > > > > > > > > Any clues? > > > > > > > > > > > > > > I tried a similar operation with the nfs mount of rsize=32768 > > > > > > > and mtu 6144, but the machine runs HEAD and em instead of age. > > > > > > > I was unable to reproduce the panic on the copy of the 5GB > > > > > > > file from nfs mount. > > > > > > > > > > Hmmm, I did a quick test. If I do not change the MTU, so just > > > > > configuring age0 with > > > > > > > > > > # ifconfig age0 inet 192.168.2.2 up > > > > > > > > > > then I can copy all files from the mounted directory without any > > > > > problems, too. So it's probably age0 related? > > > > > > > > From your backtrace and the buffer printout, I see somewhat strange > > > > thing. The buffer data address is 0xffffff8171418000, while kernel > > > > faulted at the attempt to write at 0xffffff8171413000, which is is > > > > lower then the buffer data pointer, at the attempt to bcopy to the > > > > buffer. > > > > > > > > The other data suggests that there were no overflow of the data from > > > > the server response. So it might be that mbuf_len(mp) returned > > > > negative number ? I am not sure is it possible at all. > > > > > > > > Try this debugging patch, please. You need to add INVARIANTS etc to > > > > the kernel config. > > > > > > > > diff --git a/sys/fs/nfs/nfs_commonsubs.c > > > > b/sys/fs/nfs/nfs_commonsubs.c index efc0786..9a6bda5 100644 > > > > --- a/sys/fs/nfs/nfs_commonsubs.c > > > > +++ b/sys/fs/nfs/nfs_commonsubs.c > > > > @@ -218,6 +218,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct > > > > uio *uiop, int siz) } > > > > > > > > mbufcp = NFSMTOD(mp, caddr_t); > > > > len = mbuf_len(mp); > > > > > > > > + KASSERT(len > 0, ("len %d", len)); > > > > > > > > } > > > > xfer = (left > len) ? len : left; > > > > > > > > #ifdef notdef > > > > > > > > @@ -239,6 +240,8 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct > > > > uio *uiop, int siz) uiop->uio_resid -= xfer; > > > > > > > > } > > > > if (uiop->uio_iov->iov_len <= siz) { > > > > > > > > + KASSERT(uiop->uio_iovcnt > 1, ("uio_iovcnt %d", > > > > + uiop->uio_iovcnt)); > > > > > > > > uiop->uio_iovcnt--; > > > > uiop->uio_iov++; > > > > > > > > } else { > > > > > > > > I thought that server have returned too long response, but it seems > > > > to be not the case from your data. Still, I think the patch below > > > > might be due. > > > > > > > > diff --git a/sys/fs/nfsclient/nfs_clrpcops.c > > > > b/sys/fs/nfsclient/nfs_clrpcops.c index be0476a..a89b907 100644 > > > > --- a/sys/fs/nfsclient/nfs_clrpcops.c > > > > +++ b/sys/fs/nfsclient/nfs_clrpcops.c > > > > @@ -1444,7 +1444,7 @@ nfsrpc_readrpc(vnode_t vp, struct uio *uiop, > > > > struct ucred *cred, NFSM_DISSECT(tl, u_int32_t *, NFSX_UNSIGNED); > > > > > > > > eof = fxdr_unsigned(int, *tl); > > > > > > > > } > > > > > > > > - NFSM_STRSIZ(retlen, rsize); > > > > + NFSM_STRSIZ(retlen, len); > > > > > > > > error = nfsm_mbufuio(nd, uiop, retlen); > > > > if (error) > > > > > > > > goto nfsmout; > > > > > > I applied your patches and now I get a > > > > > > panic: len -4 > > > cpuid = 1 > > > KDB: enter: panic > > > Dumping 377 out of 6116 > > > MB:..5%..13%..22%..34%..43%..51%..64%..73%..81%..94% > > > > This means that the age driver either produced corrupted mbuf chain, > > or filled wrong negative value into the mbuf len field. I am quite > > certain that the issue is in the driver. > > > > I added the net@ to Cc:, hopefully you could get help there. > > And I've cc'd Pyun who has written most of this driver and is likely the > one most familiar with its handling of jumbo frames. Hi All! I was in contact with Pyun. We quickly found out that it is indeed a driver problem. Pyun solved it and will commit the fix within the next few days. There's only one (minor) problem open, which I can not tell if it really is one: Konstantin sent me an initial patch for the NFS code where he added an KASSERT(uiop->uio_iovcnt > 1) which triggers even with Pyun's fix. Without that assert my tests show now problem at all. So is this a problem? Thanks guys (especially Pyun) for helping & fixing! Ciao, Christian. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 4 16:33:57 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6C83F7FB; Mon, 4 Feb 2013 16:33:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D76CB7F3; Mon, 4 Feb 2013 16:33:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r14GXnZB011216; Mon, 4 Feb 2013 18:33:49 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r14GXnZB011216 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r14GXnMu011215; Mon, 4 Feb 2013 18:33:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 4 Feb 2013 18:33:49 +0200 From: Konstantin Belousov To: Christian Gusenbauer Subject: Re: [SOLVED] Re: 9.1-stable crashes while copying data from a NFS mounted directory Message-ID: <20130204163349.GA2522@kib.kiev.ua> References: <201301241805.57623.c47g@gmx.at> <20130124212212.GM2522@kib.kiev.ua> <201301241721.51102.jhb@freebsd.org> <201302041705.31461.c47g@gmx.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6QJUVa4aAx/xSqH0" Content-Disposition: inline In-Reply-To: <201302041705.31461.c47g@gmx.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-fs@freebsd.org, yongari@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, 04 Feb 2013 16:33:57 -0000 --6QJUVa4aAx/xSqH0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 04, 2013 at 05:05:31PM +0100, Christian Gusenbauer wrote: > I was in contact with Pyun. We quickly found out that it is indeed a driv= er=20 > problem. Pyun solved it and will commit the fix within the next few days. >=20 > There's only one (minor) problem open, which I can not tell if it really = is=20 > one: Konstantin sent me an initial patch for the NFS code where he added = an=20 > KASSERT(uiop->uio_iovcnt > 1) which triggers even with Pyun's fix. Withou= t=20 Is it > 1 or >=3D 1 ? I believe it should work fine with the condition being >=3D 1, it did for my test box. Anyway, I do not plan to commit this assertion for now. > that assert my tests show now problem at all. So is this a problem? >=20 > Thanks guys (especially Pyun) for helping & fixing! >=20 > Ciao, > Christian. --6QJUVa4aAx/xSqH0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRD+LsAAoJEJDCuSvBvK1BwRsP/04uzLXN8IbJZPOVupk/dcpc aJwAbcx5Bey9aT/MeHT9NBNkPDFW8T3IRR3XmROZX1sce4KWrGa1Ynj7udgS7CMc sKlRkgBXCesk7lnUYuXR2SgsNtzY5kMJocziyrGsPuJTM+U8w/dYePvZLGq11P3i zvWkEC3HHWB2cDkfZxd3Sc49uvyZAsH+ioQSfqLHqHQzzbW/ji5BCbxPLy4pGcGZ vLvi38PwhTa0Kajr3CcXonP2IXlhYC1sCY2F9U25JPmtDsuZzsS2+tJkpQPmKw1f EJnef/74KtfdeHnY1K2pJNYD3Z4ucHiC8roVlUuFnuObhhDSRquWnRbMsd6MBsK6 lXFsi4S5o+t4WGDzT1sOfWh7ga0iF0olsKUYgY/AwYe8TwICRxKo3hl69jw4VicP BSXZZD7Gzi6MMvadw/fhqfHf7GbTul1YJ0rSkCW+qy+tKo8YMVwzA5oXEG/53TSD RUqv8P+NOkTI9uFISJ0eMwbp2QRLJS4vy9H4ROIVmeY990gbThl53qlVDLIQqJCi uCaOr/9mN6k0ilL5AOxalEUF6orCeuT65su+XK3vlsaO/O20XmXKPuq9n8ZsbtzF Fllmg647MoJZsuCT8k5TcuiFiWR9yTFiMCfv3r/bhaUrZcWJjvkWEc4b5yO1BcBc tp1uX0wjFLITBw7gDnKw =Xp8e -----END PGP SIGNATURE----- --6QJUVa4aAx/xSqH0-- From owner-freebsd-fs@FreeBSD.ORG Mon Feb 4 16:38:30 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A4DA8F9 for ; Mon, 4 Feb 2013 16:38:30 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id AA6A3826 for ; Mon, 4 Feb 2013 16:38:29 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M06gE-1UphOa3UE8-00uG3y for ; Mon, 04 Feb 2013 17:38:28 +0100 Received: (qmail invoked by alias); 04 Feb 2013 16:38:28 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp031) with SMTP; 04 Feb 2013 17:38:28 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX1+nTFQls06n+DixucTay+gVwY/HzJLP2EFNb7OT/H 1j0e8UguoPfJqC From: Christian Gusenbauer To: Konstantin Belousov Subject: Re: [SOLVED] Re: 9.1-stable crashes while copying data from a NFS mounted directory Date: Mon, 4 Feb 2013 17:40:32 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201301241805.57623.c47g@gmx.at> <201302041705.31461.c47g@gmx.at> <20130204163349.GA2522@kib.kiev.ua> In-Reply-To: <20130204163349.GA2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201302041740.33014.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: freebsd-fs@freebsd.org, yongari@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, 04 Feb 2013 16:38:30 -0000 On Monday 04 February 2013 17:33:49 Konstantin Belousov wrote: > On Mon, Feb 04, 2013 at 05:05:31PM +0100, Christian Gusenbauer wrote: > > I was in contact with Pyun. We quickly found out that it is indeed a > > driver problem. Pyun solved it and will commit the fix within the next > > few days. > > > > There's only one (minor) problem open, which I can not tell if it really > > is one: Konstantin sent me an initial patch for the NFS code where he > > added an KASSERT(uiop->uio_iovcnt > 1) which triggers even with Pyun's > > fix. Without > > Is it > 1 or >= 1 ? I believe it should work fine with the condition being > > >= 1, it did for my test box. > > Anyway, I do not plan to commit this assertion for now. > > > that assert my tests show now problem at all. So is this a problem? > > > > Thanks guys (especially Pyun) for helping & fixing! > > > > Ciao, > > Christian. Hi! It's > 1. Ciao, Christian. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 4 20:47:24 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4BF9F85E; Mon, 4 Feb 2013 20:47:24 +0000 (UTC) (envelope-from linimon@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 25661D7D; Mon, 4 Feb 2013 20:47:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r14KlOZ2041587; Mon, 4 Feb 2013 20:47:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r14KlOhH041583; Mon, 4 Feb 2013 20:47:24 GMT (envelope-from linimon) Date: Mon, 4 Feb 2013 20:47:24 GMT Message-Id: <201302042047.r14KlOhH041583@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/175794: [ufs] [patch] remove cruft, fix inconsistent panic messages 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, 04 Feb 2013 20:47:24 -0000 Old Synopsis: Patches for ufs New Synopsis: [ufs] [patch] remove cruft, fix inconsistent panic messages Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 4 20:46:18 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=175794 From owner-freebsd-fs@FreeBSD.ORG Tue Feb 5 04:45:40 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 867D3619; Tue, 5 Feb 2013 04:45:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2076DA; Tue, 5 Feb 2013 04:45:39 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id kp1so1047507pab.17 for ; Mon, 04 Feb 2013 20:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=zDTVncVd7DCDcP8RnfhIMVwvl6UeD3n+qrLKBySrkMc=; b=cY8chhdRrsbWtbPaM0hx79/Z0lB8hCmgwNi2eXLl+Gk9txIIa+w451LN2sbwWc8g7N 3W9JwbFfLKElk2UxtKSc/woQkk5fPpEfRncbl7XVaPuZHnQfEn5HwsD5WXe5LMlgVmFg TO8jRQOUyIJ+X6l9YpODWzL3r6jMj3vO6PB+8+OlaZW6w6nUsnVNXWuhL+DD5GcE49/P o91pcxefIdji9frK5MZJmGXt/mXLB7Hy+VxZpfWLjKwAxO+2Alz9WgV8G165Xtha5SuE GBSOhvLGuimCcC9/w0LK/UeEoMluuMgwNLotSQVvt+svf75QpeTxFIJNi0FuGvQwLBqF xeFg== X-Received: by 10.66.83.165 with SMTP id r5mr60601919pay.3.1360039532352; Mon, 04 Feb 2013 20:45:32 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id t7sm22684585pax.17.2013.02.04.20.45.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Feb 2013 20:45:31 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 05 Feb 2013 13:45:22 +0900 From: YongHyeon PYUN Date: Tue, 5 Feb 2013 13:45:22 +0900 To: Christian Gusenbauer Subject: Re: [SOLVED] Re: 9.1-stable crashes while copying data from a NFS mounted directory Message-ID: <20130205044522.GA1439@michelle.cdnetworks.com> References: <201301241805.57623.c47g@gmx.at> <20130124212212.GM2522@kib.kiev.ua> <201301241721.51102.jhb@freebsd.org> <201302041705.31461.c47g@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201302041705.31461.c47g@gmx.at> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 04:45:40 -0000 On Mon, Feb 04, 2013 at 05:05:31PM +0100, Christian Gusenbauer wrote: > On Thursday 24 January 2013 23:21:50 John Baldwin wrote: > > On Thursday, January 24, 2013 4:22:12 pm Konstantin Belousov wrote: > > > On Thu, Jan 24, 2013 at 09:50:52PM +0100, Christian Gusenbauer wrote: > > > > On Thursday 24 January 2013 20:37:09 Konstantin Belousov wrote: > > > > > On Thu, Jan 24, 2013 at 07:50:49PM +0100, Christian Gusenbauer wrote: > > > > > > On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: > > > > > > > On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov > wrote: > > > > > > > > On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian Gusenbauer > wrote: > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > I'm using 9.1 stable svn revision 245605 and I get the panic > > > > > > > > > below if I execute the following commands (as single user): > > > > > > > > > > > > > > > > > > # swapon -a > > > > > > > > > # dumpon /dev/ada0s3b > > > > > > > > > # mount -u / > > > > > > > > > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > > > > > > > > > # mount -t nfs -o rsize=32768 data:/multimedia /mnt > > > > > > > > > # cp /mnt/Movies/test/a.m2ts /tmp > > > > > > > > > > > > > > > > > > then the system panics almost immediately. I'll attach the > > > > > > > > > stack trace. > > > > > > > > > > > > > > > > > > Note, that I'm using jumbo frames (6144 byte) on a 1Gbit > > > > > > > > > network, maybe that's the cause for the panic, because the > > > > > > > > > bcopy (see stack frame #15) fails. > > > > > > > > > > > > > > > > > > Any clues? > > > > > > > > > > > > > > > > I tried a similar operation with the nfs mount of rsize=32768 > > > > > > > > and mtu 6144, but the machine runs HEAD and em instead of age. > > > > > > > > I was unable to reproduce the panic on the copy of the 5GB > > > > > > > > file from nfs mount. > > > > > > > > > > > > Hmmm, I did a quick test. If I do not change the MTU, so just > > > > > > configuring age0 with > > > > > > > > > > > > # ifconfig age0 inet 192.168.2.2 up > > > > > > > > > > > > then I can copy all files from the mounted directory without any > > > > > > problems, too. So it's probably age0 related? > > > > > > > > > > From your backtrace and the buffer printout, I see somewhat strange > > > > > thing. The buffer data address is 0xffffff8171418000, while kernel > > > > > faulted at the attempt to write at 0xffffff8171413000, which is is > > > > > lower then the buffer data pointer, at the attempt to bcopy to the > > > > > buffer. > > > > > > > > > > The other data suggests that there were no overflow of the data from > > > > > the server response. So it might be that mbuf_len(mp) returned > > > > > negative number ? I am not sure is it possible at all. > > > > > > > > > > Try this debugging patch, please. You need to add INVARIANTS etc to > > > > > the kernel config. > > > > > > > > > > diff --git a/sys/fs/nfs/nfs_commonsubs.c > > > > > b/sys/fs/nfs/nfs_commonsubs.c index efc0786..9a6bda5 100644 > > > > > --- a/sys/fs/nfs/nfs_commonsubs.c > > > > > +++ b/sys/fs/nfs/nfs_commonsubs.c > > > > > @@ -218,6 +218,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct > > > > > uio *uiop, int siz) } > > > > > > > > > > mbufcp = NFSMTOD(mp, caddr_t); > > > > > len = mbuf_len(mp); > > > > > > > > > > + KASSERT(len > 0, ("len %d", len)); > > > > > > > > > > } > > > > > xfer = (left > len) ? len : left; > > > > > > > > > > #ifdef notdef > > > > > > > > > > @@ -239,6 +240,8 @@ nfsm_mbufuio(struct nfsrv_descript *nd, struct > > > > > uio *uiop, int siz) uiop->uio_resid -= xfer; > > > > > > > > > > } > > > > > if (uiop->uio_iov->iov_len <= siz) { > > > > > > > > > > + KASSERT(uiop->uio_iovcnt > 1, ("uio_iovcnt %d", > > > > > + uiop->uio_iovcnt)); > > > > > > > > > > uiop->uio_iovcnt--; > > > > > uiop->uio_iov++; > > > > > > > > > > } else { > > > > > > > > > > I thought that server have returned too long response, but it seems > > > > > to be not the case from your data. Still, I think the patch below > > > > > might be due. > > > > > > > > > > diff --git a/sys/fs/nfsclient/nfs_clrpcops.c > > > > > b/sys/fs/nfsclient/nfs_clrpcops.c index be0476a..a89b907 100644 > > > > > --- a/sys/fs/nfsclient/nfs_clrpcops.c > > > > > +++ b/sys/fs/nfsclient/nfs_clrpcops.c > > > > > @@ -1444,7 +1444,7 @@ nfsrpc_readrpc(vnode_t vp, struct uio *uiop, > > > > > struct ucred *cred, NFSM_DISSECT(tl, u_int32_t *, NFSX_UNSIGNED); > > > > > > > > > > eof = fxdr_unsigned(int, *tl); > > > > > > > > > > } > > > > > > > > > > - NFSM_STRSIZ(retlen, rsize); > > > > > + NFSM_STRSIZ(retlen, len); > > > > > > > > > > error = nfsm_mbufuio(nd, uiop, retlen); > > > > > if (error) > > > > > > > > > > goto nfsmout; > > > > > > > > I applied your patches and now I get a > > > > > > > > panic: len -4 > > > > cpuid = 1 > > > > KDB: enter: panic > > > > Dumping 377 out of 6116 > > > > MB:..5%..13%..22%..34%..43%..51%..64%..73%..81%..94% > > > > > > This means that the age driver either produced corrupted mbuf chain, > > > or filled wrong negative value into the mbuf len field. I am quite > > > certain that the issue is in the driver. > > > > > > I added the net@ to Cc:, hopefully you could get help there. > > > > And I've cc'd Pyun who has written most of this driver and is likely the > > one most familiar with its handling of jumbo frames. > > Hi All! > > I was in contact with Pyun. We quickly found out that it is indeed a driver > problem. Pyun solved it and will commit the fix within the next few days. > Committed in r246341. Thanks for reporting and testing! > There's only one (minor) problem open, which I can not tell if it really is > one: Konstantin sent me an initial patch for the NFS code where he added an > KASSERT(uiop->uio_iovcnt > 1) which triggers even with Pyun's fix. Without > that assert my tests show now problem at all. So is this a problem? > > Thanks guys (especially Pyun) for helping & fixing! > > Ciao, > Christian. From owner-freebsd-fs@FreeBSD.ORG Tue Feb 5 18:33:08 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 18B884F9; Tue, 5 Feb 2013 18:33:08 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mx1.freebsd.org (Postfix) with ESMTP id CD811ECB; Tue, 5 Feb 2013 18:33:07 +0000 (UTC) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (Postfix) with ESMTP id 2F4AE9B2; Tue, 5 Feb 2013 19:33:03 +0100 (CET) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from mail.wasikowski.net ([91.204.91.44]) by mail.wasikowski.net (scan.wasikowski.net [91.204.91.44]) (amavisd-new, port 10026) with ESMTP id k4l11_ZCYQZ7; Tue, 5 Feb 2013 19:33:02 +0100 (CET) Received: from [192.168.168.2] (89-72-12-251.dynamic.chello.pl [89.72.12.251]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lukasz@wasikowski.net) by mail.wasikowski.net (Postfix) with ESMTPSA id CA51B9AD; Tue, 5 Feb 2013 19:33:02 +0100 (CET) Message-ID: <5111505E.6030105@wasikowski.net> Date: Tue, 05 Feb 2013 19:33:02 +0100 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-jail@freebsd.org Subject: zfs in jail - cannot mount: Insufficient privileges X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 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: Tue, 05 Feb 2013 18:33:08 -0000 FreeBSD 9.1-STABLE r246099, zfs in jail, unprivileged user is unable to mount dataset. In jail: # sysctl vfs.usermount security.jail.enforce_statfs security.jail.mount_zfs_allowed security.jail.mount_allowed security.jail.jailed vfs.usermount: 1 security.jail.enforce_statfs: 0 security.jail.mount_zfs_allowed: 1 security.jail.mount_allowed: 1 security.jail.jailed: 1 # zfs allow jinx/jails/jtest/testset ---- Permissions on jinx/jails/jtest/testset ------------------------- Permission sets: @testperms clone,create,destroy,mount,quota,readonly,receive,rollback,send,snapshot Local+Descendent permissions: user testuser @testperms # zfs get mountpoint jinx/jails/jtest/testset NAME PROPERTY VALUE SOURCE jinx/jails/jtest/testset mountpoint /testset local # getfacl /testset # file: /testset # owner: testuser # group: testuser owner@:rwxp--aARWcCos:------:allow group@:r-x---a-R-c--s:------:allow everyone@:r-x---a-R-c--s:------:allow # su - testuser $ zfs create jinx/jails/jtest/testset/testdir cannot mount 'jinx/jails/jtest/testset/testdir': Insufficient privileges filesystem successfully created, but not mounted Is it a bug or am I missing something? root can create dataset in this jail without any problem: # zfs create jinx/jails/jtest/testset/testdir2 && zfs list jinx/jails/jtest/testset/testdir2 NAME USED AVAIL REFER MOUNTPOINT jinx/jails/jtest/testset/testdir2 31K 18.4G 31K /testset/testdir2 On host user can create and mount dataset, problem appears only in jail. -- best regards, Lukasz Wasikowski From owner-freebsd-fs@FreeBSD.ORG Wed Feb 6 01:27:01 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A26FCC9; Wed, 6 Feb 2013 01:27:01 +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 5448530B; Wed, 6 Feb 2013 01:27:00 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAByxEVGDaFvO/2dsb2JhbAA9CIZIuThzgkkEUjUCDRkCX4gkDKg1gkCQF4Eji3yDKYETA4hmjTuBHY81gxyCBg X-IronPort-AV: E=Sophos;i="4.84,612,1355115600"; d="scan'208";a="12631227" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 05 Feb 2013 20:26:38 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4FD1AB3F2E; Tue, 5 Feb 2013 20:26:38 -0500 (EST) Date: Tue, 5 Feb 2013 20:26:38 -0500 (EST) From: Rick Macklem To: FreeBSD Filesystems Message-ID: <1945675096.2731799.1360113998312.JavaMail.root@erie.cs.uoguelph.ca> Subject: ZFS lookup of ".." below .zfs returns itself (same vnode as dvp) 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: Sergey Kandaurov 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, 06 Feb 2013 01:27:01 -0000 Hi, I've been working on a panic/crash that happens when a NFSv4 mount from a client tries to lookup ".." below a .zfs directory. The thread is over on freebsd-current: http://docs.FreeBSD.org/cgi/mid.cgi?CAE-mSOLA2J6KteFM-NH9Lb9TfX3rykckkMjguZMQFg4oLx-mWQ It seems that, for this case, the lookup of ".." returns itself. This causes a panic() when the code in zfs_lookup() tries to re-lock the directory, since it is already returned locked. A one line change at line #1451 in zfs_vnops.c to if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) stops the panics, but because I know nothing about ZFS, I don't know where to take this. Normally, I would only expect this at the root of a file system, but VV_ROOT isn't set for this vnode. >From reading a few comments, it seems that ZFS returns the snapshot directory for this case. I can vaguely see that .zfs is somehow "special". Knowing nothing about ZFS, maybe someone can help with answers to a few questions and/or suggestions w.r.t. how the NFS server should handle this case. Is .zfs considered a snapshot directory or is the snapshot directory below .zfs? I see lookups for the name "snapshot". Is that the actual name of this snapshot directory and is it always the same? Are these meant to look like normal mount points. If not, I can't see how things like getcwd() would work once cd'd to below it? Any help with understanding this would be appreciated, rick ps: After the one line patch, the server doesn't panic, but it seems to return an empty directory when the "ls /.zfs/shares/" is done by Sergey. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 6 03:00:02 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C985D10F for ; Wed, 6 Feb 2013 03:00:02 +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 BD0CB826 for ; Wed, 6 Feb 2013 03:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r16302TC013768 for ; Wed, 6 Feb 2013 03:00:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r16302ge013767; Wed, 6 Feb 2013 03:00:02 GMT (envelope-from gnats) Date: Wed, 6 Feb 2013 03:00:02 GMT Message-Id: <201302060300.r16302ge013767@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: kern/175794: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 03:00:02 -0000 The following reply was made to PR kern/175794; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/175794: commit references a PR Date: Wed, 6 Feb 2013 02:51:38 +0000 (UTC) Author: pfg Date: Wed Feb 6 02:51:25 2013 New Revision: 246376 URL: http://svnweb.freebsd.org/changeset/base/246376 Log: MFC r246299; UFS: Remove dead assignment. PR: kern/175794 Submitted by: Christoph Mallon Modified: stable/9/sys/ufs/ufs/ufs_lookup.c Directory Properties: stable/9/sys/ (props changed) Modified: stable/9/sys/ufs/ufs/ufs_lookup.c ============================================================================== --- stable/9/sys/ufs/ufs/ufs_lookup.c Wed Feb 6 01:03:13 2013 (r246375) +++ stable/9/sys/ufs/ufs/ufs_lookup.c Wed Feb 6 02:51:25 2013 (r246376) @@ -1432,7 +1432,6 @@ ufs_checkpath(ino_t source_ino, ino_t pa return (0); if (target->i_number == ROOTINO) return (0); - error = 0; for (;;) { error = ufs_dir_dd_ino(vp, cred, &dd_ino); if (error != 0) _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed Feb 6 03:04:56 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AA4884D7; Wed, 6 Feb 2013 03:04:56 +0000 (UTC) (envelope-from pfg@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 864808F3; Wed, 6 Feb 2013 03:04:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1634upR015608; Wed, 6 Feb 2013 03:04:56 GMT (envelope-from pfg@freefall.freebsd.org) Received: (from pfg@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1634uRb015604; Wed, 6 Feb 2013 03:04:56 GMT (envelope-from pfg) Date: Wed, 6 Feb 2013 03:04:56 GMT Message-Id: <201302060304.r1634uRb015604@freefall.freebsd.org> To: pfg@FreeBSD.org, freebsd-fs@FreeBSD.org, pfg@FreeBSD.org From: pfg@FreeBSD.org Subject: Re: kern/175794: [ufs] [patch] remove cruft, fix inconsistent panic messages 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, 06 Feb 2013 03:04:56 -0000 Synopsis: [ufs] [patch] remove cruft, fix inconsistent panic messages Responsible-Changed-From-To: freebsd-fs->pfg Responsible-Changed-By: pfg Responsible-Changed-When: Wed Feb 6 03:02:04 UTC 2013 Responsible-Changed-Why: Grab I was CC'd so I have the readable version of the patches. http://www.freebsd.org/cgi/query-pr.cgi?pr=175794 From owner-freebsd-fs@FreeBSD.ORG Wed Feb 6 09:15:59 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7A597555; Wed, 6 Feb 2013 09:15:59 +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 9EB64B1B; Wed, 6 Feb 2013 09:15:58 +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 LAA13753; Wed, 06 Feb 2013 11:15:55 +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 1U316g-000IX6-Mb; Wed, 06 Feb 2013 11:15:54 +0200 Message-ID: <51121F4A.6050107@FreeBSD.org> Date: Wed, 06 Feb 2013 11:15:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: ZFS lookup of ".." below .zfs returns itself (same vnode as dvp) References: <1945675096.2731799.1360113998312.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1945675096.2731799.1360113998312.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Filesystems , Sergey Kandaurov 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, 06 Feb 2013 09:15:59 -0000 on 06/02/2013 03:26 Rick Macklem said the following: > Hi, > > I've been working on a panic/crash that happens when a NFSv4 > mount from a client tries to lookup ".." below a .zfs directory. > > The thread is over on freebsd-current: > http://docs.FreeBSD.org/cgi/mid.cgi?CAE-mSOLA2J6KteFM-NH9Lb9TfX3rykckkMjguZMQFg4oLx-mWQ Replicating here what I've just posted there, just in case. > It seems that, for this case, the lookup of ".." returns itself. > This causes a panic() when the code in zfs_lookup() tries to re-lock > the directory, since it is already returned locked. A one line > change at line #1451 in zfs_vnops.c to > if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) > stops the panics, but because I know nothing about ZFS, I don't > know where to take this. Normally, I would only expect this at > the root of a file system, but VV_ROOT isn't set for this vnode. > > From reading a few comments, it seems that ZFS returns the snapshot > directory for this case. I can vaguely see that .zfs is somehow "special". > > Knowing nothing about ZFS, maybe someone can help with answers to > a few questions and/or suggestions w.r.t. how the NFS server should > handle this case. > > Is .zfs considered a snapshot directory or is the snapshot directory > below .zfs? > > I see lookups for the name "snapshot". Is that the actual name of > this snapshot directory and is it always the same? > > Are these meant to look like normal mount points. If not, I can't > see how things like getcwd() would work once cd'd to below it? > > Any help with understanding this would be appreciated, rick > ps: After the one line patch, the server doesn't panic, but it > seems to return an empty directory when the "ls /.zfs/shares/" > is done by Sergey. Actually I think I have an explanation, just been busy past couple of days. The problem is precisely with .zfs/shares, which is a strange beast that currently has no practical use on FreeBSD. .zfs/shares has its own on-disk node. The node has some special properties: - it is a directory node - it is not reachable from any other node - its parent ID is set to itself (as for a root node) - its ID is stored in a special filesystem property At run time ZFS creates special vnodes for .zfs, .zfs/snapshot and .zfs/shares. The vnodes are special is a sense that each of them has its own v_ops different from v_ops of the regular ZFS vnodes. For example, vop_lookup method of .zfs/shares should return the .zfs vnode for a ".." lookup. The v_ops are sane and self-consistent and everything is supposed to work fine with them and provide some ".zfs magic". Except for one hole. The .zfs/shares vnode has the same inode number as the on-disk node. Also, its vop_vptofh generates fid_t consistent with the on-disk node. Then, ZFS vfs_fhtovp has a special case to do the right thing for fid_t-s of .zfs and .zfs/snapshot. But for some reason there is no special code for .zfs/shares. And so a regular ZFS vnode is created/returned in that case. And this is the problem. Regular zfs_lookup for ".." in this vnode returns the vnode itself because of the magic properties described in the beginning. And so on. We seem to have inherited this problem from the upstream: http://thread.gmane.org/gmane.os.illumos.zfs/599 I believe that currently NFS is the only user of VOP_FID and VFS_FHTOVP. There are also getfh(2), lgetfh(2) and fhopen(2), but I am not sure how widely they are used. In either case, I believe that zfs_fhtovp should grow a check for object == zfsvfs->z_shares_dir and return the "made up" .zfs/shares vnode in that case (instead of a regular zfs vnode). Additionally, I am not sure, but perhaps zfs_vget() should do the same kind of tricks as zfs_fhtovp. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Feb 6 20:03:08 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12EBDD38; Wed, 6 Feb 2013 20:03:08 +0000 (UTC) (envelope-from jhein@symmetricom.us) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C1721704; Wed, 6 Feb 2013 20:03:07 +0000 (UTC) Received: from bosvc206-1.symmetricom.us (bosvc206-1.symmetricom.us [206.168.13.145]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r16K36GQ019014; Wed, 6 Feb 2013 13:03:06 -0700 (MST) (envelope-from jhein@symmetricom.us) Received: from bosvc206-1.symmetricom.us (localhost [127.0.0.1]) by bosvc206-1.symmetricom.us (8.14.5/8.14.5) with ESMTP id r16K36Ns046063; Wed, 6 Feb 2013 13:03:06 -0700 (MST) (envelope-from jhein@bosvc206-1.symmetricom.us) Received: (from jhein@localhost) by bosvc206-1.symmetricom.us (8.14.6/8.14.6/Submit) id r16K35Nf046062; Wed, 6 Feb 2013 13:03:05 -0700 (MST) (envelope-from jhein) Date: Wed, 6 Feb 2013 13:03:05 -0700 (MST) Message-Id: <201302062003.r16K35Nf046062@bosvc206-1.symmetricom.us> To: FreeBSD-gnats-submit@freebsd.org Subject: operations on readonly zpool hang From: John Hein X-send-pr-version: 3.114 X-GNATS-Notify: 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: Wed, 06 Feb 2013 20:03:08 -0000 >Submitter-Id: current-users >Originator: John Hein >Organization: >Confidential: no >Synopsis: operations on readonly zpool hang >Severity: serious >Priority: medium >Category: kern >Class: sw-bug >Release: >Environment: recent 8-stable, 9-stable; noticed on both i386 & amd64 >Description: On 9-stable & 8-stable, zfs/zpool operations hang when trying to work on a readonly pool. I've tried 'zfs set mountpoint' and 'zfs scrub' (the latter accidentally during overnight run of periodic with daily_scrub_zfs_enable=yes). See also https://forums.freebsd.org/showthread.php?t=35505&highlight=readonly+zpool which mentions a panic. I didn't get a panic (yet). Use case when this was noticed: replace old pool with new, setting the new pool to have the old pool's mountpoint (to avoid changing all nfs clients). I think zfs should refuse the operation if readonly is a problem. What I really wanted was for the data to be readonly, but not the zfs metadata (i.e., "_mostly_ readonly"). But I can see how disallowing metadata ops on a readonly pool makes sense. >How-To-Repeat: cd /tmp dd if=/dev/zero bs=1m count=100 > ! z0 dd if=/dev/zero bs=1m count=100 > ! z1 sudo mdconfig -f z0 sudo mdconfig -f z1 sudo zpool create -m /tmp/ztmp ztmp mirror /dev/md0 /dev/md1 sudo zpool export ztmp sudo zpool import -o readonly=on ztmp sudo zfs set mountpoint=/tmp/ztmpnew ztmp ... hangs here In another window... % ps -ww -ax -o pid,ppid,%cpu,%mem,vsz,rss,wchan,stat,lstart,time,command | egrep 'zfs|PID' PID PPID %CPU %MEM VSZ RSS WCHAN STAT STARTED TIME COMMAND 45377 0 0.0 0.0 0 32 l2arc_fe DL Wed Feb 6 12:38:30 2013 0:00.01 [zfskern] 45674 1 0.0 0.3 44460 3256 select I Wed Feb 6 12:40:54 2013 0:00.01 sudo zfs set mountpoint=/tmp/z\ tmpnew ztmp 45687 45674 0.0 0.3 33488 3064 tx->tx_s D Wed Feb 6 12:40:54 2013 0:00.00 zfs set mountpoint=/tmp/ztmpne\ w ztmp % sudo procstat -k 45674 45687 PID TID COMM TDNAME KSTACK 45674 100106 sudo - mi_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdw\ ait kern_select sys_select amd64_syscall Xfast_syscall 45687 100098 zfs - mi_switch sleepq_wait _cv_wait txg_wait_synced dsl_sync_task_group\ _wait dsl_sync_task_do dsl_props_set zfs_set_prop_nvlist zfs_ioc_set_prop zfsdev_ioctl devfs_ioctl_f kern_ioctl s\ ys_ioctl amd64_syscall Xfast_syscall >Fix: From owner-freebsd-fs@FreeBSD.ORG Thu Feb 7 09:41:21 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 89FC7ECA; Thu, 7 Feb 2013 09:41:21 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 41940C4; Thu, 7 Feb 2013 09:41:20 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1U3Nyj-0007OE-Bt; Thu, 07 Feb 2013 10:41:13 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U3Nyi-00072g-UK; Thu, 07 Feb 2013 10:41:12 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Boris Astardzhiev" , "Mateusz Guzik" Subject: Re: NANDFS eats itself up References: <20121128104218.GA17871@dft-labs.eu> <20121128151336.GC17871@dft-labs.eu> <20121129110719.GA26212@dft-labs.eu> <20130103235451.GA31491@dft-labs.eu> Date: Thu, 07 Feb 2013 10:41:11 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130103235451.GA31491@dft-labs.eu> User-Agent: Opera Mail/12.13 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.1 X-Scan-Signature: 0ccaee305be983877c9e38c09cbf8ec4 Cc: freebsd-fs@freebsd.org, gjb@semihalf.com, Grzegorz Bernacki , stanislav_galabov@smartcom.bg 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, 07 Feb 2013 09:41:21 -0000 On Fri, 04 Jan 2013 00:54:51 +0100, Mateusz Guzik wrote: > On Thu, Nov 29, 2012 at 01:13:55PM +0200, Boris Astardzhiev wrote: >> > On Wed, Nov 28, 2012 at 05:36:11PM +0200, Boris Astardzhiev wrote: >> > > If I do that I might be unable to set back the verbose level to 0 >> since >> > the >> > > output is very very NOISY. This means that I will have to start >> again >> > from >> > > the beginning if I need to reproduce it. Nevertheless here you go. >> Check >> > > the attachment (OUTPUTNAND.txt.bz2). >> > > >> > >> > I think I reproduced your problem. Possibly I'll have time to work on >> > this next week, but no promises. >> > > > So, I think I understand what is causing the problem here and will most > likely have time to work on it this month. > Hi, Not to push you or something like that, but did you find the time? I'm curious to running my SHEEVAPLUG using the NAND memory. If there is something to test or help in another way, I'm willing to do that. Ronald. From owner-freebsd-fs@FreeBSD.ORG Fri Feb 8 08:44:08 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6DA22BA for ; Fri, 8 Feb 2013 08:44:08 +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 DD5E56F for ; Fri, 8 Feb 2013 08:44:07 +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 KAA08464 for ; Fri, 08 Feb 2013 10:44:06 +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 1U3jZ0-0002aw-61 for freebsd-fs@FreeBSD.org; Fri, 08 Feb 2013 10:44:06 +0200 Message-ID: <5114BAD4.1030700@FreeBSD.org> Date: Fri, 08 Feb 2013 10:44:04 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Subject: zpool import vs zvol snapshots X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=X-VIET-VPS 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: Fri, 08 Feb 2013 08:44:08 -0000 Just want to share a minor annoyance. Because zvol snapshot devfs entries are created in the same subdirectory as the zvol entries, then zpool import might prefer a snapshot device over a zvol device, which then would fail. This is, of course, a problem only if you use pools on top of zvols (as I do for hacking purposes). -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Feb 8 22:08:29 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 821) id F1443AF2; Fri, 8 Feb 2013 22:08:29 +0000 (UTC) Date: Fri, 8 Feb 2013 22:08:29 +0000 From: John To: freebsd-fs@freebsd.org Subject: zfs zvol vs file i/o performance Message-ID: <20130208220829.GA56079@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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, 08 Feb 2013 22:08:30 -0000 Hi Folks, Recently I was chasing down some performance differences and thought I'd post some results for general discussion. The system is a Dell R620 w/128GB ram, 2xLSI 9207-8e cards, and a pair of HP D2700 shelves. Two test areas created: zfs create -b 128K -V 300G pool0/lun000004 vs zfs create pool0/lun000004 truncate -s 300G /pool0/lun000004/fun000004 The dataset was destroyed and re-created between the different types of test runs, thus the same name. The areas are filled with random data prior to the test runs also (no null blocks). Some test numbers are below. In general, there appears to be about an 800MB/sec difference in I/O rates. Please note the test case is 300GB which is 2.5 x the about of ram in the system. The system is configured with defaults for loader.conf and sysctl.conf. I'd be curious if anyone else can replicate this. Comments welcome. Cheers, John For the file based lun: 1.96GB/sec # dd if=fun000004 of=/dev/null bs=64k 4915200+0 records in 4915200+0 records out 322122547200 bytes transferred in 165.930512 secs (1941309910 bytes/sec) # dd if=fun000004 of=/dev/null bs=128k 2457600+0 records in 2457600+0 records out 322122547200 bytes transferred in 163.977835 secs (1964427371 bytes/sec) # dd if=fun000004 of=/dev/null bs=256k 1228800+0 records in 1228800+0 records out 322122547200 bytes transferred in 163.109616 secs (1974883854 bytes/sec) # dd if=fun000004 of=/dev/null bs=384k 819200+0 records in 819200+0 records out 322122547200 bytes transferred in 162.981242 secs (1976439392 bytes/sec) # dd if=fun000004 of=/dev/null bs=768k 409600+0 records in 409600+0 records out 322122547200 bytes transferred in 163.756843 secs (1967078390 bytes/sec) For the zvol based lun: 1.1GB/sec # dd if=/dev/zvol/pool0/lun000004 of=/dev/null bs=64k 4915200+0 records in 4915200+0 records out 322122547200 bytes transferred in 305.941880 secs (1052888043 bytes/sec) # dd if=/dev/zvol/pool0/lun000004 of=/dev/null bs=128k 2457600+0 records in 2457600+0 records out 322122547200 bytes transferred in 270.188876 secs (1192212469 bytes/sec) # dd if=/dev/zvol/pool0/lun000004 of=/dev/null bs=256k 1228800+0 records in 1228800+0 records out 322122547200 bytes transferred in 270.208030 secs (1192127959 bytes/sec) # dd if=/dev/zvol/pool0/lun000004 of=/dev/null bs=384k 819200+0 records in 819200+0 records out 322122547200 bytes transferred in 271.366702 secs (1187037852 bytes/sec) # dd if=/dev/zvol/pool0/lun000004 of=/dev/null bs=512k 614400+0 records in 614400+0 records out 322122547200 bytes transferred in 269.715238 secs (1194306075 bytes/sec) # dd if=/dev/zvol/pool0/lun000004 of=/dev/null bs=768k 409600+0 records in 409600+0 records out 322122547200 bytes transferred in 269.289512 secs (1196194181 bytes/sec) The pool config: # zpool status pool: pool0 state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM pool0 ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 multipath/Z0 ONLINE 0 0 0 multipath/Z1 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 multipath/Z2 ONLINE 0 0 0 multipath/Z3 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 multipath/Z4 ONLINE 0 0 0 multipath/Z5 ONLINE 0 0 0 mirror-3 ONLINE 0 0 0 multipath/Z6 ONLINE 0 0 0 multipath/Z7 ONLINE 0 0 0 mirror-4 ONLINE 0 0 0 multipath/Z8 ONLINE 0 0 0 multipath/Z9 ONLINE 0 0 0 mirror-5 ONLINE 0 0 0 multipath/Z10 ONLINE 0 0 0 multipath/Z11 ONLINE 0 0 0 mirror-6 ONLINE 0 0 0 multipath/Z12 ONLINE 0 0 0 multipath/Z13 ONLINE 0 0 0 mirror-7 ONLINE 0 0 0 multipath/Z14 ONLINE 0 0 0 multipath/Z15 ONLINE 0 0 0 mirror-8 ONLINE 0 0 0 multipath/Z16 ONLINE 0 0 0 multipath/Z17 ONLINE 0 0 0 mirror-9 ONLINE 0 0 0 multipath/Z18 ONLINE 0 0 0 multipath/Z19 ONLINE 0 0 0 mirror-10 ONLINE 0 0 0 multipath/Z20 ONLINE 0 0 0 multipath/Z21 ONLINE 0 0 0 mirror-11 ONLINE 0 0 0 multipath/Z22 ONLINE 0 0 0 multipath/Z23 ONLINE 0 0 0 mirror-12 ONLINE 0 0 0 multipath/Z24 ONLINE 0 0 0 multipath/Z25 ONLINE 0 0 0 mirror-13 ONLINE 0 0 0 multipath/Z26 ONLINE 0 0 0 multipath/Z27 ONLINE 0 0 0 mirror-14 ONLINE 0 0 0 multipath/Z28 ONLINE 0 0 0 multipath/Z29 ONLINE 0 0 0 mirror-15 ONLINE 0 0 0 multipath/Z30 ONLINE 0 0 0 multipath/Z31 ONLINE 0 0 0 mirror-16 ONLINE 0 0 0 multipath/Z32 ONLINE 0 0 0 multipath/Z33 ONLINE 0 0 0 mirror-17 ONLINE 0 0 0 multipath/Z34 ONLINE 0 0 0 multipath/Z35 ONLINE 0 0 0 mirror-18 ONLINE 0 0 0 multipath/Z36 ONLINE 0 0 0 multipath/Z37 ONLINE 0 0 0 mirror-19 ONLINE 0 0 0 multipath/Z38 ONLINE 0 0 0 multipath/Z39 ONLINE 0 0 0 mirror-20 ONLINE 0 0 0 multipath/Z40 ONLINE 0 0 0 multipath/Z41 ONLINE 0 0 0 mirror-21 ONLINE 0 0 0 multipath/Z42 ONLINE 0 0 0 multipath/Z43 ONLINE 0 0 0 mirror-22 ONLINE 0 0 0 multipath/Z44 ONLINE 0 0 0 multipath/Z45 ONLINE 0 0 0 mirror-23 ONLINE 0 0 0 multipath/Z46 ONLINE 0 0 0 multipath/Z47 ONLINE 0 0 0 spares multipath/Z48 AVAIL multipath/Z49 AVAIL errors: No known data errors And what a disk looks like in the system: # camcontrol inquiry da0 pass2: Fixed Direct Access SCSI-5 device pass2: Serial Number EA01PC91LPW91239 pass2: 600.000MB/s transfers, Command Queueing Enabled From owner-freebsd-fs@FreeBSD.ORG Fri Feb 8 22:49:20 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1EA0A74 for ; Fri, 8 Feb 2013 22:49:20 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9CBFD795 for ; Fri, 8 Feb 2013 22:49:20 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id g10so537074qah.11 for ; Fri, 08 Feb 2013 14:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FV6rD84k84OKFui9hr3D8RxWAAv/PeR7b7nRxDPAOMU=; b=pXCWErnqO8wF7G6HGXIJKeG44id/sCXBsC8KpNW5uk8bgYf4cybiWxTI5AWueZ6eU+ 7s5K9rgEOUPVpov//WvVjkzGEJv0XoUSQ+58QSbS5NM/hZgBmBKxNa4ybinuIvS/L0kk ZluJc9FpJ2DPPkGtOKLQtymjWvSxzfjDlrq0/H9Bk+F7FMLN2KYJk8Es6oc4PlVFH0wG WipA5DISrtHq73/3gRmzKotXsewmTQ5Fg0VAy69CSkxGafMo/3tdRv5QzRN28HULa7sY wj6hOX/ogmYfPANr70QWuGtiKe3Z7N6Y76cL5KuywPjdu4+EsELIwLin8Ic2AO4CMpd7 l/+w== MIME-Version: 1.0 X-Received: by 10.49.12.138 with SMTP id y10mr2869465qeb.64.1360363754670; Fri, 08 Feb 2013 14:49:14 -0800 (PST) Received: by 10.49.12.162 with HTTP; Fri, 8 Feb 2013 14:49:14 -0800 (PST) In-Reply-To: <50F990A9.1030305@gmail.com> References: <50F990A9.1030305@gmail.com> Date: Fri, 8 Feb 2013 14:49:14 -0800 Message-ID: Subject: Re: lz4 support for ZFS From: Xin LI To: Volodymyr Kostyrko Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs 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, 08 Feb 2013 22:49:21 -0000 Hi, On Fri, Jan 18, 2013 at 10:12 AM, Volodymyr Kostyrko wrote: > I see LZ4 is now supported in head. Can I ask is there any plans MFC'ing it > to stable? No it was not in -HEAD. I got some data corruption and was stuck with some $DAYJOB lately. The problem is now fixed and I'm doing a final pre-commit build and testing to make sure there is no regressions and then I can merge it to -HEAD later today, the planned MFC settle time would be a month. Cheers, -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-fs@FreeBSD.ORG Sat Feb 9 14:19:22 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6EF1DFD5 for ; Sat, 9 Feb 2013 14:19:22 +0000 (UTC) (envelope-from momchil@xaxo.eu) Received: from vps2.xaxo.eu (vps2.xaxo.eu [78.47.156.66]) by mx1.freebsd.org (Postfix) with ESMTP id F1E4CCCD for ; Sat, 9 Feb 2013 14:19:21 +0000 (UTC) Received: from t61.xaxo.eu ([10.75.23.6]) by vps2.xaxo.eu (8.14.4/8.14.4) with ESMTP id r19EBOcr020531; Sat, 9 Feb 2013 15:11:24 +0100 (CET) (envelope-from momchil@xaxo.eu) Date: Sat, 09 Feb 2013 15:11:15 +0100 Message-ID: <86bobtmvb0.wl%momchil@xaxo.eu> From: Momchil Ivanov To: freebsd-fs@freebsd.org Subject: NFS + Kerberos MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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, 09 Feb 2013 14:19:22 -0000 Hello, I have been trying to follow this guide [1] to get NFS with Kerberos working on FreeBSD, but I have some trouble. I hope somebody has the time and desire to help me... I am using FreeBSD 9.1 as NFS server with the following configuration on the server: file /etc/krb5.conf: [libdefaults] default_realm = EXAMPLE.LOCAL default_etypes = des-cbc-crc default_etypes_des = des-cbc-crc allow_weak_crypto = true [realms] EXAMPLE.LOCAL = { kdc = kerberos.example.local admin_server = kerberos.example.local } [domain_realm] .example.local = EXAMPLE.LOCAL file /etc/exports: V4: / -sec=krb5i:krb5p /tank/storage -sec=krb5i:krb5p file /etc/rc.conf: ## nfsv4 nfs_server_enable="YES" nfsv4_server_enable="YES" nfsuserd_enable="YES" mountd_enable="YES" mountd_flags="-r -n" # for kerberos gssd_enable="YES" kerberos seems to be working: root@srv:/root # kinit -k nfs/srv.example.local root@srv:/root # klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: nfs/srv.example.local@EXAMPLE.LOCAL Issued Expires Principal Feb 2 21:04:02 Feb 3 07:04:02 krbtgt/EXAMPLE.LOCAL@EXAMPLE.LOCAL root@srv:/root # kdestroy root@srv:/root # ktutil list FILE:/etc/krb5.keytab: Vno Type Principal 1 des-cbc-crc nfs/srv.example.local@EXAMPLE.LOCAL krb4:/etc/srvtab: Vno Type Principal the client is FreeBSD 8.2 with the following configuration: file /etc/krb5.conf: [libdefaults] default_realm = EXAMPLE.LOCAL default_etypes = des-cbc-crc default_etypes_des = des-cbc-crc allow_weak_crypto = true [realms] EXAMPLE.LOCAL = { kdc = kerberos.example.local admin_server = kerberos.example.local } [domain_realm] .example.local = EXAMPLE.LOCAL file /etc/rc.conf: ## NFS v4 nfsuserd_enable="YES" nfscbd_enable="YES" # kerberos gssd_enable="YES" file /etc/sysctl.conf: # Allow normal users to mount filesystems. vfs.usermount=1 here is the output from the client: $ klist klist: No ticket file: /tmp/krb5cc_1001 $ mount -t nfs -o nfsv4,soft,sec=krb5i srv.example.local:/tank/storage /mnt/srv mount_nfs: can't update /var/db/mounttab for srv.example.local:/tank/storage nfsv4 err=10016 mount_nfs: /mnt/srv, : Input/output error then I do: $ kinit user $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: user@EXAMPLE.LOCAL Issued Expires Principal Feb 2 21:15:36 Feb 3 07:15:33 krbtgt/EXAMPLE.LOCAL@EXAMPLE.LOCAL $ mount -t nfs -o nfsv4,soft,sec=krb5i srv.example.local:/tank/storage /mnt/srv mount_nfs: can't update /var/db/mounttab for srv.example.local:/tank/storage nfsv4 err=10016 mount_nfs: /mnt/srv, : Input/output error $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: user@EXAMPLE.LOCAL Issued Expires Principal Feb 2 21:15:36 Feb 3 07:15:33 krbtgt/EXAMPLE.LOCAL@EXAMPLE.LOCAL Feb 2 21:15:43 Feb 3 07:15:33 nfs/srv.example.local@EXAMPLE.LOCAL Note: the mount works without Kerberos if I add "sys" to the "sec" option on both lines of /etc/exports, ownership works too, therefore I think that nfsv4 works, nfsv3 works too. However I have no idea why they don't work with Kerberos. Note: With and without a kerberos ticket, the result when using nfsv3 is: $ mount -t nfs -o nfsv3,soft,sec=krb5i srv.example.local:/tank/storage /mnt/srv mount_nfs: can't update /var/db/mounttab for srv.example.local:/tank/storage $ ls /mnt/srv ls: /mnt/srv: Permission denied Is there an easy way to get it working? Am I doing something wrong? PS: Please CC me, since I am not subscribed. 1: http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup Regards, Momchil From owner-freebsd-fs@FreeBSD.ORG Sat Feb 9 16:02:29 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 44FFF971 for ; Sat, 9 Feb 2013 16:02:29 +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 D5BF8F7 for ; Sat, 9 Feb 2013 16:02:28 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAOpxFlGDaFvO/2dsb2JhbABEhk66bHOCHwEBAQMBAQEBICsgCwUWGAICDRkCKQEJJgYIBwQBHASHagYMrHySH4EjjC4GBIMcgRMDiGaLC4IzgR2PNoMkgUkIFx4 X-IronPort-AV: E=Sophos;i="4.84,634,1355115600"; d="scan'208";a="13227191" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 09 Feb 2013 11:02:21 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7CDFFB3F4A; Sat, 9 Feb 2013 11:02:21 -0500 (EST) Date: Sat, 9 Feb 2013 11:02:21 -0500 (EST) From: Rick Macklem To: Momchil Ivanov Message-ID: <843900310.2847717.1360425741450.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <86bobtmvb0.wl%momchil@xaxo.eu> Subject: Re: NFS + Kerberos 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 (Win)/6.0.10_GA_2692) 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: Sat, 09 Feb 2013 16:02:29 -0000 Monchil Ivanov wrote: > Hello, > > I have been trying to follow this guide [1] to get NFS with Kerberos > working on FreeBSD, but I have some trouble. I hope somebody has the > time and desire to help me... > > I am using FreeBSD 9.1 as NFS server with the following configuration > on the server: > > file /etc/krb5.conf: > > [libdefaults] > default_realm = EXAMPLE.LOCAL > default_etypes = des-cbc-crc > default_etypes_des = des-cbc-crc > allow_weak_crypto = true > [realms] > EXAMPLE.LOCAL = { > kdc = kerberos.example.local > admin_server = kerberos.example.local > } > [domain_realm] > .example.local = EXAMPLE.LOCAL > > file /etc/exports: > > V4: / -sec=krb5i:krb5p > /tank/storage -sec=krb5i:krb5p > For ZFS every ZFS volume below the "V4: " normally needs to be exported. Below you mention that the NFSv4 mount worked for -sec=sys, but I don't know how it would. Assuming /tank is ZFS (if it's UFS, just ignore this;-), I'd suggest changing the line to: V4: /tank/storage -sec=krb5i,krb5p (You then need to use srv.example.local:/ as your mount point for the mount command for NFSv4.) > file /etc/rc.conf: > > ## nfsv4 > nfs_server_enable="YES" > nfsv4_server_enable="YES" > nfsuserd_enable="YES" > mountd_enable="YES" > mountd_flags="-r -n" > > # for kerberos > gssd_enable="YES" > > kerberos seems to be working: > > root@srv:/root # kinit -k nfs/srv.example.local > root@srv:/root # klist > Credentials cache: FILE:/tmp/krb5cc_0 > Principal: nfs/srv.example.local@EXAMPLE.LOCAL > > Issued Expires Principal > Feb 2 21:04:02 Feb 3 07:04:02 krbtgt/EXAMPLE.LOCAL@EXAMPLE.LOCAL > root@srv:/root # kdestroy > root@srv:/root # ktutil list > FILE:/etc/krb5.keytab: > > Vno Type Principal > 1 des-cbc-crc nfs/srv.example.local@EXAMPLE.LOCAL > > krb4:/etc/srvtab: > > Vno Type Principal > > the client is FreeBSD 8.2 with the following configuration: > > file /etc/krb5.conf: > > [libdefaults] > default_realm = EXAMPLE.LOCAL > default_etypes = des-cbc-crc > default_etypes_des = des-cbc-crc > allow_weak_crypto = true > [realms] > EXAMPLE.LOCAL = { > kdc = kerberos.example.local > admin_server = kerberos.example.local > } > [domain_realm] > .example.local = EXAMPLE.LOCAL > > file /etc/rc.conf: > > ## NFS v4 > nfsuserd_enable="YES" > nfscbd_enable="YES" > # kerberos > gssd_enable="YES" > > file /etc/sysctl.conf: > # Allow normal users to mount filesystems. > vfs.usermount=1 > > here is the output from the client: > > $ klist > klist: No ticket file: /tmp/krb5cc_1001 > > $ mount -t nfs -o nfsv4,soft,sec=krb5i srv.example.local:/tank/storage > /mnt/srv > mount_nfs: can't update /var/db/mounttab for > srv.example.local:/tank/storage > nfsv4 err=10016 > mount_nfs: /mnt/srv, : Input/output error > Yep, I would expect this to fail. > then I do: > > $ kinit user > $ klist > Credentials cache: FILE:/tmp/krb5cc_1001 > Principal: user@EXAMPLE.LOCAL > > Issued Expires Principal > Feb 2 21:15:36 Feb 3 07:15:33 krbtgt/EXAMPLE.LOCAL@EXAMPLE.LOCAL > > $ mount -t nfs -o nfsv4,soft,sec=krb5i srv.example.local:/tank/storage > /mnt/srv > mount_nfs: can't update /var/db/mounttab for > srv.example.local:/tank/storage This error message happens because the non-root user doesn`t have write access mounttab. You can fix the problem by opening up permissions on it, but it does not really matter. The contents of mounttab is for information only and does not affect the mount. > nfsv4 err=10016 > mount_nfs: /mnt/srv, : Input/output error > Not sure why this fails. Might have been the issue I mentioned above. I`d suggest you try again with the above V4: line modified and the mount looking like: $ mount -t nfs -o nfsv4,sec=krb5i srv.example.local:/ /mnt/srv (I also strongly recommend against using `soft` for NFSv4 mounts, but that shouldn`t cause this to fail.) 10016 is NFS4ERR_WRONGSEC, so it didn`t like you using Kerberos. I suspect that would be somewhere higher up in the path. > $ klist > Credentials cache: FILE:/tmp/krb5cc_1001 > Principal: user@EXAMPLE.LOCAL > > Issued Expires Principal > Feb 2 21:15:36 Feb 3 07:15:33 krbtgt/EXAMPLE.LOCAL@EXAMPLE.LOCAL > Feb 2 21:15:43 Feb 3 07:15:33 nfs/srv.example.local@EXAMPLE.LOCAL > > Note: the mount works without Kerberos if I add "sys" to the "sec" > option on both lines of /etc/exports, ownership works too, therefore I > think that nfsv4 works, nfsv3 works too. However I have no idea why > they don't work with Kerberos. > I was never sure it was the correct thing to do, but the original author coded it so that it would fall back to -sec=sys when Kerberos failed. That would explain why it succeeds for this case. > Note: With and without a kerberos ticket, the result when using nfsv3 > is: > > $ mount -t nfs -o nfsv3,soft,sec=krb5i srv.example.local:/tank/storage > /mnt/srv > mount_nfs: can't update /var/db/mounttab for > srv.example.local:/tank/storage > > $ ls /mnt/srv > ls: /mnt/srv: Permission denied I have never tried a non-root NFSv3 Kerberos mount. Normally, the above mount would be done by root and then accessed by the non-root user. (NFSv3 has no state-related operations, so the mount can be done by root, since it does not need kerberos authentication.) I cannot think of why a non-root mount would not work, but since I have never done it, I would suggest you try doing this mount as root and see if it makes any difference. In general, the cause of these failures can be difficult to figure out, since it can fail in so many ways. Looking at the log file for the KDC can sometimes help. Or, capturing packets and looking at them in wireshark (which understands NFSv4 and RPCSEC_GSS) will give you some idea where it breaks. Good luck with it, rick > > Is there an easy way to get it working? Am I doing something wrong? > > PS: Please CC me, since I am not subscribed. > > 1: http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup > > Regards, > Momchil > _______________________________________________ > 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"