From owner-freebsd-fs@FreeBSD.ORG Sun Jul 8 17:50:15 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4919F16A46D for ; Sun, 8 Jul 2007 17:50:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from gigi.cs.uoguelph.ca (gigi.cs.uoguelph.ca [131.104.94.210]) by mx1.freebsd.org (Postfix) with ESMTP id EC7F413C457 for ; Sun, 8 Jul 2007 17:50:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.96.170]) by gigi.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id l68HR7g7022728 for ; Sun, 8 Jul 2007 13:27:07 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id l68HUtG19482 for ; Sun, 8 Jul 2007 13:30:55 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 8 Jul 2007 13:30:55 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher To: freebsd-fs@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 131.104.94.210 Subject: NFSv4 patch for FreeBSD-current 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, 08 Jul 2007 17:50:15 -0000 Just fyi, I've put a patch up on the ftp site for FreeBSD-current. It uses newer server code intended to be more portable and only grabs Giant if the underlying local FS requires it. I believe it is SMP safe. If you are interested, it is in ftp.cis.uoguelph.ca/pub/nfsv4/FreeBSD-CURRENT. The patch is against the May 2007 snapshot kernel, but hopefully "patch" can apply it for a while. Please let me know if the patch no longer works. (This newer server code will be in the next OpenBSD patch I generate and is mostly ported to Darwin/Mac OS X.) Have fun with it, rick From owner-freebsd-fs@FreeBSD.ORG Sun Jul 8 19:02:23 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21EB016A400 for ; Sun, 8 Jul 2007 19:02:23 +0000 (UTC) (envelope-from gore_jarold@yahoo.com) Received: from web63009.mail.re1.yahoo.com (web63009.mail.re1.yahoo.com [69.147.96.220]) by mx1.freebsd.org (Postfix) with SMTP id 64B5213C447 for ; Sun, 8 Jul 2007 19:02:22 +0000 (UTC) (envelope-from gore_jarold@yahoo.com) Received: (qmail 40621 invoked by uid 60001); 8 Jul 2007 18:35:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=lJ17BHqsIB5PJp/0gCizslDkV2ue861ulitjcafSKzFfP/4KbudLYRKSIXcF/lc8HTzacmB25c0U+e/P4TbFSm9Uw8/vsOO7DwvqfYEDtWA9qqXYwugnyyhz4ptOn+YspjwrAbrb/gQTQ0OZWn/7DYCz1IZGf2++SDGc/CYxDHs=; X-YMail-OSG: R.n_qVcVM1kMH1fRTojraCvYNLGFhc7xubf.Ga6WIkQEdPUyWibPOcMyp7UFdr9v9w-- Received: from [71.63.232.32] by web63009.mail.re1.yahoo.com via HTTP; Sun, 08 Jul 2007 11:35:40 PDT Date: Sun, 8 Jul 2007 11:35:40 -0700 (PDT) From: Gore Jarold To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <727911.39831.qm@web63009.mail.re1.yahoo.com> Subject: help needed - tuning a filesystem for rm and cp ? 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, 08 Jul 2007 19:02:23 -0000 I have a filesystem that a lot of deletions and intra-filesystem copying (cp) are done. System is FreeBSD 6.2-RELEASE, i386 32-bit, SATA drives attached to twa0: <3ware 9000 series Storage Controller>. It is a 8 TB filesystem that I created with: newfs -i 32768 -U /dev/da2 I have done no further optimization to this filesystem, the kernels, or the disks, etc. I would like very much for rm and cp processes (copying files from one place to another on the same filesystem) on this filesystem to complete more quickly. Is there any kind of tuning I can do to achieve this ? If so, what expenses do I incur in other operations ? The CPU and ram on this system are both essentially at zero. The 4 GB of ram is barely used, and the 4 GB of swap has never been touched. All comments and suggestions appreciated. ____________________________________________________________________________________ Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 04:34:02 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDF0D16A47A for ; Tue, 10 Jul 2007 04:34:02 +0000 (UTC) (envelope-from gore_jarold@yahoo.com) Received: from web63003.mail.re1.yahoo.com (web63003.mail.re1.yahoo.com [69.147.96.214]) by mx1.freebsd.org (Postfix) with SMTP id 3BB0C13C448 for ; Tue, 10 Jul 2007 04:34:02 +0000 (UTC) (envelope-from gore_jarold@yahoo.com) Received: (qmail 88492 invoked by uid 60001); 10 Jul 2007 04:34:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=mwfrsSHBeuog15dOwElmp5VoapSAix5k4Amt0U3nPlLZ3LAlkF2NrvIyaaUC7N3EVLlg4k4gmFwDB5EebJ4P4TjzQIwMIhA42saHZOkrF/rKVOO00Hx0BXpvBKGOh3l7oPHjRpGXW0Pxdop3SKsxKoce5LplCBbMbmiSpXLpRFQ=; X-YMail-OSG: jfhbZhwVM1l4L09VwZ9OZYrLhlpMzpbCBQ6C64MgllIyOnrpIinnvpMImPhAL4FiPQ-- Received: from [71.63.232.32] by web63003.mail.re1.yahoo.com via HTTP; Mon, 09 Jul 2007 21:34:01 PDT Date: Mon, 9 Jul 2007 21:34:01 -0700 (PDT) From: Gore Jarold To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <423307.86822.qm@web63003.mail.re1.yahoo.com> Subject: Re: help needed - tuning a filesystem for rm and cp ? (MORE) 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, 10 Jul 2007 04:34:02 -0000 Some more information on my question... The directories on the single mount point that I am referring to are varied in depth and density - but some of them have as many as a few million inodes in them and can go 5-10 levels deep. But that is not a rule - it is a large multi-user system (think old school shell server) with hundreds of users that can populate their home directories with anything they want. The only thing I can say for sure is that I am using 2.5 TB of space (out of 8 TB) and am using 23.8 million inodes. So it's not that dense with inodes at all, but there is no telling how even a distribution that is - a cp/rm target might not be represented well by the average (ie. they might be very sparse or very dense) So again, all is well, but I have these long 'cp' and 'rm' processes that I would like to speed up, if possible. All else being equal, how do you optimize a system for copying from one place to another on the same mount point ? How do you optimize a system for fast file deletion ? Are the two mutually exclusive ? ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 08:31:50 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA5FA16A469 for ; Tue, 10 Jul 2007 08:31:50 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6377B13C4B0 for ; Tue, 10 Jul 2007 08:31:49 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I8B8L-000787-UE for freebsd-fs@freebsd.org; Tue, 10 Jul 2007 10:31:45 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Jul 2007 10:31:45 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Jul 2007 10:31:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Tue, 10 Jul 2007 10:31:38 +0200 Lines: 35 Message-ID: References: <423307.86822.qm@web63003.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9A445193D0C221B8C860A78B" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <423307.86822.qm@web63003.mail.re1.yahoo.com> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: help needed - tuning a filesystem for rm and cp ? (MORE) 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, 10 Jul 2007 08:31:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9A445193D0C221B8C860A78B Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Gore Jarold wrote: > All else being equal, how do you optimize a system for > copying from one place to another on the same mount > point ? How do you optimize a system for fast file > deletion ? Are the two mutually exclusive ? You might try increasing vfs.ufs.dirhash_maxmem if the default's too low = for you (see what "sysctl -a | grep dirhash" reports). What does iostat report during these operations? MB/s, CPU utilization?=20 What time of it's spent in SYS? --------------enig9A445193D0C221B8C860A78B 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.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGk0PqldnAQVacBcgRAgsjAKDh+xh48awT8Jy7Ex7RuKQrxTOCAgCfeKMa 8wGHThPLoplcVP/8HHPigMA= =Fd1D -----END PGP SIGNATURE----- --------------enig9A445193D0C221B8C860A78B-- From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 11:54:07 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A6FC16A468 for ; Tue, 10 Jul 2007 11:54:07 +0000 (UTC) (envelope-from aristeu.jr@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 9194513C4B9 for ; Tue, 10 Jul 2007 11:54:01 +0000 (UTC) (envelope-from aristeu.jr@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so1618041uge for ; Tue, 10 Jul 2007 04:54:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=paxlGgXnbBIFY4pPF+aEv5wCWNyLFotthF7SHBXy/bSTP+GIsZrSFR0dHlPhgUQ9u08N60XfJ+sRlprdqLPbu3WGUPy42xikR6TokxkX8TYGhFxKAM9VMw2r2MUH0GYU13Q46QGrdEMWd6zuhQ076Y7xnc6a0UrBg2whWj8R8yU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oQlPc7+qgZYY5NwOVfxV0rMqMAGLaohrZvcze/GGoYGGNOBOkDJpgW+5SsXQkfXm/qCaCRoeAHKFnI7KVenE0KnOSZF0U6TonTULn9knY4ms9RK60GC71l2/4RN+pUXtZlcddkgBZVF/Gj3W2W0KUiK5fIUmINzu0NYhg5Bcfhs= Received: by 10.82.156.12 with SMTP id d12mr9470254bue.1184068439656; Tue, 10 Jul 2007 04:53:59 -0700 (PDT) Received: by 10.82.178.15 with HTTP; Tue, 10 Jul 2007 04:53:59 -0700 (PDT) Message-ID: <2c84c1de0707100453j9570769vfd19fea05ae11f76@mail.gmail.com> Date: Tue, 10 Jul 2007 08:53:59 -0300 From: "Aristeu Gil Alves Jr" To: freebsd-fs@freebsd.org In-Reply-To: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> Subject: Re: Coda-client and kernel panic 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, 10 Jul 2007 11:54:07 -0000 2007/7/6, Aristeu Gil Alves Jr : > I'm using a 6.2-RELEASE-p4, updated with freebsd-update. Installed > coda-client-6.1.2 from ports. I'm having the same problems that were > submitted on April 2006 for 7.0-CURRENT [1]. > > Coda-server is running apparently fine (I can't test it without the clien= t). > > Is coda-client usable in ANY freebsd supported versions? > Are there any strict userlevel client available (to scape the kernel pani= c)? (...) > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=3D95891&cat=3D > It seems to be a very big lack (almost a non existence) of communication between freebsd and coda. The error reported in [1] seems to happen in every distribution, from release to stable/current, and it=B4s fixed a long time ago says the Coda Coders, from CMU [2]. Coda, at least to me, should be a very active and stable project, since it=B4s one of the few storage projects on developers page [3] (the only that is a distributed file system). Please, if one of the submmiters is reading this, please contact Jan Harkes (jaharkes at cs.cmu.edu) to solve the issue, and subscribe him to the bugtracker to create some interaction between the projects. Thanks and regards, --=20 Aristeu Gil Alves Jr [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=3D95891&cat=3D [2] http://www.coda.cs.cmu.edu/cgi-bin/gitweb.cgi?p=3Dfbsd-coda.git;a=3Dsum= mary [3] http://www.freebsd.org/projects/index.html#storage From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 12:47:05 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CC1916A468 for ; Tue, 10 Jul 2007 12:47:05 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 1008713C465 for ; Tue, 10 Jul 2007 12:47:04 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6ACl33C035297; Tue, 10 Jul 2007 07:47:03 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46937FC7.1040306@freebsd.org> Date: Tue, 10 Jul 2007 07:47:03 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Gore Jarold References: <423307.86822.qm@web63003.mail.re1.yahoo.com> In-Reply-To: <423307.86822.qm@web63003.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-fs@freebsd.org Subject: Re: help needed - tuning a filesystem for rm and cp ? (MORE) 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, 10 Jul 2007 12:47:05 -0000 Gore Jarold wrote: > Some more information on my question... > > The directories on the single mount point that I am > referring to are varied in depth and density - but > some of them have as many as a few million inodes in > them and can go 5-10 levels deep. > > But that is not a rule - it is a large multi-user > system (think old school shell server) with hundreds > of users that can populate their home directories with > anything they want. The only thing I can say for sure > is that I am using 2.5 TB of space (out of 8 TB) and > am using 23.8 million inodes. > > So it's not that dense with inodes at all, but there > is no telling how even a distribution that is - a > cp/rm target might not be represented well by the > average (ie. they might be very sparse or very dense) > > So again, all is well, but I have these long 'cp' and > 'rm' processes that I would like to speed up, if > possible. > > All else being equal, how do you optimize a system for > copying from one place to another on the same mount > point ? How do you optimize a system for fast file > deletion ? Are the two mutually exclusive ? Are you cp'ing a tree, and then deleting one of its copies? Are you running 6-STABLE or -CURRENT? (sorry if I missed that part) Eric From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 13:00:18 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B1AE16A421 for ; Tue, 10 Jul 2007 13:00:18 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.freebsd.org (Postfix) with ESMTP id 39DFD13C459 for ; Tue, 10 Jul 2007 13:00:16 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.14.1/8.13.1) with ESMTP id l6ACf61M002506; Tue, 10 Jul 2007 08:41:06 -0400 (EDT) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.14.1/8.13.1/Submit) id l6ACf1Eq002503; Tue, 10 Jul 2007 08:41:01 -0400 (EDT) (envelope-from bv) Date: Tue, 10 Jul 2007 08:40:50 -0400 From: Bill Vermillion To: Gore Jarold Message-ID: <20070710124050.GA2184@wjv.com> References: <423307.86822.qm@web63003.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423307.86822.qm@web63003.mail.re1.yahoo.com> User-Agent: Mutt/1.4.2.2i Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,SPF_HELO_PASS, SPF_PASS autolearn=unavailable version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on bilver.wjv.com Cc: freebsd-fs@freebsd.org Subject: Re: help needed - tuning a filesystem for rm and cp ? (MORE) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 13:00:18 -0000 "Ang utong ko ay sasabog sa sarap!" exclaimed Gore Jarold while reading this message on Mon, Jul 09, 2007 at 21:34 and then responded with: > > Some more information on my question... > The directories on the single mount point that I am > referring to are varied in depth and density - but > some of them have as many as a few million inodes in > them and can go 5-10 levels deep. > But that is not a rule - it is a large multi-user > system (think old school shell server) with hundreds > of users that can populate their home directories with > anything they want. The only thing I can say for sure > is that I am using 2.5 TB of space (out of 8 TB) and > am using 23.8 million inodes. > So it's not that dense with inodes at all, but there > is no telling how even a distribution that is - a > cp/rm target might not be represented well by the > average (ie. they might be very sparse or very dense) > So again, all is well, but I have these long 'cp' and > 'rm' processes that I would like to speed up, if > possible. > All else being equal, how do you optimize a system for > copying from one place to another on the same mount > point ? How do you optimize a system for fast file > deletion ? Are the two mutually exclusive ? I've not done this recently as I've not had to, but when you need to move files from one place to another >on the same filesystem< you don't have to copy them. Use cpio with the -pdlm arguments. This will make hard links from the original file locations to the new file location. Then you can just 'rm' the original directory entries and the new directory will be running just as the old one. -p is passthrough, -d makes directories as needed, -l make links but you must use the -p option, and -v is verbose. I always run this way as I like to see just exactly what is going on. The big upside of this is that you only build directories and it does NOT move the files themselves. Thus both the build new directory and remove the old directories are going to be much faster than copying files. It can be quite fast. Just checking the man pages for FreeBSD's cpio, I see the flags have greatly expanded, as I used to just use the -pdlm flags on System V.3 systems I was running. You may have to go thorugh manual carefuly to make sure of the flags. Bill -- Bill Vermillion - bv @ wjv . com From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 13:20:49 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92A0916A492 for ; Tue, 10 Jul 2007 13:20:49 +0000 (UTC) (envelope-from gore_jarold@yahoo.com) Received: from web63007.mail.re1.yahoo.com (web63007.mail.re1.yahoo.com [69.147.96.218]) by mx1.freebsd.org (Postfix) with SMTP id 4131C13C4B9 for ; Tue, 10 Jul 2007 13:20:48 +0000 (UTC) (envelope-from gore_jarold@yahoo.com) Received: (qmail 70263 invoked by uid 60001); 10 Jul 2007 13:20:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=QBva1wimUzsdFWHV+Mhr7j4zLTM4C95+t9WTRB7dJkLgiU/qSLG8vWvDQoku2AapP59KMbUcq7NhQrpeGmesdrgkRayHdcIT59zJNcrJ2L8b9/6qHODn36Rd8MNAk+Hr9JgkRBa6S3VNJwtX3AqEuiQMLyqZUEO9H3tMz2WnxeE=; X-YMail-OSG: P0ArORQVM1lpec4WxVBNWUjncjAXwwWIouP_6bDWPiULEN9nI3g1Q2p26.vZioH0u_odrhZrvYTXCOlobQXzkTB1cCPJxy_eTO9xDWPRS3eJIe4kQ0U.TCibIx8CEHes Received: from [71.63.232.32] by web63007.mail.re1.yahoo.com via HTTP; Tue, 10 Jul 2007 06:20:47 PDT Date: Tue, 10 Jul 2007 06:20:47 -0700 (PDT) From: Gore Jarold To: bv@wjv.com In-Reply-To: <20070710124050.GA2184@wjv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <774173.69403.qm@web63007.mail.re1.yahoo.com> Cc: freebsd-fs@freebsd.org Subject: Re: help needed - tuning a filesystem for rm and cp ? (MORE) 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, 10 Jul 2007 13:20:49 -0000 --- Bill Vermillion wrote: > > All else being equal, how do you optimize a system > for > > copying from one place to another on the same > mount > > point ? How do you optimize a system for fast > file > > deletion ? Are the two mutually exclusive ? > > I've not done this recently as I've not had to, but > when > you need to move files from one place to another > >on the same > filesystem< you don't have to copy them. > > Use cpio with the -pdlm arguments. This will make > hard links > from the original file locations to the new file > location. > Then you can just 'rm' the original directory > entries and the > new directory will be running just as the old one. > > -p is passthrough, -d makes directories as needed, > -l make links > but you must use the -p option, and -v is verbose. > I always > run this way as I like to see just exactly what is > going on. > > The big upside of this is that you only build > directories and > it does NOT move the files themselves. Thus both > the build new > directory and remove the old directories are going > to be much > faster than copying files. > > It can be quite fast. Just checking the man pages > for > FreeBSD's cpio, I see the flags have greatly > expanded, as I used to > just use the -pdlm flags on System V.3 systems I was > running. > You may have to go thorugh manual carefuly to make > sure of > the flags. Yes - this is exactly what I do for the copies. I already do exactly as you describe. So perhaps there is no further system tuning or optimization that can be done for my copy processes ? What about my 'rm' processes - is there any way to optimize/tune a system to do very fast file deletions ? ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 18:43:09 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33F8116A46D for ; Tue, 10 Jul 2007 18:43:09 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (DELFT.AURA.CS.CMU.EDU [128.2.206.88]) by mx1.freebsd.org (Postfix) with ESMTP id 06EE013C455 for ; Tue, 10 Jul 2007 18:43:08 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1I8K2D-0007M6-Is; Tue, 10 Jul 2007 14:02:01 -0400 From: Jan Harkes To: freebsd-fs@freebsd.org Date: Tue, 10 Jul 2007 14:01:58 -0400 Message-Id: <11840905213019-git-send-email-jaharkes@cs.cmu.edu> X-Mailer: git-send-email 1.5.2.1 In-Reply-To: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> Cc: Jan Harkes Subject: [PATCH Coda 2/5] Mount was failing because we failed to match the device operations. 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, 10 Jul 2007 18:43:09 -0000 But we don't have to, if we find the coda_mntinfo structure for this device in our linked list, we know the device is good. --- coda_vfsops.c | 12 ++++-------- 1 files changed, 4 insertions(+), 8 deletions(-) diff --git a/coda_vfsops.c b/coda_vfsops.c index 44538a2..68fdafe 100644 --- a/coda_vfsops.c +++ b/coda_vfsops.c @@ -153,19 +153,15 @@ coda_mount(struct mount *vfsp, struct thread *td) NDFREE(&ndp, NDF_ONLY_PNBUF); /* - * See if the device table matches our expectations. + * Initialize the mount record and link it to the vfs struct */ - if (dev->si_devsw->d_open != vc_nb_open) - { + mi = dev2coda_mntinfo(dev); + if (!mi) { MARK_INT_FAIL(CODA_MOUNT_STATS); + printf("Coda mount: %s is not a cfs device\n", from); return(ENXIO); } - /* - * Initialize the mount record and link it to the vfs struct - */ - mi = dev2coda_mntinfo(dev); - if (!VC_OPEN(&mi->mi_vcomm)) { MARK_INT_FAIL(CODA_MOUNT_STATS); return(ENODEV); -- 1.5.2.1 From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 18:43:09 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0A4216A400 for ; Tue, 10 Jul 2007 18:43:09 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (DELFT.AURA.CS.CMU.EDU [128.2.206.88]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF6F13C4C2 for ; Tue, 10 Jul 2007 18:43:09 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1I8K2D-0007M4-I4; Tue, 10 Jul 2007 14:02:01 -0400 From: Jan Harkes To: freebsd-fs@freebsd.org Date: Tue, 10 Jul 2007 14:01:57 -0400 Message-Id: <11840905214090-git-send-email-jaharkes@cs.cmu.edu> X-Mailer: git-send-email 1.5.2.1 In-Reply-To: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> Cc: Jan Harkes Subject: [PATCH Coda 1/5] Avoid crash when opening Coda device 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, 10 Jul 2007 18:43:09 -0000 When allocating coda_mntinfo, we need to initialize dev so that we can actually find the allocated coda_mntinfo structure later on. --- coda_fbsd.c | 5 +++-- coda_psdev.c | 12 +++++++----- 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/coda_fbsd.c b/coda_fbsd.c index 8a74ada..5a603de 100644 --- a/coda_fbsd.c +++ b/coda_fbsd.c @@ -124,6 +124,7 @@ static void coda_fbsd_clone(arg, cred, name, namelen, dev) dev_ref(*dev); mnt = malloc(sizeof(struct coda_mntinfo), M_CODA, M_WAITOK|M_ZERO); LIST_INSERT_HEAD(&coda_mnttbl, mnt, mi_list); + mnt->dev = *dev; } struct coda_mntinfo * @@ -133,8 +134,8 @@ dev2coda_mntinfo(struct cdev *dev) LIST_FOREACH(mnt, &coda_mnttbl, mi_list) { if (mnt->dev == dev) - break; + return mnt; } - return mnt; + return NULL; } diff --git a/coda_psdev.c b/coda_psdev.c index 7d35540..d5d965a 100644 --- a/coda_psdev.c +++ b/coda_psdev.c @@ -129,6 +129,8 @@ vc_nb_open(dev, flag, mode, td) coda_nc_init(); mnt = dev2coda_mntinfo(dev); + KASSERT(mnt, ("Coda: tried to open uninitialized cfs device")); + vcp = &mnt->mi_vcomm; if (VC_OPEN(vcp)) return(EBUSY); @@ -154,15 +156,15 @@ vc_nb_close (dev, flag, mode, td) register struct vcomm *vcp; register struct vmsg *vmp, *nvmp = NULL; struct coda_mntinfo *mi; - int err; + int err; ENTRY; mi = dev2coda_mntinfo(dev); - vcp = &(mi->mi_vcomm); - - if (!VC_OPEN(vcp)) - panic("vcclose: not open"); + KASSERT(mi, ("Coda: closing unknown cfs device")); + + vcp = &mi->mi_vcomm; + KASSERT(VC_OPEN(vcp), ("Coda: closing unopened cfs device")); /* prevent future operations on this vfs from succeeding by auto- * unmounting any vfs mounted via this device. This frees user or -- 1.5.2.1 From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 18:43:10 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33EE416A41F for ; Tue, 10 Jul 2007 18:43:10 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (DELFT.AURA.CS.CMU.EDU [128.2.206.88]) by mx1.freebsd.org (Postfix) with ESMTP id 12BEF13C447 for ; Tue, 10 Jul 2007 18:43:10 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1I8K2D-0007M2-Gv for freebsd-fs@freebsd.org; Tue, 10 Jul 2007 14:02:01 -0400 From: Jan Harkes To: freebsd-fs@freebsd.org Date: Tue, 10 Jul 2007 14:01:56 -0400 Message-Id: <1184090521301-git-send-email-jaharkes@cs.cmu.edu> X-Mailer: git-send-email 1.5.2.1 In-Reply-To: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> Subject: [PATCH Coda 0/5] 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, 10 Jul 2007 18:43:10 -0000 Here is my current patch series. The first three were originally developed to fix several issues in a fbsd-current checkout of Nov 7th 2006. The last two patches were added when I updated and retested against a checkout of -current, May 8th, 2007. Yesterday I updated my test system with cvsup and rebased the patches (only one minor conflict). I am still in the middle of make buildworld and that will probably take a while, but the change was pretty trivial so I expect it will work as well as when I tested on May 8th. And on the bright side, it can't do much worse compared to right now, which is to crash or panic the kernel as soon as either /dev/cfs0 is opened or the Coda filesystem is mounted. Short summary, [1/5] Avoid crash when opening Coda's control device. [2/5] mount coda failed because we failed to match on the device operations. [3/5] When opening a file in /coda ask userspace to pass an opened file descriptor instead of device/inode number pair. [4/5] insmntque panics the kernel when passed a NULL mount, so we should not pass that. [5/5] ioctls on a character device fails before it gets passed on to the file system. Change the type of the control object to a regular file. The diffs are taken from a repository that only tracks /usr/src/sys/coda, they should apply cleanly with the following command, patch -d /usr/src/sys/coda -p1 < patchN Jan From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 18:43:10 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C65FA16A421 for ; Tue, 10 Jul 2007 18:43:10 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (DELFT.AURA.CS.CMU.EDU [128.2.206.88]) by mx1.freebsd.org (Postfix) with ESMTP id 88CF413C46C for ; Tue, 10 Jul 2007 18:43:10 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1I8K2D-0007M8-JY; Tue, 10 Jul 2007 14:02:01 -0400 From: Jan Harkes To: freebsd-fs@freebsd.org Date: Tue, 10 Jul 2007 14:01:59 -0400 Message-Id: <11840905213508-git-send-email-jaharkes@cs.cmu.edu> X-Mailer: git-send-email 1.5.2.1 In-Reply-To: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> Cc: Jan Harkes Subject: [PATCH Coda 3/5] Replace CODA_OPEN with CODA_OPEN_BY_FD 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, 10 Jul 2007 18:43:10 -0000 coda_open was disabled because we can't open container files by device/inode number pair anymore. Replace the CODA_OPEN upcall with CODA_OPEN_BY_FD, where venus returns an open file descriptor for the container file. We can then grab a reference on the vnode coda_psdev.c:vc_nb_write and use this vnode for further accesses to the container file. --- cnode.h | 2 - coda.h | 2 +- coda_psdev.c | 23 +++++++++- coda_venus.c | 19 +++------ coda_venus.h | 2 +- coda_vnops.c | 137 ++++++++++----------------------------------------------- 6 files changed, 54 insertions(+), 131 deletions(-) diff --git a/cnode.h b/cnode.h index 0ab2ab9..26cbaaa 100644 --- a/cnode.h +++ b/cnode.h @@ -107,8 +107,6 @@ struct cnode { struct vattr c_vattr; /* attributes */ char *c_symlink; /* pointer to symbolic link */ u_short c_symlen; /* length of symbolic link */ - struct cdev *c_device; /* associated vnode device */ - ino_t c_inode; /* associated vnode inode */ struct cnode *c_next; /* links if on NetBSD machine */ }; #define VTOC(vp) ((struct cnode *)(vp)->v_data) diff --git a/coda.h b/coda.h index 13cae28..5bbc193 100644 --- a/coda.h +++ b/coda.h @@ -679,7 +679,7 @@ struct coda_open_by_fd_in { struct coda_open_by_fd_out { struct coda_out_hdr oh; int fd; - struct file *fh; + struct vnode *vp; }; /* coda_open_by_path: */ diff --git a/coda_psdev.c b/coda_psdev.c index d5d965a..82307c0 100644 --- a/coda_psdev.c +++ b/coda_psdev.c @@ -65,6 +65,7 @@ extern int coda_nc_initialized; /* Set if cache has been initialized */ #include #include #include +#include #include #include @@ -370,9 +371,29 @@ vc_nb_write(dev, uiop, flag) out->unique = seq; vmp->vm_outSize = buf[0]; /* Amount of data transferred? */ vmp->vm_flags |= VM_WRITE; + + error = 0; + if (opcode == CODA_OPEN_BY_FD) { + struct coda_open_by_fd_out *tmp = (struct coda_open_by_fd_out *)out; + struct file *fp; + struct vnode *vp = NULL; + + if (tmp->oh.result == 0) { + error = getvnode(uiop->uio_td->td_proc->p_fd, tmp->fd, &fp); + if (!error) { + mtx_lock(&Giant); + vp = fp->f_vnode; + VREF(vp); + fdrop(fp, uiop->uio_td); + mtx_unlock(&Giant); + } + } + tmp->vp = vp; + } + wakeup(&vmp->vm_sleep); - return(0); + return(error); } int diff --git a/coda_venus.c b/coda_venus.c index cce9f4a..5d7ad2b 100644 --- a/coda_venus.c +++ b/coda_venus.c @@ -198,30 +198,23 @@ venus_root(void *mdp, int venus_open(void *mdp, CodaFid *fid, int flag, struct ucred *cred, struct proc *p, -/*out*/ struct cdev **dev, ino_t *inode) +/*out*/ struct vnode **vp) { -#if 0 int cflag; - DECL(coda_open); /* sets Isize & Osize */ - ALLOC(coda_open); /* sets inp & outp */ + DECL(coda_open_by_fd); /* sets Isize & Osize */ + ALLOC(coda_open_by_fd); /* sets inp & outp */ /* send the open to venus. */ - INIT_IN(&inp->ih, CODA_OPEN, cred, p); + INIT_IN(&inp->ih, CODA_OPEN_BY_FD, cred, p); inp->Fid = *fid; CNV_OFLAG(cflag, flag); inp->flags = cflag; error = coda_call(mdp, Isize, &Osize, (char *)inp); - if (!error) { - *dev = findcdev(outp->dev); - *inode = outp->inode; - } + *vp = error ? NULL : outp->vp; - CODA_FREE(inp, coda_open_size); + CODA_FREE(inp, coda_open_by_fd_size); return error; -#else - return (EOPNOTSUPP); -#endif } int diff --git a/coda_venus.h b/coda_venus.h index 329ea32..8f0acb6 100644 --- a/coda_venus.h +++ b/coda_venus.h @@ -39,7 +39,7 @@ venus_root(void *mdp, int venus_open(void *mdp, CodaFid *fid, int flag, struct ucred *cred, struct proc *p, -/*out*/ struct cdev **dev, ino_t *inode); +/*out*/ struct vnode **vp); int venus_close(void *mdp, CodaFid *fid, int flag, diff --git a/coda_vnops.c b/coda_vnops.c index 7d06764..c75fbed 100644 --- a/coda_vnops.c +++ b/coda_vnops.c @@ -178,9 +178,10 @@ coda_vnodeopstats_init(void) } /* - * coda_open calls Venus to return the device, inode pair of the cache - * file holding the data. Using iget, coda_open finds the vnode of the - * cache file, and then opens it. + * coda_open calls Venus which returns an open file descriptor the cache + * file holding the data. We get the vnode while we are still in the + * context of the venus process in coda_psdev.c. This vnode is then + * passed back to the caller and opened. */ int coda_open(struct vop_open_args *ap) @@ -199,8 +200,6 @@ coda_open(struct vop_open_args *ap) /* locals */ int error; struct vnode *vp; - struct cdev *dev; - ino_t inode; MARK_ENTRY(CODA_OPEN_STATS); @@ -216,23 +215,12 @@ coda_open(struct vop_open_args *ap) return(0); } - error = venus_open(vtomi((*vpp)), &cp->c_fid, flag, cred, td->td_proc, &dev, &inode); + error = venus_open(vtomi((*vpp)), &cp->c_fid, flag, cred, td->td_proc, &vp); if (error) return (error); - if (!error) { - CODADEBUG( CODA_OPEN,myprintf(("open: dev %#lx inode %lu result %d\n", - (u_long)dev2udev(dev), (u_long)inode, - error)); ) - } - /* Translate the pair for the cache file into - an inode pointer. */ - error = coda_grab_vnode(dev, inode, &vp); - if (error) - return (error); + CODADEBUG( CODA_OPEN,myprintf(("open: vp %p result %d\n", vp, error));) - /* We get the vnode back locked. Needs unlocked */ - VOP_UNLOCK(vp, 0, td); /* Keep a reference until the close comes in. */ vref(*vpp); @@ -251,11 +239,6 @@ coda_open(struct vop_open_args *ap) cp->c_flags &= ~C_VATTR; } - /* Save the pair for the cache file to speed - up subsequent page_read's. */ - cp->c_device = dev; - cp->c_inode = inode; - /* Open the cache file. */ error = VOP_OPEN(vp, flag, cred, td, NULL); if (error) { @@ -290,28 +273,13 @@ coda_close(struct vop_close_args *ap) return(0); } - if (IS_UNMOUNTING(cp)) { - if (cp->c_ovp) { -#ifdef CODA_VERBOSE - printf("coda_close: destroying container ref %d, ufs vp %p of vp %p/cp %p\n", - vrefcnt(vp), cp->c_ovp, vp, cp); -#endif -#ifdef hmm - vgone(cp->c_ovp); -#else - VOP_CLOSE(cp->c_ovp, flag, cred, td); /* Do errors matter here? */ - vrele(cp->c_ovp); -#endif - } else { -#ifdef CODA_VERBOSE - printf("coda_close: NO container vp %p/cp %p\n", vp, cp); -#endif - } - return ENODEV; - } else { + if (cp->c_ovp) { VOP_CLOSE(cp->c_ovp, flag, cred, td); /* Do errors matter here? */ vrele(cp->c_ovp); } +#ifdef CODA_VERBOSE + else printf("coda_close: NO container vp %p/cp %p\n", vp, cp); +#endif if (--cp->c_ocount == 0) cp->c_ovp = NULL; @@ -319,8 +287,11 @@ coda_close(struct vop_close_args *ap) if (flag & FWRITE) /* file was opened for write */ --cp->c_owrite; - error = venus_close(vtomi(vp), &cp->c_fid, flag, cred, td->td_proc); - vrele(CTOV(cp)); + if (!IS_UNMOUNTING(cp)) + error = venus_close(vtomi(vp), &cp->c_fid, flag, cred, td->td_proc); + else error = ENODEV; + + vrele(vp); CODADEBUG(CODA_CLOSE, myprintf(("close: result %d\n",error)); ) return(error); @@ -353,12 +324,8 @@ coda_rdwr(struct vnode *vp, struct uio *uiop, enum uio_rw rw, int ioflag, /* locals */ struct cnode *cp = VTOC(vp); struct vnode *cfvp = cp->c_ovp; - struct proc *p = td->td_proc; - struct thread *ltd = td; - int igot_internally = 0; int opened_internally = 0; int error = 0; - int iscore = 0; MARK_ENTRY(CODA_RDWR_STATS); @@ -373,51 +340,19 @@ coda_rdwr(struct vnode *vp, struct uio *uiop, enum uio_rw rw, int ioflag, } /* - * If file is not already open this must be a page - * {read,write} request. Iget the cache file's inode - * pointer if we still have its pair. - * Otherwise, we must do an internal open to derive the - * pair. + * If file is not already open this must be a page {read,write} request + * and we should open it internally. */ if (cfvp == NULL) { - /* - * If we're dumping core, do the internal open. Otherwise - * venus won't have the correct size of the core when - * it's completely written. - */ - if (p) { - PROC_LOCK(p); - iscore = (p->p_acflag & ACORE); - PROC_UNLOCK(p); - } - else - ltd = curthread; - - if (cp->c_inode != 0 && !iscore) { - igot_internally = 1; - error = coda_grab_vnode(cp->c_device, cp->c_inode, &cfvp); - if (error) { - MARK_INT_FAIL(CODA_RDWR_STATS); - return(error); - } - /* - * We get the vnode back locked by curthread in both Mach and - * NetBSD. Needs unlocked - */ - VOP_UNLOCK(cfvp, 0, ltd); - } - else { - opened_internally = 1; - MARK_INT_GEN(CODA_OPEN_STATS); - error = VOP_OPEN(vp, (rw == UIO_READ ? FREAD : FWRITE), - cred, td, NULL); -printf("coda_rdwr: Internally Opening %p\n", vp); - if (error) { + opened_internally = 1; + MARK_INT_GEN(CODA_OPEN_STATS); + error = VOP_OPEN(vp, (rw == UIO_READ ? FREAD : FWRITE), cred, td, NULL); + printf("coda_rdwr: Internally Opening %p\n", vp); + if (error) { printf("coda_rdwr: VOP_OPEN on container failed %d\n", error); return (error); - } - cfvp = cp->c_ovp; } + cfvp = cp->c_ovp; } /* Have UFS handle the call. */ @@ -1526,7 +1461,7 @@ coda_readdir(struct vop_readdir_args *ap) opened_internally = 1; MARK_INT_GEN(CODA_OPEN_STATS); error = VOP_OPEN(vp, FREAD, cred, td, NULL); -printf("coda_readdir: Internally Opening %p\n", vp); + printf("coda_readdir: Internally Opening %p\n", vp); if (error) { printf("coda_readdir: VOP_OPEN on container failed %d\n", error); return (error); @@ -1677,30 +1612,6 @@ coda_islocked(struct vop_islocked_args *ap) return (vop_stdislocked(ap)); } -/* How one looks up a vnode given a device/inode pair: */ -int -coda_grab_vnode(struct cdev *dev, ino_t ino, struct vnode **vpp) -{ - /* This is like VFS_VGET() or igetinode()! */ - int error; - struct mount *mp; - - if (!(mp = devtomp(dev))) { - myprintf(("coda_grab_vnode: devtomp(%#lx) returns NULL\n", - (u_long)dev2udev(dev))); - return(ENXIO); - } - - /* XXX - ensure that nonzero-return means failure */ - error = VFS_VGET(mp,ino,LK_EXCLUSIVE,vpp); - if (error) { - myprintf(("coda_grab_vnode: iget/vget(%lx, %lu) returns %p, err %d\n", - (u_long)dev2udev(dev), (u_long)ino, (void *)*vpp, error)); - return(ENOENT); - } - return(0); -} - void print_vattr(struct vattr *attr) { -- 1.5.2.1 From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 18:43:11 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4511F16A469 for ; Tue, 10 Jul 2007 18:43:11 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (DELFT.AURA.CS.CMU.EDU [128.2.206.88]) by mx1.freebsd.org (Postfix) with ESMTP id 2361313C44C for ; Tue, 10 Jul 2007 18:43:11 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1I8K2D-0007MA-Ke; Tue, 10 Jul 2007 14:02:01 -0400 From: Jan Harkes To: freebsd-fs@freebsd.org Date: Tue, 10 Jul 2007 14:02:00 -0400 Message-Id: <11840905213288-git-send-email-jaharkes@cs.cmu.edu> X-Mailer: git-send-email 1.5.2.1 In-Reply-To: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> Cc: Jan Harkes Subject: [PATCH Coda 4/5] Avoid a panic in insmntque when we pass a NULL mount 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, 10 Jul 2007 18:43:11 -0000 This reenables some previously disabled code which according to the comment caused a problem during shutdown. But even that is still better than triggering a kernel panic whenever venus is started. --- coda_vfsops.c | 8 +------- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/coda_vfsops.c b/coda_vfsops.c index 68fdafe..07d0ad1 100644 --- a/coda_vfsops.c +++ b/coda_vfsops.c @@ -183,13 +183,7 @@ coda_mount(struct mount *vfsp, struct thread *td) rootvp = CTOV(cp); rootvp->v_vflag |= VV_ROOT; -/* cp = make_coda_node(&ctlfid, vfsp, VCHR); - The above code seems to cause a loop in the cnode links. - I don't totally understand when it happens, it is caught - when closing down the system. - */ - cp = make_coda_node(&ctlfid, 0, VCHR); - + cp = make_coda_node(&ctlfid, vfsp, VCHR); coda_ctlvp = CTOV(cp); /* Add vfs and rootvp to chain of vfs hanging off mntinfo */ -- 1.5.2.1 From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 18:43:11 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5FF616A46C for ; Tue, 10 Jul 2007 18:43:11 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (DELFT.AURA.CS.CMU.EDU [128.2.206.88]) by mx1.freebsd.org (Postfix) with ESMTP id B3B0613C484 for ; Tue, 10 Jul 2007 18:43:11 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1I8K2D-0007MC-Ll; Tue, 10 Jul 2007 14:02:01 -0400 From: Jan Harkes To: freebsd-fs@freebsd.org Date: Tue, 10 Jul 2007 14:02:01 -0400 Message-Id: <1184090521919-git-send-email-jaharkes@cs.cmu.edu> X-Mailer: git-send-email 1.5.2.1 In-Reply-To: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> Cc: Jan Harkes Subject: [PATCH Coda 5/5] Fix ioctls on the control vnode 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, 10 Jul 2007 18:43:11 -0000 Ioctls on a character device fail with ENOTTY. Make the control vnode a regular file so that ioctls are passed through to our kernel module. --- coda_vfsops.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/coda_vfsops.c b/coda_vfsops.c index 07d0ad1..1f8b9da 100644 --- a/coda_vfsops.c +++ b/coda_vfsops.c @@ -183,7 +183,7 @@ coda_mount(struct mount *vfsp, struct thread *td) rootvp = CTOV(cp); rootvp->v_vflag |= VV_ROOT; - cp = make_coda_node(&ctlfid, vfsp, VCHR); + cp = make_coda_node(&ctlfid, vfsp, VREG); coda_ctlvp = CTOV(cp); /* Add vfs and rootvp to chain of vfs hanging off mntinfo */ -- 1.5.2.1 From owner-freebsd-fs@FreeBSD.ORG Tue Jul 10 23:58:31 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5FEA16A46F for ; Tue, 10 Jul 2007 23:58:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4F80F13C45D for ; Tue, 10 Jul 2007 23:58:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5DFB547336; Tue, 10 Jul 2007 19:58:30 -0400 (EDT) Date: Wed, 11 Jul 2007 00:58:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Aristeu Gil Alves Jr In-Reply-To: <2c84c1de0707100453j9570769vfd19fea05ae11f76@mail.gmail.com> Message-ID: <20070711005300.V8913@fledge.watson.org> References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <2c84c1de0707100453j9570769vfd19fea05ae11f76@mail.gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1470605626-1184111910=:8913" Cc: freebsd-fs@freebsd.org Subject: Re: Coda-client and kernel panic 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, 10 Jul 2007 23:58:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1470605626-1184111910=:8913 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 10 Jul 2007, Aristeu Gil Alves Jr wrote: > 2007/7/6, Aristeu Gil Alves Jr : > >> I'm using a 6.2-RELEASE-p4, updated with freebsd-update. Installed=20 >> coda-client-6.1.2 from ports. I'm having the same problems that were=20 >> submitted on April 2006 for 7.0-CURRENT [1]. >>=20 >> Coda-server is running apparently fine (I can't test it without the=20 >> client). >>=20 >> Is coda-client usable in ANY freebsd supported versions? Are there any= =20 >> strict userlevel client available (to scape the kernel panic)? > (...) >> [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=3D95891&cat=3D > > It seems to be a very big lack (almost a non existence) of communication= =20 > between freebsd and coda. The error reported in [1] seems to happen in ev= ery=20 > distribution, from release to stable/current, and it=B4s fixed a long tim= e ago=20 > says the Coda Coders, from CMU [2]. Coda, at least to me, should be a ver= y=20 > active and stable project, since it=B4s one of the few storage projects o= n=20 > developers page [3] (the only that is a distributed file system). Please,= if=20 > one of the submmiters is reading this, please contact Jan Harkes (jaharke= s=20 > at cs.cmu.edu) to solve the issue, and subscribe him to the bugtracker to= =20 > create some interaction between the projects. The FreeBSD Project has a long history of granting commit rights to Coda=20 developers in order to allow Coda developers to maintain the in-kernel Coda= =20 module -- Bob Baron, myself, and later Shafeeq Sinnamohideen. I believe=20 Shafeeq may still be affiliated with, or at least in the general physical= =20 vicinity of, the Coda Project. I sent him e-mail in early June asking what= =20 the status of the Coda work was, and what, if anything, to do about the ker= nel=20 module--I didn't hear back. I see Jan has just submitted a number of kerne= l=20 patches and will see about getting them into the tree before the 7.0 beta= =20 series starts. There has been discussion of removing the Coda module from = the=20 kernel tree on the basis that it has been, until the last day or so,=20 effectively unmaintained for several years. However, if it's now maintaine= d,=20 then obviously that is neither necessary nor desirable. Robert N M Watson Computer Laboratory University of Cambridge --0-1470605626-1184111910=:8913-- From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 01:42:05 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59CB216A46D for ; Wed, 11 Jul 2007 01:42:05 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (DELFT.AURA.CS.CMU.EDU [128.2.206.88]) by mx1.freebsd.org (Postfix) with ESMTP id 3717F13C45B for ; Wed, 11 Jul 2007 01:42:04 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1I8RDQ-00077L-GQ for freebsd-fs@freebsd.org; Tue, 10 Jul 2007 21:42:04 -0400 Date: Tue, 10 Jul 2007 21:42:04 -0400 To: freebsd-fs@freebsd.org Message-ID: <20070711014204.GE5824@delft.aura.cs.cmu.edu> Mail-Followup-To: freebsd-fs@freebsd.org References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <2c84c1de0707100453j9570769vfd19fea05ae11f76@mail.gmail.com> <20070711005300.V8913@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711005300.V8913@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: Jan Harkes Subject: Re: Coda-client and kernel panic 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, 11 Jul 2007 01:42:05 -0000 On Wed, Jul 11, 2007 at 12:58:30AM +0100, Robert Watson wrote: > On Tue, 10 Jul 2007, Aristeu Gil Alves Jr wrote: > >2007/7/6, Aristeu Gil Alves Jr : > > > >>I'm using a 6.2-RELEASE-p4, updated with freebsd-update. Installed > >>coda-client-6.1.2 from ports. I'm having the same problems that were > >>submitted on April 2006 for 7.0-CURRENT [1]. The kernel patches I sent are part of the solution. You also need to update Coda's userspace to the latest release, 6.9.1 which is not in ports. That version adds the necessary support for the new nmount system call and it is also the version that I used when testing the kernel patches. > The FreeBSD Project has a long history of granting commit rights to Coda > developers in order to allow Coda developers to maintain the in-kernel Coda > module -- Bob Baron, myself, and later Shafeeq Sinnamohideen. I believe > Shafeeq may still be affiliated with, or at least in the general physical > vicinity of, the Coda Project. I sent him e-mail in early June asking what > the status of the Coda work was, and what, if anything, to do about the > kernel module--I didn't hear back. I see Jan has just submitted a number I bump into Shafeeq once in a while around campus, but nowadays he is pretty much in full thesis writing mode, which may explain why he has dropped off of the face of the earth. > 7.0 beta series starts. There has been discussion of removing the Coda > module from the kernel tree on the basis that it has been, until the last > day or so, effectively unmaintained for several years. However, if it's I hadn't heard those rumours, is there some other list besides freebsd-fs that I should subscribe to? Jan From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 02:12:07 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A2B716A421 for ; Wed, 11 Jul 2007 02:12:07 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id E459413C4AD for ; Wed, 11 Jul 2007 02:12:06 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6B2C56f043699 for ; Tue, 10 Jul 2007 21:12:06 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46943C70.1080500@freebsd.org> Date: Tue, 10 Jul 2007 21:12:00 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <2c84c1de0707100453j9570769vfd19fea05ae11f76@mail.gmail.com> <20070711005300.V8913@fledge.watson.org> <20070711014204.GE5824@delft.aura.cs.cmu.edu> In-Reply-To: <20070711014204.GE5824@delft.aura.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Subject: Re: Coda-client and kernel panic 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, 11 Jul 2007 02:12:07 -0000 Jan Harkes wrote: > On Wed, Jul 11, 2007 at 12:58:30AM +0100, Robert Watson wrote: >> On Tue, 10 Jul 2007, Aristeu Gil Alves Jr wrote: >>> 2007/7/6, Aristeu Gil Alves Jr : >>> >>>> I'm using a 6.2-RELEASE-p4, updated with freebsd-update. Installed >>>> coda-client-6.1.2 from ports. I'm having the same problems that were >>>> submitted on April 2006 for 7.0-CURRENT [1]. > > The kernel patches I sent are part of the solution. You also need to > update Coda's userspace to the latest release, 6.9.1 which is not in > ports. That version adds the necessary support for the new nmount system > call and it is also the version that I used when testing the kernel > patches. > >> The FreeBSD Project has a long history of granting commit rights to Coda >> developers in order to allow Coda developers to maintain the in-kernel Coda >> module -- Bob Baron, myself, and later Shafeeq Sinnamohideen. I believe >> Shafeeq may still be affiliated with, or at least in the general physical >> vicinity of, the Coda Project. I sent him e-mail in early June asking what >> the status of the Coda work was, and what, if anything, to do about the >> kernel module--I didn't hear back. I see Jan has just submitted a number > > I bump into Shafeeq once in a while around campus, but nowadays he is > pretty much in full thesis writing mode, which may explain why he has > dropped off of the face of the earth. > >> 7.0 beta series starts. There has been discussion of removing the Coda >> module from the kernel tree on the basis that it has been, until the last >> day or so, effectively unmaintained for several years. However, if it's > > I hadn't heard those rumours, is there some other list besides > freebsd-fs that I should subscribe to? Jan - I think it was on -current, and it was a brief discussion if I recall. Jan actually sent me the patches back in May, but I had some initial issues with them (from some changes in -CURRENT), and then I had two major things happen (new baby and new job at a startup) so I had *zero* time to finish looking at the patches (sorry Jan!). If it's worth anything, I can try to at least do some quick testing with it, and then I think it should be committed - at least it can't be as bad as what's in the tree already. :) Eric From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 13:26:40 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76D9916A468 for ; Wed, 11 Jul 2007 13:26:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 14D4A13C4C7 for ; Wed, 11 Jul 2007 13:26:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 16C8847341; Wed, 11 Jul 2007 09:26:39 -0400 (EDT) Date: Wed, 11 Jul 2007 14:26:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Eric Anderson In-Reply-To: <46943C70.1080500@freebsd.org> Message-ID: <20070711142332.M64621@fledge.watson.org> References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <2c84c1de0707100453j9570769vfd19fea05ae11f76@mail.gmail.com> <20070711005300.V8913@fledge.watson.org> <20070711014204.GE5824@delft.aura.cs.cmu.edu> <46943C70.1080500@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: Coda-client and kernel panic 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, 11 Jul 2007 13:26:40 -0000 On Tue, 10 Jul 2007, Eric Anderson wrote: >>> The FreeBSD Project has a long history of granting commit rights to Coda >>> developers in order to allow Coda developers to maintain the in-kernel >>> Coda module -- Bob Baron, myself, and later Shafeeq Sinnamohideen. I >>> believe Shafeeq may still be affiliated with, or at least in the general >>> physical vicinity of, the Coda Project. I sent him e-mail in early June >>> asking what the status of the Coda work was, and what, if anything, to do >>> about the kernel module--I didn't hear back. I see Jan has just submitted >>> a number >> >> I bump into Shafeeq once in a while around campus, but nowadays he is >> pretty much in full thesis writing mode, which may explain why he has >> dropped off of the face of the earth. This is good to know :-). >>> 7.0 beta series starts. There has been discussion of removing the Coda >>> module from the kernel tree on the basis that it has been, until the last >>> day or so, effectively unmaintained for several years. However, if it's >> >> I hadn't heard those rumours, is there some other list besides freebsd-fs >> that I should subscribe to? > > Jan - I think it was on -current, and it was a brief discussion if I recall. > > Jan actually sent me the patches back in May, but I had some initial issues > with them (from some changes in -CURRENT), and then I had two major things > happen (new baby and new job at a startup) so I had *zero* time to finish > looking at the patches (sorry Jan!). > > If it's worth anything, I can try to at least do some quick testing with it, > and then I think it should be committed - at least it can't be as bad as > what's in the tree already. :) Sounds good -- I installed a new VM for this purpose also last night, but as the port for Coda is still at 6.1.2 and the 6.9.1 version is required now, I haven't had a chance to put the Coda bits together yet. If you can do the testing on the patches, I can commit them after getting release engineering approval (since we're in the 7.0 freeze). It sounds like we also need to get the Coda port up-to-date, which is not something I'm set up to do. Shafeeq may still have his ports commit bit, although I think I saw word that it was being expired due to non-use, so we may need to draft someone else in. The right way forward is, if there's no convenient ports committer on hand, is to file a PR with the port update. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 14:52:10 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3656116A41F for ; Wed, 11 Jul 2007 14:52:10 +0000 (UTC) (envelope-from gore_jarold@yahoo.com) Received: from web63012.mail.re1.yahoo.com (web63012.mail.re1.yahoo.com [69.147.96.223]) by mx1.freebsd.org (Postfix) with SMTP id E3CA013C43E for ; Wed, 11 Jul 2007 14:52:09 +0000 (UTC) (envelope-from gore_jarold@yahoo.com) Received: (qmail 26579 invoked by uid 60001); 11 Jul 2007 14:52:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=pLT/dgeKM7Ns4Gxua7ojZEjET4R6QRkN1aAU4XLui4gCZhauV/c1nD6SfpELZW51htAJeP9n7JaVXmJ38UyBybQL7aAodW2UEbENKaN+Vbqhzeo9U/bEemwL0TZK791QETpXbkKr3kQn3id4b157cPmA0f0EiozAfqCYn8V3mU4=; X-YMail-OSG: 7LuVZycVM1k69FTmNmQIxnal.N9haUXzjl8z0qEOiBHGvnFlhymzVnHSEMRaexBj1qPjctYuvBJPwZL45LmMHx.6kT53U8kHlq4w4tYQDDaK06844nCX8SiMZn80_n7g Received: from [71.63.232.32] by web63012.mail.re1.yahoo.com via HTTP; Wed, 11 Jul 2007 07:52:09 PDT Date: Wed, 11 Jul 2007 07:52:09 -0700 (PDT) From: Gore Jarold To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <86847.26083.qm@web63012.mail.re1.yahoo.com> Subject: Re: help needed - tuning a filesystem for rm and cp ? (MORE) 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, 11 Jul 2007 14:52:10 -0000 > > All else being equal, how do you optimize a system for > > copying from one place to another on the same mount > > point ? How do you optimize a system for fast file > > deletion ? Are the two mutually exclusive ? > > You might try increasing vfs.ufs.dirhash_maxmem if the default's too low > for you (see what "sysctl -a | grep dirhash" reports). # sysctl -a | grep dirhash UFS dirhash 895 181K - 550269 16,32,64,128,256,512,1024,2048,4096 vfs.ufs.dirhash_minsize: 2560 vfs.ufs.dirhash_maxmem: 2097152 vfs.ufs.dirhash_mem: 2065716 vfs.ufs.dirhash_docheck: 0 Interesting at all ? Above ^^^ is the output for today, but I checked it yesterday as well and got: # sysctl -a | grep dirhash UFS dirhash 180 43K - 452370 16,32,64,128,256,512,1024,2048,4096 vfs.ufs.dirhash_minsize: 2560 vfs.ufs.dirhash_maxmem: 2097152 vfs.ufs.dirhash_mem: 860405 vfs.ufs.dirhash_docheck: 0 So do I understand this correctly that right now I am at ~550000 and yesterday I was at ~452000, but yesterday my high water mark was ~860000 and today my high water mark is 2065716 ? So it looks like I maxed it out last night ? ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 15:58:48 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 844CF16A400 for ; Wed, 11 Jul 2007 15:58:48 +0000 (UTC) (envelope-from vsjni@vax2.concordia.ca) Received: from d141-98-196.home.cgocable.net (d141-98-196.home.cgocable.net [24.141.98.196]) by mx1.freebsd.org (Postfix) with SMTP id 36FCE13C4B9 for ; Wed, 11 Jul 2007 15:58:48 +0000 (UTC) (envelope-from vsjni@vax2.concordia.ca) Received: from [60.109.233.79] (helo=duhv) by d141-98-196.home.cgocable.net with smtp (Exim 4.62 (FreeBSD)) id 1I9ýdB-0007H0-CW; Wed, 11 Jul 2007 12:01:33 -0400 Message-ID: <4694FE38.3040400@aberystwyth.com> Date: Wed, 11 Jul 2007 11:58:48 -0400 From: Payton Gwendolen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: transmit century 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, 11 Jul 2007 15:58:48 -0000 Vision Airships Global Expansion! BANGKOK, THAILAND, Jul 09, 2007 (MARKET WIRE via COMTEX) -- Vision Airships Inc. (PINKSHEETS: VPSN) -- The company wishes to announce that it has finalized arrangements for funding for its global expansion. Vision Airships is set to become a worldwide operator of blimps used for advertising around the world. As the advertising market gets more crowded in conventional mediums -- the use of alternative forms of advertising is gaining more and more traction -- this is where Vision Airships comes in and supplies the end to end solution to major advertisers worldwide with its unique form of alternative displays. The size of the market worldwide will support 24 airships which would bring in approximately $400,000,000 annually. Check out the news and get on VPSN first thing Wednesday! The introduction of technology to previously non-tech hobbies is a huge benefit. He wishes he could find a way to better organize his information, some way to sort through his constant overload of ideas. The Neo is an incredibly simple device to use, and so becomes more reliable and stable. This allows you to bring the comfort of a full-sized keyboard anywhere. pGeep is free encryption software package. Hushmail use is simple and fast. If all my books were recycled, I wouldn't be saving trees, but entire ecosystems. Some are supported by ads, or the ability to pay money for more improvements to your game character. PGP Desktop Home edition is for when you really mean business. Perfect for writers composing books, screenplays, and of course technology columns. It's a mini-keyboard for computers, cellphones and PDAs. From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 20:20:03 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E87916A469; Wed, 11 Jul 2007 20:20:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx03.syd.optusnet.com.au (fallbackmx03.syd.optusnet.com.au [211.29.133.136]) by mx1.freebsd.org (Postfix) with ESMTP id A749113C4D1; Wed, 11 Jul 2007 20:20:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx03.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l6AE8OCB008565; Wed, 11 Jul 2007 00:08:24 +1000 Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l6AE8JSj012079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 00:08:22 +1000 Date: Wed, 11 Jul 2007 00:08:19 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: fs@freebsd.org Message-ID: <20070710233455.O2101@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bugs@freebsd.org Subject: msdosfs not MPSAFE 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, 11 Jul 2007 20:20:03 -0000 msdsofs has been broken since Giant locking for file systems (or syscalls) was removed. It allows multiple threads to race accessing the shared static buffer `nambuf' and related variables. This causes remarkably few problems. One case that breaks reliably is concurrent tars or finds, especially with a small cluster size, even on a UP system. Then getdirentries() returns garbage entries and/or lookup() of correct entries can't find things. On my UP system, I think the race occurs mainly when getdirentries() blocks on i/o and a directory entry spans the block boundary. Then another getdirentries() or lookup() can run, and if it does then it will almost certainly corrupt the state for the blocked getdirentries(). On SMP systems, I think the race occurs much more often and suspect that it is more harmful. Quick fix for an old version of FreeBSD. The part in msdosfs_lookup.c has not been tested at runtime. The part in msdosfs_vnops.c may also fix bugs involving cookie handling (but not a memory leak like I first thought?). msdosfs_lookup.c is harder to fix because it has no common cleanup code. %%% Index: msdosfs_lookup.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_lookup.c,v retrieving revision 1.40 diff -u -2 -r1.40 msdosfs_lookup.c --- msdosfs_lookup.c 26 Dec 2003 17:24:37 -0000 1.40 +++ msdosfs_lookup.c 10 Jul 2007 13:33:37 -0000 @@ -78,11 +78,11 @@ * memory denode's will be in synch. */ -int -msdosfs_lookup(ap) +static int +msdosfs_lookup_locked( struct vop_cachedlookup_args /* { struct vnode *a_dvp; struct vnode **a_vpp; struct componentname *a_cnp; - } */ *ap; + } */ *ap) { struct vnode *vdp = ap->a_dvp; @@ -560,4 +561,20 @@ /* + * XXX msdosfs_lookup() is split up because unlocking Giant before all the + * returns in the original function would be too churning. + */ +int +msdosfs_lookup(ap) + struct vop_cachedlookup_args *ap; +{ + int error; + + mtx_lock(&Giant); /* XXX for exclusive access to nambuf. */ + error = msdosfs_lookup_locked(ap); + mtx_unlock(&Giant); + return (error); +} + +/* * dep - directory entry to copy into the directory * ddep - directory to add to Index: msdosfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v retrieving revision 1.147 diff -u -2 -r1.147 msdosfs_vnops.c --- msdosfs_vnops.c 4 Feb 2004 21:52:53 -0000 1.147 +++ msdosfs_vnops.c 10 Jul 2007 05:08:17 -0000 @@ -1559,4 +1592,5 @@ } + mtx_lock(&Giant); /* XXX for exclusive access to nambuf. */ mbnambuf_init(); off = offset; @@ -1575,10 +1609,13 @@ if (error) { brelse(bp); - return (error); + Debugger("used to leak cookies 1"); + break; } n = min(n, blsize - bp->b_resid); if (n == 0) { brelse(bp); - return (EIO); + error = EIO; + Debugger("used to leak cookies 2"); + break; } @@ -1687,4 +1725,6 @@ } out: + mtx_unlock(&Giant); + /* Subtract unused cookies */ if (ap->a_ncookies) %%% Please fix this better. mbnambuf_init() could return a non-static buffer that doesn't require locking. Deallocation would be painful. Note that even the details for Giant locking can't be hidden in msdosfs_conv.c like the current interfaces intend, since mbnambuf_init() is used a lot to reinitialize an in-use buffer, and there is no interface to drop usage. Bruce From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 20:52:06 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4216516A400; Wed, 11 Jul 2007 20:52:06 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3440E13C455; Wed, 11 Jul 2007 20:52:06 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id C45D01A4D80; Wed, 11 Jul 2007 13:26:40 -0700 (PDT) Date: Wed, 11 Jul 2007 13:26:40 -0700 From: Alfred Perlstein To: current@freebsd.org, fs@freebsd.org Message-ID: <20070711202640.GV45894@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: bgfsck hosed (lockups) in -current? 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, 11 Jul 2007 20:52:06 -0000 I have current as of last week. I noticed that if I needed a bgfsck on ufs when rebooting my system would lock up almost immediately. Everything would deadlock. If I rebooted single user and did a regular "fsck -y" then continued to boot, I'd be OK. Has anyone else experienced this? I'm going to update to the most recent current and get more information (which wait channels etc) but wanted to know if anyone knew about this. I recall seeing a LOT of fixes for various deadlocks in snapshots and bgfsck going in lately, but nothing that looked to me as if it'd trigger a regression. -- - Alfred Perlstein From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 21:10:07 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0ABD516A41F; Wed, 11 Jul 2007 21:10:07 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id EAE4C13C44C; Wed, 11 Jul 2007 21:10:06 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id CF5291A4DA7; Wed, 11 Jul 2007 14:10:06 -0700 (PDT) Date: Wed, 11 Jul 2007 14:10:06 -0700 From: Alfred Perlstein To: Dan Nelson Message-ID: <20070711211006.GW45894@elvis.mu.org> References: <20070711202640.GV45894@elvis.mu.org> <20070711210556.GD45534@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711210556.GD45534@dan.emsphone.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, fs@freebsd.org Subject: Re: bgfsck hosed (lockups) in -current? 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, 11 Jul 2007 21:10:07 -0000 * Dan Nelson [070711 14:06] wrote: > In the last episode (Jul 11), Alfred Perlstein said: > > I have current as of last week. > > > > I noticed that if I needed a bgfsck on ufs when rebooting my system > > would lock up almost immediately. Everything would deadlock. > > I've been suffering from trap 12's in rt_check() every day for the last > week or so (will post to the list once I get a good coredump) but > haven't had the subsequent bgfsck lock up on me yet. Interesting. It may just be heavy IO on my machine or on current in general. thank you, -Alfred From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 21:31:26 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BCB216A469 for ; Wed, 11 Jul 2007 21:31:26 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id E461313C447 for ; Wed, 11 Jul 2007 21:31:15 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.13.8) id l6BL5vbK045584; Wed, 11 Jul 2007 16:05:57 -0500 (CDT) (envelope-from dan) Date: Wed, 11 Jul 2007 16:05:56 -0500 From: Dan Nelson To: Alfred Perlstein Message-ID: <20070711210556.GD45534@dan.emsphone.com> References: <20070711202640.GV45894@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711202640.GV45894@elvis.mu.org> X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org, fs@freebsd.org Subject: Re: bgfsck hosed (lockups) in -current? 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, 11 Jul 2007 21:31:26 -0000 In the last episode (Jul 11), Alfred Perlstein said: > I have current as of last week. > > I noticed that if I needed a bgfsck on ufs when rebooting my system > would lock up almost immediately. Everything would deadlock. I've been suffering from trap 12's in rt_check() every day for the last week or so (will post to the list once I get a good coredump) but haven't had the subsequent bgfsck lock up on me yet. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 21:36:11 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DBBC16A47D for ; Wed, 11 Jul 2007 21:36:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 216C613C458 for ; Wed, 11 Jul 2007 21:36:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1720147B46; Wed, 11 Jul 2007 17:36:10 -0400 (EDT) Date: Wed, 11 Jul 2007 22:36:10 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jan Harkes In-Reply-To: <1184090521301-git-send-email-jaharkes@cs.cmu.edu> Message-ID: <20070711223527.S97304@fledge.watson.org> References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <1184090521301-git-send-email-jaharkes@cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: [PATCH Coda 0/5] 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, 11 Jul 2007 21:36:11 -0000 On Tue, 10 Jul 2007, Jan Harkes wrote: > Here is my current patch series. > > The first three were originally developed to fix several issues in a > fbsd-current checkout of Nov 7th 2006. > > The last two patches were added when I updated and retested against a > checkout of -current, May 8th, 2007. > > Yesterday I updated my test system with cvsup and rebased the patches (only > one minor conflict). I am still in the middle of make buildworld and that > will probably take a while, but the change was pretty trivial so I expect it > will work as well as when I tested on May 8th. And on the bright side, it > can't do much worse compared to right now, which is to crash or panic the > kernel as soon as either /dev/cfs0 is opened or the Coda filesystem is > mounted. I've now committed these five patches to the CVS HEAD. Let me know if there are any further patches that need committing, and if it's appropriate to merge these to the RELENG_6 branch after a suitable delay (a couple of weeks?). Robert N M Watson Computer Laboratory University of Cambridge > > Short summary, > > [1/5] Avoid crash when opening Coda's control device. > > [2/5] mount coda failed because we failed to match on the device > operations. > > [3/5] When opening a file in /coda ask userspace to pass an opened file > descriptor instead of device/inode number pair. > > [4/5] insmntque panics the kernel when passed a NULL mount, so we should > not pass that. > > [5/5] ioctls on a character device fails before it gets passed on to the > file system. Change the type of the control object to a regular file. > > The diffs are taken from a repository that only tracks /usr/src/sys/coda, > they should apply cleanly with the following command, > > patch -d /usr/src/sys/coda -p1 < patchN > > Jan > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 21:55:44 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 290B616A41F for ; Wed, 11 Jul 2007 21:55:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 03B2B13C447 for ; Wed, 11 Jul 2007 21:55:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3B1FF47CA4; Wed, 11 Jul 2007 17:37:54 -0400 (EDT) Date: Wed, 11 Jul 2007 22:37:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alfred Perlstein In-Reply-To: <20070711202640.GV45894@elvis.mu.org> Message-ID: <20070711223720.C97304@fledge.watson.org> References: <20070711202640.GV45894@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, fs@freebsd.org Subject: Re: bgfsck hosed (lockups) in -current? 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, 11 Jul 2007 21:55:44 -0000 On Wed, 11 Jul 2007, Alfred Perlstein wrote: > I have current as of last week. > > I noticed that if I needed a bgfsck on ufs when rebooting my system would > lock up almost immediately. Everything would deadlock. > > If I rebooted single user and did a regular "fsck -y" then continued to > boot, I'd be OK. > > Has anyone else experienced this? I'm going to update to the most recent > current and get more information (which wait channels etc) but wanted to > know if anyone knew about this. > > I recall seeing a LOT of fixes for various deadlocks in snapshots and bgfsck > going in lately, but nothing that looked to me as if it'd trigger a > regression. I'm not seeing this either -- have you tried running a manual fsck to see if it turns up anything deeply unsatisfying that could be causing bgfsck some bother? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 22:05:08 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E47F16A421; Wed, 11 Jul 2007 22:05:08 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4994213C4C3; Wed, 11 Jul 2007 22:05:08 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 2EB471A4DA7; Wed, 11 Jul 2007 15:05:08 -0700 (PDT) Date: Wed, 11 Jul 2007 15:05:08 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20070711220508.GY45894@elvis.mu.org> References: <20070711202640.GV45894@elvis.mu.org> <20070711223720.C97304@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711223720.C97304@fledge.watson.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, fs@freebsd.org Subject: Re: bgfsck hosed (lockups) in -current? 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, 11 Jul 2007 22:05:08 -0000 * Robert Watson [070711 14:37] wrote: > > On Wed, 11 Jul 2007, Alfred Perlstein wrote: > > >I have current as of last week. > > > >I noticed that if I needed a bgfsck on ufs when rebooting my system would > >lock up almost immediately. Everything would deadlock. > > > >If I rebooted single user and did a regular "fsck -y" then continued to > >boot, I'd be OK. > > > >Has anyone else experienced this? I'm going to update to the most recent > >current and get more information (which wait channels etc) but wanted to > >know if anyone knew about this. > > > >I recall seeing a LOT of fixes for various deadlocks in snapshots and > >bgfsck going in lately, but nothing that looked to me as if it'd trigger a > >regression. > > I'm not seeing this either -- have you tried running a manual fsck to see > if it turns up anything deeply unsatisfying that could be causing bgfsck > some bother? Of course, nothing comes up that's interesting. I'll try to reproduce this and give better feedback in the next few days. -- - Alfred Perlstein From owner-freebsd-fs@FreeBSD.ORG Wed Jul 11 22:35:18 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3839A16A46E for ; Wed, 11 Jul 2007 22:35:18 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (DELFT.AURA.CS.CMU.EDU [128.2.206.88]) by mx1.freebsd.org (Postfix) with ESMTP id 137C613C43E for ; Wed, 11 Jul 2007 22:35:17 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1I8kmD-0001Os-Cg for freebsd-fs@freebsd.org; Wed, 11 Jul 2007 18:35:17 -0400 Date: Wed, 11 Jul 2007 18:35:17 -0400 To: freebsd-fs@freebsd.org Message-ID: <20070711223517.GH5824@delft.aura.cs.cmu.edu> Mail-Followup-To: freebsd-fs@freebsd.org References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <1184090521301-git-send-email-jaharkes@cs.cmu.edu> <20070711223527.S97304@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711223527.S97304@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: Jan Harkes Subject: Re: [PATCH Coda 0/5] 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, 11 Jul 2007 22:35:18 -0000 On Wed, Jul 11, 2007 at 10:36:10PM +0100, Robert Watson wrote: > On Tue, 10 Jul 2007, Jan Harkes wrote: > >Here is my current patch series. > > I've now committed these five patches to the CVS HEAD. Let me know if > there are any further patches that need committing, and if it's appropriate > to merge these to the RELENG_6 branch after a suitable delay (a couple of > weeks?). Thank you. I'm pretty sure not all of these changes are appropriate for RELENG_6. Once I make sure current is in shape I'll start looking at a possible backmerge. > >(only one minor conflict). I am still in the middle of make buildworld and Buildworld is actually still running. There was a problem that caused the build to fail during "stage 4.3 make dependencies". It took me a couple of tries before I figured out that it was because the clock in the qemu VM was somehow set to the middle of May 2007. As a result the dependencies in usr/gnu/usr.bin/cc/cc_tools triggered a rebuild of a header file which caused a rebuild of the C compiler (which went fine during the earlier bootstrap). The build failure was then caused by the fact that the generated binaries were linked against the new libc and as such were expecting FBSD_1.0 symbol and failed to run with the installed libc, which doesn't have symbol versions. The real bug was the incorrect system time, which triggered a rebuild of some critical binaries when it was supposed to just recalculate dependencies. Jan From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 02:57:38 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A28E816A421 for ; Thu, 12 Jul 2007 02:57:38 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 6FAC613C483 for ; Thu, 12 Jul 2007 02:57:38 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.vnode.org (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6C2vaME055673 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Jul 2007 21:57:37 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <4695989B.7020200@freebsd.org> Date: Wed, 11 Jul 2007 21:57:31 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (X11/20070629) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <1184090521301-git-send-email-jaharkes@cs.cmu.edu> <20070711223527.S97304@fledge.watson.org> <20070711223517.GH5824@delft.aura.cs.cmu.edu> In-Reply-To: <20070711223517.GH5824@delft.aura.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Subject: Re: [PATCH Coda 0/5] 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, 12 Jul 2007 02:57:38 -0000 On 07/11/07 17:35, Jan Harkes wrote: > On Wed, Jul 11, 2007 at 10:36:10PM +0100, Robert Watson wrote: >> On Tue, 10 Jul 2007, Jan Harkes wrote: >>> Here is my current patch series. >> I've now committed these five patches to the CVS HEAD. Let me know if >> there are any further patches that need committing, and if it's appropriate >> to merge these to the RELENG_6 branch after a suitable delay (a couple of >> weeks?). > > Thank you. I'm pretty sure not all of these changes are appropriate for > RELENG_6. Once I make sure current is in shape I'll start looking at a > possible backmerge. > >>> (only one minor conflict). I am still in the middle of make buildworld and > > Buildworld is actually still running. There was a problem that caused > the build to fail during "stage 4.3 make dependencies". It took me a > couple of tries before I figured out that it was because the clock in > the qemu VM was somehow set to the middle of May 2007. > > As a result the dependencies in usr/gnu/usr.bin/cc/cc_tools triggered a > rebuild of a header file which caused a rebuild of the C compiler (which > went fine during the earlier bootstrap). The build failure was then > caused by the fact that the generated binaries were linked against the > new libc and as such were expecting FBSD_1.0 symbol and failed to run > with the installed libc, which doesn't have symbol versions. > > The real bug was the incorrect system time, which triggered a rebuild > of some critical binaries when it was supposed to just recalculate > dependencies. I've done the patches and buildworld/kernel, and have loaded the kernel module. All seems well. Now I need to get the latest client running, and begin some tests. Do you have any notes on the client, since the port is essentially defunct? What's my fastest path to a working client? Eric From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 03:12:34 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3513516A400 for ; Thu, 12 Jul 2007 03:12:34 +0000 (UTC) (envelope-from soc@hbar.us) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id B12C213C468 for ; Thu, 12 Jul 2007 03:12:33 +0000 (UTC) (envelope-from soc@hbar.us) Received: by ug-out-1314.google.com with SMTP id o4so277972uge for ; Wed, 11 Jul 2007 20:12:32 -0700 (PDT) Received: by 10.78.170.6 with SMTP id s6mr30703hue.1184208298208; Wed, 11 Jul 2007 19:44:58 -0700 (PDT) Received: by 10.78.138.5 with HTTP; Wed, 11 Jul 2007 19:44:58 -0700 (PDT) Message-ID: <47a4f3080707111944u2b9ad091t2f4b8be482ab3a69@mail.gmail.com> Date: Wed, 11 Jul 2007 22:44:58 -0400 From: "Brian Chu" To: "Bruce Evans" In-Reply-To: <20070710233455.O2101@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070710233455.O2101@besplex.bde.org> Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE 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, 12 Jul 2007 03:12:34 -0000 Bruce, I've already planned to look at this. I had not been aware that calls to the Giant Lock were being ignored in the current kernel. Brian On 7/10/07, Bruce Evans wrote: > msdsofs has been broken since Giant locking for file systems (or syscalls) > was removed. It allows multiple threads to race accessing the shared > static buffer `nambuf' and related variables. This causes remarkably > few problems. One case that breaks reliably is concurrent tars or finds, > especially with a small cluster size, even on a UP system. Then > getdirentries() returns garbage entries and/or lookup() of correct entries > can't find things. On my UP system, I think the race occurs mainly when > getdirentries() blocks on i/o and a directory entry spans the block > boundary. Then another getdirentries() or lookup() can run, and if it > does then it will almost certainly corrupt the state for the blocked > getdirentries(). On SMP systems, I think the race occurs much more often > and suspect that it is more harmful. > > Quick fix for an old version of FreeBSD. The part in msdosfs_lookup.c > has not been tested at runtime. The part in msdosfs_vnops.c may also > fix bugs involving cookie handling (but not a memory leak like I first > thought?). msdosfs_lookup.c is harder to fix because it has no common > cleanup code. > > %%% > Index: msdosfs_lookup.c > =================================================================== > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_lookup.c,v > retrieving revision 1.40 > diff -u -2 -r1.40 msdosfs_lookup.c > --- msdosfs_lookup.c 26 Dec 2003 17:24:37 -0000 1.40 > +++ msdosfs_lookup.c 10 Jul 2007 13:33:37 -0000 > @@ -78,11 +78,11 @@ > * memory denode's will be in synch. > */ > -int > -msdosfs_lookup(ap) > +static int > +msdosfs_lookup_locked( > struct vop_cachedlookup_args /* { > struct vnode *a_dvp; > struct vnode **a_vpp; > struct componentname *a_cnp; > - } */ *ap; > + } */ *ap) > { > struct vnode *vdp = ap->a_dvp; > @@ -560,4 +561,20 @@ > > /* > + * XXX msdosfs_lookup() is split up because unlocking Giant before all the > + * returns in the original function would be too churning. > + */ > +int > +msdosfs_lookup(ap) > + struct vop_cachedlookup_args *ap; > +{ > + int error; > + > + mtx_lock(&Giant); /* XXX for exclusive access to nambuf. */ > + error = msdosfs_lookup_locked(ap); > + mtx_unlock(&Giant); > + return (error); > +} > + > +/* > * dep - directory entry to copy into the directory > * ddep - directory to add to > Index: msdosfs_vnops.c > =================================================================== > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v > retrieving revision 1.147 > diff -u -2 -r1.147 msdosfs_vnops.c > --- msdosfs_vnops.c 4 Feb 2004 21:52:53 -0000 1.147 > +++ msdosfs_vnops.c 10 Jul 2007 05:08:17 -0000 > @@ -1559,4 +1592,5 @@ > } > > + mtx_lock(&Giant); /* XXX for exclusive access to nambuf. */ > mbnambuf_init(); > off = offset; > @@ -1575,10 +1609,13 @@ > if (error) { > brelse(bp); > - return (error); > + Debugger("used to leak cookies 1"); > + break; > } > n = min(n, blsize - bp->b_resid); > if (n == 0) { > brelse(bp); > - return (EIO); > + error = EIO; > + Debugger("used to leak cookies 2"); > + break; > } > > @@ -1687,4 +1725,6 @@ > } > out: > + mtx_unlock(&Giant); > + > /* Subtract unused cookies */ > if (ap->a_ncookies) > %%% > > Please fix this better. mbnambuf_init() could return a non-static buffer > that doesn't require locking. Deallocation would be painful. Note that > even the details for Giant locking can't be hidden in msdosfs_conv.c like > the current interfaces intend, since mbnambuf_init() is used a lot to > reinitialize an in-use buffer, and there is no interface to drop usage. > > Bruce > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 03:40:34 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4772F16A41F for ; Thu, 12 Jul 2007 03:40:34 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (DELFT.AURA.CS.CMU.EDU [128.2.206.88]) by mx1.freebsd.org (Postfix) with ESMTP id 0F79D13C45D for ; Thu, 12 Jul 2007 03:40:33 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1I8pXd-0001wA-6n; Wed, 11 Jul 2007 23:40:33 -0400 Date: Wed, 11 Jul 2007 23:40:33 -0400 To: Eric Anderson Message-ID: <20070712034033.GO5824@delft.aura.cs.cmu.edu> Mail-Followup-To: Eric Anderson , freebsd-fs@freebsd.org References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <1184090521301-git-send-email-jaharkes@cs.cmu.edu> <20070711223527.S97304@fledge.watson.org> <20070711223517.GH5824@delft.aura.cs.cmu.edu> <4695989B.7020200@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4695989B.7020200@freebsd.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: Jan Harkes Cc: freebsd-fs@freebsd.org Subject: Re: [PATCH Coda 0/5] 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, 12 Jul 2007 03:40:34 -0000 On Wed, Jul 11, 2007 at 09:57:31PM -0500, Eric Anderson wrote: > I've done the patches and buildworld/kernel, and have loaded the kernel > module. All seems well. Now I need to get the latest client running, > and begin some tests. Do you have any notes on the client, since the > port is essentially defunct? What's my fastest path to a working client? wget http://www.coda.cs.cmu.edu/pub/lwp/src/lwp-2.3.tar.gz wget http://www.coda.cs.cmu.edu/pub/rvm/src/rvm-1.14.tar.gz wget http://www.coda.cs.cmu.edu/pub/rpc2/src/rpc2-2.5.tar.gz wget http://www.coda.cs.cmu.edu/pub/rpc2/src/coda-6.9.1.tar.gz tar -xzf lwp-2.3.tar.gz ( cd lwp-2.3 ; ./configure ; gmake ; sudo gmake install ) tar -xzf rvm-1.14.tar.gz ( cd rvm-1.14 ; ./configure ; gmake ; sudo gmake install ) tar -xzf rpc2-2.5.tar.gz ( cd rpc2-2.5 ; ./configure ; gmake ; sudo gmake install ) tar -xzf coda-6.9.1.tar.gz ( cd coda-6.9.1 ; ./configure --prefix=/usr/coda ; gmake ; sudo gmake client-install ) # load the coda kernel module, kldload coda or something /usr/coda/sbin/venus-setup testserver.coda.cs.cmu.edu 100000 /usr/coda/sbin/venus ls /coda/testserver.coda.cs.cmu.edu/ If everything worked ok you should see 2 directories and a file named 'WELCOME'. lwp, rvm and rpc2 use automake so I think gmake is not really necessary anymore, but there may still be some gnu artifacts around, I think I removed the one more from rpc2 not too long ago. I still want to move the main Coda source to automake to simplify the build and get rid of the remaining gmake dependencies. As far as other build dependencies, I think the following are the minimal needed one, but they tend to come installed on most systems, pkg-config, libreadline5-dev, libncurses5-dev, g++, flex, bison or yacc (these were listed as build dependencies on a debian system) To remove everything from your system, the automake based libraries have a convenient uninstall target, for Coda itself everything 'should' have ended up under /usr/coda. I haven't actually tried installing outside of /usr or /usr/local in a while though. Jan From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 03:42:02 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4F0516A421 for ; Thu, 12 Jul 2007 03:42:02 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (DELFT.AURA.CS.CMU.EDU [128.2.206.88]) by mx1.freebsd.org (Postfix) with ESMTP id 8E11F13C457 for ; Thu, 12 Jul 2007 03:42:02 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1I8pZ4-0001wU-6v; Wed, 11 Jul 2007 23:42:02 -0400 Date: Wed, 11 Jul 2007 23:42:02 -0400 To: freebsd-fs@freebsd.org Message-ID: <20070712034202.GP5824@delft.aura.cs.cmu.edu> Mail-Followup-To: freebsd-fs@freebsd.org, Eric Anderson References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <1184090521301-git-send-email-jaharkes@cs.cmu.edu> <20070711223527.S97304@fledge.watson.org> <20070711223517.GH5824@delft.aura.cs.cmu.edu> <4695989B.7020200@freebsd.org> <20070712034033.GO5824@delft.aura.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070712034033.GO5824@delft.aura.cs.cmu.edu> User-Agent: Mutt/1.5.13 (2006-08-11) From: Jan Harkes Cc: Subject: Re: [PATCH Coda 0/5] 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, 12 Jul 2007 03:42:02 -0000 On Wed, Jul 11, 2007 at 11:40:33PM -0400, Jan Harkes wrote: > On Wed, Jul 11, 2007 at 09:57:31PM -0500, Eric Anderson wrote: > > I've done the patches and buildworld/kernel, and have loaded the kernel > > module. All seems well. Now I need to get the latest client running, > > and begin some tests. Do you have any notes on the client, since the > > port is essentially defunct? What's my fastest path to a working client? > > wget http://www.coda.cs.cmu.edu/pub/lwp/src/lwp-2.3.tar.gz > wget http://www.coda.cs.cmu.edu/pub/rvm/src/rvm-1.14.tar.gz > wget http://www.coda.cs.cmu.edu/pub/rpc2/src/rpc2-2.5.tar.gz > wget http://www.coda.cs.cmu.edu/pub/rpc2/src/coda-6.9.1.tar.gz Oops, that last one should have been, wget http://www.coda.cs.cmu.edu/pub/coda/src/coda-6.9.1.tar.gz Jan From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 03:59:13 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22C3C16A46C for ; Thu, 12 Jul 2007 03:59:13 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id E9C8513C4B7 for ; Thu, 12 Jul 2007 03:59:12 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.vnode.org (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6C3xBfp075993 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Jul 2007 22:59:12 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <4695A70A.9090902@freebsd.org> Date: Wed, 11 Jul 2007 22:59:06 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (X11/20070629) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <1184090521301-git-send-email-jaharkes@cs.cmu.edu> <20070711223527.S97304@fledge.watson.org> <20070711223517.GH5824@delft.aura.cs.cmu.edu> <4695989B.7020200@freebsd.org> In-Reply-To: <4695989B.7020200@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Subject: Re: [PATCH Coda 0/5] 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, 12 Jul 2007 03:59:13 -0000 On 07/11/07 21:57, Eric Anderson wrote: > On 07/11/07 17:35, Jan Harkes wrote: >> On Wed, Jul 11, 2007 at 10:36:10PM +0100, Robert Watson wrote: >>> On Tue, 10 Jul 2007, Jan Harkes wrote: >>>> Here is my current patch series. >>> I've now committed these five patches to the CVS HEAD. Let me know if >>> there are any further patches that need committing, and if it's appropriate >>> to merge these to the RELENG_6 branch after a suitable delay (a couple of >>> weeks?). >> Thank you. I'm pretty sure not all of these changes are appropriate for >> RELENG_6. Once I make sure current is in shape I'll start looking at a >> possible backmerge. >> >>>> (only one minor conflict). I am still in the middle of make buildworld and >> Buildworld is actually still running. There was a problem that caused >> the build to fail during "stage 4.3 make dependencies". It took me a >> couple of tries before I figured out that it was because the clock in >> the qemu VM was somehow set to the middle of May 2007. >> >> As a result the dependencies in usr/gnu/usr.bin/cc/cc_tools triggered a >> rebuild of a header file which caused a rebuild of the C compiler (which >> went fine during the earlier bootstrap). The build failure was then >> caused by the fact that the generated binaries were linked against the >> new libc and as such were expecting FBSD_1.0 symbol and failed to run >> with the installed libc, which doesn't have symbol versions. >> >> The real bug was the incorrect system time, which triggered a rebuild >> of some critical binaries when it was supposed to just recalculate >> dependencies. > > > I've done the patches and buildworld/kernel, and have loaded the kernel > module. All seems well. Now I need to get the latest client running, > and begin some tests. Do you have any notes on the client, since the > port is essentially defunct? What's my fastest path to a working client? Nevermind - I successfully got the coda 6.9.1 code going, and have tested it and the kernel code recently committed, and all seems to work very well. I've only done very simple testing, but so far nothing has broken, things have worked, and no panics. Eric From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 06:23:25 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12AEA16A469 for ; Thu, 12 Jul 2007 06:23:25 +0000 (UTC) (envelope-from pramod@juniper.net) Received: from smtpa.juniper.net (smtpa.juniper.net [207.17.137.120]) by mx1.freebsd.org (Postfix) with ESMTP id E774F13C487 for ; Thu, 12 Jul 2007 06:23:24 +0000 (UTC) (envelope-from pramod@juniper.net) Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by smtpa.juniper.net with ESMTP; 11 Jul 2007 22:54:13 -0700 X-IronPort-AV: i="4.16,529,1175497200"; d="scan'208"; a="35346090:sNHT3864643596" Received: from emailcorp1.jnpr.net ([66.129.254.11]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 22:54:12 -0700 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 22:53:51 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2007 22:53:53 -0700 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E1D9453@emailcorp3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ffs_blkfree: freeing free block Thread-Index: AcfESQdlj0QChkD0TDiTUtfSCzdkOA== From: "Pramod Srinivasan" To: X-OriginalArrivalTime: 12 Jul 2007 05:53:51.0358 (UTC) FILETIME=[05E021E0:01C7C449] Subject: ffs_blkfree: freeing free block 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, 12 Jul 2007 06:23:25 -0000 Hi Folks, I am hitting an issue with FS mostly happens during unmount (there was heavy FS activity before unmount). I saw couple of open issues in the gnat system which resembled what I am facing, is this known issue in FreeBSD 6.1? Any suggestions that can help me isolate this issue? Any help greatly appreciated. Thanks, Pramod o 2004/10/07 kern/72424 panic: ffs_blkfree: freeing free block in ffs/ffs_alloc.c:1750=20 o 2007/04/17 kern/111766 [panic] "panic: ffs_blkfree: freeing free block" during disk activity=20 Logs: bad block 1879705254, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -2044978536, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1604323672, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1596776907, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1508683655, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 2116800231, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1784947406, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1634164916, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1799029551, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 480176283, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 737555399, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -888105817, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 581137468, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1793207079, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1229629769, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 713629400, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -991665073, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 2089328936, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1936327699, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -164428600, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 935535580, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1619363206, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1041685823, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -350035627, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1064513623, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -2123597818, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1772760714, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1833488349, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 834902787, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1859837541, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -754399098, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -136478242, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -558985721, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1041423635, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -383587351, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1099346864, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1511092906, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 985062738, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -98951346, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 227642895, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1852928728, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1925604902, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1079569569, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -226022630, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1916855325, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -805772511, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1272161097, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1353245282, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 916375283, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1414897852, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 723561386, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1621781218, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -535915444, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1658392720, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1274821438, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -996100997, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1374139456, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 723958296, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 871475185, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 282648856, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -388725962, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 825570873, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 909699212, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -37808773, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1424765782, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1609269280, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 370514994, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 861089254, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -755285343, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1468276211, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1894031774, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1537254379, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -1600099672, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block 1861139431, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block bad block -315213489, ino 134428 pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block dev =3D ad1s1f, block =3D 5001639, fs =3D /mnt/var panic: ffs_blkfree: freeing free block db_log_stack_trace_cmd(c08c9220) at 0 panic(c087d5cc,c087d5ac,c8d76780,4c51a7,0) at 0 ffs_blkfree(c8d9a400,c8da2800,c8d9278c,4c51a7,0) at 0 indir_trunc(c8ab99c0,231120,0,0,c,0,f1c1eb54) at 0 handle_workitem_freeblocks(c8ab99c0,0) at 0 process_worklist_item(c8d3d000,0) at 0 softdep_process_worklist(c8d3d000,1) at 0 softdep_flushworklist(c8d3d000,f1c1ec48,c8d51600) at 0 ffs_sync(c8d3d000,1,c8d51600,0,1) at 0 dounmount(c8d3d000,8000000,c8d51600,4695a41e,209c004) at 0 unmount(c8d51600,f1c1ed04,2,1,206) at 0 syscall(3b,3b,3b,804a592,804ea51) at 0 Xint0x80_syscall() at 0 --- syscall (22, FreeBSD ELF32, unmount), eip =3D 0x480ba03b, esp =3D 0xbfbed66c, ebp =3D 0xbfbed718 --- KDB: enter: panic [thread pid 2753 tid 100041 ] Stopped at kdb_enter+0x37: pushl $-0x1 db> From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 08:14:54 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9774516A421 for ; Thu, 12 Jul 2007 08:14:54 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30308.mail.mud.yahoo.com (web30308.mail.mud.yahoo.com [209.191.69.70]) by mx1.freebsd.org (Postfix) with SMTP id 47BF213C484 for ; Thu, 12 Jul 2007 08:14:54 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: (qmail 3463 invoked by uid 60001); 12 Jul 2007 07:48:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=BESmkEG8oTaSiTYlbynQak1qFgcGO/liiOe7GEGD1lQ98CkBfEZxh915krXHnNOQRvYVyFfvZ/SgG/hd6IaHKNhxiylCZBgwVgKkc3smZXa295IGA6WXji+fMGZMqo1WnljWyIeaBJi3EEYWbVj3ASNK4VnC7EHm059hqjdx5Cc=; X-YMail-OSG: NhNUl7sVM1kiqIObFNcvkG0ZnFxhcqDxrKahg3iBazyqbiCOIAbsp6NeGeeoGd6aL7ig7QCi2bmYLWRBFNHxdMISNjOSe.smdNxgiXUj4SZNkcMa9pOGSTPZysGLTw-- Received: from [84.141.81.74] by web30308.mail.mud.yahoo.com via HTTP; Thu, 12 Jul 2007 00:48:12 PDT Date: Thu, 12 Jul 2007 00:48:12 -0700 (PDT) From: Arne "Wörner" To: Pramod Srinivasan , freebsd-fs@freebsd.org In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E1D9453@emailcorp3.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <420056.3187.qm@web30308.mail.mud.yahoo.com> Cc: Subject: Re: ffs_blkfree: freeing free block 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, 12 Jul 2007 08:14:54 -0000 --- Pramod Srinivasan wrote: > I am hitting an issue with FS mostly happens during unmount (there was > heavy FS activity before unmount). I saw couple of open issues in the > gnat system which resembled what I am facing, is this known issue in > FreeBSD 6.1? Any suggestions that can help me isolate this issue? > I would try an fsck first... I had no such problems with R6.1... -Arne ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 08:58:42 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAE8616A41F for ; Thu, 12 Jul 2007 08:58:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 3CB4513C4E7 for ; Thu, 12 Jul 2007 08:58:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1I8uG8-0004Ac-3F; Thu, 12 Jul 2007 11:42:51 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6C8geIc088958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 11:42:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6C8geW5056191; Thu, 12 Jul 2007 11:42:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l6C8geCY056190; Thu, 12 Jul 2007 11:42:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Jul 2007 11:42:40 +0300 From: Kostik Belousov To: Alfred Perlstein Message-ID: <20070712084240.GB2200@deviant.kiev.zoral.com.ua> References: <20070711202640.GV45894@elvis.mu.org> <20070711223720.C97304@fledge.watson.org> <20070711220508.GY45894@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XPTkPaWipqgB+utH" Content-Disposition: inline In-Reply-To: <20070711220508.GY45894@elvis.mu.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.6 required=5.0 tests=ALL_TRUSTED, DNS_FROM_AHBL_RHSBL autolearn=no version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: e04e44772e0ad72f7751591e8aa1bd99 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1209 [July 11 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Robert Watson , current@freebsd.org, fs@freebsd.org Subject: Re: bgfsck hosed (lockups) in -current? 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, 12 Jul 2007 08:58:42 -0000 --XPTkPaWipqgB+utH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 11, 2007 at 03:05:08PM -0700, Alfred Perlstein wrote: > * Robert Watson [070711 14:37] wrote: > >=20 > > On Wed, 11 Jul 2007, Alfred Perlstein wrote: > >=20 > > >I have current as of last week. > > > > > >I noticed that if I needed a bgfsck on ufs when rebooting my system wo= uld=20 > > >lock up almost immediately. Everything would deadlock. > > > > > >If I rebooted single user and did a regular "fsck -y" then continued t= o=20 > > >boot, I'd be OK. > > > > > >Has anyone else experienced this? I'm going to update to the most rec= ent=20 > > >current and get more information (which wait channels etc) but wanted = to=20 > > >know if anyone knew about this. > > > > > >I recall seeing a LOT of fixes for various deadlocks in snapshots and= =20 > > >bgfsck going in lately, but nothing that looked to me as if it'd trigg= er a=20 > > >regression. > >=20 > > I'm not seeing this either -- have you tried running a manual fsck to s= ee=20 > > if it turns up anything deeply unsatisfying that could be causing bgfsc= k=20 > > some bother? >=20 > Of course, nothing comes up that's interesting. >=20 > I'll try to reproduce this and give better feedback in the next few > days. Please. Deadlock debugging chapter from dev handbook contains enumeration of the needed things. --XPTkPaWipqgB+utH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGlel/C3+MBN1Mb4gRAt1vAKDBMQRWJB1T/YomwXl7VXo1Wj25mQCeLRB8 WksXrTP5X2bqmVVhv6k93uU= =kGEQ -----END PGP SIGNATURE----- --XPTkPaWipqgB+utH-- From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 09:16:04 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 117A716A41F; Thu, 12 Jul 2007 09:16:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA9813C455; Thu, 12 Jul 2007 09:16:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-235-248.carlnfd3.nsw.optusnet.com.au (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l6C9FvQr013643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 19:16:00 +1000 Date: Thu, 12 Jul 2007 19:15:57 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Brian Chu In-Reply-To: <47a4f3080707111944u2b9ad091t2f4b8be482ab3a69@mail.gmail.com> Message-ID: <20070712185224.I4682@delplex.bde.org> References: <20070710233455.O2101@besplex.bde.org> <47a4f3080707111944u2b9ad091t2f4b8be482ab3a69@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE 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, 12 Jul 2007 09:16:04 -0000 On Wed, 11 Jul 2007, Brian Chu wrote: > I've already planned to look at this. I had not been aware that calls > to the Giant Lock were being ignored in the current kernel. Maybe the problem doesn't affect -current. I first saw this bug in a 3-year old version of -current and thought that I verified that it still affects -current. In the old version, getdirentries() and stat() are Giant-locked (not MSTD in syscalls.master), so I don't understand why there was a problem. In -current, msdosfs is not MNTK_MPSAFE, so the problem shouldn't affect -current -- it is already fixed unbetter by Giant-locking everything. [context lost to top posting] Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 09:25:43 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D25416A41F for ; Thu, 12 Jul 2007 09:25:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 877E713C4B9 for ; Thu, 12 Jul 2007 09:25:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1I8uEo-0002g2-Sj; Thu, 12 Jul 2007 11:41:30 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6C8fGpL088945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 11:41:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6C8fGIk056169; Thu, 12 Jul 2007 11:41:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l6C8fFLf056168; Thu, 12 Jul 2007 11:41:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Jul 2007 11:41:15 +0300 From: Kostik Belousov To: Bruce Evans Message-ID: <20070712084115.GA2200@deviant.kiev.zoral.com.ua> References: <20070710233455.O2101@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="adlATi0AGRzVk0TM" Content-Disposition: inline In-Reply-To: <20070710233455.O2101@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.6 required=5.0 tests=ALL_TRUSTED, DNS_FROM_AHBL_RHSBL autolearn=no version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 0c76fa1f3f831c98d9dd14672e80d09a X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1209 [July 11 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE 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, 12 Jul 2007 09:25:43 -0000 --adlATi0AGRzVk0TM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 11, 2007 at 12:08:19AM +1000, Bruce Evans wrote: > msdsofs has been broken since Giant locking for file systems (or syscalls) > was removed. It allows multiple threads to race accessing the shared > static buffer `nambuf' and related variables. This causes remarkably > few problems. One case that breaks reliably is concurrent tars or finds, > especially with a small cluster size, even on a UP system. Then > getdirentries() returns garbage entries and/or lookup() of correct entries > can't find things. On my UP system, I think the race occurs mainly when > getdirentries() blocks on i/o and a directory entry spans the block > boundary. Then another getdirentries() or lookup() can run, and if it > does then it will almost certainly corrupt the state for the blocked > getdirentries(). On SMP systems, I think the race occurs much more often > and suspect that it is more harmful. >=20 > Quick fix for an old version of FreeBSD. The part in msdosfs_lookup.c > has not been tested at runtime. The part in msdosfs_vnops.c may also > fix bugs involving cookie handling (but not a memory leak like I first > thought?). msdosfs_lookup.c is harder to fix because it has no common > cleanup code. >=20 > %%% > Index: msdosfs_lookup.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_lookup.c,v > retrieving revision 1.40 > diff -u -2 -r1.40 msdosfs_lookup.c > --- msdosfs_lookup.c 26 Dec 2003 17:24:37 -0000 1.40 > +++ msdosfs_lookup.c 10 Jul 2007 13:33:37 -0000 > @@ -78,11 +78,11 @@ > * memory denode's will be in synch. > */ > -int > -msdosfs_lookup(ap) > +static int > +msdosfs_lookup_locked( > struct vop_cachedlookup_args /* { > struct vnode *a_dvp; > struct vnode **a_vpp; > struct componentname *a_cnp; > - } */ *ap; > + } */ *ap) > { > struct vnode *vdp =3D ap->a_dvp; > @@ -560,4 +561,20 @@ >=20 > /* > + * XXX msdosfs_lookup() is split up because unlocking Giant before all t= he > + * returns in the original function would be too churning. > + */ > +int > +msdosfs_lookup(ap) > + struct vop_cachedlookup_args *ap; > +{ > + int error; > + > + mtx_lock(&Giant); /* XXX for exclusive access to nambuf. */ > + error =3D msdosfs_lookup_locked(ap); > + mtx_unlock(&Giant); > + return (error); > +} > + > +/* > * dep - directory entry to copy into the directory > * ddep - directory to add to > Index: msdosfs_vnops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v > retrieving revision 1.147 > diff -u -2 -r1.147 msdosfs_vnops.c > --- msdosfs_vnops.c 4 Feb 2004 21:52:53 -0000 1.147 > +++ msdosfs_vnops.c 10 Jul 2007 05:08:17 -0000 > @@ -1559,4 +1592,5 @@ > } >=20 > + mtx_lock(&Giant); /* XXX for exclusive access to nambuf. */ > mbnambuf_init(); > off =3D offset; > @@ -1575,10 +1609,13 @@ > if (error) { > brelse(bp); > - return (error); > + Debugger("used to leak cookies 1"); > + break; > } > n =3D min(n, blsize - bp->b_resid); > if (n =3D=3D 0) { > brelse(bp); > - return (EIO); > + error =3D EIO; > + Debugger("used to leak cookies 2"); > + break; > } >=20 > @@ -1687,4 +1725,6 @@ > } > out: > + mtx_unlock(&Giant); > + > /* Subtract unused cookies */ > if (ap->a_ncookies) > %%% >=20 > Please fix this better. mbnambuf_init() could return a non-static buffer > that doesn't require locking. Deallocation would be painful. Note that > even the details for Giant locking can't be hidden in msdosfs_conv.c like > the current interfaces intend, since mbnambuf_init() is used a lot to > reinitialize an in-use buffer, and there is no interface to drop usage. >=20 > Bruce It seems that msdosfs_lookup() can sleep, thus Giant protection would be lost. --adlATi0AGRzVk0TM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGlekrC3+MBN1Mb4gRApEAAJ94vAGI9bvng4lZh89Nfj2G1xeI3ACfRaNx gmMuH2O7CCdU5K1DFVRwYgw= =0cKT -----END PGP SIGNATURE----- --adlATi0AGRzVk0TM-- From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 11:37:38 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F65316A485 for ; Thu, 12 Jul 2007 11:37:38 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 04DF913C448 for ; Thu, 12 Jul 2007 11:37:37 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6CBba5x048098; Thu, 12 Jul 2007 06:37:37 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46961281.2000607@freebsd.org> Date: Thu, 12 Jul 2007 06:37:37 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Pramod Srinivasan References: <7FA0C743C38E5340BFC2873488FA1E8E1D9453@emailcorp3.jnpr.net> In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E1D9453@emailcorp3.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-fs@freebsd.org Subject: Re: ffs_blkfree: freeing free block 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, 12 Jul 2007 11:37:38 -0000 Pramod Srinivasan wrote: > Hi Folks, > > I am hitting an issue with FS mostly happens during unmount (there was > heavy FS activity before unmount). I saw couple of open issues in the > gnat system which resembled what I am facing, is this known issue in > FreeBSD 6.1? Any suggestions that can help me isolate this issue? > > Any help greatly appreciated. > > Thanks, > Pramod > > o 2004/10/07 kern/72424 panic: ffs_blkfree: freeing free block in > ffs/ffs_alloc.c:1750 > o 2007/04/17 kern/111766 [panic] "panic: ffs_blkfree: freeing free > block" during disk activity > > Logs: > > bad block 1879705254, ino 134428 > pid 2753 (umount), uid 0 inumber 134428 on /mnt/var: bad block > bad block -2044978536, ino 134428 You should do three things: - Check your disk for errors - fsck the partition - Update to 6-STABLE After doing the above, please give feedback on your findings.. Eric From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 12:11:04 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5227216A469; Thu, 12 Jul 2007 12:11:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id F3EF213C4BC; Thu, 12 Jul 2007 12:11:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id ACFC24824F; Thu, 12 Jul 2007 08:11:03 -0400 (EDT) Date: Thu, 12 Jul 2007 13:11:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jan Harkes In-Reply-To: <20070712034033.GO5824@delft.aura.cs.cmu.edu> Message-ID: <20070712124134.G27319@fledge.watson.org> References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <1184090521301-git-send-email-jaharkes@cs.cmu.edu> <20070711223527.S97304@fledge.watson.org> <20070711223517.GH5824@delft.aura.cs.cmu.edu> <4695989B.7020200@freebsd.org> <20070712034033.GO5824@delft.aura.cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: [PATCH Coda 0/5] 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, 12 Jul 2007 12:11:04 -0000 On Wed, 11 Jul 2007, Jan Harkes wrote: > On Wed, Jul 11, 2007 at 09:57:31PM -0500, Eric Anderson wrote: > >> I've done the patches and buildworld/kernel, and have loaded the kernel >> module. All seems well. Now I need to get the latest client running, and >> begin some tests. Do you have any notes on the client, since the port is >> essentially defunct? What's my fastest path to a working client? > > wget http://www.coda.cs.cmu.edu/pub/lwp/src/lwp-2.3.tar.gz > wget http://www.coda.cs.cmu.edu/pub/rvm/src/rvm-1.14.tar.gz > wget http://www.coda.cs.cmu.edu/pub/rpc2/src/rpc2-2.5.tar.gz > wget http://www.coda.cs.cmu.edu/pub/rpc2/src/coda-6.9.1.tar.gz Should be: wget http://www.coda.cs.cmu.edu/pub/coda/src/coda-6.9.1.tar-gz > tar -xzf lwp-2.3.tar.gz > ( cd lwp-2.3 ; ./configure ; gmake ; sudo gmake install ) > > tar -xzf rvm-1.14.tar.gz > ( cd rvm-1.14 ; ./configure ; gmake ; sudo gmake install ) > > tar -xzf rpc2-2.5.tar.gz > ( cd rpc2-2.5 ; ./configure ; gmake ; sudo gmake install ) rpc2 depends on perl and should probably check for it in configure. > tar -xzf coda-6.9.1.tar.gz > ( cd coda-6.9.1 ; ./configure --prefix=/usr/coda ; gmake ; > sudo gmake client-install ) Newer gcc revisions get awful cranky about all those string constants being passed around as 'char *'s :-). > # load the coda kernel module, kldload coda or something > /usr/coda/sbin/venus-setup testserver.coda.cs.cmu.edu 100000 This probably no longer applies on FreeBSD: You need a character device for the Coda kernel module On *BSD systems you probably have to run "mknod /dev/cfs0 c 93 0" ...and might lead to confusion. > /usr/coda/sbin/venus I neglected to notice your instructions to explicitly load the kernel module, so ran Venus without it -- the error message wasn't as suggestive as might be hoped. Perhaps "Load the kernel module, dammit" if consecutive ENOENT's come from trying to open the device nodes would be appropriate? 13:45:07 Coda Venus, version 6.9.1 13:45:07 Probably another Venus is running! open failed for /dev/cfs0,/dev/coda/0, exiting > ls /coda/testserver.coda.cs.cmu.edu/ > > If everything worked ok you should see 2 directories and a file named > 'WELCOME'. At this point I got an ls stuck in the coda_call wait channel: freebsd-coda# ls /coda freebsd-coda# ls /coda/testserver.coda.cs.cmu.edu/ load:0.02 cmd: ls 39084 [coda_call] 0.00u 0.00s 0% 1116k I see UDP traffic to telemann.coda.cs.cmu.edu but no apparent forward progress until eventually: ls: /coda/testserver.coda.cs.cmu.edu/: No such file or directory So it sounded like things sort of worked. I'm behind four layers of NAT on this VM, what with Parallels, the WAP, a Soekris box, and a Newnham College NAT, so if NAT problems still exist for Coda, that result might not be surprising. I notice also that the clock on the box may be off by an hour, perhaps a problem? When I killed venus and restarted it, then the system hung: freebsd-coda# killall venus freebsd-coda# ls /coda NOT_REALLY_CODA freebsd-coda# /usr/coda/sbin/venus Date: Thu 07/12/2007 13:49:59 Coda Venus, version 6.9.1 13:49:59 /usr/coda/LOG size is 2706432 bytes 13:49:59 /usr/coda/DATA size is 10821456 bytes 13:49:59 Loading RVM data 13:49:59 Last init was Thu Jul 12 13:46:24 2007 13:49:59 Last shutdown was clean 13:49:59 Starting RealmDB scan 13:49:59 Found 2 realms 13:49:59 starting VDB scan 13:49:59 2 volume replicas 13:49:59 0 replicated volumes 13:49:59 0 CML entries allocated 13:49:59 0 CML entries on free-list 13:49:59 starting FSDB scan (4166, 100000) (25, 75, 4) 13:49:59 2 cache files in table (0 blocks) Sadly, no BREAK_TO_DEBUGGER on this box, so I will rebuild the kernel and try again later. > lwp, rvm and rpc2 use automake so I think gmake is not really necessary > anymore, but there may still be some gnu artifacts around, I think I > removed the one more from rpc2 not too long ago. I still want to move > the main Coda source to automake to simplify the build and get rid of > the remaining gmake dependencies. > > As far as other build dependencies, I think the following are the > minimal needed one, but they tend to come installed on most systems, > > pkg-config, libreadline5-dev, libncurses5-dev, g++, flex, bison or yacc > > (these were listed as build dependencies on a debian system) > > To remove everything from your system, the automake based libraries have a > convenient uninstall target, for Coda itself everything 'should' have ended > up under /usr/coda. I haven't actually tried installing outside of /usr or > /usr/local in a while though. To do the build I needed to install gmake and perl packages. These implicitly brought in gettext and libiconv, so I'm not sure if there are any explicit dependencies there. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 13:33:44 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAB1416A400; Thu, 12 Jul 2007 13:33:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2F013C46C; Thu, 12 Jul 2007 13:33:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l6CDXe1g007363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 23:33:42 +1000 Date: Thu, 12 Jul 2007 23:33:40 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20070712084115.GA2200@deviant.kiev.zoral.com.ua> Message-ID: <20070712225324.F9515@besplex.bde.org> References: <20070710233455.O2101@besplex.bde.org> <20070712084115.GA2200@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE 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, 12 Jul 2007 13:33:44 -0000 On Thu, 12 Jul 2007, Kostik Belousov wrote: > On Wed, Jul 11, 2007 at 12:08:19AM +1000, Bruce Evans wrote: >> msdsofs has been broken since Giant locking for file systems (or syscalls) >> was removed. It allows multiple threads to race accessing the shared >> static buffer `nambuf' and related variables. This causes remarkably >> [Add Giant locking] >> Please fix this better. mbnambuf_init() could return a non-static buffer >> that doesn't require locking. Deallocation would be painful. Note that >> even the details for Giant locking can't be hidden in msdosfs_conv.c like >> the current interfaces intend, since mbnambuf_init() is used a lot to >> reinitialize an in-use buffer, and there is no interface to drop usage. > It seems that msdosfs_lookup() can sleep, thus Giant protection would be > lost. It can certainly block in bread(). I now think this is not really an SMP bug. The nambuf* data structure requires a long-term global lock, but it has never had one. The bug seems to be relatively new. nambuf* is for multi-byte characters, not for long names, and has only existed since 2003 (msdosfs_vnops.c 1.141, etc.). I thought that long names were built up in nambuf, but they are apparently built up in the directory entry. This should work for multi-byte characters too -- don't translate anything until all the low- level directory entries have been accumulated. How does my adding Giant locking help? I checked that at least in FreeBSD-~5.2-current, msdosfs_readdir() is already Giant-locked, so my fix just increments the recursion count. What happens to recursively- held Giant locks across sleeps? I think they should cause a KASSERT() failure, but if they are handled by only dropping Giant once then my fix might sort of work but sleeps would be broken generally. Bruce From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 14:21:41 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D32AD16A400; Thu, 12 Jul 2007 14:21:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 213E913C457; Thu, 12 Jul 2007 14:21:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1I8zY2-000GLx-0K; Thu, 12 Jul 2007 17:21:39 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6CELSnv098428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 17:21:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6CELSVh025819; Thu, 12 Jul 2007 17:21:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l6CELRK5025818; Thu, 12 Jul 2007 17:21:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Jul 2007 17:21:27 +0300 From: Kostik Belousov To: Bruce Evans Message-ID: <20070712142127.GD2200@deviant.kiev.zoral.com.ua> References: <20070710233455.O2101@besplex.bde.org> <20070712084115.GA2200@deviant.kiev.zoral.com.ua> <20070712225324.F9515@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QQBmthHSezQuldOP" Content-Disposition: inline In-Reply-To: <20070712225324.F9515@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.6 required=5.0 tests=ALL_TRUSTED, DNS_FROM_AHBL_RHSBL autolearn=no version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 3f6c5f504711b4b2e39067d20b60c9d6 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1214 [July 12 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE 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, 12 Jul 2007 14:21:41 -0000 --QQBmthHSezQuldOP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2007 at 11:33:40PM +1000, Bruce Evans wrote: >=20 >=20 > On Thu, 12 Jul 2007, Kostik Belousov wrote: >=20 > >On Wed, Jul 11, 2007 at 12:08:19AM +1000, Bruce Evans wrote: > >>msdsofs has been broken since Giant locking for file systems (or syscal= ls) > >>was removed. It allows multiple threads to race accessing the shared > >>static buffer `nambuf' and related variables. This causes remarkably >=20 > >>[Add Giant locking] >=20 > >>Please fix this better. mbnambuf_init() could return a non-static buff= er > >>that doesn't require locking. Deallocation would be painful. Note that > >>even the details for Giant locking can't be hidden in msdosfs_conv.c li= ke > >>the current interfaces intend, since mbnambuf_init() is used a lot to > >>reinitialize an in-use buffer, and there is no interface to drop usage. >=20 > >It seems that msdosfs_lookup() can sleep, thus Giant protection would be > >lost. >=20 > It can certainly block in bread(). Besides bread(), there is a (re)locking for ".." case, and deget() call, that itself calls malloc(M_WAITOK), vfs_hash_get(), getnewvnode() and readep(). The latter itself calls bread(). This is from the brief look. >=20 > I now think this is not really an SMP bug. The nambuf* data structure > requires a long-term global lock, but it has never had one. The bug > seems to be relatively new. nambuf* is for multi-byte characters, not > for long names, and has only existed since 2003 (msdosfs_vnops.c 1.141, > etc.). I thought that long names were built up in nambuf, but they > are apparently built up in the directory entry. This should work for > multi-byte characters too -- don't translate anything until all the low- > level directory entries have been accumulated. >=20 > How does my adding Giant locking help? I checked that at least in > FreeBSD-~5.2-current, msdosfs_readdir() is already Giant-locked, so my > fix just increments the recursion count. What happens to recursively- > held Giant locks across sleeps? I think they should cause a KASSERT() > failure, but if they are handled by only dropping Giant once then my > fix might sort of work but sleeps would be broken generally. >=20 Look at the kern/kern_sync.c:_sleep(). It does DROP_GIANT(), that (from the sys/mutex.h) calls mtx_unlock() until Giant is owned. --QQBmthHSezQuldOP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGljjmC3+MBN1Mb4gRAkMNAJwKu64+eN4bOF0xcIFEF4UjNIenuQCfVAP7 CpnkfmWcpcpbNRPidZxWAtk= =WeyX -----END PGP SIGNATURE----- --QQBmthHSezQuldOP-- From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 14:31:04 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84E7216A400 for ; Thu, 12 Jul 2007 14:31:04 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (DELFT.AURA.CS.CMU.EDU [128.2.206.88]) by mx1.freebsd.org (Postfix) with ESMTP id 4B57F13C448 for ; Thu, 12 Jul 2007 14:31:04 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1I8zh9-00038W-QG for freebsd-fs@freebsd.org; Thu, 12 Jul 2007 10:31:03 -0400 Date: Thu, 12 Jul 2007 10:31:03 -0400 To: freebsd-fs@freebsd.org Message-ID: <20070712143103.GR5824@delft.aura.cs.cmu.edu> Mail-Followup-To: freebsd-fs@freebsd.org References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <1184090521301-git-send-email-jaharkes@cs.cmu.edu> <20070711223527.S97304@fledge.watson.org> <20070711223517.GH5824@delft.aura.cs.cmu.edu> <4695989B.7020200@freebsd.org> <20070712034033.GO5824@delft.aura.cs.cmu.edu> <20070712124134.G27319@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070712124134.G27319@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: Jan Harkes Subject: Re: [PATCH Coda 0/5] 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, 12 Jul 2007 14:31:04 -0000 On Thu, Jul 12, 2007 at 01:11:03PM +0100, Robert Watson wrote: > On Wed, 11 Jul 2007, Jan Harkes wrote: > > tar -xzf rpc2-2.5.tar.gz > > ( cd rpc2-2.5 ; ./configure ; gmake ; sudo gmake install ) > > rpc2 depends on perl and should probably check for it in configure. Right, I was looking at my cvs/git tree which doesn't need perl anymore. In fact the makefile snippet that ran the perl script was afaik the last gmake dependency in rpc2. > > tar -xzf coda-6.9.1.tar.gz > > ( cd coda-6.9.1 ; ./configure --prefix=/usr/coda ; gmake ; > > sudo gmake client-install ) > > Newer gcc revisions get awful cranky about all those string constants being > passed around as 'char *'s :-). Sigh, every new gcc adds a new target for cleanups, and I haven't even fixed all the aliasing warnings yet (still using gcc-4.1 here). Although I don't remember if any of these more paranoid warnings have uncovered bugs, at least it helps with cleaning up the code. > > # load the coda kernel module, kldload coda or something > > /usr/coda/sbin/venus-setup testserver.coda.cs.cmu.edu 100000 > > This probably no longer applies on FreeBSD: > > You need a character device for the Coda kernel module > On *BSD systems you probably have to run "mknod /dev/cfs0 c 93 0" > > ...and might lead to confusion. I think most of what venus-setup tries to do no longer applies, checks for missing ports in /etc/services, etc. I remember adding a test to avoid that message on devfs-based systems but I may have never committed the fix. > > /usr/coda/sbin/venus > > I neglected to notice your instructions to explicitly load the kernel > module, so ran Venus without it -- the error message wasn't as suggestive > as might be hoped. Perhaps "Load the kernel module, dammit" if consecutive > ENOENT's come from trying to open the device nodes would be appropriate? > > 13:45:07 Coda Venus, version 6.9.1 > 13:45:07 Probably another Venus is running! open failed for > /dev/cfs0,/dev/coda/0, exiting Right, when venus is already running we should see something like EBUSY. > > ls /coda/testserver.coda.cs.cmu.edu/ > > > >If everything worked ok you should see 2 directories and a file named > >'WELCOME'. > > At this point I got an ls stuck in the coda_call wait channel: > > freebsd-coda# ls /coda > freebsd-coda# ls /coda/testserver.coda.cs.cmu.edu/ > load:0.02 cmd: ls 39084 [coda_call] 0.00u 0.00s 0% 1116k > > I see UDP traffic to telemann.coda.cs.cmu.edu but no apparent forward > progress until eventually: > > ls: /coda/testserver.coda.cs.cmu.edu/: No such file or directory Probably took about 60 or 90 seconds. I guess we the reply packets never really made it all the way across the firewalls and the remote procedure call timed out. We can handle some classes of address translation firewalls better than we used to, the side-effect and server->client connections are now going over the same UDP port pair, but there are clearly still situations that we just don't handle. I've seen firewalls that assume that UDP traffic is single request, single reply and no state between requests. So they basically drop the redirection once a reply has been received and send the next request from a new port. Hey it works fine for DNS... Very confusing on the server side, it identifies clients based on the (ip,port) and each new request is assumed to come from a new client and so we can never get a stable connection. > surprising. I notice also that the clock on the box may be off by an hour, > perhaps a problem? Shouldn't be, can't rely on time being anywhere near consistent in a distributed system. > When I killed venus and restarted it, then the system hung: ... > 13:49:59 starting FSDB scan (4166, 100000) (25, 75, 4) > 13:49:59 2 cache files in table (0 blocks) Hmm, at this point we haven't even tried to mount /coda yet, so I'm kind of surprised this actually managed to wedge the system. I wonder if this has to do with that bit of code where we used to pass a NULL vfs mount. -/* cp = make_coda_node(&ctlfid, vfsp, VCHR); - The above code seems to cause a loop in the cnode links. - I don't totally understand when it happens, it is caught - when closing down the system. - */ - cp = make_coda_node(&ctlfid, 0, VCHR); - + cp = make_coda_node(&ctlfid, vfsp, VCHR); Without debugging I can't tell if your kernel ended up spinning on this 'loop in the cnode links', but I'm pretty sure that passing a NULL mount is not the correct fix for the issue. If it weren't for the assert or panic that is triggered in insmntque it would probably just leave the vnode hanging around without any references. Jan From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 21:16:35 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4370F16A400; Thu, 12 Jul 2007 21:16:35 +0000 (UTC) (envelope-from root@mail.monkeytower.net) Received: from mail.monkeytower.net (mail.monkeytower.net [217.24.215.50]) by mx1.freebsd.org (Postfix) with ESMTP id CED8F13C4B8; Thu, 12 Jul 2007 21:16:32 +0000 (UTC) (envelope-from root@mail.monkeytower.net) Received: from root by mail.monkeytower.net with local Exim id 1I95hd-0006QT-Cx; Thu, 12 Jul 2007 22:55:57 +0200 Received: from mx2.freebsd.org ([69.147.83.53]) by mail.monkeytower.net with esmtp Exim id 1I8zXf-0008UY-Vw for mailinglists@suntsu.org; Thu, 12 Jul 2007 16:21:16 +0200 Received: from hub.freebsd.org (hub.freebsd.org [69.147.83.54]) by mx2.freebsd.org (Postfix) with ESMTP id C0AA2FE94; Thu, 12 Jul 2007 14:21:45 +0000 (UTC) (envelope-from owner-freebsd-bugs@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 8631A16A49A; Thu, 12 Jul 2007 14:21:45 +0000 (UTC) (envelope-from owner-freebsd-bugs@freebsd.org) X-Original-To: bugs@freebsd.org Delivered-To: freebsd-bugs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D32AD16A400; Thu, 12 Jul 2007 14:21:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 213E913C457; Thu, 12 Jul 2007 14:21:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1I8zY2-000GLx-0K; Thu, 12 Jul 2007 17:21:39 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6CELSnv098428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 17:21:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l6CELSVh025819; Thu, 12 Jul 2007 17:21:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l6CELRK5025818; Thu, 12 Jul 2007 17:21:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Jul 2007 17:21:27 +0300 From: Kostik Belousov To: Bruce Evans Message-ID: <20070712142127.GD2200@deviant.kiev.zoral.com.ua> References: <20070710233455.O2101@besplex.bde.org> <20070712084115.GA2200@deviant.kiev.zoral.com.ua> <20070712225324.F9515@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QQBmthHSezQuldOP" Content-Disposition: inline In-Reply-To: <20070712225324.F9515@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.6 required=5.0 tests=ALL_TRUSTED, DNS_FROM_AHBL_RHSBL autolearn=no version=3.2.1, No X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 3f6c5f504711b4b2e39067d20b60c9d6 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1214 [July 12 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-bugs@freebsd.org Errors-To: owner-freebsd-bugs@freebsd.org X-monkeytower-MailScanner-Information: contact information at http://www.monkeytower.net X-monkeytower-MailScanner: Found to be clean X-monkeytower-MailScanner-From: root@mail.monkeytower.net Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 21:16:35 -0000 --QQBmthHSezQuldOP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2007 at 11:33:40PM +1000, Bruce Evans wrote: >=20 >=20 > On Thu, 12 Jul 2007, Kostik Belousov wrote: >=20 > >On Wed, Jul 11, 2007 at 12:08:19AM +1000, Bruce Evans wrote: > >>msdsofs has been broken since Giant locking for file systems (or syscal= ls) > >>was removed. It allows multiple threads to race accessing the shared > >>static buffer `nambuf' and related variables. This causes remarkably >=20 > >>[Add Giant locking] >=20 > >>Please fix this better. mbnambuf_init() could return a non-static buff= er > >>that doesn't require locking. Deallocation would be painful. Note that > >>even the details for Giant locking can't be hidden in msdosfs_conv.c li= ke > >>the current interfaces intend, since mbnambuf_init() is used a lot to > >>reinitialize an in-use buffer, and there is no interface to drop usage. >=20 > >It seems that msdosfs_lookup() can sleep, thus Giant protection would be > >lost. >=20 > It can certainly block in bread(). Besides bread(), there is a (re)locking for ".." case, and deget() call, that itself calls malloc(M_WAITOK), vfs_hash_get(), getnewvnode() and readep(). The latter itself calls bread(). This is from the brief look. >=20 > I now think this is not really an SMP bug. The nambuf* data structure > requires a long-term global lock, but it has never had one. The bug > seems to be relatively new. nambuf* is for multi-byte characters, not > for long names, and has only existed since 2003 (msdosfs_vnops.c 1.141, > etc.). I thought that long names were built up in nambuf, but they > are apparently built up in the directory entry. This should work for > multi-byte characters too -- don't translate anything until all the low- > level directory entries have been accumulated. >=20 > How does my adding Giant locking help? I checked that at least in > FreeBSD-~5.2-current, msdosfs_readdir() is already Giant-locked, so my > fix just increments the recursion count. What happens to recursively- > held Giant locks across sleeps? I think they should cause a KASSERT() > failure, but if they are handled by only dropping Giant once then my > fix might sort of work but sleeps would be broken generally. >=20 Look at the kern/kern_sync.c:_sleep(). It does DROP_GIANT(), that (from the sys/mutex.h) calls mtx_unlock() until Giant is owned. --QQBmthHSezQuldOP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGljjmC3+MBN1Mb4gRAkMNAJwKu64+eN4bOF0xcIFEF4UjNIenuQCfVAP7 CpnkfmWcpcpbNRPidZxWAtk= =WeyX -----END PGP SIGNATURE----- --QQBmthHSezQuldOP-- From owner-freebsd-fs@FreeBSD.ORG Thu Jul 12 21:16:40 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D69316A46E; Thu, 12 Jul 2007 21:16:40 +0000 (UTC) (envelope-from root@mail.monkeytower.net) Received: from mail.monkeytower.net (mail.monkeytower.net [217.24.215.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2596B13C4C5; Thu, 12 Jul 2007 21:16:40 +0000 (UTC) (envelope-from root@mail.monkeytower.net) Received: from root by mail.monkeytower.net with local Exim id 1I95du-0005T0-EE; Thu, 12 Jul 2007 22:52:06 +0200 Received: from mx2.freebsd.org ([69.147.83.53]) by mail.monkeytower.net with esmtp Exim id 1I8ynq-0006Jp-G9 for mailinglists@suntsu.org; Thu, 12 Jul 2007 15:33:54 +0200 Received: from hub.freebsd.org (hub.freebsd.org [69.147.83.54]) by mx2.freebsd.org (Postfix) with ESMTP id C3D9732594; Thu, 12 Jul 2007 13:33:49 +0000 (UTC) (envelope-from owner-freebsd-bugs@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BA0B716A49C; Thu, 12 Jul 2007 13:33:49 +0000 (UTC) (envelope-from owner-freebsd-bugs@freebsd.org) X-Original-To: bugs@freebsd.org Delivered-To: freebsd-bugs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAB1416A400; Thu, 12 Jul 2007 13:33:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2F013C46C; Thu, 12 Jul 2007 13:33:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l6CDXe1g007363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 23:33:42 +1000 Date: Thu, 12 Jul 2007 23:33:40 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20070712084115.GA2200@deviant.kiev.zoral.com.ua> Message-ID: <20070712225324.F9515@besplex.bde.org> References: <20070710233455.O2101@besplex.bde.org> <20070712084115.GA2200@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-bugs@freebsd.org Errors-To: owner-freebsd-bugs@freebsd.org X-monkeytower-MailScanner-Information: contact information at http://www.monkeytower.net X-monkeytower-MailScanner: Found to be clean X-monkeytower-MailScanner-From: root@mail.monkeytower.net X-Spam-Status: No Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE X-BeenThere: freebsd-fs@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 21:16:40 -0000 On Thu, 12 Jul 2007, Kostik Belousov wrote: > On Wed, Jul 11, 2007 at 12:08:19AM +1000, Bruce Evans wrote: >> msdsofs has been broken since Giant locking for file systems (or syscalls) >> was removed. It allows multiple threads to race accessing the shared >> static buffer `nambuf' and related variables. This causes remarkably >> [Add Giant locking] >> Please fix this better. mbnambuf_init() could return a non-static buffer >> that doesn't require locking. Deallocation would be painful. Note that >> even the details for Giant locking can't be hidden in msdosfs_conv.c like >> the current interfaces intend, since mbnambuf_init() is used a lot to >> reinitialize an in-use buffer, and there is no interface to drop usage. > It seems that msdosfs_lookup() can sleep, thus Giant protection would be > lost. It can certainly block in bread(). I now think this is not really an SMP bug. The nambuf* data structure requires a long-term global lock, but it has never had one. The bug seems to be relatively new. nambuf* is for multi-byte characters, not for long names, and has only existed since 2003 (msdosfs_vnops.c 1.141, etc.). I thought that long names were built up in nambuf, but they are apparently built up in the directory entry. This should work for multi-byte characters too -- don't translate anything until all the low- level directory entries have been accumulated. How does my adding Giant locking help? I checked that at least in FreeBSD-~5.2-current, msdosfs_readdir() is already Giant-locked, so my fix just increments the recursion count. What happens to recursively- held Giant locks across sleeps? I think they should cause a KASSERT() failure, but if they are handled by only dropping Giant once then my fix might sort of work but sleeps would be broken generally. Bruce _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Jul 13 08:19:14 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A01BE16A402 for ; Fri, 13 Jul 2007 08:19:14 +0000 (UTC) (envelope-from soc@hbar.us) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.180]) by mx1.freebsd.org (Postfix) with ESMTP id A852113C4B4 for ; Fri, 13 Jul 2007 08:19:13 +0000 (UTC) (envelope-from soc@hbar.us) Received: by ik-out-1112.google.com with SMTP id c21so322665ika for ; Fri, 13 Jul 2007 01:19:11 -0700 (PDT) Received: by 10.78.132.2 with SMTP id f2mr420091hud.1184314751480; Fri, 13 Jul 2007 01:19:11 -0700 (PDT) Received: by 10.78.138.5 with HTTP; Fri, 13 Jul 2007 01:19:11 -0700 (PDT) Message-ID: <47a4f3080707130119xbee4477y3e96d27763f793aa@mail.gmail.com> Date: Fri, 13 Jul 2007 04:19:11 -0400 From: "Brian Chu" Sender: soc@hbar.us To: freebsd-fs@freebsd.org, "Kostik Belousov" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_31586_12249243.1184314751446" X-Google-Sender-Auth: b6d1a8a81213f7e4 Cc: Subject: msdosfs header unification patch X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:19:14 -0000 ------=_Part_31586_12249243.1184314751446 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi fs, The included diff is the work I've done on header consolidation in msdosfs. The three areas I concentrated on where: - sys/fs/msdosfs/ - sys/geom/label/g_label_msdosfs.* - sbin/fsck_msdosfs/ I decided to preserve the headers in sys/fs/msdosfs since the bulk of the code lives there and is most widely understood (don't want to be pulling the rug from under other developers here). There were several places where a meta-structure describing FAT12/FAT16/FAT32 bootsectors and bpb's were kept intact because they were more compact than the actual on disk bs/bpb's. Please feel free to comment! Thanks, Brian ------=_Part_31586_12249243.1184314751446 Content-Type: application/octet-stream; name=patch-chub-msdosfs-unifiedheaders Content-Transfer-Encoding: base64 X-Attachment-Id: f_f42e4psv Content-Disposition: attachment; filename="patch-chub-msdosfs-unifiedheaders" LS0tIC8vZGVwb3QvcHJvamVjdHMvc29jMjAwNy9jaHViLW1zZG9zZnMyL3NiaW4vZnNja19tc2Rv c2ZzL2Jvb3QuYwkyMDA3LzA2LzI5IDAwOjQyOjQyCisrKyAvL2RlcG90L3Byb2plY3RzL3NvYzIw MDcvY2h1Yi1tc2Rvc2ZzMi9zYmluL2ZzY2tfbXNkb3Nmcy9ib290LmMJMjAwNy8wNy8wOCAwODoy ODo1MApAQCAtMzAsOCArMzAsOCBAQAogICogVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VE IE9GIFRIRSBQT1NTSUJJTElUWSBPRiBTVUNIIERBTUFHRS4KICAqLwogCisjaW5jbHVkZSA8c3lz L2NkZWZzLmg+CiAKLSNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KICNpZm5kZWYgbGludAogX19SQ1NJ RCgiJE5ldEJTRDogYm9vdC5jLHYgMS45IDIwMDMvMDcvMjQgMTk6MjU6NDYgd3MgRXhwICQiKTsK IHN0YXRpYyBjb25zdCBjaGFyIHJjc2lkW10gPQpAQCAtNDQsMTMxICs0NCwxNjQgQEAKICNpbmNs dWRlIDxzdGRpby5oPgogI2luY2x1ZGUgPHVuaXN0ZC5oPgogCisjaW5jbHVkZSA8ZnMvbXNkb3Nm cy9ib290c2VjdC5oPgorI2luY2x1ZGUgPGZzL21zZG9zZnMvYnBiLmg+CiAjaW5jbHVkZSAiZXh0 LmgiCiAjaW5jbHVkZSAiZnN1dGlsLmgiCiAKIGludAotcmVhZGJvb3QoZG9zZnMsIGJvb3QpCi0J aW50IGRvc2ZzOwotCXN0cnVjdCBib290YmxvY2sgKmJvb3Q7CityZWFkYm9vdChpbnQgZG9zZnMs IHN0cnVjdCBib290YmxvY2sgKmJvb3QpCiB7Ci0JdV9jaGFyIGJsb2NrW0RPU0JPT1RCTE9DS1NJ WkVdOwotCXVfY2hhciBmc2luZm9bMiAqIERPU0JPT1RCTE9DS1NJWkVdOwotCXVfY2hhciBiYWNr dXBbRE9TQk9PVEJMT0NLU0laRV07CisgIHVuaW9uIGJvb3RzZWN0b3IgYnVmZmVyOworICB1bmlv biBib290c2VjdG9yIGJhY2t1cDsKKyAgc3RydWN0IGJ5dGVfYnBiNTAgKnBmYXQ1MDsKKyAgc3Ry dWN0IGJ5dGVfYnBiNzEwICpwZmF0NzEwOworICBzdHJ1Y3QgYnl0ZV9FeHRib290ICpwZmF0ZXh0 OworICBzdHJ1Y3QgZnNpbmZvIGZzc3RydWN0OwogCWludCByZXQgPSBGU09LOwogCQotCWlmIChy ZWFkKGRvc2ZzLCBibG9jaywgc2l6ZW9mIGJsb2NrKSA8IHNpemVvZiBibG9jaykgeworCWlmIChy ZWFkKGRvc2ZzLCAmYnVmZmVyLCBzaXplb2YodW5pb24gYm9vdHNlY3RvcikpCisgICAgICA8IHNp emVvZih1bmlvbiBib290c2VjdG9yKSkgewogCQlwZXJyb3IoImNvdWxkIG5vdCByZWFkIGJvb3Qg YmxvY2siKTsKIAkJcmV0dXJuIEZTRkFUQUw7CiAJfQogCi0JaWYgKGJsb2NrWzUxMF0gIT0gMHg1 NSB8fCBibG9ja1s1MTFdICE9IDB4YWEpIHsKLQkJcGZhdGFsKCJJbnZhbGlkIHNpZ25hdHVyZSBp biBib290IGJsb2NrOiAlMDJ4JTAyeCIsIGJsb2NrWzUxMV0sIGJsb2NrWzUxMF0pOworCWlmIChi dWZmZXIuYnM1MC5ic0Jvb3RTZWN0U2lnMCAhPSBCT09UU0lHMCB8fAorICAgICAgYnVmZmVyLmJz NTAuYnNCb290U2VjdFNpZzEgIT0gQk9PVFNJRzEpIHsKKwkJcGZhdGFsKCJJbnZhbGlkIHNpZ25h dHVyZSBpbiBib290IGJsb2NrOiAlMDJ4JTAyeCIsCisgICAgICAgICAgIGJ1ZmZlci5iczUwLmJz Qm9vdFNlY3RTaWcxLAorICAgICAgICAgICBidWZmZXIuYnM1MC5ic0Jvb3RTZWN0U2lnMCk7CiAJ CXJldHVybiBGU0ZBVEFMOwogCX0KKyAgCisgIC8qIHNldCB0aGUgYnBiIHN0cnVjdHMgdG8gdGhl IGJvb3Qgc2VjdG9yJ3MgYnBiICovCisgIHBmYXQ1MCA9IChzdHJ1Y3QgYnl0ZV9icGI1MCAqKSZi dWZmZXIuYnM1MC5ic0JQQjsKKyAgcGZhdDcxMCA9IChzdHJ1Y3QgYnl0ZV9icGI3MTAgKikmYnVm ZmVyLmJzNzEwLmJzQlBCOwogCi0JbWVtc2V0KGJvb3QsIDAsIHNpemVvZiAqYm9vdCk7CisJbWVt c2V0KGJvb3QsIDAsIHNpemVvZihzdHJ1Y3QgYm9vdGJsb2NrKSk7CiAJYm9vdC0+VmFsaWRGYXQg PSAtMTsKIAotCS8qIGRlY29kZSBiaW9zIHBhcmFtZXRlciBibG9jayAqLwotCWJvb3QtPkJ5dGVz UGVyU2VjID0gYmxvY2tbMTFdICsgKGJsb2NrWzEyXSA8PCA4KTsKLQlib290LT5TZWNQZXJDbHVz dCA9IGJsb2NrWzEzXTsKLQlib290LT5SZXNTZWN0b3JzID0gYmxvY2tbMTRdICsgKGJsb2NrWzE1 XSA8PCA4KTsKLQlib290LT5GQVRzID0gYmxvY2tbMTZdOwotCWJvb3QtPlJvb3REaXJFbnRzID0g YmxvY2tbMTddICsgKGJsb2NrWzE4XSA8PCA4KTsKLQlib290LT5TZWN0b3JzID0gYmxvY2tbMTld ICsgKGJsb2NrWzIwXSA8PCA4KTsKLQlib290LT5NZWRpYSA9IGJsb2NrWzIxXTsKLQlib290LT5G QVRzbWFsbCA9IGJsb2NrWzIyXSArIChibG9ja1syM10gPDwgOCk7Ci0JYm9vdC0+U2VjUGVyVHJh Y2sgPSBibG9ja1syNF0gKyAoYmxvY2tbMjVdIDw8IDgpOwotCWJvb3QtPkhlYWRzID0gYmxvY2tb MjZdICsgKGJsb2NrWzI3XSA8PCA4KTsKLQlib290LT5IaWRkZW5TZWNzID0gYmxvY2tbMjhdICsg KGJsb2NrWzI5XSA8PCA4KSArIChibG9ja1szMF0gPDwgMTYpICsgKGJsb2NrWzMxXSA8PCAyNCk7 Ci0JYm9vdC0+SHVnZVNlY3RvcnMgPSBibG9ja1szMl0gKyAoYmxvY2tbMzNdIDw8IDgpICsgKGJs b2NrWzM0XSA8PCAxNikgKyAoYmxvY2tbMzVdIDw8IDI0KTsKKwkvKiBkZWNvZGUgYmlvcyBwYXJh bWV0ZXIgYmxvY2sgYW5kIHN0b3JlIGluIGEgY29tcGFjdGVkCisgICAqIGFyY2hpdGVjdHVyZSBp bmRlcGVuZGVudCBkYXRhIHN0cnVjdHVyZSBmb3IgZnV0dXJlIHVzZQorICAgKi8KKwlib290LT5C eXRlc1BlclNlYyA9IGdldHVzaG9ydChwZmF0NTAtPmJwYkJ5dGVzUGVyU2VjKTsKKwlib290LT5T ZWNQZXJDbHVzdCA9IHBmYXQ1MC0+YnBiU2VjUGVyQ2x1c3Q7CisJYm9vdC0+UmVzU2VjdG9ycyA9 IGdldHVzaG9ydChwZmF0NTAtPmJwYlJlc1NlY3RvcnMpOworCWJvb3QtPkZBVHMgPSBwZmF0NTAt PmJwYkZBVHM7CisJYm9vdC0+Um9vdERpckVudHMgPSBnZXR1c2hvcnQocGZhdDUwLT5icGJSb290 RGlyRW50cyk7CisJYm9vdC0+U2VjdG9ycyA9IGdldHVzaG9ydChwZmF0NTAtPmJwYlNlY3RvcnMp OworCWJvb3QtPk1lZGlhID0gcGZhdDUwLT5icGJNZWRpYTsKKwlib290LT5TZWNQZXJUcmFjayA9 IGdldHVzaG9ydChwZmF0NTAtPmJwYlNlY1BlclRyYWNrKTsKKwlib290LT5IZWFkcyA9IGdldHVz aG9ydChwZmF0NTAtPmJwYkhlYWRzKTsKKwlib290LT5IaWRkZW5TZWNzID0gZ2V0dWxvbmcocGZh dDUwLT5icGJIaWRkZW5TZWNzKTsKKwlib290LT5IdWdlU2VjdG9ycyA9IGdldHVsb25nKHBmYXQ1 MC0+YnBiSHVnZVNlY3RvcnMpOwogCi0JYm9vdC0+RkFUc2VjcyA9IGJvb3QtPkZBVHNtYWxsOwor ICAvKiBmaXJzdCBkZWZhdWx0aW5nIHRvIEZBVDEyL0ZBVDE2IGZvciBudW1iZXIgb2YgRkFUIHNl Y3RvcnMgKi8KKwlib290LT5GQVRzZWNzID0gZ2V0dXNob3J0KHBmYXQ1MC0+YnBiRkFUc2Vjcyk7 CiAKLQlpZiAoIWJvb3QtPlJvb3REaXJFbnRzKQorCWlmIChib290LT5Sb290RGlyRW50cyA9PSAw KSB7CisgICAgLyogRkFUMzIgcGFyc2luZyAqLwogCQlib290LT5mbGFncyB8PSBGQVQzMjsKLQlp ZiAoYm9vdC0+ZmxhZ3MgJiBGQVQzMikgewotCQlib290LT5GQVRzZWNzID0gYmxvY2tbMzZdICsg KGJsb2NrWzM3XSA8PCA4KQotCQkJCSsgKGJsb2NrWzM4XSA8PCAxNikgKyAoYmxvY2tbMzldIDw8 IDI0KTsKLQkJaWYgKGJsb2NrWzQwXSAmIDB4ODApCi0JCQlib290LT5WYWxpZEZhdCA9IGJsb2Nr WzQwXSAmIDB4MGY7CisJCWJvb3QtPkZBVHNlY3MgPSBnZXR1bG9uZyhwZmF0NzEwLT5icGJCaWdG QVRzZWNzKTsKKwkJaWYgKHBmYXQ3MTAtPmJwYkV4dEZsYWdzWzBdICYgMHg4MCkgeworCQkJYm9v dC0+VmFsaWRGYXQgPSBwZmF0NzEwLT5icGJFeHRGbGFnc1swXSAmIDB4MGY7CisgICAgfQogCiAJ CS8qIGNoZWNrIHZlcnNpb24gbnVtYmVyOiAqLwotCQlpZiAoYmxvY2tbNDJdIHx8IGJsb2NrWzQz XSkgewotCQkJLyogQ29ycmVjdD8JCQkJWFhYICovCisgICAgaWYgKHBmYXQ3MTAtPmJwYkZTVmVy c1swXSAhPSAwIHx8CisgICAgICAgIHBmYXQ3MTAtPmJwYkZTVmVyc1sxXSAhPSAwKSB7CiAJCQlw ZmF0YWwoIlVua25vd24gZmlsZSBzeXN0ZW0gdmVyc2lvbjogJXguJXgiLAotCQkJICAgICAgIGJs b2NrWzQzXSwgYmxvY2tbNDJdKTsKKwkJCSAgICAgICBwZmF0NzEwLT5icGJGU1ZlcnNbMV0sCisg ICAgICAgICAgICAgcGZhdDcxMC0+YnBiRlNWZXJzWzBdKTsKIAkJCXJldHVybiBGU0ZBVEFMOwog CQl9Ci0JCWJvb3QtPlJvb3RDbCA9IGJsb2NrWzQ0XSArIChibG9ja1s0NV0gPDwgOCkKLQkJCSAg ICAgICArIChibG9ja1s0Nl0gPDwgMTYpICsgKGJsb2NrWzQ3XSA8PCAyNCk7Ci0JCWJvb3QtPkZT SW5mbyA9IGJsb2NrWzQ4XSArIChibG9ja1s0OV0gPDwgOCk7Ci0JCWJvb3QtPkJhY2t1cCA9IGJs b2NrWzUwXSArIChibG9ja1s1MV0gPDwgOCk7CisKKwkJYm9vdC0+Um9vdENsID0gZ2V0dWxvbmco cGZhdDcxMC0+YnBiUm9vdENsdXN0KTsKKwkJYm9vdC0+RlNJbmZvID0gZ2V0dXNob3J0KHBmYXQ3 MTAtPmJwYkZTSW5mbyk7CisJCWJvb3QtPkJhY2t1cCA9IGdldHVzaG9ydChwZmF0NzEwLT5icGJC YWNrdXApOwogCiAJCWlmIChsc2Vlayhkb3NmcywgYm9vdC0+RlNJbmZvICogYm9vdC0+Qnl0ZXNQ ZXJTZWMsIFNFRUtfU0VUKQotCQkgICAgIT0gYm9vdC0+RlNJbmZvICogYm9vdC0+Qnl0ZXNQZXJT ZWMKLQkJICAgIHx8IHJlYWQoZG9zZnMsIGZzaW5mbywgc2l6ZW9mIGZzaW5mbykKLQkJICAgICE9 IHNpemVvZiBmc2luZm8pIHsKKwkJICAgICE9IGJvb3QtPkZTSW5mbyAqIGJvb3QtPkJ5dGVzUGVy U2VjKSB7CisgICAgICBwZXJyb3IoImNvdWxkIG5vdCBzZWVrIHRvIGZzaW5mbyBibG9jayB0byBy ZWFkIik7CisgICAgICByZXR1cm4gRlNGQVRBTDsKKyAgICB9CisKKyAgICBpZiAocmVhZChkb3Nm cywgJmZzc3RydWN0LCBzaXplb2Yoc3RydWN0IGZzaW5mbykpCisgICAgICAgICE9IHNpemVvZihz dHJ1Y3QgZnNpbmZvKSkgewogCQkJcGVycm9yKCJjb3VsZCBub3QgcmVhZCBmc2luZm8gYmxvY2si KTsKIAkJCXJldHVybiBGU0ZBVEFMOwogCQl9Ci0JCWlmIChtZW1jbXAoZnNpbmZvLCAiUlJhQSIs IDQpCi0JCSAgICB8fCBtZW1jbXAoZnNpbmZvICsgMHgxZTQsICJyckFhIiwgNCkKLQkJICAgIHx8 IGZzaW5mb1sweDFmY10KLQkJICAgIHx8IGZzaW5mb1sweDFmZF0KLQkJICAgIHx8IGZzaW5mb1sw eDFmZV0gIT0gMHg1NQotCQkgICAgfHwgZnNpbmZvWzB4MWZmXSAhPSAweGFhCi0JCSAgICB8fCBm c2luZm9bMHgzZmNdCi0JCSAgICB8fCBmc2luZm9bMHgzZmRdCi0JCSAgICB8fCBmc2luZm9bMHgz ZmVdICE9IDB4NTUKLQkJICAgIHx8IGZzaW5mb1sweDNmZl0gIT0gMHhhYSkgeworCisJCWlmICht ZW1jbXAoZnNzdHJ1Y3QuZnNpc2lnMSwgIlJSYUEiLCA0KSB8fAorCQkgICAgbWVtY21wKGZzc3Ry dWN0LmZzaXNpZzIsICJyckFhIiwgNCkgfHwKKyAgICAgICAgbWVtY21wKGZzc3RydWN0LmZzaXNp ZzMsICJcMFwwXDEyNVwyNTIiLCA0KSB8fAorICAgICAgICBtZW1jbXAoZnNzdHJ1Y3QuZnNpc2ln NCwgIlwwXDBcMTI1XDI1MiIsIDQpKSB7CiAJCQlwd2FybigiSW52YWxpZCBzaWduYXR1cmUgaW4g ZnNpbmZvIGJsb2NrIik7CisKIAkJCWlmIChhc2soMCwgImZpeCIpKSB7Ci0JCQkJbWVtY3B5KGZz aW5mbywgIlJSYUEiLCA0KTsKLQkJCQltZW1jcHkoZnNpbmZvICsgMHgxZTQsICJyckFhIiwgNCk7 Ci0JCQkJZnNpbmZvWzB4MWZjXSA9IGZzaW5mb1sweDFmZF0gPSAwOwotCQkJCWZzaW5mb1sweDFm ZV0gPSAweDU1OwotCQkJCWZzaW5mb1sweDFmZl0gPSAweGFhOwotCQkJCWZzaW5mb1sweDNmY10g PSBmc2luZm9bMHgzZmRdID0gMDsKLQkJCQlmc2luZm9bMHgzZmVdID0gMHg1NTsKLQkJCQlmc2lu Zm9bMHgzZmZdID0gMHhhYTsKKyAgICAgICAgbWVtY3B5KGZzc3RydWN0LmZzaXNpZzEsICJSUmFB IiwgNCk7CisgICAgICAgIG1lbWNweShmc3N0cnVjdC5mc2lzaWcyLCAicnJBYSIsIDQpOworICAg ICAgICBtZW1jcHkoZnNzdHJ1Y3QuZnNpc2lnMywgIlwwXDBcMTI1XDI1MiIsIDQpOworICAgICAg ICBtZW1jcHkoZnNzdHJ1Y3QuZnNpc2lnNCwgIlwwXDBcMTI1XDI1MiIsIDQpOworCiAJCQkJaWYg KGxzZWVrKGRvc2ZzLCBib290LT5GU0luZm8gKiBib290LT5CeXRlc1BlclNlYywgU0VFS19TRVQp Ci0JCQkJICAgICE9IGJvb3QtPkZTSW5mbyAqIGJvb3QtPkJ5dGVzUGVyU2VjCi0JCQkJICAgIHx8 IHdyaXRlKGRvc2ZzLCBmc2luZm8sIHNpemVvZiBmc2luZm8pCi0JCQkJICAgICE9IHNpemVvZiBm c2luZm8pIHsKLQkJCQkJcGVycm9yKCJVbmFibGUgdG8gd3JpdGUgRlNJbmZvIik7CisJCQkJICAg ICE9IGJvb3QtPkZTSW5mbyAqIGJvb3QtPkJ5dGVzUGVyU2VjKSB7CisJCQkJCXBlcnJvcigiY291 bGQgbm90IHNlZWsgdG8gZnNpbmZvIGJsb2NrIHRvIGZpeC93cml0ZSIpOworCQkJCQlyZXR1cm4g RlNGQVRBTDsKKwkJCQl9CisKKyAgICAgICAgaWYgKHdyaXRlKGRvc2ZzLCAmZnNzdHJ1Y3QsIHNp emVvZihzdHJ1Y3QgZnNpbmZvKSkKKwkJCQkgICAgIT0gc2l6ZW9mKHN0cnVjdCBmc2luZm8pKSB7 CisJCQkJCXBlcnJvcigiY291bGQgbm90IHdyaXRlIGZpeGVkIGZzaW5mbyIpOwogCQkJCQlyZXR1 cm4gRlNGQVRBTDsKIAkJCQl9CisKIAkJCQlyZXQgPSBGU0JPT1RNT0Q7Ci0JCQl9IGVsc2UKKwkJ CX0KKyAgICAgIGVsc2UgeworICAgICAgICAvKiB3ZSBkaWRuJ3QgZml4IHRoZSBjb3JydXB0ZWQg RlNJbmZvIGJsb2NrICovCiAJCQkJYm9vdC0+RlNJbmZvID0gMDsKKyAgICAgIH0KIAkJfQotCQlp ZiAoYm9vdC0+RlNJbmZvKSB7Ci0JCQlib290LT5GU0ZyZWUgPSBmc2luZm9bMHgxZThdICsgKGZz aW5mb1sweDFlOV0gPDwgOCkKLQkJCQkgICAgICAgKyAoZnNpbmZvWzB4MWVhXSA8PCAxNikKLQkJ CQkgICAgICAgKyAoZnNpbmZvWzB4MWViXSA8PCAyNCk7Ci0JCQlib290LT5GU05leHQgPSBmc2lu Zm9bMHgxZWNdICsgKGZzaW5mb1sweDFlZF0gPDwgOCkKLQkJCQkgICAgICAgKyAoZnNpbmZvWzB4 MWVlXSA8PCAxNikKLQkJCQkgICAgICAgKyAoZnNpbmZvWzB4MWVmXSA8PCAyNCk7CisKKwkJaWYg KGJvb3QtPkZTSW5mbyAhPSAwKSB7CisJCQlib290LT5GU0ZyZWUgPSBnZXR1bG9uZyhmc3N0cnVj dC5mc2luZnJlZSk7CisJCQlib290LT5GU05leHQgPSBnZXR1bG9uZyhmc3N0cnVjdC5mc2lueHRm cmVlKTsKIAkJfQogCiAJCWlmIChsc2Vlayhkb3NmcywgYm9vdC0+QmFja3VwICogYm9vdC0+Qnl0 ZXNQZXJTZWMsIFNFRUtfU0VUKQotCQkgICAgIT0gYm9vdC0+QmFja3VwICogYm9vdC0+Qnl0ZXNQ ZXJTZWMKLQkJICAgIHx8IHJlYWQoZG9zZnMsIGJhY2t1cCwgc2l6ZW9mIGJhY2t1cCkgIT0gc2l6 ZW9mICBiYWNrdXApIHsKKwkJICAgICE9IGJvb3QtPkJhY2t1cCAqIGJvb3QtPkJ5dGVzUGVyU2Vj KSB7CisJCQlwZXJyb3IoImNvdWxkIG5vdCBzZWVrIHRvIHJlYWQgYmFja3VwIGJvb3RibG9jayIp OworCQkJcmV0dXJuIEZTRkFUQUw7CisJCX0KKworICAgIGlmIChyZWFkKGRvc2ZzLCAmYmFja3Vw LCBzaXplb2YodW5pb24gYm9vdHNlY3RvcikpCisgICAgICAgICE9IHNpemVvZih1bmlvbiBib290 c2VjdG9yKSkgewogCQkJcGVycm9yKCJjb3VsZCBub3QgcmVhZCBiYWNrdXAgYm9vdGJsb2NrIik7 CiAJCQlyZXR1cm4gRlNGQVRBTDsKIAkJfQotCQliYWNrdXBbNjVdID0gYmxvY2tbNjVdOwkJCQkv KiBYWFggKi8KLQkJaWYgKG1lbWNtcChibG9jayArIDExLCBiYWNrdXAgKyAxMSwgNzkpKSB7Ci0J CQkvKiBDb3JyZWN0PwkJCQkJWFhYICovCisKKyAgICAvLyBuZXZlciB3cml0dGVuIGJhY2sgdG8g ZGlzaworICAgIC8vYmFja3VwLmJzNzEwLmJzRXh0LmV4UmVzZXJ2ZWQxID0gYnVmZmVyLmJzNzEw LmJzRXh0LmV4UmVzZXJ2ZWQxOworCisJCWlmIChtZW1jbXAoYnVmZmVyLmJzNzEwLmJzQlBCLAor ICAgICAgICAgICAgICAgYmFja3VwLmJzNzEwLmJzQlBCLAorICAgICAgICAgICAgICAgc2l6ZW9m KHN0cnVjdCBicGI3MTApKSB8fAorICAgICAgICBtZW1jbXAoYnVmZmVyLmJzNzEwLmJzRXh0LAor ICAgICAgICAgICAgICAgYmFja3VwLmJzNzEwLmJzRXh0LAorICAgICAgICAgICAgICAgc2l6ZW9m KHN0cnVjdCBleHRib290KSkpIHsKKwogCQkJcGZhdGFsKCJiYWNrdXAgZG9lc24ndCBjb21wYXJl IHRvIHByaW1hcnkgYm9vdGJsb2NrIik7CiAJCQlpZiAoYWx3YXlzbm8pCiAJCQkJcGZhdGFsKCJc biIpOwogCQkJZWxzZQogCQkJCXJldHVybiBGU0ZBVEFMOwogCQl9Ci0JCS8qIENoZWNrIGJhY2t1 cCBGU0luZm8/CQkJCQlYWFggKi8KKworICAgIC8qIFVubmVjZXNzYXJ5IHRvIGNoZWNrIHRoZSBi YWNrdXAgRlNJbmZvIGJlY2F1c2UgdGhlcmUgaXNuJ3QKKyAgICAgKiBhbiBwaHlzaWNhbCBiYWNr dXAgY29weSBvZiB0aGUgRlNJbmZvIGJsb2NrLiAgVGhlcmUncyBvbmx5IGEKKyAgICAgKiBiYWNr dXAgb2YgdGhlIEZTSW5mbyBibG9jayBudW1iZXIsIHdoaWNoIHdhcyBjaGVja2VkIChic0JQQikg YWJvdmUuCisgICAgICovCiAJfQogCiAJYm9vdC0+Q2x1c3Rlck9mZnNldCA9IChib290LT5Sb290 RGlyRW50cyAqIDMyICsgYm9vdC0+Qnl0ZXNQZXJTZWMgLSAxKQpAQCAtMTkwLDEzICsyMjMsMTQg QEAKIAkJYm9vdC0+TnVtU2VjdG9ycyA9IGJvb3QtPlNlY3RvcnM7CiAJfSBlbHNlCiAJCWJvb3Qt Pk51bVNlY3RvcnMgPSBib290LT5IdWdlU2VjdG9yczsKLQlib290LT5OdW1DbHVzdGVycyA9IChi b290LT5OdW1TZWN0b3JzIC0gYm9vdC0+Q2x1c3Rlck9mZnNldCkgLyBib290LT5TZWNQZXJDbHVz dDsKKwlib290LT5OdW1DbHVzdGVycyA9IChib290LT5OdW1TZWN0b3JzIC0gYm9vdC0+Q2x1c3Rl ck9mZnNldCkKKyAgICAvIGJvb3QtPlNlY1BlckNsdXN0OwogCi0JaWYgKGJvb3QtPmZsYWdzJkZB VDMyKQorCWlmIChib290LT5mbGFncyAmIEZBVDMyKQogCQlib290LT5DbHVzdE1hc2sgPSBDTFVT VDMyX01BU0s7Ci0JZWxzZSBpZiAoYm9vdC0+TnVtQ2x1c3RlcnMgPCAoQ0xVU1RfUlNSVkQmQ0xV U1QxMl9NQVNLKSkKKwllbHNlIGlmIChib290LT5OdW1DbHVzdGVycyA8IChDTFVTVF9SU1JWRCAm IENMVVNUMTJfTUFTSykpCiAJCWJvb3QtPkNsdXN0TWFzayA9IENMVVNUMTJfTUFTSzsKLQllbHNl IGlmIChib290LT5OdW1DbHVzdGVycyA8IChDTFVTVF9SU1JWRCZDTFVTVDE2X01BU0spKQorCWVs c2UgaWYgKGJvb3QtPk51bUNsdXN0ZXJzIDwgKENMVVNUX1JTUlZEICYgQ0xVU1QxNl9NQVNLKSkK IAkJYm9vdC0+Q2x1c3RNYXNrID0gQ0xVU1QxNl9NQVNLOwogCWVsc2UgewogCQlwZmF0YWwoIkZp bGVzeXN0ZW0gdG9vIGJpZyAoJXUgY2x1c3RlcnMpIGZvciBub24tRkFUMzIgcGFydGl0aW9uIiwK QEAgLTIzMCwzMyArMjY0LDM4IEBACiB9CiAKIGludAotd3JpdGVmc2luZm8oZG9zZnMsIGJvb3Qp Ci0JaW50IGRvc2ZzOwotCXN0cnVjdCBib290YmxvY2sgKmJvb3Q7Cit3cml0ZWZzaW5mbyhpbnQg ZG9zZnMsIHN0cnVjdCBib290YmxvY2sgKmJvb3QpCiB7CisgIHN0cnVjdCBmc2luZm8gZnNzdHJ1 Y3Q7CiAJdV9jaGFyIGZzaW5mb1syICogRE9TQk9PVEJMT0NLU0laRV07CiAKLQlpZiAobHNlZWso ZG9zZnMsIGJvb3QtPkZTSW5mbyAqIGJvb3QtPkJ5dGVzUGVyU2VjLCBTRUVLX1NFVCkKLQkgICAg IT0gYm9vdC0+RlNJbmZvICogYm9vdC0+Qnl0ZXNQZXJTZWMKLQkgICAgfHwgcmVhZChkb3Nmcywg ZnNpbmZvLCBzaXplb2YgZnNpbmZvKSAhPSBzaXplb2YgZnNpbmZvKSB7Ci0JCXBlcnJvcigiY291 bGQgbm90IHJlYWQgZnNpbmZvIGJsb2NrIik7CisgIGlmIChsc2Vlayhkb3NmcywgYm9vdC0+RlNJ bmZvICogYm9vdC0+Qnl0ZXNQZXJTZWMsIFNFRUtfU0VUKQorICAgICAgIT0gYm9vdC0+RlNJbmZv ICogYm9vdC0+Qnl0ZXNQZXJTZWMpIHsKKyAgICBwZXJyb3IoImNvdWxkIG5vdCBzZWVrIHRvIGZz aW5mbyBibG9jayB0byByZWFkIik7CisgICAgcmV0dXJuIEZTRkFUQUw7CisgIH0KKworICBpZiAo cmVhZChkb3NmcywgJmZzc3RydWN0LCBzaXplb2Yoc3RydWN0IGZzaW5mbykpCisgICAgICAhPSBz aXplb2Yoc3RydWN0IGZzaW5mbykpIHsKKyAgICBwZXJyb3IoImNvdWxkIG5vdCByZWFkIGZzaW5m byBibG9jayIpOworICAgIHJldHVybiBGU0ZBVEFMOworICB9CisKKyAgcHV0dWxvbmcoJmZzc3Ry dWN0LmZzaW5mcmVlLCBib290LT5GU0ZyZWUpOworICBwdXR1bG9uZygmZnNzdHJ1Y3QuZnNpbnh0 ZnJlZSwgYm9vdC0+RlNOZXh0KTsKKworICBpZiAobHNlZWsoZG9zZnMsIGJvb3QtPkZTSW5mbyAq IGJvb3QtPkJ5dGVzUGVyU2VjLCBTRUVLX1NFVCkKKyAgICAgICE9IGJvb3QtPkZTSW5mbyAqIGJv b3QtPkJ5dGVzUGVyU2VjKSB7CisgICAgcGVycm9yKCJjb3VsZCBub3Qgc2VlayB0byBmc2luZm8g YmxvY2sgdG8gd3JpdGUgbmV3IGJsb2NrIik7CisgICAgcmV0dXJuIEZTRkFUQUw7CisgIH0KKwor CWlmICh3cml0ZShkb3NmcywgJmZzc3RydWN0LCBzaXplb2Yoc3RydWN0IGZzaW5mbykpCisJICAg ICE9IHNpemVvZihzdHJ1Y3QgZnNpbmZvKSkgeworICAgIHBlcnJvcigiY291bGQgbm90IHdyaXRl IGZpeGVkIGZzaW5mbyIpOwogCQlyZXR1cm4gRlNGQVRBTDsKIAl9Ci0JZnNpbmZvWzB4MWU4XSA9 ICh1X2NoYXIpYm9vdC0+RlNGcmVlOwotCWZzaW5mb1sweDFlOV0gPSAodV9jaGFyKShib290LT5G U0ZyZWUgPj4gOCk7Ci0JZnNpbmZvWzB4MWVhXSA9ICh1X2NoYXIpKGJvb3QtPkZTRnJlZSA+PiAx Nik7Ci0JZnNpbmZvWzB4MWViXSA9ICh1X2NoYXIpKGJvb3QtPkZTRnJlZSA+PiAyNCk7Ci0JZnNp bmZvWzB4MWVjXSA9ICh1X2NoYXIpYm9vdC0+RlNOZXh0OwotCWZzaW5mb1sweDFlZF0gPSAodV9j aGFyKShib290LT5GU05leHQgPj4gOCk7Ci0JZnNpbmZvWzB4MWVlXSA9ICh1X2NoYXIpKGJvb3Qt PkZTTmV4dCA+PiAxNik7Ci0JZnNpbmZvWzB4MWVmXSA9ICh1X2NoYXIpKGJvb3QtPkZTTmV4dCA+ PiAyNCk7Ci0JaWYgKGxzZWVrKGRvc2ZzLCBib290LT5GU0luZm8gKiBib290LT5CeXRlc1BlclNl YywgU0VFS19TRVQpCi0JICAgICE9IGJvb3QtPkZTSW5mbyAqIGJvb3QtPkJ5dGVzUGVyU2VjCi0J ICAgIHx8IHdyaXRlKGRvc2ZzLCBmc2luZm8sIHNpemVvZiBmc2luZm8pCi0JICAgICE9IHNpemVv ZiBmc2luZm8pIHsKLQkJcGVycm9yKCJVbmFibGUgdG8gd3JpdGUgRlNJbmZvIik7Ci0JCXJldHVy biBGU0ZBVEFMOwotCX0KKwogCS8qCiAJICogVGVjaG5pY2FsbHksIHdlIHNob3VsZCByZXR1cm4g RlNCT09UTU9EIGhlcmUuCiAJICoKQEAgLTI2NCw3ICszMDMsNyBAQAogCSAqIHN1cHBvcnQgZm9y IEZBVDMyKSBkb2Vzbid0IG1haW50YWluIHRoZSBGU0lORk8gYmxvY2sKIAkgKiBjb3JyZWN0bHks IGl0IGhhcyB0byBiZSBmaXhlZCBwcmV0dHkgb2Z0ZW4uCiAJICoKLQkgKiBUaGVyZWZvciwgd2Ug aGFuZGxlIHRoZSBGU0lORk8gYmxvY2sgb25seSBpbmZvcm1hbGx5LAorCSAqIFRoZXJlZm9yZSwg d2UgaGFuZGxlIHRoZSBGU0lORk8gYmxvY2sgb25seSBpbmZvcm1hbGx5LAogCSAqIGZpeGluZyBp dCBpZiBuZWNlc3NhcnksIGJ1dCBvdGhlcndpc2UgaWdub3JpbmcgdGhlCiAJICogZmFjdCB0aGF0 IGl0IHdhcyBpbmNvcnJlY3QuCiAJICovCi0tLSAvL2RlcG90L3Byb2plY3RzL3NvYzIwMDcvY2h1 Yi1tc2Rvc2ZzMi9zYmluL2ZzY2tfbXNkb3Nmcy9kb3Nmcy5oCTIwMDcvMDYvMjkgMDA6NDI6NDIK KysrIC8vZGVwb3QvcHJvamVjdHMvc29jMjAwNy9jaHViLW1zZG9zZnMyL3NiaW4vZnNja19tc2Rv c2ZzL2Rvc2ZzLmgJMjAwNy8wNy8wOCAwODowNTo1NQpAQCAtNTIsNyArNTIsNiBAQAogCXVfaW50 CUZBVHM7CQkJLyogbnVtYmVyIG9mIEZBVHMgKi8KIAl1X2ludAlSb290RGlyRW50czsJCS8qIG51 bWJlciBvZiByb290IGRpcmVjdG9yeSBlbnRyaWVzICovCiAJdV9pbnQJTWVkaWE7CQkJLyogbWVk aWEgZGVzY3JpcHRvciAqLwotCXVfaW50CUZBVHNtYWxsOwkJLyogbnVtYmVyIG9mIHNlY3RvcnMg cGVyIEZBVCAqLwogCXVfaW50CVNlY1BlclRyYWNrOwkJLyogc2VjdG9ycyBwZXIgdHJhY2sgKi8K IAl1X2ludAlIZWFkczsJCQkvKiBudW1iZXIgb2YgaGVhZHMgKi8KIAl1X2ludDMyX3QgU2VjdG9y czsJCS8qIHRvdGFsIG51bWJlciBvZiBzZWN0b3JzICovCi0tLSAvL2RlcG90L3Byb2plY3RzL3Nv YzIwMDcvY2h1Yi1tc2Rvc2ZzMi9zeXMvZnMvbXNkb3Nmcy9ib290c2VjdC5oCTIwMDcvMDYvMjkg MDA6NDI6NDIKKysrIC8vZGVwb3QvcHJvamVjdHMvc29jMjAwNy9jaHViLW1zZG9zZnMyL3N5cy9m cy9tc2Rvc2ZzL2Jvb3RzZWN0LmgJMjAwNy8wNy8wOCAwODowMTowOQpAQCAtMSw2ICsxLDkgQEAK IC8qICRGcmVlQlNEOiBzcmMvc3lzL2ZzL21zZG9zZnMvYm9vdHNlY3QuaCx2IDEuMTMgMjAwNS8w OS8yOSAxNDowOTo0NiBwZWFkYXIgRXhwICQgKi8KIC8qCSROZXRCU0Q6IGJvb3RzZWN0LmgsdiAx LjkgMTk5Ny8xMS8xNyAxNTozNjoxNyB3cyBFeHAgJAkqLwogCisjaWZuZGVmIF9GU19NU0RPU0ZT X0JPT1RTRUNUX0gKKyNkZWZpbmUgX0ZTX01TRE9TRlNfQk9PVFNFQ1RfSAorCiAvKi0KICAqIFdy aXR0ZW4gYnkgUGF1bCBQb3BlbGthIChwYXVscEB1dHMuYW1kYWhsLmNvbSkKICAqCkBAIC0xNyw2 ICsyMCw4IEBACiAgKiBPY3RvYmVyIDE5OTIKICAqLwogCisjaW5jbHVkZSA8ZnMvbXNkb3Nmcy9i cGIuaD4KKwogLyoKICAqIEZvcm1hdCBvZiBhIGJvb3Qgc2VjdG9yLiAgVGhpcyBpcyB0aGUgZmly c3Qgc2VjdG9yIG9uIGEgRE9TIGZsb3BweSBkaXNrCiAgKiBvciB0aGUgZmlzdCBzZWN0b3Igb2Yg YSBwYXJ0aXRpb24gb24gYSBoYXJkIGRpc2suICBCdXQsIGl0IGlzIG5vdCB0aGUKQEAgLTI1LDcg KzMwLDggQEAKIHN0cnVjdCBib290c2VjdG9yMzMgewogCXVfaW50OF90CWJzSnVtcFszXTsJCS8q IGp1bXAgaW5zdCBFOXh4eHggb3IgRUJ4eDkwICovCiAJaW50OF90CQlic09lbU5hbWVbOF07CQkv KiBPRU0gbmFtZSBhbmQgdmVyc2lvbiAqLwotCWludDhfdAkJYnNCUEJbMTldOwkJLyogQklPUyBw YXJhbWV0ZXIgYmxvY2sgKi8KKyAgLy8JaW50OF90CQlic0JQQlsxOV07CQkvKiBCSU9TIHBhcmFt ZXRlciBibG9jayAqLworICBzdHJ1Y3QgYnBiMzMgYnNCUEI7CQkvKiBCSU9TIHBhcmFtZXRlciBi bG9jayAqLwogCWludDhfdAkJYnNEcml2ZU51bWJlcjsJCS8qIGRyaXZlIG51bWJlciAoMHg4MCkg Ki8KIAlpbnQ4X3QJCWJzQm9vdENvZGVbNDc5XTsJLyogcGFkIHNvIHN0cnVjdCBpcyA1MTJiICov CiAJdV9pbnQ4X3QJYnNCb290U2VjdFNpZzA7CkBAIC0zNCwxMCArNDAsMjAgQEAKICNkZWZpbmUJ Qk9PVFNJRzEJMHhhYQogfTsKIAorI2RlZmluZQlFWEJPT1RTSUcJMHgyOQogc3RydWN0IGV4dGJv b3QgewogCWludDhfdAkJZXhEcml2ZU51bWJlcjsJCS8qIGRyaXZlIG51bWJlciAoMHg4MCkgKi8K IAlpbnQ4X3QJCWV4UmVzZXJ2ZWQxOwkJLyogcmVzZXJ2ZWQgKi8KIAlpbnQ4X3QJCWV4Qm9vdFNp Z25hdHVyZTsJLyogZXh0LiBib290IHNpZ25hdHVyZSAoMHgyOSkgKi8KKwl1X2ludDMyX3QJZXhW b2x1bWVJRDsJCS8qIHZvbHVtZSBJRCBudW1iZXIgKi8KKwlpbnQ4X3QJCWV4Vm9sdW1lTGFiZWxb MTFdOwkvKiB2b2x1bWUgbGFiZWwgKi8KKwlpbnQ4X3QJCWV4RmlsZVN5c1R5cGVbOF07CS8qIGZz IHR5cGUgKEZBVDEyIG9yIEZBVDE2KSAqLworfTsKKworc3RydWN0IGJ5dGVfZXh0Ym9vdCB7CisJ aW50OF90CQlleERyaXZlTnVtYmVyOwkJLyogZHJpdmUgbnVtYmVyICgweDgwKSAqLworCWludDhf dAkJZXhSZXNlcnZlZDE7CQkvKiByZXNlcnZlZCAqLworCWludDhfdAkJZXhCb290U2lnbmF0dXJl OwkvKiBleHQuIGJvb3Qgc2lnbmF0dXJlICgweDI5KSAqLwogI2RlZmluZQlFWEJPT1RTSUcJMHgy OQogCWludDhfdAkJZXhWb2x1bWVJRFs0XTsJCS8qIHZvbHVtZSBJRCBudW1iZXIgKi8KIAlpbnQ4 X3QJCWV4Vm9sdW1lTGFiZWxbMTFdOwkvKiB2b2x1bWUgbGFiZWwgKi8KQEAgLTQ3LDggKzYzLDgg QEAKIHN0cnVjdCBib290c2VjdG9yNTAgewogCXVfaW50OF90CWJzSnVtcFszXTsJCS8qIGp1bXAg aW5zdCBFOXh4eHggb3IgRUJ4eDkwICovCiAJaW50OF90CQlic09lbU5hbWVbOF07CQkvKiBPRU0g bmFtZSBhbmQgdmVyc2lvbiAqLwotCWludDhfdAkJYnNCUEJbMjVdOwkJLyogQklPUyBwYXJhbWV0 ZXIgYmxvY2sgKi8KLQlpbnQ4X3QJCWJzRXh0WzI2XTsJCS8qIEJvb3RzZWN0b3IgRXh0ZW5zaW9u ICovCisgIHN0cnVjdCBicGI1MCBic0JQQjsgICAgICAgLyogQklPUyBwYXJhbWV0ZXIgYmxvY2sg Ki8KKyAgc3RydWN0IGV4dGJvb3QgYnNFeHQ7ICAgICAvKiBCb290c2VjdG9yIEV4dGVuc2lvbiAq LwogCWludDhfdAkJYnNCb290Q29kZVs0NDhdOwkvKiBwYWQgc28gc3RydWN0dXJlIGlzIDUxMmIg Ki8KIAl1X2ludDhfdAlic0Jvb3RTZWN0U2lnMDsKIAl1X2ludDhfdAlic0Jvb3RTZWN0U2lnMTsK QEAgLTU5LDggKzc1LDggQEAKIHN0cnVjdCBib290c2VjdG9yNzEwIHsKIAl1X2ludDhfdAlic0p1 bXBbM107CQkvKiBqdW1wIGluc3QgRTl4eHh4IG9yIEVCeHg5MCAqLwogCWludDhfdAkJYnNPRU1O YW1lWzhdOwkJLyogT0VNIG5hbWUgYW5kIHZlcnNpb24gKi8KLQlpbnQ4X3QJCWJzQlBCWzUzXTsJ CS8qIEJJT1MgcGFyYW1ldGVyIGJsb2NrICovCi0JaW50OF90CQlic0V4dFsyNl07CQkvKiBCb290 c2VjdG9yIEV4dGVuc2lvbiAqLworICBzdHJ1Y3QgYnBiNzEwIGJzQlBCOwkJICAvKiBCSU9TIHBh cmFtZXRlciBibG9jayAqLworICBzdHJ1Y3QgZXh0Ym9vdCBic0V4dDsgICAgIC8qIEJvb3RzZWN0 b3IgRXh0ZW5zaW9uICovCiAJaW50OF90CQlic0Jvb3RDb2RlWzQyMF07CS8qIHBhZCBzbyBzdHJ1 Y3R1cmUgaXMgNTEyYiAqLwogCXVfaW50OF90CWJzQm9vdFNlY3RTaWcwOwogCXVfaW50OF90CWJz Qm9vdFNlY3RTaWcxOwpAQCAtNzQsMjAgKzkwLDUgQEAKIAlzdHJ1Y3QgYm9vdHNlY3RvcjcxMCBi czcxMDsKIH07CiAKLSNpZiAwCi0vKgotICogU2hvcnRoYW5kIGZvciBmaWVsZHMgaW4gdGhlIGJw Yi4KLSAqLwotI2RlZmluZQlic0J5dGVzUGVyU2VjCWJzQlBCLmJwYkJ5dGVzUGVyU2VjCi0jZGVm aW5lCWJzU2VjdFBlckNsdXN0CWJzQlBCLmJwYlNlY3RQZXJDbHVzdAotI2RlZmluZQlic1Jlc1Nl Y3RvcnMJYnNCUEIuYnBiUmVzU2VjdG9ycwotI2RlZmluZQlic0ZBVFMJCWJzQlBCLmJwYkZBVFMK LSNkZWZpbmUJYnNSb290RGlyRW50cwlic0JQQi5icGJSb290RGlyRW50cwotI2RlZmluZQlic1Nl Y3RvcnMJYnNCUEIuYnBiU2VjdG9ycwotI2RlZmluZQlic01lZGlhCQlic0JQQi5icGJNZWRpYQot I2RlZmluZQlic0ZBVHNlY3MJYnNCUEIuYnBiRkFUc2VjcwotI2RlZmluZQlic1NlY3RQZXJUcmFj awlic0JQQi5icGJTZWN0UGVyVHJhY2sKLSNkZWZpbmUJYnNIZWFkcwkJYnNCUEIuYnBiSGVhZHMK LSNkZWZpbmUJYnNIaWRkZW5TZWNzCWJzQlBCLmJwYkhpZGRlblNlY3MKLSNkZWZpbmUJYnNIdWdl U2VjdG9ycwlic0JQQi5icGJIdWdlU2VjdG9ycwogI2VuZGlmCisvLyBfRlNfTVNET1NGU19CT09U U0VDVF9ICi0tLSAvL2RlcG90L3Byb2plY3RzL3NvYzIwMDcvY2h1Yi1tc2Rvc2ZzMi9zeXMvZnMv bXNkb3Nmcy9icGIuaAkyMDA3LzA2LzI5IDAwOjQyOjQyCisrKyAvL2RlcG90L3Byb2plY3RzL3Nv YzIwMDcvY2h1Yi1tc2Rvc2ZzMi9zeXMvZnMvbXNkb3Nmcy9icGIuaAkyMDA3LzA3LzA4IDA4OjAx OjA5CkBAIC0xLDYgKzEsOSBAQAogLyogJEZyZWVCU0Q6IHNyYy9zeXMvZnMvbXNkb3Nmcy9icGIu aCx2IDEuMTUgMjAwNy8wMS8wNSAwNToyODo1NyByb2RyaWdjIEV4cCAkICovCiAvKgkkTmV0QlNE OiBicGIuaCx2IDEuNyAxOTk3LzExLzE3IDE1OjM2OjI0IHdzIEV4cCAkCSovCiAKKyNpZm5kZWYg X0ZTX01TRE9TRlNfQlBCX0gKKyNkZWZpbmUgX0ZTX01TRE9TRlNfQlBCX0gKKwogLyotCiAgKiBX cml0dGVuIGJ5IFBhdWwgUG9wZWxrYSAocGF1bHBAdXRzLmFtZGFobC5jb20pCiAgKgpAQCAtNzgs NyArODEsNyBAQAogCXVfaW50MzJfdAlicGJSb290Q2x1c3Q7CS8qIHN0YXJ0IGNsdXN0ZXIgZm9y IHJvb3QgZGlyZWN0b3J5ICovCiAJdV9pbnQxNl90CWJwYkZTSW5mbzsJLyogZmlsZXN5c3RlbSBp bmZvIHN0cnVjdHVyZSBzZWN0b3IgKi8KIAl1X2ludDE2X3QJYnBiQmFja3VwOwkvKiBiYWNrdXAg Ym9vdCBzZWN0b3IgKi8KLQkvKiBUaGVyZSBpcyBhIDEyIGJ5dGUgZmlsbGVyIGhlcmUsIGJ1dCB3 ZSBpZ25vcmUgaXQgKi8KKwl1X2ludDhfdCAgYnBiUmVzZXJ2ZWRbMTJdOyAvKiAxMiBieXRlIGZp bGxlciBoZXJlICovCiB9OwogCiAvKgpAQCAtMTUzLDcgKzE1Niw3IEBACiAJdV9pbnQ4X3QgYnBi Um9vdENsdXN0WzRdOwkvKiBzdGFydCBjbHVzdGVyIGZvciByb290IGRpcmVjdG9yeSAqLwogCXVf aW50OF90IGJwYkZTSW5mb1syXTsJCS8qIGZpbGVzeXN0ZW0gaW5mbyBzdHJ1Y3R1cmUgc2VjdG9y ICovCiAJdV9pbnQ4X3QgYnBiQmFja3VwWzJdOwkJLyogYmFja3VwIGJvb3Qgc2VjdG9yICovCi0J LyogVGhlcmUgaXMgYSAxMiBieXRlIGZpbGxlciBoZXJlLCBidXQgd2UgaWdub3JlIGl0ICovCisJ dV9pbnQ4X3QgYnBiUmVzZXJ2ZWRbMTJdOyAvKiAxMiBieXRlIGZpbGxlciBoZXJlICovCiB9Owog CiAvKgpAQCAtMTcwLDMgKzE3Myw2IEBACiAJdV9pbnQ4X3QgZnNpZmlsbDNbNTA4XTsKIAl1X2lu dDhfdCBmc2lzaWc0WzRdOwogfTsKKworI2VuZGlmCisvLyBfRlNfTVNET1NGU19CUEJfSAotLS0g Ly9kZXBvdC9wcm9qZWN0cy9zb2MyMDA3L2NodWItbXNkb3NmczIvc3lzL2ZzL21zZG9zZnMvZGly ZW50cnkuaAkyMDA3LzA2LzI5IDAwOjQyOjQyCisrKyAvL2RlcG90L3Byb2plY3RzL3NvYzIwMDcv Y2h1Yi1tc2Rvc2ZzMi9zeXMvZnMvbXNkb3Nmcy9kaXJlbnRyeS5oCTIwMDcvMDcvMDQgMDY6NTI6 MzEKQEAgLTg4LDcgKzg4LDcgQEAKICNkZWZpbmUJV0lOX0NOVAkJMHgzZgogCXVfaW50OF90CXdl UGFydDFbMTBdOwogCXVfaW50OF90CXdlQXR0cmlidXRlczsKLSNkZWZpbmUJQVRUUl9XSU45NQkw eDBmCisjZGVmaW5lCUFUVFJfV0lOOTUJMHgwZiAgLyogTG9uZyBkaXJlY3RvcnkgZW50cnlpZXMg Ki8KIAl1X2ludDhfdAl3ZVJlc2VydmVkMTsKIAl1X2ludDhfdAl3ZUNoa3N1bTsKIAl1X2ludDhf dAl3ZVBhcnQyWzEyXTsKLS0tIC8vZGVwb3QvcHJvamVjdHMvc29jMjAwNy9jaHViLW1zZG9zZnMy L3N5cy9mcy9tc2Rvc2ZzL21zZG9zZnNfdmZzb3BzLmMJMjAwNy8wNi8yOSAwMDo0Mjo0MgorKysg Ly9kZXBvdC9wcm9qZWN0cy9zb2MyMDA3L2NodWItbXNkb3NmczIvc3lzL2ZzL21zZG9zZnMvbXNk b3Nmc192ZnNvcHMuYwkyMDA3LzA3LzA4IDA4OjAxOjA5CkBAIC00MzAsOSArNDMwLDkgQEAKIAkJ Z290byBlcnJvcl9leGl0OwogCWJwLT5iX2ZsYWdzIHw9IEJfQUdFOwogCWJzcCA9ICh1bmlvbiBi b290c2VjdG9yICopYnAtPmJfZGF0YTsKLQliMzMgPSAoc3RydWN0IGJ5dGVfYnBiMzMgKilic3At PmJzMzMuYnNCUEI7Ci0JYjUwID0gKHN0cnVjdCBieXRlX2JwYjUwICopYnNwLT5iczUwLmJzQlBC OwotCWI3MTAgPSAoc3RydWN0IGJ5dGVfYnBiNzEwICopYnNwLT5iczcxMC5ic0JQQjsKKwliMzMg PSAoc3RydWN0IGJ5dGVfYnBiMzMgKikmYnNwLT5iczMzLmJzQlBCOworCWI1MCA9IChzdHJ1Y3Qg Ynl0ZV9icGI1MCAqKSZic3AtPmJzNTAuYnNCUEI7CisJYjcxMCA9IChzdHJ1Y3QgYnl0ZV9icGI3 MTAgKikmYnNwLT5iczcxMC5ic0JQQjsKIAogI2lmbmRlZiBNU0RPU0ZTX05PQ0hFQ0tTSUcKIAlp ZiAoYnNwLT5iczUwLmJzQm9vdFNlY3RTaWcwICE9IEJPT1RTSUcwCkBAIC00ODcsNyArNDg3LDYg QEAKIAogCS8qIFhYWCAtIFdlIHNob3VsZCBwcm9iYWJseSBjaGVjayBtb3JlIHZhbHVlcyBoZXJl ICovCiAJaWYgKCFwbXAtPnBtX0J5dGVzUGVyU2VjIHx8ICFTZWNQZXJDbHVzdAotCQl8fCAhcG1w LT5wbV9IZWFkcwogI2lmZGVmIFBDOTgKICAgICAJCXx8ICFwbXAtPnBtX1NlY1BlclRyYWNrIHx8 IHBtcC0+cG1fU2VjUGVyVHJhY2sgPiAyNTUpIHsKICNlbHNlCi0tLSAvL2RlcG90L3Byb2plY3Rz L3NvYzIwMDcvY2h1Yi1tc2Rvc2ZzMi9zeXMvZ2VvbS9sYWJlbC9nX2xhYmVsX21zZG9zZnMuYwky MDA3LzA2LzI5IDAwOjQyOjQyCisrKyAvL2RlcG90L3Byb2plY3RzL3NvYzIwMDcvY2h1Yi1tc2Rv c2ZzMi9zeXMvZ2VvbS9sYWJlbC9nX2xhYmVsX21zZG9zZnMuYwkyMDA3LzA3LzA5IDE4OjU4OjU4 CkBAIC0xLDYgKzEsNyBAQAogLyotCiAgKiBDb3B5cmlnaHQgKGMpIDIwMDQgUGF3ZWwgSmFrdWIg RGF3aWRlayA8cGpkQEZyZWVCU0Qub3JnPgogICogQ29weXJpZ2h0IChjKSAyMDA2IFRvYmlhcyBS ZWlmZW5iZXJnZXIKKyAqIENvcHlyaWdodCAoYykgMjAwNyBCcmlhbiBDaHUgPGNodWJARnJlZUJT RC5vcmc+CiAgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgogICoKICAqIFJlZGlzdHJpYnV0aW9uIGFu ZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dApAQCAtMzMs MjAgKzM0LDI3IEBACiAjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgogI2luY2x1ZGUgPHN5cy9tYWxs b2MuaD4KIAorI2luY2x1ZGUgPGZzL21zZG9zZnMvYm9vdHNlY3QuaD4KKyNpbmNsdWRlIDxmcy9t c2Rvc2ZzL2JwYi5oPgorI2luY2x1ZGUgPGZzL21zZG9zZnMvZGlyZW50cnkuaD4KKwogI2luY2x1 ZGUgPGdlb20vZ2VvbS5oPgogI2luY2x1ZGUgPGdlb20vbGFiZWwvZ19sYWJlbC5oPgotI2luY2x1 ZGUgPGdlb20vbGFiZWwvZ19sYWJlbF9tc2Rvc2ZzLmg+CiAKICNkZWZpbmUgR19MQUJFTF9NU0RP U0ZTX0RJUgkibXNkb3NmcyIKICNkZWZpbmUgTEFCRUxfTk9fTkFNRQkJIk5PIE5BTUUgICAgIgog CisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisKIHN0YXRpYyB2b2lkCiBnX2xhYmVsX21zZG9zZnNf dGFzdGUoc3RydWN0IGdfY29uc3VtZXIgKmNwLCBjaGFyICpsYWJlbCwgc2l6ZV90IHNpemUpCiB7 CiAJc3RydWN0IGdfcHJvdmlkZXIgKnBwOwotCUZBVF9CU0JQQiAqcGZhdF9ic2JwYjsKLQlGQVQz Ml9CU0JQQiAqcGZhdDMyX2JzYnBiOwotCUZBVF9ERVMgKnBmYXRfZW50cnk7CisgIHVuaW9uIGJv b3RzZWN0b3IgKmJzcDsKKyAgc3RydWN0IGJ5dGVfYnBiNTAgKnBmYXRfYnBiNTA7CisgIHN0cnVj dCBieXRlX2JwYjcxMCAqcGZhdF9icGI3MTA7CisgIHN0cnVjdCBleHRib290ICpwZmF0X2V4dGJv b3Q7CisgIHN0cnVjdCBkaXJlbnRyeSogcGZhdF9lbnRyeTsKIAl1aW50OF90ICpzZWN0b3IwLCAq c2VjdG9yOwogCXVpbnQzMl90IGk7CiAKQEAgLTc0LDEwICs4MiwxNyBAQAogCWlmIChzZWN0b3Iw ID09IE5VTEwpCiAJCXJldHVybjsKIAorICAvKiBTZXQgdGhlIGJvb3RzZWN0b3IvYm9vdCBwYXJh bWV0ZXIgYmxvY2sgdG8gYSBzdHJ1Y3QuICovCisgIGJzcCA9ICh1bmlvbiBib290c2VjdG9yICop c2VjdG9yMDsKKyAgcGZhdF9icGI1MCA9IChzdHJ1Y3QgYnl0ZV9icGI1MCAqKSAmYnNwLT5iczUw LmJzQlBCOworICBwZmF0X2JwYjcxMCA9IChzdHJ1Y3QgYnl0ZV9icGI3MTAgKikgJmJzcC0+YnM3 MTAuYnNCUEI7CisKIAkvKiBDaGVjayBmb3IgdGhlIEZBVCBib290IHNlY3RvciBzaWduYXR1cmUu ICovCi0JaWYgKHNlY3RvcjBbNTEwXSAhPSAweDU1IHx8IHNlY3RvcjBbNTExXSAhPSAweGFhKSB7 Ci0JCUdfTEFCRUxfREVCVUcoMSwgIk1TRE9TRlM6ICVzOiBubyBGQVQgc2lnbmF0dXJlIGZvdW5k LiIsCi0JCSAgICBwcC0+bmFtZSk7CisJaWYgKGJzcC0+YnM1MC5ic0Jvb3RTZWN0U2lnMCAhPSBC T09UU0lHMCB8fAorICAgICAgYnNwLT5iczUwLmJzQm9vdFNlY3RTaWcxICE9IEJPT1RTSUcxKSB7 CisJCUdfTEFCRUxfREVCVUcoMSwKKyAgICAgICAgIk1TRE9TRlM6ICVzOiBubyBGQVQgc2lnbmF0 dXJlIGZvdW5kLiIsCisgICAgICAgIHBwLT5uYW1lKTsKIAkJZ290byBlcnJvcjsKIAl9CiAKQEAg LTg1LDQyICsxMDAsNTYgQEAKIAkvKgogCSAqIFRlc3QgaWYgdGhpcyBpcyByZWFsbHkgYSBGQVQg dm9sdW1lIGFuZCBkZXRlcm1pbmUgdGhlIEZBVCB0eXBlLgogCSAqLworCWlmIChnZXR1c2hvcnQo cGZhdF9icGI1MC0+YnBiRkFUc2VjcykgIT0gMCkgeworICAgIC8qIFRoZSBleHRlbmRlZCBib290 IHJlY29yZCBpcyBvbmUgcGxhY2UgZm9yIEZBVDEyL0ZBVDE2CisgICAgICogYW5kIGFub3RoZXIg Zm9yIEZBVDMyLgorICAgICAqLwogCi0JcGZhdF9ic2JwYiA9IChGQVRfQlNCUEIgKilzZWN0b3Iw OwotCXBmYXQzMl9ic2JwYiA9IChGQVQzMl9CU0JQQiAqKXNlY3RvcjA7CisgICAgcGZhdF9leHRi b290ID0gKHN0cnVjdCBleHRib290ICopICZic3AtPmJzNTAuYnNFeHQ7CiAKLQlpZiAoVUlOVDE2 QllURVMocGZhdF9ic2JwYi0+QlBCX0ZBVFN6MTYpICE9IDApIHsKIAkJLyoKLQkJICogSWYgdGhl IEJQQl9GQVRTejE2IGZpZWxkIGlzIG5vdCB6ZXJvIGFuZCB0aGUgc3RyaW5nICJGQVQiIGlzCi0J CSAqIGF0IHRoZSByaWdodCBwbGFjZSwgdGhpcyBzaG91bGQgYmUgYSBGQVQxMiBvciBGQVQxNiB2 b2x1bWUuCisJCSAqIElmIHRoZSBCUEJfRkFUU3oxNi9icGJGQVRzZWNzIGZpZWxkIGlzIG5vdCB6 ZXJvIGFuZAorICAgICAqIHRoZSBzdHJpbmcgIkZBVCIgaXMgYXQgdGhlIHJpZ2h0IHBsYWNlLCB0 aGlzIHNob3VsZAorICAgICAqIGJlIGEgRkFUMTIgb3IgRkFUMTYgdm9sdW1lLgogCQkgKi8KLQkJ aWYgKHN0cm5jbXAocGZhdF9ic2JwYi0+QlNfRmlsU3lzVHlwZSwgIkZBVCIsIDMpICE9IDApIHsK KworCQlpZiAoc3RybmNtcChwZmF0X2V4dGJvb3QtPmV4RmlsZVN5c1R5cGUsICJGQVQiLCAzKSAh PSAwKSB7CiAJCQlHX0xBQkVMX0RFQlVHKDEsCiAJCQkgICAgIk1TRE9TRlM6ICVzOiBGQVQxMi8x NiB2b2x1bWUgbm90IHZhbGlkLiIsCiAJCQkgICAgcHAtPm5hbWUpOwogCQkJZ290byBlcnJvcjsK IAkJfQotCQlHX0xBQkVMX0RFQlVHKDEsICJNU0RPU0ZTOiAlczogRkFUMTIvRkFUMTYgdm9sdW1l IGRldGVjdGVkLiIsCi0JCSAgICBwcC0+bmFtZSk7CisJCUdfTEFCRUxfREVCVUcoMSwKKyAgICAg ICAgIk1TRE9TRlM6ICVzOiBGQVQxMi9GQVQxNiB2b2x1bWUgZGV0ZWN0ZWQuIiwKKyAgICAgICAg cHAtPm5hbWUpOwogCiAJCS8qIEEgdm9sdW1lIHdpdGggbm8gbmFtZSBzaG91bGQgaGF2ZSAiTk8g TkFNRSAgICAiIGFzIGxhYmVsLiAqLwotCQlpZiAoc3RybmNtcChwZmF0X2JzYnBiLT5CU19Wb2xM YWIsIExBQkVMX05PX05BTUUsCi0JCSAgICBzaXplb2YocGZhdF9ic2JwYi0+QlNfVm9sTGFiKSkg PT0gMCkgeworCQlpZiAoc3RybmNtcChwZmF0X2V4dGJvb3QtPmV4Vm9sdW1lTGFiZWwsIExBQkVM X05PX05BTUUsCisJCSAgICBzaXplb2YocGZhdF9leHRib290LT5leFZvbHVtZUxhYmVsKSkgPT0g MCkgewogCQkJR19MQUJFTF9ERUJVRygxLAogCQkJICAgICJNU0RPU0ZTOiAlczogRkFUMTIvMTYg dm9sdW1lIGhhcyBubyBuYW1lLiIsCiAJCQkgICAgcHAtPm5hbWUpOwogCQkJZ290byBlcnJvcjsK IAkJfQotCQlzdHJsY3B5KGxhYmVsLCBwZmF0X2JzYnBiLT5CU19Wb2xMYWIsCi0JCSAgICBNSU4o c2l6ZSwgc2l6ZW9mKHBmYXRfYnNicGItPkJTX1ZvbExhYikgKyAxKSk7Ci0JfSBlbHNlIGlmIChV SU5UMzJCWVRFUyhwZmF0MzJfYnNicGItPkJQQl9GQVRTejMyKSAhPSAwKSB7CisJCXN0cmxjcHko bGFiZWwsIHBmYXRfZXh0Ym9vdC0+ZXhWb2x1bWVMYWJlbCwKKwkJICAgIE1JTihzaXplLCBzaXpl b2YocGZhdF9leHRib290LT5leFZvbHVtZUxhYmVsKSArIDEpKTsKKwl9CisgIGVsc2UgaWYgKGdl dHVsb25nKHBmYXRfYnBiNzEwLT5icGJCaWdGQVRzZWNzKSAhPSAwKSB7CiAJCXVpbnQzMl90IGZh dF9GaXJzdERhdGFTZWN0b3IsIGZhdF9CeXRlc1BlclNlY3Rvciwgb2Zmc2V0OwogCisgICAgLyog VGhlIGV4dGVuZGVkIGJvb3QgcmVjb3JkIGlzIG9uZSBwbGFjZSBmb3IgRkFUMTIvRkFUMTYKKyAg ICAgKiBhbmQgYW5vdGhlciBmb3IgRkFUMzIuCisgICAgICovCisKKyAgICBwZmF0X2V4dGJvb3Qg PSAoc3RydWN0IGV4dGJvb3QgKikgJmJzcC0+YnM3MTAuYnNFeHQ7CisKIAkJLyoKLQkJICogSWYg dGhlIEJQQl9GQVRTejMyIGZpZWxkIGlzIG5vdCB6ZXJvIGFuZCB0aGUgc3RyaW5nICJGQVQiIGlz Ci0JCSAqIGF0IHRoZSByaWdodCBwbGFjZSwgdGhpcyBzaG91bGQgYmUgYSBGQVQzMiB2b2x1bWUu CisJCSAqIElmIHRoZSBCUEJfRkFUU3ozMi9icGJCaWdGQVRzZWNzIGZpZWxkIGlzIG5vdCB6ZXJv CisgICAgICogYW5kIHRoZSBzdHJpbmcgIkZBVCIgaXMgYXQgdGhlIHJpZ2h0IHBsYWNlLCB0aGlz CisgICAgICogc2hvdWxkIGJlIGEgRkFUMzIgdm9sdW1lLgogCQkgKi8KLQkJaWYgKHN0cm5jbXAo cGZhdDMyX2JzYnBiLT5CU19GaWxTeXNUeXBlLCAiRkFUIiwgMykgIT0gMCkgeworCisJCWlmIChz dHJuY21wKHBmYXRfZXh0Ym9vdC0+ZXhGaWxlU3lzVHlwZSwgIkZBVCIsIDMpICE9IDApIHsKIAkJ CUdfTEFCRUxfREVCVUcoMSwgIk1TRE9TRlM6ICVzOiBGQVQzMiB2b2x1bWUgbm90IHZhbGlkLiIs CiAJCQkgICAgcHAtPm5hbWUpOwogCQkJZ290byBlcnJvcjsKQEAgLTEzMSwxMCArMTYwLDEwIEBA CiAJCS8qCiAJCSAqIElmIHRoZSB2b2x1bWUgbGFiZWwgaXMgbm90ICJOTyBOQU1FICAgICIgd2Un cmUgZG9uZS4KIAkJICovCi0JCWlmIChzdHJuY21wKHBmYXQzMl9ic2JwYi0+QlNfVm9sTGFiLCBM QUJFTF9OT19OQU1FLAotCQkgICAgc2l6ZW9mKHBmYXQzMl9ic2JwYi0+QlNfVm9sTGFiKSkgIT0g MCkgewotCQkJc3RybGNweShsYWJlbCwgcGZhdDMyX2JzYnBiLT5CU19Wb2xMYWIsCi0JCQkgICAg TUlOKHNpemUsIHNpemVvZihwZmF0MzJfYnNicGItPkJTX1ZvbExhYikgKyAxKSk7CisJCWlmIChz dHJuY21wKHBmYXRfZXh0Ym9vdC0+ZXhWb2x1bWVMYWJlbCwgTEFCRUxfTk9fTkFNRSwKKwkJICAg IHNpemVvZihwZmF0X2V4dGJvb3QtPmV4Vm9sdW1lTGFiZWwpKSA9PSAwKSB7CisJCQlzdHJsY3B5 KGxhYmVsLCBwZmF0X2V4dGJvb3QtPmV4Vm9sdW1lTGFiZWwsCisJCQkgICAgTUlOKHNpemUsIHNp emVvZihwZmF0X2V4dGJvb3QtPmV4Vm9sdW1lTGFiZWwpICsgMSkpOwogCQkJZ290byBlbmRvZmNo ZWNrczsKIAkJfQogCkBAIC0xNDQsMTAgKzE3MywxMCBAQAogCQkgKiB0aGUgcm9vdCBkaXJlY3Rv cnkuCiAJCSAqLwogCQlmYXRfRmlyc3REYXRhU2VjdG9yID0KLQkJICAgIFVJTlQxNkJZVEVTKHBm YXQzMl9ic2JwYi0+QlBCX1JzdmRTZWNDbnQpICsKLQkJICAgIChwZmF0MzJfYnNicGItPkJQQl9O dW1GQVRzICoKLQkJICAgICBVSU5UMzJCWVRFUyhwZmF0MzJfYnNicGItPkJQQl9GQVRTejMyKSk7 Ci0JCWZhdF9CeXRlc1BlclNlY3RvciA9IFVJTlQxNkJZVEVTKHBmYXQzMl9ic2JwYi0+QlBCX0J5 dHNQZXJTZWMpOworCQkgICAgZ2V0dXNob3J0KHBmYXRfYnBiNzEwLT5icGJSZXNTZWN0b3JzKSAr CisJCSAgICAocGZhdF9icGI3MTAtPmJwYkZBVHMgKgorCQkgICAgIGdldHVsb25nKHBmYXRfYnBi NzEwLT5icGJCaWdGQVRzZWNzKSk7CisJCWZhdF9CeXRlc1BlclNlY3RvciA9IGdldHVzaG9ydChw ZmF0X2JwYjcxMC0+YnBiQnl0ZXNQZXJTZWMpOwogCiAJCUdfTEFCRUxfREVCVUcoMiwKIAkJICAg ICJNU0RPU0ZTOiBGQVRfRmlyc3REYXRhU2VjdG9yPTB4JXgsIEZBVF9CeXRlc1BlclNlY3Rvcj0l ZCIsCkBAIC0xNjAsMTAgKzE4OSwxMCBAQAogCQkJaWYgKHNlY3RvciA9PSBOVUxMKQogCQkJCWdv dG8gZXJyb3I7CiAKLQkJCXBmYXRfZW50cnkgPSAoRkFUX0RFUyAqKXNlY3RvcjsKKwkJCXBmYXRf ZW50cnkgPSAoc3RydWN0IGRpcmVudHJ5ICopc2VjdG9yOwogCQkJZG8gewogCQkJCS8qIE5vIG1v cmUgZW50cmllcyBhdmFpbGFibGUuICovCi0JCQkJaWYgKHBmYXRfZW50cnktPkRJUl9OYW1lWzBd ID09IDApIHsKKwkJCQlpZiAocGZhdF9lbnRyeS0+ZGVOYW1lWzBdID09IDApIHsKIAkJCQkJR19M QUJFTF9ERUJVRygxLCAiTVNET1NGUzogJXM6ICIKIAkJCQkJICAgICJGQVQzMiB2b2x1bWUgaGFz IG5vIG5hbWUuIiwKIAkJCQkJICAgIHBwLT5uYW1lKTsKQEAgLTE3MSwxMCArMjAwLDkgQEAKIAkJ CQl9CiAKIAkJCQkvKiBTa2lwIGVtcHR5IG9yIGxvbmcgbmFtZSBlbnRyaWVzLiAqLwotCQkJCWlm IChwZmF0X2VudHJ5LT5ESVJfTmFtZVswXSA9PSAweGU1IHx8Ci0JCQkJICAgIChwZmF0X2VudHJ5 LT5ESVJfQXR0ciAmCi0JCQkJICAgICBGQVRfREVTX0FUVFJfTE9OR19OQU1FKSA9PQotCQkJCSAg ICBGQVRfREVTX0FUVFJfTE9OR19OQU1FKSB7CisJCQkJaWYgKHBmYXRfZW50cnktPmRlTmFtZVsw XSA9PSAweGU1IHx8CisJCQkJICAgIChwZmF0X2VudHJ5LT5kZUF0dHJpYnV0ZXMgJgorCQkJCSAg ICAgQVRUUl9XSU45NSkgPT0gQVRUUl9XSU45NSkgewogCQkJCQljb250aW51ZTsKIAkJCQl9CiAK QEAgLTE4MiwxMSArMjEwLDExIEBACiAJCQkJICogVGhlIG5hbWUgb2YgdGhlIGVudHJ5IGlzIHRo ZSB2b2x1bWUgbGFiZWwgaWYKIAkJCQkgKiBBVFRSX1ZPTFVNRV9JRCBpcyBzZXQuCiAJCQkJICov Ci0JCQkJaWYgKHBmYXRfZW50cnktPkRJUl9BdHRyICYKLQkJCQkgICAgRkFUX0RFU19BVFRSX1ZP TFVNRV9JRCkgewotCQkJCQlzdHJsY3B5KGxhYmVsLCBwZmF0X2VudHJ5LT5ESVJfTmFtZSwKKwkJ CQlpZiAocGZhdF9lbnRyeS0+ZGVBdHRyaWJ1dGVzICYKKwkJCQkgICAgQVRUUl9ESVJFQ1RPUlkp IHsKKwkJCQkJc3RybGNweShsYWJlbCwgcGZhdF9lbnRyeS0+ZGVOYW1lLAogCQkJCQkgICAgTUlO KHNpemUsCi0JCQkJCSAgICBzaXplb2YocGZhdF9ic2JwYi0+QlNfVm9sTGFiKSArIDEpKTsKKwkJ CQkJICAgIHNpemVvZihwZmF0X2V4dGJvb3QtPmV4Vm9sdW1lTGFiZWwpICsgMSkpOwogCQkJCQln b3RvIGVuZG9mY2hlY2tzOwogCQkJCX0KIAkJCX0gd2hpbGUoKHVpbnQ4X3QgKikoKytwZmF0X2Vu dHJ5KSA8Cg== ------=_Part_31586_12249243.1184314751446-- From owner-freebsd-fs@FreeBSD.ORG Fri Jul 13 09:22:49 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26A5F16A404 for ; Fri, 13 Jul 2007 09:22:49 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D351413C461 for ; Fri, 13 Jul 2007 09:22:48 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I9HMD-0001S5-DD for freebsd-fs@freebsd.org; Fri, 13 Jul 2007 11:22:37 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Jul 2007 11:22:37 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Jul 2007 11:22:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Fri, 13 Jul 2007 11:22:22 +0200 Lines: 35 Message-ID: References: <86847.26083.qm@web63012.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5DFB069CB167438D6E6015E8" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <86847.26083.qm@web63012.mail.re1.yahoo.com> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: help needed - tuning a filesystem for rm and cp ? (MORE) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 09:22:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5DFB069CB167438D6E6015E8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Gore Jarold wrote: > vfs.ufs.dirhash_maxmem: 2097152 > vfs.ufs.dirhash_mem: 2065716 >=20 >=20 > Interesting at all ? Yes, you've used up all dirhash_mem. Since you have enough memory, try=20 increasing dirhash_maxmem by a factor of 4 or more and testing again. It = might help you with large directories (lots of files). --------------enig5DFB069CB167438D6E6015E8 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.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGl0ROldnAQVacBcgRAhAKAJ0YyaaDQ0Nf4zLlfJ6AQwopLx25+gCg2x/t Uv1onzDyAJxtcNLzph56kFA= =Q0Mf -----END PGP SIGNATURE----- --------------enig5DFB069CB167438D6E6015E8-- From owner-freebsd-fs@FreeBSD.ORG Fri Jul 13 13:44:37 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C64116A400; Fri, 13 Jul 2007 13:44:37 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D1CAA13C4A3; Fri, 13 Jul 2007 13:44:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 6C47D17380; Fri, 13 Jul 2007 13:19:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l6DDJ7cn080556; Fri, 13 Jul 2007 13:19:07 GMT (envelope-from phk@critter.freebsd.dk) To: "Brian Chu" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 13 Jul 2007 04:19:11 -0400." <47a4f3080707130119xbee4477y3e96d27763f793aa@mail.gmail.com> Date: Fri, 13 Jul 2007 13:19:07 +0000 Message-ID: <80555.1184332747@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-fs@freebsd.org Subject: Re: msdosfs header unification patch X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 13:44:37 -0000 In message <47a4f3080707130119xbee4477y3e96d27763f793aa@mail.gmail.com>, "Brian Chu" writes: >The included diff is the work I've done on header consolidation in >msdosfs. The three areas I concentrated on where: > >- sys/fs/msdosfs/ >- sys/geom/label/g_label_msdosfs.* >- sbin/fsck_msdosfs/ This is *SO* great that I hate to point out that you missed one set of copies: src/sbin/newfs_msdos/newfs_msdos.c But THANK YOU! I have hated these multiple incompatible copies for sooo many years... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-fs@FreeBSD.ORG Fri Jul 13 13:54:13 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FF2616A406 for ; Fri, 13 Jul 2007 13:54:13 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 01BD513C4BD for ; Fri, 13 Jul 2007 13:54:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l6DDs8CX004626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 23:54:10 +1000 Date: Fri, 13 Jul 2007 23:54:08 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Brian Chu In-Reply-To: <47a4f3080707130119xbee4477y3e96d27763f793aa@mail.gmail.com> Message-ID: <20070713223111.P2242@besplex.bde.org> References: <47a4f3080707130119xbee4477y3e96d27763f793aa@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: msdosfs header unification patch X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 13:54:13 -0000 On Fri, 13 Jul 2007, Brian Chu wrote: > The included diff is the work I've done on header consolidation in > msdosfs. The three areas I concentrated on where: > > - sys/fs/msdosfs/ > - sys/geom/label/g_label_msdosfs.* > - sbin/fsck_msdosfs/ > > I decided to preserve the headers in sys/fs/msdosfs since the bulk of > the code lives there and is most widely understood (don't want to be > pulling the rug from under other developers here). Good. > There were several places where a meta-structure describing > FAT12/FAT16/FAT32 bootsectors and bpb's were kept intact because they > were more compact than the actual on disk bs/bpb's. > > Please feel free to comment! Somthing seems to have corrupted most of the tabs before it was mailed. % --- //depot/projects/soc2007/chub-msdosfs2/sbin/fsck_msdosfs/boot.c 2007/06/29 00:42:42 % +++ //depot/projects/soc2007/chub-msdosfs2/sbin/fsck_msdosfs/boot.c 2007/07/08 08:28:50 % @@ -30,8 +30,8 @@ % * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. % */ % % +#include % % -#include % #ifndef lint % __RCSID("$NetBSD: boot.c,v 1.9 2003/07/24 19:25:46 ws Exp $"); % static const char rcsid[] = Just adds a style bug. % @@ -44,131 +44,164 @@ % #include % #include % % +#include % +#include % #include "ext.h" % #include "fsutil.h" % % int % -readboot(dosfs, boot) % - int dosfs; % - struct bootblock *boot; % +readboot(int dosfs, struct bootblock *boot) % { % - u_char block[DOSBOOTBLOCKSIZE]; % - u_char fsinfo[2 * DOSBOOTBLOCKSIZE]; % - u_char backup[DOSBOOTBLOCKSIZE]; % + union bootsector buffer; % + union bootsector backup; % + struct byte_bpb50 *pfat50; % + struct byte_bpb710 *pfat710; % + struct byte_Extboot *pfatext; % + struct fsinfo fsstruct; The tab lossage mostly looks like this. % int ret = FSOK; % % - if (read(dosfs, block, sizeof block) < sizeof block) { % + if (read(dosfs, &buffer, sizeof(union bootsector)) % + < sizeof(union bootsector)) { % perror("could not read boot block"); % return FSFATAL; % } The old code above (declarations and read()'s third arg) had fewer bugs. read() should read into character arrays, not into structs. It is necessary to do i/o in units of the sector size. readboot() must try various sizes, since the sector size is unknown initially. After reading something, it should get the sector size from the BPB after doing a few sanity checks. Buffers can then be sized using expressions like roundup(sizeof(foo), boot->BytesPerSec) or just boot->BytesPerSec since most data structures fit in one 512-byte sector and sector sizes < 512 are not supported. All i/o here except for fsinfo currently fails if the sector size is != 512. fsinfo has the wrong size 1024 (without your changes), so i/o to fsinfo would accidentally succeed for sector size 1024 if execution reached that far. % ... % + /* decode bios parameter block and store in a compacted % + * architecture independent data structure for future use % + */ Various style bugs here. % ... % + boot->BytesPerSec = getushort(pfat50->bpbBytesPerSec); % + boot->SecPerClust = pfat50->bpbSecPerClust; % + boot->ResSectors = getushort(pfat50->bpbResSectors); % + boot->FATs = pfat50->bpbFATs; % + boot->RootDirEnts = getushort(pfat50->bpbRootDirEnts); % + boot->Sectors = getushort(pfat50->bpbSectors); % + boot->Media = pfat50->bpbMedia; % + boot->SecPerTrack = getushort(pfat50->bpbSecPerTrack); % + boot->Heads = getushort(pfat50->bpbHeads); % + boot->HiddenSecs = getulong(pfat50->bpbHiddenSecs); % + boot->HugeSectors = getulong(pfat50->bpbHugeSectors); This part is fine. % ... % - /* Check backup FSInfo? XXX */ % + % + /* Unnecessary to check the backup FSInfo because there isn't % + * an physical backup copy of the FSInfo block. There's only a % + * backup of the FSInfo block number, which was checked (bsBPB) above. % + */ % } But there is a physical backup FSinfo. The normal layout is: main boot sector (sector 0) fsinfo (sector 1, but can be anywhere) second boot sector (next sector? -- no pointer to this) fsisig4 checks/clobbers here backup main boot sector (sector 3, but can be anywhere) backup fsinfo (next sector? -- no pointer to this, since backup main boot sector can't have a different pointer than main bs) backup second boot sector (next sector?) backup fsisig4 would check/clobber here newfs_msdos omits the second boot sector and creates the following layout: main boot sector (sector 0) fsinfo (sector 1) backup main boot sector (sector 2) fsisig4 checks/clobbers here backup fsinfo (sector 3) backup fsisig4 would check/clobber outside of all boot sectors This is valid (WinXP accepts it) for sector size 512, but newfs_msdos puts all fsinfo stuff except fsisig1 in a logically wrong place, at the end of the sector, so it creates invalid fsinfo (FreeBSD rejects it) if the sector size != 512. % --- //depot/projects/soc2007/chub-msdosfs2/sys/fs/msdosfs/bootsect.h 2007/06/29 00:42:42 % +++ //depot/projects/soc2007/chub-msdosfs2/sys/fs/msdosfs/bootsect.h 2007/07/08 08:01:09 % @@ -17,6 +20,8 @@ % * October 1992 % */ % % +#include % + % /* % * Format of a boot sector. This is the first sector on a DOS floppy disk % * or the fist sector of a partition on a hard disk. But, it is not the Namespace pollution. % @@ -25,7 +30,8 @@ % struct bootsector33 { % u_int8_t bsJump[3]; /* jump inst E9xxxx or EBxx90 */ % int8_t bsOemName[8]; /* OEM name and version */ % - int8_t bsBPB[19]; /* BIOS parameter block */ % + // int8_t bsBPB[19]; /* BIOS parameter block */ % + struct bpb33 bsBPB; /* BIOS parameter block */ This gained independence of bpb.h by not using a struct. If a struct is used here, then it has to be struct byte_bpb. struct_bpb33 has size != 19 due to padding. % @@ -47,8 +63,8 @@ % struct bootsector50 { % u_int8_t bsJump[3]; /* jump inst E9xxxx or EBxx90 */ % int8_t bsOemName[8]; /* OEM name and version */ % - int8_t bsBPB[25]; /* BIOS parameter block */ % - int8_t bsExt[26]; /* Bootsector Extension */ % + struct bpb50 bsBPB; /* BIOS parameter block */ % + struct extboot bsExt; /* Bootsector Extension */ % int8_t bsBootCode[448]; /* pad so structure is 512b */ % u_int8_t bsBootSectSig0; % u_int8_t bsBootSectSig1; % @@ -59,8 +75,8 @@ % struct bootsector710 { % u_int8_t bsJump[3]; /* jump inst E9xxxx or EBxx90 */ % int8_t bsOEMName[8]; /* OEM name and version */ % - int8_t bsBPB[53]; /* BIOS parameter block */ % - int8_t bsExt[26]; /* Bootsector Extension */ % + struct bpb710 bsBPB; /* BIOS parameter block */ % + struct extboot bsExt; /* Bootsector Extension */ % int8_t bsBootCode[420]; /* pad so structure is 512b */ % u_int8_t bsBootSectSig0; % u_int8_t bsBootSectSig1; As above. You declared byte_extboot, but don't use it here. Also in fsck_msdosfs, extboot is used where byte_extboot seems to be needed. % --- //depot/projects/soc2007/chub-msdosfs2/sys/fs/msdosfs/bpb.h 2007/06/29 00:42:42 % +++ //depot/projects/soc2007/chub-msdosfs2/sys/fs/msdosfs/bpb.h 2007/07/08 08:01:09 % @@ -78,7 +81,7 @@ % u_int32_t bpbRootClust; /* start cluster for root directory */ % u_int16_t bpbFSInfo; /* filesystem info structure sector */ % u_int16_t bpbBackup; /* backup boot sector */ % - /* There is a 12 byte filler here, but we ignore it */ % + u_int8_t bpbReserved[12]; /* 12 byte filler here */ % }; % % /* % @@ -153,7 +156,7 @@ % u_int8_t bpbRootClust[4]; /* start cluster for root directory */ % u_int8_t bpbFSInfo[2]; /* filesystem info structure sector */ % u_int8_t bpbBackup[2]; /* backup boot sector */ % - /* There is a 12 byte filler here, but we ignore it */ % + u_int8_t bpbReserved[12]; /* 12 byte filler here */ % }; % % /* % @@ -170,3 +173,6 @@ % u_int8_t fsifill3[508]; % u_int8_t fsisig4[4]; % }; % + % +#endif % +// _FS_MSDOSFS_BPB_H The vendor (NetBSD) version has similar changes. [...] There is also newfs_msdosfs. It doesn't even use headers for msdsofs things, but declares everything in its own style. Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Jul 14 02:19:30 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 389C816A400 for ; Sat, 14 Jul 2007 02:19:30 +0000 (UTC) (envelope-from pramod@juniper.net) Received: from smtpa.juniper.net (smtpa.juniper.net [207.17.137.120]) by mx1.freebsd.org (Postfix) with ESMTP id 11DAD13C46B for ; Sat, 14 Jul 2007 02:19:29 +0000 (UTC) (envelope-from pramod@juniper.net) Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by smtpa.juniper.net with ESMTP; 13 Jul 2007 19:19:28 -0700 X-IronPort-AV: i="4.16,538,1175497200"; d="scan'208"; a="36614971:sNHT33891384" Received: from emailcorp1.jnpr.net ([66.129.254.11]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 19:19:27 -0700 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 19:18:23 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jul 2007 19:18:24 -0700 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E1D958A@emailcorp3.jnpr.net> In-Reply-To: <46961281.2000607@freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ffs_blkfree: freeing free block Thread-Index: AcfEeRzaS85l3443SHCeUF/8Gu2OpABQpdxQ References: <7FA0C743C38E5340BFC2873488FA1E8E1D9453@emailcorp3.jnpr.net> <46961281.2000607@freebsd.org> From: "Pramod Srinivasan" To: "Eric Anderson" X-OriginalArrivalTime: 14 Jul 2007 02:18:23.0510 (UTC) FILETIME=[411A9360:01C7C5BD] Cc: freebsd-fs@freebsd.org Subject: RE: ffs_blkfree: freeing free block 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, 14 Jul 2007 02:19:30 -0000 >=20 > You should do three things: >=20 > - Check your disk for errors > - fsck the partition > - Update to 6-STABLE > > After doing the above, please give feedback on your findings.. >=20 > Eric Thanks for the response. The disk has no error and has also did fsck. I can't move to 6-STABLE easily as this is on our product, I disabled soft updates on the file system, this seems to help and I don't see the crash any more. Does this ring any bell? Thanks, Pramod From owner-freebsd-fs@FreeBSD.ORG Sat Jul 14 11:18:49 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F00A616A402; Sat, 14 Jul 2007 11:18:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 75DFC13C4A6; Sat, 14 Jul 2007 11:18:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l6EBIjFT002407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2007 21:18:47 +1000 Date: Sat, 14 Jul 2007 21:18:45 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20070713223111.P2242@besplex.bde.org> Message-ID: <20070714211354.I1555@besplex.bde.org> References: <47a4f3080707130119xbee4477y3e96d27763f793aa@mail.gmail.com> <20070713223111.P2242@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, Brian Chu Subject: Re: msdosfs header unification patch 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, 14 Jul 2007 11:18:50 -0000 On Fri, 13 Jul 2007, Bruce Evans wrote: > On Fri, 13 Jul 2007, Brian Chu wrote: > % ... > % - /* Check backup FSInfo? XXX > */ > % + > % + /* Unnecessary to check the backup FSInfo because there isn't > % + * an physical backup copy of the FSInfo block. There's only a > % + * backup of the FSInfo block number, which was checked (bsBPB) above. > % + */ > % } > > But there is a physical backup FSinfo. > > The normal layout is: > > main boot sector (sector 0) > fsinfo (sector 1, but can be anywhere) > second boot sector (next sector? -- no pointer to this) > fsisig4 checks/clobbers here > backup main boot sector (sector 3, but can be anywhere) Actually, it is sector 6. Sectors 3-5 are unused. Microsoft docs say not to use any other layout (for portability, since some utilities hard-code 6) ... > backup fsinfo (next sector? -- no pointer to this, since backup > main boot sector can't have a different pointer than main bs) > backup second boot sector (next sector?) > backup fsisig4 would check/clobber here > > newfs_msdos omits the second boot sector and creates the following layout: > > main boot sector (sector 0) > fsinfo (sector 1) > backup main boot sector (sector 2) > fsisig4 checks/clobbers here > backup fsinfo (sector 3) > backup fsisig4 would check/clobber outside of all boot sectors ... so this is a very unusual layout and shouldn't be produced by default. Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Jul 14 21:04:34 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A430D16A407 for ; Sat, 14 Jul 2007 21:04:34 +0000 (UTC) (envelope-from soc@hbar.us) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 4277E13C4BA for ; Sat, 14 Jul 2007 21:04:34 +0000 (UTC) (envelope-from soc@hbar.us) Received: by ug-out-1314.google.com with SMTP id o4so860124uge for ; Sat, 14 Jul 2007 14:04:33 -0700 (PDT) Received: by 10.78.195.9 with SMTP id s9mr794365huf.1184447072641; Sat, 14 Jul 2007 14:04:32 -0700 (PDT) Received: by 10.78.138.5 with HTTP; Sat, 14 Jul 2007 14:04:32 -0700 (PDT) Message-ID: <47a4f3080707141404w694570e5x9620e344f111e3bb@mail.gmail.com> Date: Sat, 14 Jul 2007 17:04:32 -0400 From: "Brian Chu" To: "Poul-Henning Kamp" In-Reply-To: <80555.1184332747@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47a4f3080707130119xbee4477y3e96d27763f793aa@mail.gmail.com> <80555.1184332747@critter.freebsd.dk> Cc: freebsd-fs@freebsd.org Subject: Re: msdosfs header unification patch 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, 14 Jul 2007 21:04:34 -0000 Hi Poul-Henning, Wow, there IS a fourth copy! Getting on it. Brian On 7/13/07, Poul-Henning Kamp wrote: > In message <47a4f3080707130119xbee4477y3e96d27763f793aa@mail.gmail.com>, "Brian > Chu" writes: > > >The included diff is the work I've done on header consolidation in > >msdosfs. The three areas I concentrated on where: > > > >- sys/fs/msdosfs/ > >- sys/geom/label/g_label_msdosfs.* > >- sbin/fsck_msdosfs/ > > This is *SO* great that I hate to point out that you missed > one set of copies: src/sbin/newfs_msdos/newfs_msdos.c > > But THANK YOU! > > I have hated these multiple incompatible copies for sooo many years... > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. >