From owner-freebsd-fs@FreeBSD.ORG Sun Jul 31 20:37:12 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 904B116A41F for ; Sun, 31 Jul 2005 20:37:12 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from moe.cs.uoguelph.ca (moe.cs.uoguelph.ca [131.104.96.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3295D43D45 for ; Sun, 31 Jul 2005 20:37:11 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from snowhite.cis.uoguelph.ca (snowhite.cis.uoguelph.ca [131.104.48.1]) by moe.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id j6VKbAcp014242; Sun, 31 Jul 2005 16:37:10 -0400 Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id QAA28479; Sun, 31 Jul 2005 16:37:40 -0400 (EDT) Date: Sun, 31 Jul 2005 16:37:40 -0400 (EDT) From: rick@snowhite.cis.uoguelph.ca Message-Id: <200507312037.QAA28479@snowhite.cis.uoguelph.ca> To: kris@obsecurity.org X-Scanned-By: MIMEDefang 2.44 Cc: fs@freebsd.org, openbsd-nfsv4@sfobug.org Subject: re: NFSv234 problems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2005 20:37:12 -0000 Well, yah got me pretty good. (I had built a kernel with NFSCLIENT and DEBUG_VFS_LOCKS for FreeBSD5.4. Not so for FreeBSD6.0-BETA1.:-) Here's some specifics: > How does one configure the kernel as an NFS client? The kernel > doesn't link when you define both > > options NFSD > options NFSCLIENT > > newnfs_port.o(.data+0x400): In function `nfsrvd_rcv': > =2E./../../newnfs/nfs/newnfs_port.c:228: multiple definition of `M_NFSLOCK' > nfs_lock.o(.data+0x0):../../../nfsclient/nfs_lock.c:81: first defined here > *** Error code 1 M_NFSLOCK needs to be renamed. I've put a simple patch in ftp://ftp.cis.uoguelph.ca/pub/nfsv4/patch1-freebsd6.0-beta1.diffc, but I think I'll be creating new tarballs for FreeBSD6.0-BETA1 soon, that will have all the server specific M_NFSxxx renamed to M_NFSDxxx. (I need to do this after I fix problems that DEBUG_VFS_LOCKS finds. I suspect your crash is one of them:-) > Also the utilities don't build properly out of the box..they need an > -I to point to the headers (or there needs to be a patch to make the > headers get installed by 'make includes'), and 'make install' doesn't > work once you fix that. There's a file called Install.notes in doc.tar.gz which I think covers the steps involved in a manual install. But you are definitely correct that these things need to be fixed up as a part of integrating it. I just heard this weekend that the FreeBSD folks might be interested in doing that now. I think the best route would be to integrate the V4 stuff into FreeBSD's current mountd/nfsd in such a way that the utilities will work for both nfs servers, depending upon which one is configured in the kernel. (Even if making ones that work with both isn't practical, integrating the V4 stuff into your current code is a good idea, since the ones in nfsv4utils are based on really old code, except for the V4 extensions.) > haessal# mount_nfs4 dosirak:/c /dosirak/c > mount_nfs4: /dosirak/c: Protocol not supported My guess on this is that your /etc/newexports doesn't have the V4 section added to it. Another possibility is that the FreeBSD client only knows how to mount "/" for V4. (I admit I've done very little testing with the FreeBSD client, since I've never gotten it to work well. See Clients.notes int doc.tar.gz.) > (nothing logged on the server), and the mount_newnfs in the utils > tarball does not compile on FreeBSD. The client only works with OpenBSD3.7 and that's what uses mount_newnfs. (It is different code than the CITI client in FreeBSD.) > It died after a few seconds with: > > panic: lockmgr: thread 0xc5aea000, not exclusive lock holder 0xc5ab0d80 unl= > ocking > db> wh > Tracing pid 54836 tid 100188 td 0xc5aea000 > kdb_enter(c06feb5a,1,c06fd00e,f7c86980,c5aea000) at kdb_enter+0x30 > panic(c06fd00e,c5aea000,c06fcff8,c5ab0d80,c5aea000) at panic+0x13e > debuglockmgr(c62f8b2c,6,c62f8b6c,c5aea000,c06f8111) at debuglockmgr+0x59e > vop_stdunlock(f7c86a24,f7c86a34,786,c5b2b400,c5bac0ba) at vop_stdunlock+0x4d > VOP_UNLOCK_APV(c0749660,f7c86a24,2,f7c86a10,c06d6282) at VOP_UNLOCK_APV+0xb2 > nfsrv_namei(c9d8de80,f7c86b7c,c62f8ad4,0,180) at nfsrv_namei+0x46b > nfsrvd_lookup(c9d8de80,c9bf4880,c62f8ad4,0,f7c86c1c) at nfsrvd_lookup+0xcf > nfsrvd_dorpc(c9d8de80,c9bf4880,c5aea000,6e5,0) at nfsrvd_dorpc+0x2f3 > nfsrvd_nfsd(c5aea000,0,c070d4cc,33d,c5ae2cb0) at nfsrvd_nfsd+0x404 > nfssvc(c5aea000,f7c86d04,8,bfbff000,2) at nfssvc+0x3a8 > syscall(2806003b,2806003b,bfbf003b,2804f40b,bfbfe884) at syscall+0x295 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (155, FreeBSD ELF32, nfssvc), eip =3D 0x280ba523, esp =3D 0xbfb= > fe64c, ebp =3D 0xbfbfe848 --- > db> Blush. I never noticed that my config for FreeBSD6-BETA1 didn't have DEBUG_VFS_LOCKS defined in it. This may keep me busy for a little while and I think I'll create new tarballs once I think it's fixed (I'm just ansifying all the function headers and doing some cleanup, as well). If you want to test in the meantime, take "options DEBUG_VFS_LOCKS" out of your config and I think it will be much happier. Thanks for the testing, rick From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 00:08:04 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A152016A41F; Mon, 1 Aug 2005 00:08:04 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ED8743D46; Mon, 1 Aug 2005 00:08:03 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from [151.26.125.187] (ppp-187-125.26-151.libero.it [151.26.125.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id B8C1F58DA; Mon, 1 Aug 2005 02:08:16 +0200 (CEST) Message-ID: <42ED67A5.8060102@freesbie.org> Date: Mon, 01 Aug 2005 02:07:01 +0200 From: Dario Freni User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: it, it-it, en-us, en MIME-Version: 1.0 To: Peter Grehan References: <42EB7B3E.3030308@freebsd.org> In-Reply-To: <42EB7B3E.3030308@freebsd.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigECC82BE48BFEF02DAB0691F5" Cc: current@freebsd.org, fs@freebsd.org Subject: Re: Rockridge extension not enabled when / is cd9660, boot fails X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 00:08:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigECC82BE48BFEF02DAB0691F5 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Peter Grehan wrote: > Hi Dario, > > I've come across this too: a hack is at: > > http://people.freebsd.org/~grehan/cd9660_vfsops.diff > > ... though I think that's the wrong way to do it. > > I guess you and I are the only ones to ever mount cd9660 as root :) I guess it too :) Thank you very much for the patch. Can't be it commited? Or can't this problem be fixed on the source tree in some way? I think the cd9660 root "feature" is quite unusable this way. Bye, Dario -- Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --------------enigECC82BE48BFEF02DAB0691F5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC7Weoymi72IiShysRAmBSAJ0U+idqjx5AW8iCzGTvr7vph/HeEACfb1j/ NsQkwDBH85V+UHwQqLio2ZQ= =Wn4Z -----END PGP SIGNATURE----- --------------enigECC82BE48BFEF02DAB0691F5-- From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 01:27:15 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 441A616A41F for ; Mon, 1 Aug 2005 01:27:15 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from moe.cs.uoguelph.ca (moe.cs.uoguelph.ca [131.104.96.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id C368243D53 for ; Mon, 1 Aug 2005 01:27:14 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from snowhite.cis.uoguelph.ca (snowhite.cis.uoguelph.ca [131.104.48.1]) by moe.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id j711RDXm021456; Sun, 31 Jul 2005 21:27:13 -0400 Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id VAA29962; Sun, 31 Jul 2005 21:27:43 -0400 (EDT) Date: Sun, 31 Jul 2005 21:27:43 -0400 (EDT) From: rick@snowhite.cis.uoguelph.ca Message-Id: <200508010127.VAA29962@snowhite.cis.uoguelph.ca> To: kris@obsecurity.org X-Scanned-By: MIMEDefang 2.44 Cc: fs@freebsd.org, openbsd-nfsv4@sfobug.org Subject: re: FreeBSD6.0-BETA1 panics X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 01:27:15 -0000 I've just put a little patch up ftp://ftp.cis.uoguelph.ca/pub/nfsv4/patch2-freebsd6.0-bet1.diffc (which is also appended to this message) that seems to fix the panics that I reproduced when testing with: option DEBUG_VFS_LOCKS option DEBUG_LOCKS I will be doing further testing on FreeBSD6.0-BETA1 and will cut new tarballs, but you can try the patch in the meantime, since I think it fixes the panic you saw. rick ps: I've got a hunch similar fixes are needed for the older versions of FreeBSD, but I'll check into that and create separate patches, as required. --- patch diffc --- *** newnfs/nfs/nfsport.h.orig Sun Jul 31 21:17:25 2005 --- newnfs/nfs/nfsport.h Sun Jul 31 21:19:54 2005 *************** *** 433,439 **** /* * Defined as the VOP_ISLOCKED macro. */ ! #define NFSVOPISLOCKED(v, p) VOP_ISLOCKED((v), (p)) /* * Increment the fp count. --- 433,439 ---- /* * Defined as the VOP_ISLOCKED macro. */ ! #define NFSVOPISLOCKED(v, p) (VOP_ISLOCKED((v), (p)) == LK_EXCLUSIVE) /* * Increment the fp count. *** newnfs/nfsd/nfsd_srv4root.c.orig Sun Jul 31 21:14:36 2005 --- newnfs/nfsd/nfsd_srv4root.c Sun Jul 31 21:15:03 2005 *************** *** 294,303 **** if (cnp->cn_nameiop != LOOKUP && (flags & ISLASTCN)) cnp->cn_flags |= SAVENAME; *(ap->a_vpp) = newvp; - if (!lockparent || !(flags & ISLASTCN)) { - VOP_UNLOCK(nfsv4root_vp, 0, p); - cnp->cn_flags |= PDIRUNLOCK; - } return (0); } cp += dp->d_reclen; --- 294,299 ---- From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 01:52:09 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4837316A41F; Mon, 1 Aug 2005 01:52:09 +0000 (GMT) (envelope-from yfyoufeng@263.net) Received: from smtp.263.net (mx01.263.net.cn [211.150.96.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC4AB43D46; Mon, 1 Aug 2005 01:52:08 +0000 (GMT) (envelope-from yfyoufeng@263.net) Received: from [10.217.12.183] (localhost [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 59C78C37A0; Mon, 1 Aug 2005 09:52:02 +0800 (CST) (envelope-from yfyoufeng@263.net) Received: from [10.217.12.183] (unknown [61.135.152.194]) by antispam-2 (Coremail:263(050316)) with SMTP id EHAgAUKA7UKqHJjC.1 for ; Mon, 01 Aug 2005 09:52:02 +0800 (CST) X-TEBIE-Originating-IP: [61.135.152.194] From: yf-263 To: Ryan Sommers In-Reply-To: <42EB9005.8080200@gamersimpact.com> References: <42E9A0E7.40703@centtech.com> <42EB9005.8080200@gamersimpact.com> Content-Type: text/plain; charset=UTF-8 Organization: Unix-driver.org Date: Mon, 01 Aug 2005 17:51:59 +0800 Message-Id: <1122889920.2885.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Pointers for understanding vfs/buffer/filesystem architecture X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yfyoufeng@263.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 01:52:09 -0000 在 2005-07-30六的 09:34 -0500，Ryan Sommers写道： > Eric Anderson wrote: > > I've very interested in learning about FreeBSD's implementation of > > vfs/buffer cache/fs archicture. I've read through mckusick@'s chapter > > in the Design and Implmentation of FreeBSD book, and I've read the UNIX > > Filesystems book cover to cover. > > > > What I'd like to see/read/understand, is how FreeBSD in particular is > > put together in this regard, and then I'd like to go about writing a > > very very simple filesystem as a learning excercise. > > > > Can anyone give me some pointers? Would anyone be willing to guide me > > along in my quest by answering questions (off list if preferred, or on > > list), etc? > > > > Thanks in advance for the hints/input! > > Eric > > > > > > Best place would be the source code itself. I think the nullfs > implementation would be a good place (src/sys/fs/nullfs). I thought I > also remembered some little article on writing an FS for freebsd, > finding it is eluding me though. I'm also doing the same work. Now I'm working on port our data access library into the FreeBSD kernel space as a vnode hooks. Hope we can help each others :) > -- yf-263 Unix-driver.org From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 10:33:23 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D651216A41F; Mon, 1 Aug 2005 10:33:23 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DD2143D4C; Mon, 1 Aug 2005 10:33:22 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from [192.168.0.3] (host46-147.pool8254.interbusiness.it [82.54.147.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id 831CC58EE; Mon, 1 Aug 2005 12:33:36 +0200 (CEST) Message-ID: <42EDFA77.1080704@freesbie.org> Date: Mon, 01 Aug 2005 12:33:27 +0200 From: Dario Freni User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Grehan References: <42EB7B3E.3030308@freebsd.org> <42ED67A5.8060102@freesbie.org> In-Reply-To: <42ED67A5.8060102@freesbie.org> X-Enigmail-Version: 0.91.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, fs@freebsd.org Subject: Re: Rockridge extension not enabled when / is cd9660, boot fails X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 10:33:24 -0000 Dario Freni wrote: > Peter Grehan wrote: > >>Hi Dario, >> >> I've come across this too: a hack is at: >> >> http://people.freebsd.org/~grehan/cd9660_vfsops.diff >> >> ... though I think that's the wrong way to do it. >> >> I guess you and I are the only ones to ever mount cd9660 as root :) > > > I guess it too :) Thank you very much for the patch. Can't be it > commited? Or can't this problem be fixed on the source tree in some way? > I think the cd9660 root "feature" is quite unusable this way. The patched worked for me in a normal environment. I'm getting a LOR under qemu: acd0: CDROM at ata1-master PIO3 ATA PseudoRAID loaded GEOM_LABEL: Label for provider acd0 is iso9660/FreeSBIE. Trying to mount root from cd9660:/dev/iso9660/FreeSBIE lock order reversal 1st 0xc12ef6e8 ATA state lock (ATA state lock) @ /usr/src/sys/dev/ata/ata-all.c:297 2nd 0xc10611c4 user map (user map) @ /usr/src/sys/vm/vm_map.c:2997 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0985108,c0985cc0,c090d5ec) at kdb_backtrace+0x29 witness_checkorder(c10611c4,9,c08c1360,bb5) at witness_checkorder+0x564 _sx_xlock(c10611c4,c08c1360,bb5) at _sx_xlock+0x50 _vm_map_lock_read(c1061180,c08c1360,bb5,2009b2b,c) at _vm_map_lock_read+0x37 vm_map_lookup(c838bb7c,c708f000,2,c838bb80,c838bb70) at vm_map_lookup+0x28 vm_fault(c1061000,c708f000,2,0,c132b300) at vm_fault+0x66 trap_pfault(c838bc44,0,c708f800) at trap_pfault+0x137 trap(8,28,28,c708f800,c12ef600) at trap+0x341 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc04fc828, esp = 0xc838bc84, ebp = 0xc838bca4 --- ata_pio_read(c1452578,800,129,c13e4200,c13f1c00) at ata_pio_read+0x78 ata_end_transaction(c1452578) at ata_end_transaction+0x8b8 ata_interrupt(c12ef600) at ata_interrupt+0xdf ithread_loop(c12fa800,c838bd38,c12fa800,c065ad88,0) at ithread_loop+0x11c fork_exit(c065ad88,c12fa800,c838bd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc838bd6c, ebp = 0 --- panic: vm_fault: fault on nofault entry, addr: c708f000 cpuid = 0 KDB: enter: panic [thread pid 26 tid 100026 ] Stopped at kdb_enter+0x2b: nop db> -- Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 11:30:10 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD1CB16A41F; Mon, 1 Aug 2005 11:30:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B82443D46; Mon, 1 Aug 2005 11:30:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 2AEC31FFACC; Mon, 1 Aug 2005 13:30:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id BE2E81FFACB; Mon, 1 Aug 2005 13:30:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id EBD361538C; Mon, 1 Aug 2005 11:26:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id E117315329; Mon, 1 Aug 2005 11:26:41 +0000 (UTC) Date: Mon, 1 Aug 2005 11:26:41 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Dario Freni In-Reply-To: <42EDFA77.1080704@freesbie.org> Message-ID: References: <42EB7B3E.3030308@freebsd.org> <42ED67A5.8060102@freesbie.org> <42EDFA77.1080704@freesbie.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: fs@freebsd.org, FreeBSD current mailing list , Peter Grehan Subject: Re: Rockridge extension not enabled when / is cd9660, boot fails X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 11:30:11 -0000 On Mon, 1 Aug 2005, Dario Freni wrote: > Dario Freni wrote: > > Peter Grehan wrote: > > > >>Hi Dario, > >> > >> I've come across this too: a hack is at: > >> > >> http://people.freebsd.org/~grehan/cd9660_vfsops.diff > >> > >> ... though I think that's the wrong way to do it. > >> > >> I guess you and I are the only ones to ever mount cd9660 as root :) > > > > > > I guess it too :) Thank you very much for the patch. Can't be it > > commited? Or can't this problem be fixed on the source tree in some way? > > I think the cd9660 root "feature" is quite unusable this way. > > The patched worked for me in a normal environment. I'm getting a LOR > under qemu: > > acd0: CDROM at ata1-master PIO3 > ATA PseudoRAID loaded > GEOM_LABEL: Label for provider acd0 is iso9660/FreeSBIE. > Trying to mount root from cd9660:/dev/iso9660/FreeSBIE > lock order reversal > 1st 0xc12ef6e8 ATA state lock (ATA state lock) @ > /usr/src/sys/dev/ata/ata-all.c:297 > 2nd 0xc10611c4 user map (user map) @ /usr/src/sys/vm/vm_map.c:2997 already seen before. See http://sources.zabbadoz.net/freebsd/lor.html#094 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 14:09:01 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C881F16A41F; Mon, 1 Aug 2005 14:09:01 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au [203.22.124.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 370BD43D45; Mon, 1 Aug 2005 14:09:01 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [203.144.2.167] (CPE-2-167.dsl.OntheNet.net [203.144.2.167]) by liberty.onthenet.com.au (8.12.9 - 20030918/8.12.9) with ESMTP id j71E8w7v090392; Tue, 2 Aug 2005 00:08:59 +1000 (EST) (envelope-from grehan@freebsd.org) Message-ID: <42EE2D09.7010505@freebsd.org> Date: Tue, 02 Aug 2005 00:09:13 +1000 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dario Freni References: <42EB7B3E.3030308@freebsd.org> <42ED67A5.8060102@freesbie.org> <42EDFA77.1080704@freesbie.org> In-Reply-To: <42EDFA77.1080704@freesbie.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, fs@freebsd.org Subject: Re: Rockridge extension not enabled when / is cd9660, boot fails X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 14:09:02 -0000 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc04fc828, esp = 0xc838bc84, ebp = 0xc838bca4 --- > ata_pio_read(c1452578,800,129,c13e4200,c13f1c00) at ata_pio_read+0x78 > ata_end_transaction(c1452578) at ata_end_transaction+0x8b8 > ata_interrupt(c12ef600) at ata_interrupt+0xdf > ithread_loop(c12fa800,c838bd38,c12fa800,c065ad88,0) at ithread_loop+0x11c > fork_exit(c065ad88,c12fa800,c838bd38) at fork_exit+0xa0 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xc838bd6c, ebp = 0 --- > panic: vm_fault: fault on nofault entry, addr: c708f000 I suspect this is a bug somewhere in qemu - the ATA driver is getting a page fault in kernel mode while it is holding a lock, and the VM code then gets a LOR as it tries to determine if the fault is expected or not. later, Peter. From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 15:09:33 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 018B416A41F; Mon, 1 Aug 2005 15:09:33 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77EC243D45; Mon, 1 Aug 2005 15:09:31 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j71F9UP3065993; Mon, 1 Aug 2005 10:09:30 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42EE3B23.7090507@centtech.com> Date: Mon, 01 Aug 2005 10:09:23 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Grehan References: <42EB7B3E.3030308@freebsd.org> <42ED67A5.8060102@freesbie.org> <42EDFA77.1080704@freesbie.org> <42EE2D09.7010505@freebsd.org> In-Reply-To: <42EE2D09.7010505@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, fs@freebsd.org Subject: Re: Rockridge extension not enabled when / is cd9660, boot fails X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 15:09:33 -0000 Peter Grehan wrote: >> calltrap() at calltrap+0x5 >> --- trap 0xc, eip = 0xc04fc828, esp = 0xc838bc84, ebp = 0xc838bca4 --- >> ata_pio_read(c1452578,800,129,c13e4200,c13f1c00) at ata_pio_read+0x78 >> ata_end_transaction(c1452578) at ata_end_transaction+0x8b8 >> ata_interrupt(c12ef600) at ata_interrupt+0xdf >> ithread_loop(c12fa800,c838bd38,c12fa800,c065ad88,0) at ithread_loop+0x11c >> fork_exit(c065ad88,c12fa800,c838bd38) at fork_exit+0xa0 >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0x1, eip = 0, esp = 0xc838bd6c, ebp = 0 --- >> panic: vm_fault: fault on nofault entry, addr: c708f000 > > > I suspect this is a bug somewhere in qemu - the ATA driver is getting a > page fault in kernel mode while it is holding a lock, and the VM code > then gets a LOR as it tries to determine if the fault is expected or not. I believe a slightly older qemu worked fine (0.7.0 < 20050717 port). Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 16:17:49 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C06A616A41F; Mon, 1 Aug 2005 16:17:49 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 624AF43D45; Mon, 1 Aug 2005 16:17:48 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from [192.168.0.3] (ppp-160-112.26-151.libero.it [151.26.112.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id 42C505747; Mon, 1 Aug 2005 18:18:03 +0200 (CEST) Message-ID: <42EE4B08.8090107@freesbie.org> Date: Mon, 01 Aug 2005 18:17:12 +0200 From: Dario Freni User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org, fs@freebsd.org X-Enigmail-Version: 0.91.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: More unionfs madness X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 16:17:49 -0000 Background: - Read-only compressed partition mounted on /var - Memory fs created on /mnt/union/var (using mount_md function of rc.subr) - Created the directory structure on the memory fs - mount_unionfs -o noatime /mnt/union/var /var (noatime is a suggested workaround for a bug I've already found, see fs@ archive) I'm getting panic during the init phase, when newsyslog script is called: Creating and/or trimming log files:panic: lockmgr: locking against myself cpuid = 0 KDB: enter: panic [thread pid 231 tid 100051 ] Stopped at kdb_enter+0x2b: nop db> tr Tracing pid 231 tid 100051 td 0xc1470480 kdb_enter(c08a550b) at kdb_enter+0x2b panic(c08a397e,c1470480,0,c0913fa0,c840a990) at panic+0x127 lockmgr(c1917058,2002,c191707c,c1470480,c840a970) at lockmgr+0x3da vop_stdlock(c840a990,2,c1917000,c840a9ac,c06cb648) at vop_stdlock+0x1e VOP_LOCK_APV(c0905ae0,c840a990) at VOP_LOCK_APV+0x87 vn_lock(c1917000,2,c1470480,0,13) at vn_lock+0xa8 union_allocvp(c840ac2c,c1455800,c1878550,c17f2990,c840ac40) at union_allocvp+0x25b union_lookup(c840ab38,c1878550,0,c840ab54,c06ba68a) at union_lookup+0x627 VOP_LOOKUP_APV(c0905ae0,c840ab38) at VOP_LOOKUP_APV+0x87 lookup(c840ac18,c1458044,0,c1470480,12b) at lookup+0x3d6 namei(c840ac18,1,0,c09861e8,c0985b30) at namei+0x35a kern_rename(c1470480,bfbfb730,8051100,0,c840ad30) at kern_rename+0xf4 rename(c1470480,c840ad04,2,1c,80296) at rename+0x15 syscall(3b,3b,3b,3,bfbfb730) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (128, FreeBSD ELF32, rename), eip = 0x280bbd47, esp = 0xbfbfb70c, ebp = 0xbfbfbba8 --- db> In know that unionfs is totally broken atm, but when will this be fixed? The unusability of unionfs is a step back for my project. Bye, Dario -- Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 16:39:57 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECCA716A41F for ; Mon, 1 Aug 2005 16:39:57 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A57B43D45 for ; Mon, 1 Aug 2005 16:39:57 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id j71Gdria092569; Mon, 1 Aug 2005 12:39:53 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id j71Gdq7D092568; Mon, 1 Aug 2005 12:39:52 -0400 (EDT) (envelope-from afields) Date: Mon, 1 Aug 2005 12:39:52 -0400 From: Allan Fields To: David Kreil Message-ID: <20050801163952.GA230@afields.ca> References: <20040828051655.GK33859@afields.ca> <200507142037.j6EKbft12951@parrot.ebi.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <200507142037.j6EKbft12951@parrot.ebi.ac.uk> User-Agent: Mutt/1.4i Cc: freebsd-fs@freebsd.org Subject: Analysis of Storage Security (Re: preventing information leakage in gbde protected system) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 16:39:58 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 14, 2005 at 09:37:41PM +0100, David Kreil wrote: >=20 > Dear Allan, >=20 > After a job induced pause in my strong interest in encryption solutions, = I'm=20 > now slowly returning to the case. You have kindly provided good advice wh= en we=20 > were in touch last year and I was wondering whether you had any further= =20 > information regarding setting up a system to be gbde protected early enou= gh=20 > during system boot to avoid leakage of sensitive information in /var, /et= c,=20 > and possible the root (/). Many thanks for your patience.. pjd has some patches that can allow encrypted root to be mounted at boot. I'd recommend trying them out. The biggest argument for full disk encryption is to say that you've eliminated at the base system level the ability for raw data leakage to disk. It's clear I should dedicate a few days doing GBDE/GELI stuff. Sorry I've not spent the time necessary as of yet. My publishing situation is slightly unordered, with time that will improve and my analysis _will_ find it's way online. I was thinking I could pursue: simple text/HTML pages, O'Reilly article, or conference papers in the future, but I want to make sure I have a verifiably strong analysis, though general tutorials might be what people need.. I'm actually working on multiple fronts investigating device-level and vnode-level solutions. There are various tools available under *BSD, Linux, Windows. I hope to post an extended inventory of the area, but if I don't get around to that, I'll be sure to post a brief on the current state of GBDE,GELI (GEOM based) solutions under FreeBSD. If someone beats me to it, I'll try to contribute anything additional that I've found. There is also someone from Max-Plank Institute in Germany who is waiting on analysis of these solutions. I'm OK with doing some analysis and making that available free, I just expanded the scope of the solution space I'm investigating. If someone wants to fund development, I don't know what the GEOM=20 authors opinion on this would be. You might check out Himeji Systems (http://himejisystems.com) which is my startup. I hope to formalize a security offering based on Open Source solutions and work with other vendors who are interested in Storage Security. Again, mostly bare bones pages. Under Linux, IBM Research based out of Austin, Texas is working on eCryptFS. Under Windows Sarah Dean has been doing work on an Open Source OTFE implementation. Most of these efforts are part-time and have gone w/o formal review or analysis (that is publicly available). Additionally there are a number of commercial solutions that work into the SAN/NAS picture. I think both FreeBSD and Linux has the potential to compete in this space given iSCSI like arrangements. Has anyone had success with ggate and gbde in this type of configuration? Thanks, Allan > With many thanks > and best regards, >=20 > David. >=20 > > > > > I wonder, in particular, what issues I have to expect in wanting = to keep > > > > > system relevant directories like /var on a gdbe partition. > > > > > > > > The gbde attach should occur early enough during multiuser startup = to avoid > > > > such problems, I don't recall if the provided rc script would be su= fficient, > > > > I'll test a configuration soon, or let me know if you have any luck. > >=20 > > I plan to elaborate further on the subject and will post more details > > to the lists. I can try to collect some practical examples, as I > > originally set out to do earlier this summer, and put up a web page. > >=20 >=20 > -------------------------------------------------------------------------= -- > Dr David Philip Kreil =20 > Research Fellow, Darwin College, | WWTF Vienna Science Chair of > University of Cambridge | Bioinformatics, Dept of Biotechnology, > ++44 1223 764107, fax 7092 810040 | c/o IAM / BOKU, A-1190 Muthgasse 18 > www.inference.phy.cam.ac.uk/dpk20 | ++43 1 360066830 -- Allan Fields (afields) - Ottawa, Canada (45"10'N 75"56'W) Himeji Systems http://himejisystems.com Afields Research/AFRSL http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541 --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQFC7lBX90UNcjm0VUERAilCAJ9rrPeRWfJp+aKNA8wEX93aY9Oh4gCfXDu2 D+nIzBFLaA61gh7iyHaBTww= =LMaS -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 18:02:48 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41D8816A420 for ; Mon, 1 Aug 2005 18:02:48 +0000 (GMT) (envelope-from igor.shmukler@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6987843D46 for ; Mon, 1 Aug 2005 18:02:47 +0000 (GMT) (envelope-from igor.shmukler@gmail.com) Received: by zproxy.gmail.com with SMTP id z6so690994nzd for ; Mon, 01 Aug 2005 11:02:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PPhtxqTVGfVQBMGpBCZUCnru+HU+1aqFyfZbfijvRUvg4YNVkhykOLSTyOar1JrbFxHbz5vTf3IEQqtlqHQQqLiuyHwdzrpU9ShHDALX60Y+kSeIzxLQSUuvlCEQmYRSxqsKgHHjZBR9SPINAfgsZikTxLsej1syEy5DvHV7Z4s= Received: by 10.36.37.12 with SMTP id k12mr4762913nzk; Mon, 01 Aug 2005 11:02:46 -0700 (PDT) Received: by 10.36.119.12 with HTTP; Mon, 1 Aug 2005 11:02:46 -0700 (PDT) Message-ID: <6533c1c905080111026f1f07ca@mail.gmail.com> Date: Mon, 1 Aug 2005 14:02:46 -0400 From: Igor Shmukler To: Matthew Dillon In-Reply-To: <200507211926.j6LJQ55D071115@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6533c1c9050721121030016b7d@mail.gmail.com> <200507211926.j6LJQ55D071115@apollo.backplane.com> Cc: hackers@freebsd.org, fs@freebsd.org Subject: Re: per file lock list X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Igor Shmukler List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 18:02:48 -0000 Matt, Thank you very much for response. This is a general solution, but it not sufficient for our needs. I guess I should have been more clear while explaining what we need. We want list of these locks for a group of processes. We made an implementation based on your suggestion, but there is one proble= m... Unfortunately this method does not return all shared locks for a range. For example, if several processes have placed a shared lock on a range [1000 - 2000], F_GETLK returns a flock structure where l_pid field contains a pid of process that takes the lock first. While, we want to know all processes that takes this lock. Is there any way to retrieve such information without using of internal kernel structures (inode information)? Thank you in advance, igor On 7/21/05, Matthew Dillon wrote: > :Hi, > : > :We have a question: how to get all POSIX locks for a given file? > :.. > : > :As far as I know, existing API does not allow to retrieve all file > :locks. Therefore, we need to use kernel internal structures to get all > :... > :So the question: is there an elegant way to get the lock list for a give= n file? > : > :Thank you in advance. >=20 > You can use F_GETLK to iterate through all posix locks held on a file= . > From man fcntl: >=20 > F_GETLK Get the first lock that blocks the lock description point= ed to > by the third argument, arg, taken as a pointer to a struc= t > flock (see above). The information retrieved overwrites = the > information passed to fcntl() in the flock structure. If= no > lock is found that would prevent this lock from being cre= ated, > the structure is left unchanged by this function call exc= ept > for the lock type which is set to F_UNLCK. >=20 > So what you do is you specify a lock description that covers the whol= e > file and call F_GETLK. You then use the results to modify the lock > description to a range that starts just past the returned lock > for the next call. You continue iterating until F_GETLK tells you th= at > there are no more locks. >=20 > -Matt > Matthew Dillon > > From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 18:40:23 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F203F16A42C; Mon, 1 Aug 2005 18:40:22 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5425E43D69; Mon, 1 Aug 2005 18:40:19 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Mon, 01 Aug 2005 11:40:17 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 5DFFA5D07; Mon, 1 Aug 2005 11:40:17 -0700 (PDT) To: Dario Freni In-reply-to: Your message of "Mon, 01 Aug 2005 18:17:12 +0200." <42EE4B08.8090107@freesbie.org> Date: Mon, 01 Aug 2005 11:40:17 -0700 From: "Kevin Oberman" Message-Id: <20050801184017.5DFFA5D07@ptavv.es.net> Cc: current@freebsd.org, fs@freebsd.org Subject: Re: More unionfs madness X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 18:40:23 -0000 > Date: Mon, 01 Aug 2005 18:17:12 +0200 > From: Dario Freni > Sender: owner-freebsd-current@freebsd.org > > Background: > - Read-only compressed partition mounted on /var > - Memory fs created on /mnt/union/var (using mount_md function of rc.subr) > - Created the directory structure on the memory fs > - mount_unionfs -o noatime /mnt/union/var /var (noatime is a suggested > workaround for a bug I've already found, see fs@ archive) > > I'm getting panic during the init phase, when newsyslog script is called: > > Creating and/or trimming log files:panic: lockmgr: locking against myself > cpuid = 0 > KDB: enter: panic > [thread pid 231 tid 100051 ] > Stopped at kdb_enter+0x2b: nop > db> tr > Tracing pid 231 tid 100051 td 0xc1470480 > kdb_enter(c08a550b) at kdb_enter+0x2b > panic(c08a397e,c1470480,0,c0913fa0,c840a990) at panic+0x127 > lockmgr(c1917058,2002,c191707c,c1470480,c840a970) at lockmgr+0x3da > vop_stdlock(c840a990,2,c1917000,c840a9ac,c06cb648) at vop_stdlock+0x1e > VOP_LOCK_APV(c0905ae0,c840a990) at VOP_LOCK_APV+0x87 > vn_lock(c1917000,2,c1470480,0,13) at vn_lock+0xa8 > union_allocvp(c840ac2c,c1455800,c1878550,c17f2990,c840ac40) at > union_allocvp+0x25b > union_lookup(c840ab38,c1878550,0,c840ab54,c06ba68a) at union_lookup+0x627 > VOP_LOOKUP_APV(c0905ae0,c840ab38) at VOP_LOOKUP_APV+0x87 > lookup(c840ac18,c1458044,0,c1470480,12b) at lookup+0x3d6 > namei(c840ac18,1,0,c09861e8,c0985b30) at namei+0x35a > kern_rename(c1470480,bfbfb730,8051100,0,c840ad30) at kern_rename+0xf4 > rename(c1470480,c840ad04,2,1c,80296) at rename+0x15 > syscall(3b,3b,3b,3,bfbfb730) at syscall+0x22f > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (128, FreeBSD ELF32, rename), eip = 0x280bbd47, esp = > 0xbfbfb70c, ebp = 0xbfbfbba8 --- > db> > > In know that unionfs is totally broken atm, but when will this be fixed? > The unusability of unionfs is a step back for my project. I don't know about "totally broken" I use unionfs regularly on my system and it's been fine. I'll admit that the use (profile) is fairly straight-forward, but it's given me no problems. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 18:55:16 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8795716A41F; Mon, 1 Aug 2005 18:55:16 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DCE943D46; Mon, 1 Aug 2005 18:55:15 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-1.free.fr (Postfix) with ESMTP id D3D651734A9; Mon, 1 Aug 2005 20:55:14 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 66181405B; Mon, 1 Aug 2005 20:55:34 +0200 (CEST) Date: Mon, 1 Aug 2005 20:55:34 +0200 From: Jeremie Le Hen To: Kevin Oberman Message-ID: <20050801185534.GD68965@obiwan.tataz.chchile.org> References: <42EE4B08.8090107@freesbie.org> <20050801184017.5DFFA5D07@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050801184017.5DFFA5D07@ptavv.es.net> User-Agent: Mutt/1.5.9i Cc: current@freebsd.org, fs@freebsd.org Subject: Re: More unionfs madness X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 18:55:16 -0000 Hi Kevin, Dario and all, > I don't know about "totally broken" I use unionfs regularly on my system > and it's been fine. I'll admit that the use (profile) is fairly > straight-forward, but it's given me no problems. profile.sh uses the "union" mount(8) option (MNT_UNION), which has far more simpler semantics as the unionfs filesystem. The latter is indeed totally broken as a simple rename(2) or rmdir(2) would lead to a panic, IIRC. BTW, if you are interested in MNT_UNION semantics, I made a patch for the profile.sh(8) manpage (among other one which are waiting for Tobias to be merged :-), which explains clearly what it is supposed to do. The real unionfs filesystem is described in mount_unionfs(8) manpage. Have a look here : http://jeremie.le-hen.org/~tataz/patches/FreeBSD/profile.sh/ Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 18:57:32 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BF0816A41F for ; Mon, 1 Aug 2005 18:57:32 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E3D143D4C for ; Mon, 1 Aug 2005 18:57:31 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j71IvSNV008564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2005 14:57:28 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j71IvR6P007380; Mon, 1 Aug 2005 14:57:27 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5ED76515A9; Mon, 1 Aug 2005 14:57:19 -0400 (EDT) Date: Mon, 1 Aug 2005 14:57:19 -0400 From: Kris Kennaway To: rick@snowhite.cis.uoguelph.ca Message-ID: <20050801185719.GA26377@xor.obsecurity.org> References: <200508010127.VAA29962@snowhite.cis.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <200508010127.VAA29962@snowhite.cis.uoguelph.ca> User-Agent: Mutt/1.4.2.1i Cc: openbsd-nfsv4@sfobug.org, fs@freebsd.org, kris@obsecurity.org Subject: Re: FreeBSD6.0-BETA1 panics X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 18:57:32 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 31, 2005 at 09:27:43PM -0400, rick@snowhite.cis.uoguelph.ca wro= te: > I've just put a little patch up > ftp://ftp.cis.uoguelph.ca/pub/nfsv4/patch2-freebsd6.0-bet1.diffc > (which is also appended to this message) that seems to fix the panics > that I reproduced when testing with: > option DEBUG_VFS_LOCKS > option DEBUG_LOCKS >=20 > I will be doing further testing on FreeBSD6.0-BETA1 and will cut new > tarballs, but you can try the patch in the meantime, since I think it > fixes the panic you saw. It didn't panic yet, but when doing a multiple simultaneous cvs update with NFS3 mounted repo the clients eventually got stuck in the nfsreq state. FreeBSD had a similar problem for a while, after a change made last December, but it was fixed early this year. Is your server based on an old version of the freebsd server code that is missing this (and possibly other) fixes, or is this a new bug introduced in your version? Kris --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7nCPWry0BWjoQKURAtlsAKCPQu7S5QP+39BRmSfQRwrlVce3jQCeJsPD Q1w2Gx7pSMJBTEAtvNtamco= =8XMj -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 21:04:22 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5919116A41F for ; Mon, 1 Aug 2005 21:04:22 +0000 (GMT) (envelope-from rees@citi.umich.edu) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 237DF43D45 for ; Mon, 1 Aug 2005 21:04:22 +0000 (GMT) (envelope-from rees@citi.umich.edu) Received: from citi.umich.edu (dumaguete.citi.umich.edu [141.211.133.51]) by citi.umich.edu (Postfix) with ESMTP id 33A0E1BAC2; Mon, 1 Aug 2005 17:04:21 -0400 (EDT) To: rick@snowhite.cis.uoguelph.ca From: Jim Rees In-Reply-To: rick@snowhite.cis.uoguelph.ca, Sun, 31 Jul 2005 16:37:40 EDT Date: Mon, 01 Aug 2005 17:04:21 -0400 Sender: rees@citi.umich.edu Message-Id: <20050801210421.33A0E1BAC2@citi.umich.edu> Cc: openbsd-nfsv4@sfobug.org, fs@freebsd.org, kris@obsecurity.org Subject: Re: NFSv234 problems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 21:04:22 -0000 Another possibility is that the FreeBSD client only knows how to mount "/" for V4. (I admit I've done very little testing with the FreeBSD client, since I've never gotten it to work well. See Clients.notes int doc.tar.gz.) The FreeBSD client works fine with submounts. And if you are having trouble with the client, please report any bugs you find. If you don't tell me about them I can't fix them. There is nothing in Clients.notes about problems with the FreeBSD client other than the restrictions listed on the man page. From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 21:14:19 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19E5A16A41F for ; Mon, 1 Aug 2005 21:14:19 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from moe.cs.uoguelph.ca (moe.cs.uoguelph.ca [131.104.96.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id C017743D45 for ; Mon, 1 Aug 2005 21:14:18 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from snowhite.cis.uoguelph.ca (snowhite.cis.uoguelph.ca [131.104.48.1]) by moe.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id j71LEFox028563; Mon, 1 Aug 2005 17:14:17 -0400 Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id RAA37699; Mon, 1 Aug 2005 17:14:45 -0400 (EDT) Date: Mon, 1 Aug 2005 17:14:45 -0400 (EDT) From: rick@snowhite.cis.uoguelph.ca Message-Id: <200508012114.RAA37699@snowhite.cis.uoguelph.ca> To: kris@obsecurity.org X-Scanned-By: MIMEDefang 2.44 Cc: fs@freebsd.org, openbsd-nfsv4@sfobug.org Subject: Re: Re: FreeBSD6.0-BETA1 panics X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 21:14:19 -0000 > It didn't panic yet, but when doing a multiple simultaneous cvs update > with NFS3 mounted repo the clients eventually got stuck in the nfsreq > state. > > FreeBSD had a similar problem for a while, after a change made last > December, but it was fixed early this year. Is your server based on > an old version of the freebsd server code that is missing this (and > possibly other) fixes, or is this a new bug introduced in your > version? The short answer is that the low level socket handling code for the FreeBSD port is pretty well cloned from the FreeBSD server, so I'll take a look at the bugfix stuff on the web site, to see what that was. I'll also check my code against the current FreeBSD server stuff. If you could email me the following on the server at the time of the hang, it could be useful: # netstat -a <-- to see if the connection has data in the send or rcv queue # ps axl | fgrep newnfsd <-- to see if any are hung and where Again, thanks for the testing, rick From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 21:20:02 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7863C16A41F for ; Mon, 1 Aug 2005 21:20:02 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from moe.cs.uoguelph.ca (moe.cs.uoguelph.ca [131.104.96.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14A9143D48 for ; Mon, 1 Aug 2005 21:20:01 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from snowhite.cis.uoguelph.ca (snowhite.cis.uoguelph.ca [131.104.48.1]) by moe.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id j71LJwAL029881; Mon, 1 Aug 2005 17:19:58 -0400 Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id RAA37786; Mon, 1 Aug 2005 17:20:28 -0400 (EDT) Date: Mon, 1 Aug 2005 17:20:28 -0400 (EDT) From: rick@snowhite.cis.uoguelph.ca Message-Id: <200508012120.RAA37786@snowhite.cis.uoguelph.ca> To: rees@citi.umich.edu X-Scanned-By: MIMEDefang 2.44 Cc: openbsd-nfsv4@sfobug.org, fs@freebsd.org, kris@obsecurity.org Subject: FreeBSD NFSv4 client X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 21:20:02 -0000 > The FreeBSD client works fine with submounts. And if you are having trouble > with the client, please report any bugs you find. If you don't tell me > about them I can't fix them. Yes, sorry, I should have tried the mount before emailing that. A mount of a subdir did work ok here. I'll do some more testing with it and let you know how it goes, rick. From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 23:07:27 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9FD516A41F for ; Mon, 1 Aug 2005 23:07:27 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B9DE43D46 for ; Mon, 1 Aug 2005 23:07:27 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j71N7QNV000625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2005 19:07:26 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j71N7Q6P020429; Mon, 1 Aug 2005 19:07:26 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E5BD351358; Mon, 1 Aug 2005 19:07:17 -0400 (EDT) Date: Mon, 1 Aug 2005 19:07:17 -0400 From: Kris Kennaway To: Jim Rees Message-ID: <20050801230717.GA7848@xor.obsecurity.org> References: <20050801210421.33A0E1BAC2@citi.umich.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <20050801210421.33A0E1BAC2@citi.umich.edu> User-Agent: Mutt/1.4.2.1i Cc: kris@obsecurity.org, openbsd-nfsv4@sfobug.org, fs@freebsd.org, rick@snowhite.cis.uoguelph.ca Subject: Re: NFSv234 problems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 23:07:28 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 05:04:21PM -0400, Jim Rees wrote: > Another possibility is that the FreeBSD client only knows how > to mount "/" for V4. (I admit I've done very little testing with the > FreeBSD client, since I've never gotten it to work well. See Clients.no= tes > int doc.tar.gz.) >=20 > The FreeBSD client works fine with submounts. And if you are having trou= ble > with the client, please report any bugs you find. If you don't tell me > about them I can't fix them. >=20 > There is nothing in Clients.notes about problems with the FreeBSD client > other than the restrictions listed on the man page. The issue is probably that I didn't know how to configure the server (I assumed it was as simple as copying my existing /etc/exports to newexports, since at the time I couldn't find docs to suggest otherwise). I'll try harder with the nfs4 client. kris --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7qslWry0BWjoQKURAo5LAJ9WjF41OLAouC4BVK5+oFSc/YcdqACeMWtw oBjYrd6WHmLVr3GW7EHW848= =DV8i -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-fs@FreeBSD.ORG Mon Aug 1 23:30:42 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DEAE16A41F for ; Mon, 1 Aug 2005 23:30:42 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1BFA43D45 for ; Mon, 1 Aug 2005 23:30:41 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j71NUeNV002700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2005 19:30:41 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j71NUe6P021624; Mon, 1 Aug 2005 19:30:40 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8C917513BD; Mon, 1 Aug 2005 19:30:32 -0400 (EDT) Date: Mon, 1 Aug 2005 19:30:32 -0400 From: Kris Kennaway To: rick@snowhite.cis.uoguelph.ca Message-ID: <20050801233032.GA8033@xor.obsecurity.org> References: <200508012114.RAA37699@snowhite.cis.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <200508012114.RAA37699@snowhite.cis.uoguelph.ca> User-Agent: Mutt/1.4.2.1i Cc: openbsd-nfsv4@sfobug.org, fs@freebsd.org, kris@obsecurity.org Subject: Re: Re: FreeBSD6.0-BETA1 panics X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 23:30:42 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 01, 2005 at 05:14:45PM -0400, rick@snowhite.cis.uoguelph.ca wro= te: > > It didn't panic yet, but when doing a multiple simultaneous cvs update > > with NFS3 mounted repo the clients eventually got stuck in the nfsreq > > state. > >=20 > > FreeBSD had a similar problem for a while, after a change made last > > December, but it was fixed early this year. Is your server based on > > an old version of the freebsd server code that is missing this (and > > possibly other) fixes, or is this a new bug introduced in your > > version? >=20 > The short answer is that the low level socket handling code for the > FreeBSD port is pretty well cloned from the FreeBSD server, > so I'll take a look at the bugfix stuff on > the web site, to see what that was. I'll also check my code against the > current FreeBSD server stuff. I'm also seeing spurious errors on the client while cvs updating, e.g.: haessal# cvs -Rq update -PdA ? INDEX-6 ? log ? log2 cvs [update aborted]: cannot make directory 2.2: File exists haessal# cvs -Rq update -PdA ? INDEX-6 ? log ? log2 load: 0.49 cmd: cvs 88091 [getblk] 2.03u 12.84s 32% 2776k cvs [update aborted]: cannot make directory scripts: File exists I suspect the server is returning bogus data, perhaps because of the locking problems. OK, I triggered another deadlock while running a simultaneous cvs checkout on the server (via ufs) and over nfs3 from a remote machine. dosirak# netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.nfsd *.* LISTEN tcp4 0 0 *.620 *.* LISTEN tcp4 0 0 dosirak.58029 haessal.ssh ESTABLIS= HED tcp4 0 0 dosirak.52869 haessal.ssh ESTABLIS= HED tcp4 0 0 dosirak.60073 haessal.ssh ESTABLIS= HED tcp4 0 96 dosirak.ssh pointyhat.freebs.58519 ESTABLIS= HED tcp4 0 0 *.infoseek *.* LISTEN tcp4 0 0 *.ftp *.* LISTEN tcp4 0 0 *.http *.* LISTEN tcp4 0 0 *.submission *.* LISTEN tcp6 0 0 *.smtp *.* LISTEN tcp4 0 0 *.smtp *.* LISTEN tcp4 0 0 *.ssh *.* LISTEN tcp6 0 0 *.ssh *.* LISTEN tcp4 0 0 *.sunrpc *.* LISTEN tcp6 0 0 *.sunrpc *.* LISTEN tcp6 0 0 localhost.rndc *.* LISTEN tcp4 0 0 localhost.rndc *.* LISTEN tcp4 0 0 localhost.domain *.* LISTEN tcp4 0 0 dosirak.domain *.* LISTEN udp4 0 0 *.nfsd *.* udp4 0 0 *.628 *.* udp4 0 0 localhost.660 localhost.964 udp4 0 0 localhost.601 localhost.738 udp4 0 0 *.964 *.* udp4 0 0 localhost.794 localhost.netgw udp4 0 0 *.738 *.* udp4 0 0 localhost.748 localhost.896 udp4 0 0 *.741 *.* udp4 0 0 *.896 *.* udp4 0 0 localhost.712 localhost.673 udp4 0 0 *.673 *.* udp6 0 0 fe80:3::1.ntp *.* udp6 0 0 localhost.ntp *.* udp4 0 0 localhost.ntp *.* udp6 0 0 fe80:1::230:48ff.ntp *.* udp4 0 0 dosirak.ntp *.* udp6 0 0 *.ntp *.* udp4 0 0 *.ntp *.* udp6 0 0 *.* *.* udp4 0 0 *.795 *.* udp4 0 0 *.sunrpc *.* udp6 0 0 *.1023 *.* udp6 0 0 *.sunrpc *.* udp6 0 0 *.56630 *.* udp4 0 0 *.56629 *.* udp4 0 0 localhost.domain *.* udp4 0 0 dosirak.domain *.* udp4 0 0 *.syslog *.* udp6 0 0 *.syslog *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr c5aec2bc stream 0 0 0 c5aec348 0 0 c5aec348 stream 0 0 0 c5aec2bc 0 0 c5aec3d4 stream 0 0 0 c5aec460 0 0 c5aec460 stream 0 0 0 c5aec3d4 0 0 c5aec4ec stream 0 0 0 c5aec578 0 0 c5aec578 stream 0 0 0 c5aec4ec 0 0 c5aec604 stream 0 0 0 c5aec690 0 0 c5aec690 stream 0 0 0 c5aec604 0 0 c5aec71c stream 0 0 0 c5aec7a8 0 0 c5aec7a8 stream 0 0 0 c5aec71c 0 0 c5aecc08 stream 0 0 c5b60604 0 0 0 /var/run/= rpcbind.sock c5aed000 stream 0 0 c5aeb134 0 0 0 /var/run/= devd.pipe c5aec94c dgram 0 0 0 c5aece38 0 0 c5aec9d8 dgram 0 0 0 c5aecec4 0 c5aeca64 c5aeca64 dgram 0 0 0 c5aecec4 0 c5aecc94 c5aecc94 dgram 0 0 0 c5aecec4 0 0 c5aecdac dgram 0 0 c5af239c 0 0 0 /var/name= d/var/run/log c5aece38 dgram 0 0 c5af2604 0 c5aec94c 0 /var/run/= log c5aecec4 dgram 0 0 c5af2738 0 c5aec9d8 0 /var/run/= logpriv c5af6118 dgram 0 0 c5ab886c 0 0 0 /var/run/= log dosirak# ps axl| fgrep newnfs 0 726 1 0 4 0 1392 1040 accept Is ?? 0:00.01 newnfsd= : master (newnfsd) 0 727 726 4 -4 0 1264 804 ufs D ?? 0:16.58 newnfsd= : server (newnfsd) 0 728 726 0 4 0 1264 804 nfsd S ?? 0:04.31 newnfsd= : server (newnfsd) 0 729 726 0 4 0 1264 804 nfsd I ?? 0:00.29 newnfsd= : server (newnfsd) 0 730 726 0 4 0 1264 804 nfsd I ?? 0:00.00 newnfsd= : server (newnfsd) 0 731 726 0 4 0 1264 804 nfsd I ?? 0:00.00 newnfsd= : server (newnfsd) 0 732 726 0 4 0 1264 804 nfsd I ?? 0:00.00 newnfsd= : server (newnfsd) 0 733 726 0 4 0 1264 804 nfsd I ?? 0:00.00 newnfsd= : server (newnfsd) 0 734 726 0 4 0 1264 804 nfsd I ?? 0:00.00 newnfsd= : server (newnfsd) 0 735 726 0 4 0 1264 804 nfsd I ?? 0:00.00 newnfsd= : server (newnfsd) 0 736 726 0 4 0 1264 804 nfsd I ?? 0:00.00 newnfsd= : server (newnfsd) db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 787 c8202c48 0 697 787 0004002 [CPU 1] sysctl 736 c5be4418 0 726 726 0000000 [SLPQ nfsd 0xc5881860][SLP] newnfsd 735 c5be4624 0 726 726 0000000 [SLPQ nfsd 0xc6090450][SLP] newnfsd 734 c5be4830 0 726 726 0000000 [SLPQ nfsd 0xc6090240][SLP] newnfsd 733 c5be4a3c 0 726 726 0000000 [SLPQ nfsd 0xc6090290][SLP] newnfsd 732 c5be4c48 0 726 726 0000000 [SLPQ nfsd 0xc6090220][SLP] newnfsd 731 c81f7000 0 726 726 0000000 [SLPQ nfsd 0xc60901b0][SLP] newnfsd 730 c81f720c 0 726 726 0000000 [SLPQ nfsd 0xc60901c0][SLP] newnfsd 729 c81f7418 0 726 726 0000000 [SLPQ nfsd 0xc6090330][SLP] newnfsd 728 c81f7624 0 726 726 0000000 [SLPQ nfsd 0xc6090270][SLP] newnfsd 727 c81f7830 0 726 726 0000000 [SLPQ ufs 0xc79d38c4][SLP] newnfsd 726 c81f7a3c 0 1 726 0000000 [SLPQ accept 0xc820d302][SLP] newnf= sd 724 c81f8000 0 1 724 0000000 [SLPQ select 0xc07673c4][SLP] newmo= untd 723 c8203624 0 718 718 0000000 [SLPQ select 0xc07673c4][SLP] gssd 722 c8203830 0 718 718 0000000 [SLPQ select 0xc07673c4][SLP] gssd 721 c5848c48 0 718 718 0000000 [SLPQ select 0xc07673c4][SLP] gssd 720 c5848a3c 0 718 718 0000000 [SLPQ select 0xc07673c4][SLP] gssd 718 c81f8418 0 1 718 0000000 [SLPQ pause 0xc81f844c][SLP] gssd 717 c5848830 0 712 712 0000000 [SLPQ select 0xc07673c4][SLP] nfsus= erd 716 c5bdb000 0 712 712 0000000 [SLPQ select 0xc07673c4][SLP] nfsus= erd 715 c5858c48 0 712 712 0000000 [SLPQ select 0xc07673c4][SLP] nfsus= erd 713 c5858a3c 0 712 712 0000000 [SLPQ select 0xc07673c4][SLP] nfsus= erd 712 c5a93000 0 1 712 0000000 [SLPQ pause 0xc5a93034][SLP] nfsuse= rd db> show lockedvnods Locked vnodes 0xc79d386c: tag ufs, type VDIR usecount 3, writecount 0, refcount 6 mountedhere 0 flags () v_object 0xc7984d68 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc5be0000 (pid 691) with 1 pe= nding ino 2737632, on dev da0s1e 0xc78f19a0: tag ufs, type VREG usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc7954210 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc5b52300 (pid 727) with 1 pe= nding ino 2751248, on dev da0s1e db> wh 727 Tracing pid 727 tid 100212 td 0xc5b52300 sched_switch(c5b52300,0,1,11e,89dd231b) at sched_switch+0x18f mi_switch(1,0,c0701768,1a3,1) at mi_switch+0x2bf sleepq_switch(c79d38c4,c06fdeed,18a,1,f7c5d8f0) at sleepq_switch+0x135 sleepq_wait(c79d38c4,0,c06ff26d,da,0) at sleepq_wait+0x42 msleep(c79d38c4,c075fb6c,50,c0704098,0) at msleep+0x374 acquire(f7c5d94c,40,60000,b5,c5b52300) at acquire+0x88 debuglockmgr(c79d38c4,3002,c79d3904,c5b52300,c0705769) at debuglockmgr+0x4af vop_stdlock(f7c5d9d8,c79d386c,c075fb6c,c0749600,f7c5d9d8) at vop_stdlock+0x= 4e VOP_LOCK_APV(c0749d00,f7c5d9d8,f7c5d9b0,c06d621a,f7c5d9d8) at VOP_LOCK_APV+= 0xa6 ffs_lock(f7c5d9d8,c07069a3,31f,1002,c79d386c) at ffs_lock+0x19 VOP_LOCK_APV(c0749600,f7c5d9d8,c07069a3,31f,c5b52300) at VOP_LOCK_APV+0xa6 debug_vn_lock(c79d386c,1002,c5b52300,c070d46c,48d) at debug_vn_lock+0xe5 nfsrvn_getattr(c79d386c,f7c5da9c,c5d73a80,c5b52300,180) at nfsrvn_getattr+0= x6b nfsrvd_lookup(c5dea100,c66dec00,c79d386c,0,f7c5dc1c) at nfsrvd_lookup+0x133 nfsrvd_dorpc(c5dea100,c66dec00,c5b52300,6e5,0) at nfsrvd_dorpc+0x2f3 nfsrvd_nfsd(c5b52300,0,c070d46c,33d,c81f7898) at nfsrvd_nfsd+0x404 nfssvc(c5b52300,f7c5dd04,8,bfbff000,2) at nfssvc+0x3a8 syscall(3b,3b,3b,2804f40b,bfbfe884) at syscall+0x295 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (155, FreeBSD ELF32, nfssvc), eip =3D 0x280ba523, esp =3D 0xbfb= fe64c, ebp =3D 0xbfbfe848 --- 691 c5bdb624 0 688 691 0004002 [SLPQ ufs 0xc78f19f8][SLP] cvs db> wh 691 Tracing pid 691 tid 100190 td 0xc5be0000 sched_switch(c5be0000,0,1,11e,f68edaa3) at sched_switch+0x18f mi_switch(1,0,c0701768,1a3,0) at mi_switch+0x2bf sleepq_switch(c78f19f8,c06fdeed,18a,0,f7cbe754) at sleepq_switch+0x135 sleepq_wait(c78f19f8,0,c06ff26d,da,0) at sleepq_wait+0x42 msleep(c78f19f8,c075fc68,50,c0704098,0) at msleep+0x374 acquire(f7cbe7b0,40,60000,b5,c5be0000) at acquire+0x88 debuglockmgr(c78f19f8,2002,c78f1a38,c5be0000,c0705769) at debuglockmgr+0x4af vop_stdlock(f7cbe83c,0,c073f7a0,c0749600,f7cbe83c) at vop_stdlock+0x4e VOP_LOCK_APV(c0749d00,f7cbe83c,f7cbe814,c06d621a,f7cbe83c) at VOP_LOCK_APV+= 0xa6 ffs_lock(f7cbe83c,0,1cd,2002,c78f19a0) at ffs_lock+0x19 VOP_LOCK_APV(c0749600,f7cbe83c,f7cbe87c,f7cbe838,c064adfd) at VOP_LOCK_APV+= 0xa6 debug_vn_lock(c78f19a0,2002,c5be0000,c0706050,765) at debug_vn_lock+0xe5 vget(c78f19a0,2002,c5be0000,1ca,f7cbebec) at vget+0xc7 cache_lookup(c79d386c,f7cbebd8,f7cbebec,c5be0000,c5d0c900) at cache_lookup+= 0x3d0 vfs_cache_lookup(f7cbe998,f7cbe998,c79d386c,c79d386c,0) at vfs_cache_lookup= +0xa4 VOP_LOOKUP_APV(c0749600,f7cbe998,c5be0000,c0705953,17c) at VOP_LOOKUP_APV+0= xa6 lookup(f7cbebc4,c5acc000,0,b4,c075f050) at lookup+0x474 namei(f7cbebc4,f7cbea58,c0521d6c,c075fc68,1) at namei+0x40a vn_open_cred(f7cbebc4,f7cbecc4,1a4,c5d0c900,4) at vn_open_cred+0x2bf vn_open(f7cbebc4,f7cbecc4,1a4,4,c5be0000) at vn_open+0x33 kern_open(c5be0000,80cd0c0,0,1,1b6) at kern_open+0xca open(c5be0000,f7cbed04,c,421,3) at open+0x36 syscall(bfbf003b,283a003b,bfbf003b,4,283a4200) at syscall+0x295 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip =3D 0x2830a043, esp =3D 0xbfbfde1= c, ebp =3D 0xbfbfde48 --- db> Here is the tail end of a tcpdump that was running at the time of deadlock: 08:21:03.246252 IP (tos 0x0, ttl 64, id 43639, offset 0, flags [none], pro= to: UDP (17), length: 196) 211.43.211.135.2049 > 211.43.211.137.1282404033:= reply ok 168 fsstat POST: DIR 755 ids 0/0 sz 512 nlink 16 rdev 5/224 fsid = 14b fileid 2 a/m/ctime 1122919265.000000 1120941164.000000 1120941193.00000= 0 tbytes 26607781888 fbytes 15932801024 abytes 13804179456 tfiles 3320830 f= files 1738675 afiles 1738675 invar 0 08:21:03.246498 IP (tos 0x0, ttl 64, id 41074, offset 0, flags [none], pro= to: UDP (17), length: 144) 211.43.211.137.1282404034 > 211.43.211.135.2049:= 116 lookup fh 1005,223386/2737632 "Makefile,v" 08:21:03.247252 IP (tos 0x0, ttl 64, id 43640, offset 0, flags [none], pro= to: UDP (17), length: 264) 211.43.211.135.2049 > 211.43.211.137.1282404034:= reply ok 236 lookup fh 1005,223386/2751244 REG 444 ids 0/0 sz 4196 nlink 1= rdev 191/10879220 fsid 14b fileid 29fb0c a/m/ctime 1122919337.000000 11124= 30346.000000 1112245585.000000 post dattr: DIR 755 ids 0/0 sz 512 nlink 4 r= dev 172/10879120 fsid 14b fileid 29c5e0 a/m/ctime 1122938463.000000 1112245= 585.000000 1112245585.000000 08:21:03.247320 IP (tos 0x0, ttl 64, id 41075, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404035 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751244 003f 08:21:03.247502 IP (tos 0x0, ttl 64, id 43641, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404035:= reply ok 120 access attr: REG 444 ids 0/0 sz 4196 nlink 1 rdev 191/1087922= 0 fsid 14b fileid 29fb0c a/m/ctime 1122919337.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.247628 IP (tos 0x0, ttl 64, id 41076, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404036 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751244 003f 08:21:03.247878 IP (tos 0x0, ttl 64, id 43642, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404036:= reply ok 120 access attr: REG 444 ids 0/0 sz 4196 nlink 1 rdev 191/1087922= 0 fsid 14b fileid 29fb0c a/m/ctime 1122919337.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.247987 IP (tos 0x0, ttl 64, id 41077, offset 0, flags [none], pro= to: UDP (17), length: 140) 211.43.211.137.1282404037 > 211.43.211.135.2049:= 112 read fh 1005,223386/2751244 8192 bytes @ 0 08:21:03.259507 IP (tos 0x0, ttl 64, id 43643, offset 0, flags [+], proto:= UDP (17), length: 1500) 211.43.211.135.2049 > 211.43.211.137.1282404037: r= eply ok 1472 read REG 444 ids 0/0 sz 4196 nlink 1 rdev 191/10879220 fsid 14= b fileid 29fb0c a/m/ctime 1122938463.000000 1112430346.000000 1112245585.00= 0000 4196 bytes EOF 08:21:03.260201 IP (tos 0x0, ttl 64, id 41079, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404038 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751244 003f 08:21:03.260378 IP (tos 0x0, ttl 64, id 43644, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404038:= reply ok 120 access attr: REG 444 ids 0/0 sz 4196 nlink 1 rdev 191/1087922= 0 fsid 14b fileid 29fb0c a/m/ctime 1122938463.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.260459 IP (tos 0x0, ttl 64, id 41080, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404039 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751244 003f 08:21:03.260635 IP (tos 0x0, ttl 64, id 43645, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404039:= reply ok 120 access attr: REG 444 ids 0/0 sz 4196 nlink 1 rdev 191/1087922= 0 fsid 14b fileid 29fb0c a/m/ctime 1122938463.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.260985 IP (tos 0x0, ttl 64, id 41081, offset 0, flags [none], pro= to: UDP (17), length: 144) 211.43.211.137.1282404040 > 211.43.211.135.2049:= 116 lookup fh 1005,223386/2737632 "distinfo,v" 08:21:03.261250 IP (tos 0x0, ttl 64, id 43646, offset 0, flags [none], pro= to: UDP (17), length: 264) 211.43.211.135.2049 > 211.43.211.137.1282404040:= reply ok 236 lookup fh 1005,223386/2751246 REG 444 ids 0/0 sz 1329 nlink 1= rdev 174/10879206 fsid 14b fileid 29fb0e a/m/ctime 1122919337.000000 11124= 30346.000000 1112245585.000000 post dattr: DIR 755 ids 0/0 sz 512 nlink 4 r= dev 172/10879120 fsid 14b fileid 29c5e0 a/m/ctime 1122938463.000000 1112245= 585.000000 1112245585.000000 08:21:03.261342 IP (tos 0x0, ttl 64, id 41082, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404041 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751246 003f 08:21:03.261510 IP (tos 0x0, ttl 64, id 43647, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404041:= reply ok 120 access attr: REG 444 ids 0/0 sz 1329 nlink 1 rdev 174/1087920= 6 fsid 14b fileid 29fb0e a/m/ctime 1122919337.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.261745 IP (tos 0x0, ttl 64, id 41083, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404042 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751246 003f 08:21:03.261889 IP (tos 0x0, ttl 64, id 43648, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404042:= reply ok 120 access attr: REG 444 ids 0/0 sz 1329 nlink 1 rdev 174/1087920= 6 fsid 14b fileid 29fb0e a/m/ctime 1122919337.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.262055 IP (tos 0x0, ttl 64, id 41085, offset 0, flags [none], pro= to: UDP (17), length: 140) 211.43.211.137.1282404043 > 211.43.211.135.2049:= 112 read fh 1005,223386/2751246 4096 bytes @ 0 08:21:03.262620 IP (tos 0x0, ttl 64, id 43649, offset 0, flags [none], pro= to: UDP (17), length: 1488) 211.43.211.135.2049 > 211.43.211.137.1282404043= : reply ok 1460 read REG 444 ids 0/0 sz 1329 nlink 1 rdev 174/10879206 fsid= 14b fileid 29fb0e a/m/ctime 1122938463.000000 1112430346.000000 1112245585= .000000 1329 bytes EOF 08:21:03.263025 IP (tos 0x0, ttl 64, id 41096, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404044 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751246 003f 08:21:03.263243 IP (tos 0x0, ttl 64, id 43655, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404044:= reply ok 120 access attr: REG 444 ids 0/0 sz 1329 nlink 1 rdev 174/1087920= 6 fsid 14b fileid 29fb0e a/m/ctime 1122938463.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.263311 IP (tos 0x0, ttl 64, id 41100, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404045 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751246 003f 08:21:03.263518 IP (tos 0x0, ttl 64, id 43658, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404045:= reply ok 120 access attr: REG 444 ids 0/0 sz 1329 nlink 1 rdev 174/1087920= 6 fsid 14b fileid 29fb0e a/m/ctime 1122938463.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.263801 IP (tos 0x0, ttl 64, id 41106, offset 0, flags [none], pro= to: UDP (17), length: 144) 211.43.211.137.1282404046 > 211.43.211.135.2049:= 116 lookup fh 1005,223386/2737632 "pkg-descr,v" 08:21:03.264117 IP (tos 0x0, ttl 64, id 43661, offset 0, flags [none], pro= to: UDP (17), length: 264) 211.43.211.135.2049 > 211.43.211.137.1282404046:= reply ok 236 lookup fh 1005,223386/2751247 REG 444 ids 0/0 sz 1534 nlink 1= rdev 174/10879214 fsid 14b fileid 29fb0f a/m/ctime 1122919337.000000 11124= 30346.000000 1112245585.000000 post dattr: DIR 755 ids 0/0 sz 512 nlink 4 r= dev 172/10879120 fsid 14b fileid 29c5e0 a/m/ctime 1122938463.000000 1112245= 585.000000 1112245585.000000 08:21:03.264192 IP (tos 0x0, ttl 64, id 41112, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404047 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751247 003f 08:21:03.264399 IP (tos 0x0, ttl 64, id 43665, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404047:= reply ok 120 access attr: REG 444 ids 0/0 sz 1534 nlink 1 rdev 174/1087921= 4 fsid 14b fileid 29fb0f a/m/ctime 1122919337.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.264540 IP (tos 0x0, ttl 64, id 41117, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404048 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751247 003f 08:21:03.264763 IP (tos 0x0, ttl 64, id 43668, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404048:= reply ok 120 access attr: REG 444 ids 0/0 sz 1534 nlink 1 rdev 174/1087921= 4 fsid 14b fileid 29fb0f a/m/ctime 1122919337.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.264901 IP (tos 0x0, ttl 64, id 41122, offset 0, flags [none], pro= to: UDP (17), length: 140) 211.43.211.137.1282404049 > 211.43.211.135.2049:= 112 read fh 1005,223386/2751247 4096 bytes @ 0 08:21:03.265492 IP (tos 0x0, ttl 64, id 43671, offset 0, flags [+], proto:= UDP (17), length: 1500) 211.43.211.135.2049 > 211.43.211.137.1282404049: r= eply ok 1472 read REG 444 ids 0/0 sz 1534 nlink 1 rdev 174/10879214 fsid 14= b fileid 29fb0f a/m/ctime 1122938463.000000 1112430346.000000 1112245585.00= 0000 1534 bytes EOF 08:21:03.265786 IP (tos 0x0, ttl 64, id 41133, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404050 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751247 003f 08:21:03.265993 IP (tos 0x0, ttl 64, id 43677, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404050:= reply ok 120 access attr: REG 444 ids 0/0 sz 1534 nlink 1 rdev 174/1087921= 4 fsid 14b fileid 29fb0f a/m/ctime 1122938463.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.266046 IP (tos 0x0, ttl 64, id 41137, offset 0, flags [none], pro= to: UDP (17), length: 132) 211.43.211.137.1282404051 > 211.43.211.135.2049:= 104 access fh 1005,223386/2751247 003f 08:21:03.266366 IP (tos 0x0, ttl 64, id 43679, offset 0, flags [none], pro= to: UDP (17), length: 148) 211.43.211.135.2049 > 211.43.211.137.1282404051:= reply ok 120 access attr: REG 444 ids 0/0 sz 1534 nlink 1 rdev 174/1087921= 4 fsid 14b fileid 29fb0f a/m/ctime 1122938463.000000 1112430346.000000 1112= 245585.000000 c 0021 08:21:03.266780 IP (tos 0x0, ttl 64, id 41147, offset 0, flags [none], pro= to: UDP (17), length: 144) 211.43.211.137.1282404052 > 211.43.211.135.2049:= 116 lookup fh 1005,223386/2737632 "pkg-plist,v" 08:21:03.316402 IP (tos 0x0, ttl 64, id 41173, offset 0, flags [none], pro= to: UDP (17), length: 144) 211.43.211.137.1282404052 > 211.43.211.135.2049:= 116 lookup fh 1005,223386/2737632 "pkg-plist,v" [...client keeps re-sending...] --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC7rCYWry0BWjoQKURApZJAKCEf77k/PcnbpyIcK0TMaJ4+ktxvgCg2e++ fDLzLfXwSLMbRFJb5LjvNy8= =gb/c -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 01:35:32 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C0A816A41F; Tue, 2 Aug 2005 01:35:32 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2036243D48; Tue, 2 Aug 2005 01:35:31 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9p2/8.12.9) with ESMTP id j721ZVYk035932; Mon, 1 Aug 2005 18:35:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j721ZVpf035931; Mon, 1 Aug 2005 18:35:31 -0700 (PDT) (envelope-from dillon) Date: Mon, 1 Aug 2005 18:35:31 -0700 (PDT) From: Matthew Dillon Message-Id: <200508020135.j721ZVpf035931@apollo.backplane.com> To: Igor Shmukler References: <6533c1c9050721121030016b7d@mail.gmail.com> <200507211926.j6LJQ55D071115@apollo.backplane.com> <6533c1c905080111026f1f07ca@mail.gmail.com> Cc: hackers@freebsd.org, fs@freebsd.org Subject: Re: per file lock list X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 01:35:32 -0000 : :Matt, : :Thank you very much for response. This is a general solution, but it :not sufficient for our needs. I guess I should have been more clear :while explaining what we need. : :We want list of these locks for a group of processes. : :We made an implementation based on your suggestion, but there is one problem... : :Unfortunately this method does not return all shared locks for a :range. For example, if several processes have placed a shared lock on :a :range [1000 - 2000], F_GETLK returns a flock structure where l_pid field :contains a pid of process that takes the lock first. While, we want :to know all processes that takes this lock. Is there any way to retrieve :such information without using of internal kernel structures (inode :information)? : :Thank you in advance, : :igor I'm pretty sure there is no way to get a list of all shared users of a particular lock range short of going through kmem. You would need to program a new fcntl feature to get access to all the related locks. If you need the information just for debugging purposes then scanning the list via kmem might suffice, but it obviously isn't the best solution due to races. What I would recommend is that you create a new fcntl, say call it F_GETLKM, and hand it an extended flock structure which contains additional information...an index and a chaining field that the kernel can use to safely sequence through all related locks. That would allow the kernel to detect races with other processes changing the locking state at the same time. -Matt From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 15:27:12 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E047416A41F for ; Tue, 2 Aug 2005 15:27:12 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from moe.cs.uoguelph.ca (moe.cs.uoguelph.ca [131.104.96.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B20A43D76 for ; Tue, 2 Aug 2005 15:27:07 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from snowhite.cis.uoguelph.ca (snowhite.cis.uoguelph.ca [131.104.48.1]) by moe.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id j72FR6w9014957; Tue, 2 Aug 2005 11:27:06 -0400 Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id LAA45116; Tue, 2 Aug 2005 11:27:35 -0400 (EDT) Date: Tue, 2 Aug 2005 11:27:35 -0400 (EDT) From: rick@snowhite.cis.uoguelph.ca Message-Id: <200508021527.LAA45116@snowhite.cis.uoguelph.ca> To: kris@obsecurity.org X-Scanned-By: MIMEDefang 2.44 Cc: fs@freebsd.org, openbsd-nfsv4@sfobug.org Subject: Re: Re: FreeBSD6.0-BETA1 panics X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 15:27:13 -0000 > I suspect the server is returning bogus data, perhaps because of the > locking problems. My server doesn't support the lockd/statd protocol, so v3 mounts won't have any advisory locking support. Is that likely to be the cause of this? (I don't know anything about the inner workings of cvs.) > OK, I triggered another deadlock while running a simultaneous cvs > checkout on the server (via ufs) and over nfs3 from a remote machine. Ok, thanks for the info. I'll try and figure this one out. (Given your original panic, I assume you're running a kernel with DEBUG_LOCKS and DEBUG_VFS_LOCKS options? That would have caught the obvious "forgot to unlock the vnode" type problems, which would suggest a race between the local ufs syscall and newnfsd for vnode locking. Could be a fun one to find:-) Thanks for the debug info, rick From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 15:59:47 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3304516A41F for ; Tue, 2 Aug 2005 15:59:47 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAB5143D45 for ; Tue, 2 Aug 2005 15:59:46 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j72FxjNV004316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2005 11:59:45 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j72Fxi6P011271; Tue, 2 Aug 2005 11:59:45 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 63B00513BD; Tue, 2 Aug 2005 11:59:36 -0400 (EDT) Date: Tue, 2 Aug 2005 11:59:36 -0400 From: Kris Kennaway To: rick@snowhite.cis.uoguelph.ca Message-ID: <20050802155936.GA74261@xor.obsecurity.org> References: <200508021527.LAA45116@snowhite.cis.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <200508021527.LAA45116@snowhite.cis.uoguelph.ca> User-Agent: Mutt/1.4.2.1i Cc: openbsd-nfsv4@sfobug.org, fs@freebsd.org, kris@obsecurity.org Subject: Re: Re: FreeBSD6.0-BETA1 panics X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 15:59:47 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 11:27:35AM -0400, rick@snowhite.cis.uoguelph.ca wro= te: > > I suspect the server is returning bogus data, perhaps because of the > > locking problems. >=20 > My server doesn't support the lockd/statd protocol, so v3 mounts won't > have any advisory locking support. Is that likely to be the cause of this? > (I don't know anything about the inner workings of cvs.) I meant vnode locking in the kernel (i.e. race between the two nfsd processes reading files on the server). Everything is read-only here (and static on the server), so there is no write collision from the client. > > OK, I triggered another deadlock while running a simultaneous cvs > > checkout on the server (via ufs) and over nfs3 from a remote machine. >=20 > Ok, thanks for the info. I'll try and figure this one out. > (Given your original panic, I assume you're running a kernel with > DEBUG_LOCKS and DEBUG_VFS_LOCKS options? That would have caught the > obvious "forgot to unlock the vnode" type problems, which would suggest > a race between the local ufs syscall and newnfsd for vnode locking. > Could be a fun one to find:-) Only DEBUG_LOCKS, I think..I'll add the other. Kris --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC75hoWry0BWjoQKURAh1yAKDKldKhVLBg74bJgIF+4fyKIvJaowCgq5Ok dees2Pb3MoVJJ4XBbQu54ss= =Tk+3 -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 16:14:34 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E35E416A41F for ; Tue, 2 Aug 2005 16:14:34 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C75A43D48 for ; Tue, 2 Aug 2005 16:14:34 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j72GEXNV006328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2005 12:14:33 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j72GEX6P012025; Tue, 2 Aug 2005 12:14:33 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A094B512BD; Tue, 2 Aug 2005 12:14:24 -0400 (EDT) Date: Tue, 2 Aug 2005 12:14:24 -0400 From: Kris Kennaway To: Kris Kennaway Message-ID: <20050802161424.GA90200@xor.obsecurity.org> References: <200508021527.LAA45116@snowhite.cis.uoguelph.ca> <20050802155936.GA74261@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <20050802155936.GA74261@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: openbsd-nfsv4@sfobug.org, fs@freebsd.org, rick@snowhite.cis.uoguelph.ca Subject: Re: Re: FreeBSD6.0-BETA1 panics X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 16:14:35 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 11:59:36AM -0400, Kris Kennaway wrote: > On Tue, Aug 02, 2005 at 11:27:35AM -0400, rick@snowhite.cis.uoguelph.ca w= rote: > > > I suspect the server is returning bogus data, perhaps because of the > > > locking problems. > >=20 > > My server doesn't support the lockd/statd protocol, so v3 mounts won't > > have any advisory locking support. Is that likely to be the cause of th= is? > > (I don't know anything about the inner workings of cvs.) >=20 > I meant vnode locking in the kernel (i.e. race between the two nfsd > processes reading files on the server). Everything is read-only here > (and static on the server), so there is no write collision from the > client. >=20 > > > OK, I triggered another deadlock while running a simultaneous cvs > > > checkout on the server (via ufs) and over nfs3 from a remote machine. > >=20 > > Ok, thanks for the info. I'll try and figure this one out. > > (Given your original panic, I assume you're running a kernel with > > DEBUG_LOCKS and DEBUG_VFS_LOCKS options? That would have caught the > > obvious "forgot to unlock the vnode" type problems, which would suggest > > a race between the local ufs syscall and newnfsd for vnode locking. > > Could be a fun one to find:-) >=20 > Only DEBUG_LOCKS, I think..I'll add the other. Didn't help. Running two cvs updates over NFS and one locally over ufs (all against the same repo) again caused a deadlock in a few seconds: 721 c5aedc48 0 718 721 0004002 [SLPQ ufs 0xc799a528][SLP] cvs 703 c5d4a000 0 702 702 0000000 [SLPQ ufs 0xc797b18c][SLP] newnfsd Client and server are SMP machines, btw. db> show lockedvnods Locked vnodes 0xc797b134: tag ufs, type VDIR usecount 3, writecount 0, refcount 6 mountedhere 0 flags () v_object 0xc799118c ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc5ae5480 (pid 721) with 1 pe= nding ino 259303, on dev da0s1e 0xc799a4d0: tag ufs, type VREG usecount 2, writecount 0, refcount 2 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc5b0e000 (pid 703) with 1 pe= nding ino 265591, on dev da0s1e db> wh 721 Tracing pid 721 tid 100195 td 0xc5ae5480 sched_switch(c5ae5480,0,1,11e,4418d673) at sched_switch+0x18f mi_switch(1,0,c0703742,1a3,0) at mi_switch+0x2bf sleepq_switch(c799a528,c06ffec7,18a,0,f7c7196c) at sleepq_switch+0x135 sleepq_wait(c799a528,0,c0701247,da,0) at sleepq_wait+0x42 msleep(c799a528,c076163c,50,c0706087,0) at msleep+0x374 acquire(f7c719c8,40,60000,b5,c5ae5480) at acquire+0x88 debuglockmgr(c799a528,2002,c799a568,c5ae5480,c070775e) at debuglockmgr+0x4af vop_stdlock(f7c71a54,0,0,c074bca0,f7c71a54) at vop_stdlock+0x4e VOP_LOCK_APV(c074c3a0,f7c71a54,f7c71a2c,c06d797b,f7c71a54) at VOP_LOCK_APV+= 0xa6 ffs_lock(f7c71a54,0,f7c71a3c,2002,c799a4d0) at ffs_lock+0x19 VOP_LOCK_APV(c074bca0,f7c71a54,c07615ac,1,c06ffec7) at VOP_LOCK_APV+0xa6 debug_vn_lock(c799a4d0,2002,c5ae5480,c0708045,765) at debug_vn_lock+0xe5 vget(c799a4d0,2002,c5ae5480,1ca,0) at vget+0xc7 cache_lookup(c797b134,f7c71c74,f7c71c88,c5ae5480,c610e100) at cache_lookup+= 0x3d0 vfs_cache_lookup(f7c71bb0,f7c71bb0,0,c797b134,0) at vfs_cache_lookup+0xa4 VOP_LOOKUP_APV(c074bca0,f7c71bb0,f7c71b9c,c5ae5480,17c) at VOP_LOOKUP_APV+0= xa6 lookup(f7c71c60,0,c0707948,b4,c06ffec7) at lookup+0x484 namei(f7c71c60,c07617c8,0,c0701108,c610e100) at namei+0x40a kern_access(c5ae5480,80cd200,0,4,f7c71d30) at kern_access+0x72 access(c5ae5480,f7c71d04,8,421,2) at access+0x29 syscall(80a003b,80d003b,bfbf003b,80cd200,80cd180) at syscall+0x295 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (33, FreeBSD ELF32, access), eip =3D 0x28309d83, esp =3D 0xbfbf= de6c, ebp =3D 0xbfbfde78 --- db> wh 703 Tracing pid 703 tid 100215 td 0xc5b0e000 sched_switch(c5b0e000,0,1,11e,1506f98b) at sched_switch+0x18f mi_switch(1,0,c0703742,1a3,1) at mi_switch+0x2bf sleepq_switch(c797b18c,c06ffec7,18a,1,f7cb18f0) at sleepq_switch+0x135 sleepq_wait(c797b18c,0,c0701247,da,0) at sleepq_wait+0x42 msleep(c797b18c,c07615ac,50,c0706087,0) at msleep+0x374 acquire(f7cb194c,40,60000,b5,c5b0e000) at acquire+0x88 debuglockmgr(c797b18c,3002,c797b1cc,c5b0e000,c070775e) at debuglockmgr+0x4af vop_stdlock(f7cb19d8,c797b134,c07615ac,c074bca0,f7cb19d8) at vop_stdlock+0x= 4e VOP_LOCK_APV(c074c3a0,f7cb19d8,f7cb19b0,c06d797b,f7cb19d8) at VOP_LOCK_APV+= 0xa6 ffs_lock(f7cb19d8,0,c5b0e000,1002,c797b134) at ffs_lock+0x19 VOP_LOCK_APV(c074bca0,f7cb19d8,c0708ba1,31f,c5b0e000) at VOP_LOCK_APV+0xa6 debug_vn_lock(c797b134,1002,c5b0e000,c070f6a6,48d) at debug_vn_lock+0xe5 nfsrvn_getattr(c797b134,f7cb1a9c,c5d47580,c5b0e000,180) at nfsrvn_getattr+0= x6b nfsrvd_lookup(c5d47500,c5d46600,c797b134,0,f7cb1c1c) at nfsrvd_lookup+0x133 nfsrvd_dorpc(c5d47500,c5d46600,c5b0e000,6e5,0) at nfsrvd_dorpc+0x2f3 nfsrvd_nfsd(c5b0e000,0,c070f6a6,33d,c5d4a068) at nfsrvd_nfsd+0x404 nfssvc(c5b0e000,f7cb1d04,8,bfbff000,2) at nfssvc+0x3a8 syscall(3b,3b,3b,2804f40b,bfbfe884) at syscall+0x295 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (155, FreeBSD ELF32, nfssvc), eip =3D 0x280ba523, esp =3D 0xbfb= fe64c, ebp =3D 0xbfbfe848 --- db> --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC75vgWry0BWjoQKURAjsZAJ9ucFoYX2HykXrSle81o5qcgrW6fQCg7GF9 LQWMjKNeZZJ7FvAPfwsXq0I= =8cQc -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 16:50:15 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DCB316A41F for ; Tue, 2 Aug 2005 16:50:15 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from mailhub.cs.uoguelph.ca (mailhub.cs.uoguelph.ca [131.104.96.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F35D43D46 for ; Tue, 2 Aug 2005 16:50:14 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from snowhite.cis.uoguelph.ca (snowhite.cis.uoguelph.ca [131.104.48.1]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id j72GoDg8006585; Tue, 2 Aug 2005 12:50:13 -0400 Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id MAA45945; Tue, 2 Aug 2005 12:50:42 -0400 (EDT) Date: Tue, 2 Aug 2005 12:50:42 -0400 (EDT) From: rick@snowhite.cis.uoguelph.ca Message-Id: <200508021650.MAA45945@snowhite.cis.uoguelph.ca> To: kris@obsecurity.org X-Scanned-By: MIMEDefang 2.44 Cc: fs@freebsd.org, openbsd-nfsv4@sfobugs.org Subject: Re: FreeBSD6.0-BETA1 panics X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 16:50:15 -0000 > Didn't help. Running two cvs updates over NFS and one locally over > ufs (all against the same repo) again caused a deadlock in a few > seconds: [good diagnostic stuff snipped] Ok, the race is obvious (although the fix not quite so:-). It is specific to the FreeBSD port. Most of my development has been done under OpenBSD and it doesn't require the vnode to be locked for a VOP_GETATTR(). To "fix" this for FreeBSD, I put a little glue routine called nfsrvn_getattr() in that locks the vnode before the VOP_GETATTR() call. Unfortunately this caused the race to hit (and probably several others at other nfsrvn_getattr() calls). I think the fix is probably to move the call down until after the vnode that was looked up has been unlocked, but it will take a little time. For the OpenBSDers: This race won't be a problem in OpenBSD3.7. Thanks yet again for the testing and I'll let you know when I have something for you to try, rick From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 22:21:10 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30E5816A420 for ; Tue, 2 Aug 2005 22:21:10 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from moe.cs.uoguelph.ca (moe.cs.uoguelph.ca [131.104.96.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id BED0843D58 for ; Tue, 2 Aug 2005 22:21:09 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from snowhite.cis.uoguelph.ca (snowhite.cis.uoguelph.ca [131.104.48.1]) by moe.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id j72ML8GM000703; Tue, 2 Aug 2005 18:21:08 -0400 Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id SAA49377; Tue, 2 Aug 2005 18:21:37 -0400 (EDT) Date: Tue, 2 Aug 2005 18:21:37 -0400 (EDT) From: rick@snowhite.cis.uoguelph.ca Message-Id: <200508022221.SAA49377@snowhite.cis.uoguelph.ca> To: kris@obsecurity.org X-Scanned-By: MIMEDefang 2.44 Cc: fs@freebsd.org, openbsd-nfsv4@sfobug.org Subject: Re: Re: FreeBSD6.0-BETA1 panics X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 22:21:10 -0000 I've put a new sys/newnfs kernel subtree up, that I think might be fixed for the deadlock race. (It also has all the functions ANSI'fied, etc.) It is ftp://ftp.cis.uoguelph.ca/pub/nfsv4/nfsv4-newnfs-FreeBSD6.0-BETA1.tar.gz. Hope it works better for you, rick From owner-freebsd-fs@FreeBSD.ORG Tue Aug 2 23:52:35 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EF7816A420 for ; Tue, 2 Aug 2005 23:52:35 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6B8943D45 for ; Tue, 2 Aug 2005 23:52:34 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j72NqXNV020568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2005 19:52:33 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j72NqW6P009179; Tue, 2 Aug 2005 19:52:33 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 31CA4512BD; Tue, 2 Aug 2005 19:52:24 -0400 (EDT) Date: Tue, 2 Aug 2005 19:52:24 -0400 From: Kris Kennaway To: rick@snowhite.cis.uoguelph.ca Message-ID: <20050802235223.GA5740@xor.obsecurity.org> References: <200508022221.SAA49377@snowhite.cis.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <200508022221.SAA49377@snowhite.cis.uoguelph.ca> User-Agent: Mutt/1.4.2.1i Cc: openbsd-nfsv4@sfobug.org, fs@freebsd.org, kris@obsecurity.org Subject: Re: Re: FreeBSD6.0-BETA1 panics X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 23:52:35 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 02, 2005 at 06:21:37PM -0400, rick@snowhite.cis.uoguelph.ca wro= te: > I've put a new sys/newnfs kernel subtree up, that I think might be fixed > for the deadlock race. (It also has all the functions ANSI'fied, etc.) >=20 > It is ftp://ftp.cis.uoguelph.ca/pub/nfsv4/nfsv4-newnfs-FreeBSD6.0-BETA1.t= ar.gz. >=20 > Hope it works better for you, rick OK, it's now survived several parallel cvs updates in a row, so things are looking better! Kris --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC8Ac3Wry0BWjoQKURAr8JAJ48wdg3YBjcmf1mPq9iKbY4Az0ZKgCgkJvo Qnw+hDWRdp3zL8URw00QUPM= =x2Lp -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-freebsd-fs@FreeBSD.ORG Wed Aug 3 15:03:26 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6777716A421; Wed, 3 Aug 2005 15:03:26 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0683243D46; Wed, 3 Aug 2005 15:03:26 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 38540A24725; Wed, 3 Aug 2005 12:03:25 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 84325-08; Wed, 3 Aug 2005 15:03:25 +0000 (GMT) Received: from ganymede.hub.org (blk-224-176-51.eastlink.ca [24.224.176.51]) by hub.org (Postfix) with ESMTP id A8102A2471D; Wed, 3 Aug 2005 12:03:24 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 2B3F749943; Wed, 3 Aug 2005 12:03:23 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 2A8174993B; Wed, 3 Aug 2005 12:03:23 -0300 (ADT) Date: Wed, 3 Aug 2005 12:03:23 -0300 (ADT) From: "Marc G. Fournier" To: fs@freebsd.org Message-ID: <20050803115513.R974@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Cc: stable@freebsd.org Subject: System hangs with 6.0-BETA1 ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 15:03:26 -0000 I posted a note to GNaTs about this yesterday, but ... There seems to be a reproducable 'system hang' related to, what I think, the unionfs code ... In the first 'test case' that I've been able to easily reproduce with, the problem seems to manifest itself when I try and use unionfs to mount /usr onto a directory hierarchy for use within a jail ... that one is easy to reproduce, since I Just need to start the jail and it hangs just as sendmail (postfix) starts ... I can break down to DDB, at this point, which is what I put in my report (kern/84498) ... The second one happened this morning ... I had mount_unionfs'd a file system, to play around a bit, but didn't try to start jail ... I forgot that I had left the mount there (had set it up last night), and by this morning, the machine was locked up solid ... I have a serial console in place, but no matter what I tried, I couldn't get it to break to DDB ... I don't know what else, beyond what I included in my bug report, I can provide, but since this is *really* easy to reproduce, and I am already setup for a serial console, if someone can provide some direction on what else I can provide in the way of information, please let me know ... Thanks ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-fs@FreeBSD.ORG Wed Aug 3 19:57:16 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8679F16A41F; Wed, 3 Aug 2005 19:57:16 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id F12DC43D46; Wed, 3 Aug 2005 19:57:15 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id B5BC7A24C74; Wed, 3 Aug 2005 16:57:12 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 76107-10; Wed, 3 Aug 2005 19:57:12 +0000 (GMT) Received: from ganymede.hub.org (blk-224-176-51.eastlink.ca [24.224.176.51]) by hub.org (Postfix) with ESMTP id 3961DA24C72; Wed, 3 Aug 2005 16:57:12 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 5E1653C8B5; Wed, 3 Aug 2005 16:57:15 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 597183572C; Wed, 3 Aug 2005 16:57:15 -0300 (ADT) Date: Wed, 3 Aug 2005 16:57:15 -0300 (ADT) From: "Marc G. Fournier" To: Robert Watson In-Reply-To: <20050729092647.Q74149@fledge.watson.org> Message-ID: <20050803165145.L974@ganymede.hub.org> References: <20050728231728.E968@ganymede.hub.org> <20050729001252.N1194@ganymede.hub.org> <20050729092647.Q74149@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Cc: freebsd-fs@freebsd.org, jeff@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Consistent file system hang with RELENG_6 of today ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 19:57:16 -0000 On Fri, 29 Jul 2005, Robert Watson wrote: > > On Fri, 29 Jul 2005, Marc G. Fournier wrote: > >> Now, as most of the "old timers" here know, my jail environment makes use >> of unionfs to "mount" a template layer, to share common binaries amongst >> the VMs ... >> >> I have tried two different ways of doing this, both result in the exact >> same 'file system hang' ... and I have a core of each 'method' ... >> >> The first was to use mount_devfs to, of course, mount the /dev directory >> within the jail itself ... >> >> The second, I used the same /dev that existed within the jail, based on >> bulding a jail using a 4.x system ... >> >> In both cases, the hang appears to be at the same spot, where 'sendmail' >> (in this case, the postfix port) starts up ... > > It would also be interesting to know: if you take unionfs out of the picture > (i.e., you use a regular file system for testing purposes), does the problem > go away? Just checked this, and yes, the jail starts if unionfs is not involved ... the problem is in unionfs itself :( And, there hasn't been any changes that I can see in unionfs since May 3rd ... so it seems a fairly 'long standing' bug :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 05:13:20 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C68616A41F; Thu, 4 Aug 2005 05:13:20 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DE3443D46; Thu, 4 Aug 2005 05:13:20 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id BEFB3A247B4; Thu, 4 Aug 2005 02:13:17 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 17449-10; Thu, 4 Aug 2005 05:13:17 +0000 (GMT) Received: from ganymede.hub.org (blk-224-176-51.eastlink.ca [24.224.176.51]) by hub.org (Postfix) with ESMTP id 4A08FA246CB; Thu, 4 Aug 2005 02:13:17 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id C86F53F241; Thu, 4 Aug 2005 02:13:15 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id C0D413A651; Thu, 4 Aug 2005 02:13:15 -0300 (ADT) Date: Thu, 4 Aug 2005 02:13:15 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-stable@freebsd.org Message-ID: <20050804021028.Q924@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Cc: freebsd-fs@freebsd.org Subject: more on unionfs lock up in RELENG_6 ... X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 05:13:20 -0000 Just found the vfs.uniondebug option in sysctl, so re-ran things with this enabled ... I have a log file of ~3100 lines with the output ... I enabled debugging just before hitting return to start the jail itself, and this goes until the whole thing locked up ... I'm not sure if this helps any, but the last 20 lines or so of the file are: Create 0xc4c82dd0 = 0xc4c85000 0xc3da2550 refs=3 Out 0 vpp 0xc4c82dd0/3 lower 0 upper 0 A 0xc4c85000 parentdir 0xc4c85000 result 0xc4c82aa0 flag 120c04c uerror 0 upperdvp 0xc4c85000 4/2, uppervp 0xc4c82aa0 ref=2/lck=2 B 0xc3da2550 parentdir 0xc3da2550 result 0xc4c82cc0 flag 120c04c Modify existing un 0xc3307100 vn 0xc4c82bb0 upper 0xc4c82aa0(refs 2) -> 0xc4c82aa0(refs 2) Create 0xc4c82bb0 = 0xc4c82aa0 0xc4c82cc0 refs=1 Out 0 vpp 0xc4c82bb0/1 lower 0 upper 0 union_root UPPERVP 0xc4c39220 locked = 0 Modify existing un 0xc2937a80 vn 0xc4c38770 upper 0xc4c39220(refs 11) -> 0xc4c39220(refs 11) error 0 union_root2 UPPERVP 0xc4c39220 locked = 0 A 0xc4c39220 parentdir 0xc4c39220 result 0xc381f550 flag 100404c uerror 0 upperdvp 0xc4c39220 11/2, uppervp 0xc381f550 ref=8/lck=2 B 0xc2d19220 parentdir 0xc2d19220 result 0xc33e5cc0 flag 100404c union_root UPPERVP 0xc4c39220 locked = 0 I can provide the complete file if that will be of interest ... Will append this to the GNaTS ticket as well ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 07:49:22 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 071BA16A41F for ; Thu, 4 Aug 2005 07:49:22 +0000 (GMT) (envelope-from fabietto82@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99BD343D46 for ; Thu, 4 Aug 2005 07:49:21 +0000 (GMT) (envelope-from fabietto82@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so307356rna for ; Thu, 04 Aug 2005 00:49:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Z8BjF+5ho/0HgSwSKAUCZH0GLiAVVCFr0UdWMT1yWqdr00Wh1utwfq/TmzHLt8BsTcopP1+S1l5LFy+L35eBjxhmoaVXbEw8Bg2z84U4tkdcLEPKZGbEO6KKYzXwUZ0OD4U8WHae2LX2HBwqnFbsphvrDvZv5TI6xMnXsP3MeRU= Received: by 10.38.73.29 with SMTP id v29mr728375rna; Thu, 04 Aug 2005 00:49:21 -0700 (PDT) Received: by 10.38.9.72 with HTTP; Thu, 4 Aug 2005 00:49:21 -0700 (PDT) Message-ID: <8394b317050804004965ebb255@mail.gmail.com> Date: Thu, 4 Aug 2005 09:49:21 +0200 From: Fabio Bucci To: freebsd-fs@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Invalid partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fabio Bucci List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 07:49:22 -0000 Hi, this is the first time i install FreeBSD.=20 I'm a newbie. :-) I've 2 HD, the first with 8GB and other with 40GB. I boot FreeBSD with CD installer and i created a slice on each HD. On the first disk i created the following partitions: - /var - / - /usr - swap While on the second disk i created only one partition called mounted as /di= sk1 When installation finished, i reboot my pc and return this error: Invalid partition Invalid partition No /boot/loader Where did i mistake????? Thanks to all!!! From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 12:47:18 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BFCF16A41F for ; Thu, 4 Aug 2005 12:47:18 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8E3E43D45 for ; Thu, 4 Aug 2005 12:47:17 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j74ClG89050215; Thu, 4 Aug 2005 07:47:16 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42F20E48.1050302@centtech.com> Date: Thu, 04 Aug 2005 07:47:04 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050802 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fabio Bucci References: <8394b317050804004965ebb255@mail.gmail.com> In-Reply-To: <8394b317050804004965ebb255@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Invalid partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 12:47:18 -0000 Fabio Bucci wrote: > Hi, > this is the first time i install FreeBSD. > I'm a newbie. > :-) > > I've 2 HD, the first with 8GB and other with 40GB. > I boot FreeBSD with CD installer and i created a slice on each HD. > > On the first disk i created the following partitions: > - /var > - / > - /usr > - swap > > While on the second disk i created only one partition called mounted as /disk1 > > When installation finished, i reboot my pc and return this error: > > Invalid partition > Invalid partition > No /boot/loader > > Where did i mistake????? Sounds like you didn't install a boot loader.. I think you can do that from the install cd. Boot off it, go into the partitioning area, then exit it - I think it will prompt you for MBR, boot loader, or none. Pick one of the first two.. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Sat Aug 6 04:21:17 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E43416A41F; Sat, 6 Aug 2005 04:21:17 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE90F43D48; Sat, 6 Aug 2005 04:21:16 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.25] ([192.168.42.25]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j764LFgl022380; Fri, 5 Aug 2005 23:21:15 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42F43AAD.2080208@centtech.com> Date: Fri, 05 Aug 2005 23:21:01 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050802 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Sommers References: <42E9A0E7.40703@centtech.com> <42EB9005.8080200@gamersimpact.com> In-Reply-To: <42EB9005.8080200@gamersimpact.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1003/Thu Aug 4 09:43:24 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Pointers for understanding vfs/buffer/filesystem architecture X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 04:21:17 -0000 Ryan Sommers wrote: > Eric Anderson wrote: > >> I've very interested in learning about FreeBSD's implementation of >> vfs/buffer cache/fs archicture. I've read through mckusick@'s chapter >> in the Design and Implmentation of FreeBSD book, and I've read the >> UNIX Filesystems book cover to cover. >> >> What I'd like to see/read/understand, is how FreeBSD in particular is >> put together in this regard, and then I'd like to go about writing a >> very very simple filesystem as a learning excercise. >> >> Can anyone give me some pointers? Would anyone be willing to guide me >> along in my quest by answering questions (off list if preferred, or on >> list), etc? >> >> Thanks in advance for the hints/input! >> Eric >> >> > > Best place would be the source code itself. I think the nullfs > implementation would be a good place (src/sys/fs/nullfs). I thought I > also remembered some little article on writing an FS for freebsd, > finding it is eluding me though. Thanks - I've begun tinkering with a copy of nullfs. If you can find that article, please let me know - I've looked and still cannot track it down. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Sat Aug 6 04:21:31 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 623E916A41F; Sat, 6 Aug 2005 04:21:31 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E241243D49; Sat, 6 Aug 2005 04:21:30 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.25] ([192.168.42.25]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j764Jt7h098313; Fri, 5 Aug 2005 23:20:00 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42F43A5D.8050608@centtech.com> Date: Fri, 05 Aug 2005 23:19:41 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050802 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ALeine References: <200507300642.j6U6ghCF057455@marlena.vvi.at> In-Reply-To: <200507300642.j6U6ghCF057455@marlena.vvi.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Pointers for understanding vfs/buffer/filesystem architecture X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 04:21:31 -0000 ALeine wrote: > Eric Anderson wrote: > >>I've very interested in learning about FreeBSD's implementation >>of vfs/buffer cache/fs archicture. > > > You may want to download the following graphical overview of the > UFS/FFS filesystem that was made by Poul-Henning Kamp earlier > this year, it's very useful: > > http://phk.freebsd.dk/misc/ufs.pdf > > If you want to print it out you'll need 18 sheets of paper. Oh my - that is quite impressive.. phk - thank you! I can't wait to print that out.. (I even wonder if it was generated automatically?) > You may also want to use something like doxygen (devel/doxygen in the > ports tree) to generate source code graphs and make browsing through > source code easier. Another resource that you may find helpful is > Robert Watson's FXR site: > > http://fxr.watson.org I've played with that a bit - quite useful. Thanks for the reminder of it. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Sat Aug 6 04:24:11 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF28F16A41F; Sat, 6 Aug 2005 04:24:11 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BB0D43D45; Sat, 6 Aug 2005 04:24:11 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.25] ([192.168.42.25]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j764NiSR098391; Fri, 5 Aug 2005 23:23:49 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42F43B43.9010205@centtech.com> Date: Fri, 05 Aug 2005 23:23:31 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050802 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yfyoufeng@263.net References: <42E9A0E7.40703@centtech.com> <42EB9005.8080200@gamersimpact.com> <1122889920.2885.2.camel@localhost.localdomain> In-Reply-To: <1122889920.2885.2.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Pointers for understanding vfs/buffer/filesystem architecture X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 04:24:12 -0000 yf-263 wrote: > =E5=9C=A8 2005-07-30=E5=85=AD=E7=9A=84 09:34 -0500=EF=BC=8CRyan Sommers= =E5=86=99=E9=81=93=EF=BC=9A >=20 >>Eric Anderson wrote: >> >>>I've very interested in learning about FreeBSD's implementation of=20 >>>vfs/buffer cache/fs archicture. I've read through mckusick@'s chapter= =20 >>>in the Design and Implmentation of FreeBSD book, and I've read the UNI= X=20 >>>Filesystems book cover to cover. >>> >>>What I'd like to see/read/understand, is how FreeBSD in particular is = >>>put together in this regard, and then I'd like to go about writing a=20 >>>very very simple filesystem as a learning excercise. >>> >>>Can anyone give me some pointers? Would anyone be willing to guide me= =20 >>>along in my quest by answering questions (off list if preferred, or on= =20 >>>list), etc? >>> >>>Thanks in advance for the hints/input! >>>Eric >>> >>> >> >>Best place would be the source code itself. I think the nullfs=20 >>implementation would be a good place (src/sys/fs/nullfs). I thought I=20 >>also remembered some little article on writing an FS for freebsd,=20 >>finding it is eluding me though. >=20 >=20 > I'm also doing the same work. Now I'm working on port our data access > library into the FreeBSD kernel space as a vnode hooks. Hope we can hel= p > each others :) Excellent! I'm looking forward to seeing some alpha code to play with :)= I'm still in the R&D mode myself. Eric --=20 ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------