From owner-freebsd-arch@FreeBSD.ORG Sun Sep 4 06:14:18 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37E0B16A420 for ; Sun, 4 Sep 2005 06:14:18 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id D62B643D45 for ; Sun, 4 Sep 2005 06:14:17 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id B705ABC66; Sun, 4 Sep 2005 06:14:13 +0000 (UTC) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 04 Sep 2005 09:43:31 +1000." <20050904090740.L2820@epsplex.bde.org> Date: Sun, 04 Sep 2005 08:14:12 +0200 Message-ID: <44924.1125814452@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Dmitry Pryanishnikov , freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2005 06:14:18 -0000 In message <20050904090740.L2820@epsplex.bde.org>, Bruce Evans writes: >> Making the hashes be 64bit is pointless since no filesystems will >> have that many inodes and it still doesn't solve the problem properly. > >Never? :-) Never. Even on very fast storage media, fsck would take for ever and you wouldn't be able to run it in parallel. Poul-Henning -- 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-arch@FreeBSD.ORG Sun Sep 4 10:29:38 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D11DD16A41F for ; Sun, 4 Sep 2005 10:29:38 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42FED43D48 for ; Sun, 4 Sep 2005 10:29:37 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5D36B.dip.t-dialin.net [84.165.211.107]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id j84AJP82066432; Sun, 4 Sep 2005 12:19:36 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j84ASMBm072797; Sun, 4 Sep 2005 12:28:22 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 4 Sep 2005 12:28:21 +0200 From: Alexander Leidinger To: Sam Leffler Message-ID: <20050904122821.34ecbdf1@Magellan.Leidinger.net> In-Reply-To: <431A2C7A.6080005@errno.com> References: <431A2C7A.6080005@errno.com> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: arch@freebsd.org Subject: Re: 802.11 status and futures X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2005 10:29:38 -0000 On Sat, 03 Sep 2005 16:06:34 -0700 Sam Leffler wrote: > As soon as it's ok to have HEAD diverge I want to bring in an entirely > new framework for doing scanning. This supports things like background > scanning (scanning for ap's while associated), roaming, and enables > station mode power save operation. These changes affect all drivers so > committing them won't happen until I get help in updating and testing > other drivers. What kind of documentation is available? Is there an HOWTO, overview or bare-bone-demo-driver with explanations available or do we have to use the source? The gap between ath and the other drivers is getting larger and larger. I wanted to add WPA support to wi a while ago, but after 30 minutes of looking at the source and searching for documentation I still lacked the big picture (I know nothing about the internals, I'm just a poor user of 2 wi cards). Where to start, what feature can be implemented in software, which one needs what kind of hardware support, what needs to be implemented, what's optional, ...? I'm talking about documentation which goes beyond what the man-pages provide currently. Documentation which provides examples and/or teaches about how to write a driver. Do we have something like this? Bye, Alexander. -- It is easier to fix Unix than to live with NT. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-arch@FreeBSD.ORG Sun Sep 4 12:34:57 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 661B116A41F for ; Sun, 4 Sep 2005 12:34:57 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93E5043D45 for ; Sun, 4 Sep 2005 12:34:56 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id j84CYf88056624; Sun, 4 Sep 2005 15:34:41 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Sun, 4 Sep 2005 15:34:41 +0300 (EEST) From: Dmitry Pryanishnikov To: Poul-Henning Kamp In-Reply-To: <44604.1125782260@phk.freebsd.dk> Message-ID: <20050904152458.J53303@atlantis.atlantis.dp.ua> References: <44604.1125782260@phk.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2005 12:34:57 -0000 Hello! On Sat, 3 Sep 2005, Poul-Henning Kamp wrote: > Uhm, did none of you guys see my email about how this must be > done correctly the say way NFS does it correctly ? Me, me! ;) I understood the right way to do it yesterday, but haven't verified it yet. Of course, I've missed vfs_hash_cmp_t *fn, void *arg arguments of vfs_hash_get(). To say more, your rev 1.88 of msdosfs_denode.c _must_ work correctly after addition of two casts to (uint64_t) in your 64-bit inode calculations! Once I get some free time, I'll check my assumption and will post an appropriate follow-up to my PR. I really want that people won't be "surprised" by 6.0-RELEASE crashing by just accessing their large FAT32 partitions. > Making the hashes be 64bit is pointless since no filesystems will > have that many inodes and it still doesn't solve the problem properly. While I agree with you about hashes, I still think that enlarging media sizes will lead to increasing number of filesystems that will support > 4 Gfiles / fs. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Sun Sep 4 12:43:00 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93C0F16A420 for ; Sun, 4 Sep 2005 12:43:00 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE2D443D46 for ; Sun, 4 Sep 2005 12:42:59 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id j84Cgr9L059515; Sun, 4 Sep 2005 15:42:53 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Sun, 4 Sep 2005 15:42:53 +0300 (EEST) From: Dmitry Pryanishnikov To: Poul-Henning Kamp In-Reply-To: <44924.1125814452@phk.freebsd.dk> Message-ID: <20050904154109.I53303@atlantis.atlantis.dp.ua> References: <44924.1125814452@phk.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2005 12:43:00 -0000 Hello! On Sun, 4 Sep 2005, Poul-Henning Kamp wrote: >>> Making the hashes be 64bit is pointless since no filesystems will >>> have that many inodes and it still doesn't solve the problem properly. >> >> Never? :-) > > Never. Never say "never" ;) > Even on very fast storage media, fsck would take for ever and you > wouldn't be able to run it in parallel. It will be a shame if e.g. some Linux's fs or NTFS will support > 4 Gfiles and we will be unable to handle it just because of architectural limitations! Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Sun Sep 4 16:54:54 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C41416A41F for ; Sun, 4 Sep 2005 16:54:54 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9436543D46 for ; Sun, 4 Sep 2005 16:54:53 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j84GsqBd003723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Sep 2005 09:54:52 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <431B2878.5090609@errno.com> Date: Sun, 04 Sep 2005 10:01:44 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Leidinger References: <431A2C7A.6080005@errno.com> <20050904122821.34ecbdf1@Magellan.Leidinger.net> In-Reply-To: <20050904122821.34ecbdf1@Magellan.Leidinger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: 802.11 status and futures X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2005 16:54:54 -0000 Alexander Leidinger wrote: > On Sat, 03 Sep 2005 16:06:34 -0700 > Sam Leffler wrote: > > >>As soon as it's ok to have HEAD diverge I want to bring in an entirely >>new framework for doing scanning. This supports things like background >>scanning (scanning for ap's while associated), roaming, and enables >>station mode power save operation. These changes affect all drivers so >>committing them won't happen until I get help in updating and testing >>other drivers. > > > What kind of documentation is available? Is there an HOWTO, overview or > bare-bone-demo-driver with explanations available or do we have to use > the source? > > The gap between ath and the other drivers is getting larger and larger. > I wanted to add WPA support to wi a while ago, but after 30 minutes of > looking at the source and searching for documentation I still lacked > the big picture (I know nothing about the internals, I'm just a poor > user of 2 wi cards). Where to start, what feature can be implemented in > software, which one needs what kind of hardware support, what needs to > be implemented, what's optional, ...? I'm talking about documentation > which goes beyond what the man-pages provide currently. Documentation > which provides examples and/or teaches about how to write a driver. Do > we have something like this? The source code is the the place to learn about the net80211 functionality right now. If that's insufficient then I respond to questions. Otherwise there are many resources on the web to use in learning about wireless networking; the slides I referenced had many url's. The ath driver is the best example to work from to understand how a wide variety of features work. Some cards with more intelligence may require some tweaks at the net80211 level (e.g. to disable functionality that is implemented in the device). For wi a good place to learn about what's needed for WPA is Jouni Malinen's hostap driver for Linux. In general you need a way to defer ap selection on scan to the host, send+receive WPA information elements in 802.11 management frames and you need to be able to pass host-encrypted data. None of these are especially difficult but for wi are only supported by sta firmware revs >1.6 I believe. OTOH I personally believe that devoting energy to legacy parts like wi is a waste; people should be working on getting new devices like iwi, ipw, ral, etc working well. All these devices have linux drivers from which you can crib. Sam From owner-freebsd-arch@FreeBSD.ORG Sun Sep 4 17:40:35 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0495616A41F for ; Sun, 4 Sep 2005 17:40:35 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1DA443D46; Sun, 4 Sep 2005 17:40:34 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.52 (FreeBSD)) id 1EByTY-000JWv-Cx; Sun, 04 Sep 2005 19:40:16 +0200 Date: Sun, 4 Sep 2005 19:40:16 +0200 From: Kirill Ponomarew To: Sam Leffler Message-ID: <20050904174016.GI65522@voodoo.oberon.net> References: <431A2C7A.6080005@errno.com> <20050904122821.34ecbdf1@Magellan.Leidinger.net> <431B2878.5090609@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <431B2878.5090609@errno.com> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 Cc: Alexander Leidinger , losh@FreeBSD.org, arch@freebsd.org Subject: Re: 802.11 status and futures X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2005 17:40:35 -0000 On Sun, Sep 04, 2005 at 10:01:44AM -0700, Sam Leffler wrote: > The ath driver is the best example to work from to understand how a wide > variety of features work. Some cards with more intelligence may require > some tweaks at the net80211 level (e.g. to disable functionality that is > implemented in the device). BTW, any chance to fix my problems with ath on HP Compaq nx9005, which I described on freebsd-mobile@ ? Warner suspected there are cbb problems, I would provide the access to the notebook for fixing it, but it seems nobody is interested :( -Kirill From owner-freebsd-arch@FreeBSD.ORG Sun Sep 4 18:28:22 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EE6116A41F for ; Sun, 4 Sep 2005 18:28:22 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3F1743D48 for ; Sun, 4 Sep 2005 18:28:21 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j84ISHwB019707; Mon, 5 Sep 2005 04:28:17 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j84ISFlE030706; Mon, 5 Sep 2005 04:28:16 +1000 Date: Mon, 5 Sep 2005 04:28:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Craig Rodrigues In-Reply-To: <20050901151531.GA43623@crodrigues.org> Message-ID: <20050905042755.F10844@delplex.bde.org> References: <20050810005323.GA42721@crodrigues.org> <20050810032308.GA80916@dragon.NUXI.org> <20050827235140.GA3063@crodrigues.org> <20050828172712.T86328@delplex.bde.org> <20050831112720.GA55376@crodrigues.org> <20050831215640.S1678@epsplex.bde.org> <20050901151531.GA43623@crodrigues.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: [RFC] -Wredundant-decls: keep it or remove it? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2005 18:28:22 -0000 On Thu, 1 Sep 2005, Craig Rodrigues wrote: > On Wed, Aug 31, 2005 at 10:32:08PM +1000, Bruce Evans wrote: >> weird cases are left. I can't see any reason not to use simply: >> >> /* Don't warn about a definition following a declaration. */ >> if (DECL_INITIAL (newdecl) && !DECL_INITIAL (olddecl))) >> >> since a definition (i.e., a declaration with an initializer) following >> a declaration (i.e., a tentative definition) can never be redundant. > > > I think you are right. I submitted a modified patch based on what you > suggested here: > http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00006.html > > and got approval for it on the GCC mainline here: > http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00019.html > > I'll try to get it into GCC soon. Thanks. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Sep 5 10:50:16 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22E5E16A41F; Mon, 5 Sep 2005 10:50:16 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A40443D48; Mon, 5 Sep 2005 10:50:14 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id j85Ao1HY080695; Mon, 5 Sep 2005 13:50:01 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Mon, 5 Sep 2005 13:50:01 +0300 (EEST) From: Dmitry Pryanishnikov To: Poul-Henning Kamp In-Reply-To: <35184.1125657474@phk.freebsd.dk> Message-ID: <20050905134006.B73214@atlantis.atlantis.dp.ua> References: <35184.1125657474@phk.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bug-followup@freebsd.org, freebsd-arch@freebsd.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2005 10:50:16 -0000 Hello! On Fri, 2 Sep 2005, Poul-Henning Kamp wrote: >> found the primary error (lack of casts leaded to 32-bit result), but then >> we should transfer this 64-bit "inode" number to vfs_hash_get(). Oops, >> it also limited to u_int (32 bits on i386). Finally, I see that the >> primary shortcoming here: in sys/vnode.h we have > > NFS has the same sort of problem, it has 16 or 32 *bytes* filehandles > that need to hash to 32 bit "inode numbers". > > If you look at vfs_hash_get calls in sys/nfsclient you can see that > it calculates a 32bit hash but then provides a "nfs_vncmpf" function > to do the actual comparison to resolve hash collisions. Indeed, I've missed last 2 arguments of vfs_hash_get(). Actually it seems that the only error here is missing cast. After application of the following patch: ftp://external.atlantis.dp.ua/FreeBSD/PR/85503/msdosfs.patch problem has gone away. Please, if possible, review and commit it. I think this patch is a good MFC candidate for RELENG_6 and RELENG_6_0, since it prevents panic in quite common environment. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Mon Sep 5 17:17:19 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57BCC16A41F; Mon, 5 Sep 2005 17:17:19 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B16443D55; Mon, 5 Sep 2005 17:17:15 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:WZ8WavLTGcLvym5mNR/+KaRoH+wCqac5NKcnfUbqXYLyVKmsEMlBrv16vV6hsA/Q@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.4/8.13.4) with ESMTP/inet6 id j85HH4GR095123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2005 02:17:05 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 06 Sep 2005 02:17:04 +0900 Message-ID: From: Hajimu UMEMOTO To: "Matthew N. Dodd" In-Reply-To: <20050826202713.X1915@sasami.jurai.net> References: <20050826202713.X1915@sasami.jurai.net> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA4 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 06 Sep 2005 02:17:05 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: arch@FreeBSD.ORG Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2005 17:17:19 -0000 Hi, >>>>> On Fri, 26 Aug 2005 20:29:39 -0400 (EDT) >>>>> "Matthew N. Dodd" said: mdodd> On Sat, 20 Aug 2005, Hajimu UMEMOTO wrote: > Our resolver reads resolv.conf once, and never re-read it. Recent > OpenBSD changed to re-read resolv.conf when it is updated. I believe it > is useful specially for mobile environment. mdodd> The more useful solution is to run a local caching nameserver that mdodd> forwards to the DHCP or location specific nameservers. I was using this solution for several years, but I prefered to use totd. Since I thought this was overkill, I mode the patch. mdodd> I've got modifications to dhclient-script and a Makefile in /etc/namedb/ mdodd> that implement this behavior. I'll clean it up for public consumption if mdodd> others are interested. Not only dhclient updates resolv.conf, but ppp, mpd and perhaps others do. I'm using dhclient and ppp on my laptops. Sometimes, I use DHCPv6, too. So, I need such setting for each applications. It is messy to setup a laptop. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Mon Sep 5 17:30:00 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAAFD16A41F; Mon, 5 Sep 2005 17:30:00 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 204DA43D46; Mon, 5 Sep 2005 17:29:59 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:OF+RpzD3+GBUapdF4PBYbZJDRJaWi/1S9Kw0Ss/N5AweAaV0JwiujA6W7fya/fEV@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.4/8.13.4) with ESMTP/inet6 id j85HTrjb085827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2005 02:29:54 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 06 Sep 2005 02:29:53 +0900 Message-ID: From: Hajimu UMEMOTO To: Randy Bush In-Reply-To: <17160.29026.1724.73259@roam.psg.com> References: <20050821003536.P14178@fledge.watson.org> <17160.29026.1724.73259@roam.psg.com> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA4 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 06 Sep 2005 02:29:54 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: arch@FreeBSD.org, Robert Watson Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2005 17:30:01 -0000 Hi, >>>>> On Sun, 21 Aug 2005 12:19:46 +0000 >>>>> Randy Bush said: > (2) By reading the configuration file more frequently and more quickly > after a change, we increase the chances of a race condition in which > the resolve reads a partially written resolv.conf file during an > update. Does this happen in practice? I've always been very leery of > re-reading configuration files automatically based on a time-stamp, as > updates to files are not atomic at all. randy> hmmmmm randy> dunno about others' use patterns, but in my world, resolv.conf only randy> changes when my mobile platform moves layer three binding (i.e. not randy> an an 802.11 access point move). so the frequency is low, and it randy> is usually not issuing dns queries as i move. but when i get to randy> the new binding, i am annoyed if i have to whack the resolver. Yes, I believe resolv.conf is not updated so often. Once, it is updated, we cannot do DNS lookup correctly without restarting an application. My patch solves this situation. Even when re-reading resolv.conf fails unfortunately, you will be able to recover easily by touching resolv.conf instead of restarting your application. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Mon Sep 5 18:16:05 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD3E216A41F for ; Mon, 5 Sep 2005 18:16:05 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CEE943D48 for ; Mon, 5 Sep 2005 18:16:05 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j85IF7jk088783; Mon, 5 Sep 2005 12:15:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 05 Sep 2005 12:14:43 -0600 (MDT) Message-Id: <20050905.121443.25301644.imp@bsdimp.com> To: krion@voodoo.oberon.net From: "M. Warner Losh" In-Reply-To: <20050904174016.GI65522@voodoo.oberon.net> References: <20050904122821.34ecbdf1@Magellan.Leidinger.net> <431B2878.5090609@errno.com> <20050904174016.GI65522@voodoo.oberon.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 05 Sep 2005 12:15:24 -0600 (MDT) Cc: arch@freebsd.org, sam@errno.com, Alexander@Leidinger.net Subject: Re: 802.11 status and futures X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2005 18:16:05 -0000 In message: <20050904174016.GI65522@voodoo.oberon.net> Kirill Ponomarew writes: : On Sun, Sep 04, 2005 at 10:01:44AM -0700, Sam Leffler wrote: : > The ath driver is the best example to work from to understand how a wide : > variety of features work. Some cards with more intelligence may require : > some tweaks at the net80211 level (e.g. to disable functionality that is : > implemented in the device). : : BTW, any chance to fix my problems with ath on HP Compaq nx9005, : which I described on freebsd-mobile@ ? Warner suspected there are : cbb problems, I would provide the access to the notebook for fixing : it, but it seems nobody is interested :( Yes. I've not had the head space to go after this set of problems. I've been trying to finalize some other pccard/cardbus changes in head/my p4 tree so I can get them into 6.0. After that, I plan on attacking cbb issues. Sorry for the delay. After looking at your traceback again, I don't think that there's a cbb problem in there that's affecting you (the interrupt storm is a problem, and should be fixed, but it clearly isn't keeping you from probing/attaching/powering up). Warner From owner-freebsd-arch@FreeBSD.ORG Mon Sep 5 22:15:57 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B08716A420; Mon, 5 Sep 2005 22:15:57 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [70.88.158.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FA6943D66; Mon, 5 Sep 2005 22:15:55 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [70.88.158.93]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id j85MFqVk075715; Mon, 5 Sep 2005 18:15:54 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Mon, 5 Sep 2005 18:15:52 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Hajimu UMEMOTO In-Reply-To: Message-ID: <20050905181505.R84118@sasami.jurai.net> References: <20050826202713.X1915@sasami.jurai.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [70.88.158.93]); Mon, 05 Sep 2005 18:15:54 -0400 (EDT) Cc: arch@FreeBSD.ORG Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2005 22:15:57 -0000 On Tue, 6 Sep 2005, Hajimu UMEMOTO wrote: > Not only dhclient updates resolv.conf, but ppp, mpd and perhaps others > do. I'm using dhclient and ppp on my laptops. Sometimes, I use DHCPv6, > too. So, I need such setting for each applications. It is messy to > setup a laptop. Right, and its simpler if -nothing- modifies resolve.conf. Hacking libc isn't the answer. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 From owner-freebsd-arch@FreeBSD.ORG Mon Sep 5 23:38:20 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 778C616A41F for ; Mon, 5 Sep 2005 23:38:20 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2B9943D46 for ; Mon, 5 Sep 2005 23:38:19 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.1/8.13.1) with ESMTP id j85NcBYC006840; Tue, 6 Sep 2005 01:38:12 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Sam Leffler In-Reply-To: <431A2C7A.6080005@errno.com> References: <431A2C7A.6080005@errno.com> Content-Type: text/plain Date: Tue, 06 Sep 2005 01:37:56 +0200 Message-Id: <1125963476.796.58.camel@genius1.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: 802.11 status and futures X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2005 23:38:20 -0000 I know that praising someone is not in the chart of this list but I just must say that I value Sam's work very much. During the building of a wireless network I had lots of problems but Sam always helped me. I hope to have helped the FreeBSD 802.11 stack a little bit by my experiments too. Thank you again, Sam. I'm looking forward the next generation 802.11 features in FreeBSD. -- Michal Mertl mime@traveller.cz From owner-freebsd-arch@FreeBSD.ORG Tue Sep 6 18:07:21 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B8E116A41F for ; Tue, 6 Sep 2005 18:07:21 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CDA443D49 for ; Tue, 6 Sep 2005 18:07:20 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.52 (FreeBSD)) id 1EChqY-000O9O-Va; Tue, 06 Sep 2005 20:07:02 +0200 Date: Tue, 6 Sep 2005 20:07:02 +0200 From: Kirill Ponomarew To: "M. Warner Losh" Message-ID: <20050906180702.GA85601@voodoo.oberon.net> References: <20050904122821.34ecbdf1@Magellan.Leidinger.net> <431B2878.5090609@errno.com> <20050904174016.GI65522@voodoo.oberon.net> <20050905.121443.25301644.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050905.121443.25301644.imp@bsdimp.com> X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE Keywords: 579279786 Cc: arch@freebsd.org, sam@errno.com, Alexander@Leidinger.net Subject: Re: 802.11 status and futures X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2005 18:07:21 -0000 On Mon, Sep 05, 2005 at 12:14:43PM -0600, M. Warner Losh wrote: > In message: <20050904174016.GI65522@voodoo.oberon.net> > Kirill Ponomarew writes: > : On Sun, Sep 04, 2005 at 10:01:44AM -0700, Sam Leffler wrote: > : > The ath driver is the best example to work from to understand how a wide > : > variety of features work. Some cards with more intelligence may require > : > some tweaks at the net80211 level (e.g. to disable functionality that is > : > implemented in the device). > : > : BTW, any chance to fix my problems with ath on HP Compaq nx9005, > : which I described on freebsd-mobile@ ? Warner suspected there are > : cbb problems, I would provide the access to the notebook for fixing > : it, but it seems nobody is interested :( > > Yes. I've not had the head space to go after this set of problems. > I've been trying to finalize some other pccard/cardbus changes in > head/my p4 tree so I can get them into 6.0. After that, I plan on > attacking cbb issues. Sorry for the delay. These are good news for notebook users. Thank you for supporting it. > After looking at your traceback again, I don't think that there's a > cbb problem in there that's affecting you (the interrupt storm is a > problem, and should be fixed, but it clearly isn't keeping you from > probing/attaching/powering up). Yeah, fixing the interrupt storm would be also a great thing. Ping me if you have time, I'll deliver all necessary info you need. -Kirill From owner-freebsd-arch@FreeBSD.ORG Wed Sep 7 10:34:33 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 234C116A41F; Wed, 7 Sep 2005 10:34:33 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B994943D45; Wed, 7 Sep 2005 10:34:30 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j87AYHRE022090; Wed, 7 Sep 2005 03:34:17 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j87AYGRl022089; Wed, 7 Sep 2005 03:34:16 -0700 (PDT) (envelope-from obrien) Date: Wed, 7 Sep 2005 03:34:16 -0700 From: "David O'Brien" To: Dmitry Pryanishnikov Message-ID: <20050907103416.GB91876@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Dmitry Pryanishnikov , Poul-Henning Kamp , bug-followup@freebsd.org, freebsd-arch@freebsd.org References: <35184.1125657474@phk.freebsd.dk> <20050905134006.B73214@atlantis.atlantis.dp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050905134006.B73214@atlantis.atlantis.dp.ua> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: Poul-Henning Kamp , bug-followup@freebsd.org, freebsd-arch@freebsd.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 10:34:33 -0000 On Mon, Sep 05, 2005 at 01:50:01PM +0300, Dmitry Pryanishnikov wrote: > ftp://external.atlantis.dp.ua/FreeBSD/PR/85503/msdosfs.patch > > problem has gone away. Please, if possible, review and commit it. I think > this > patch is a good MFC candidate for RELENG_6 and RELENG_6_0, since it > prevents panic in quite common environment. I've committed it to HEAD. It is up to the RE's to get it into RELENG_6. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Wed Sep 7 12:45:08 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A16516A41F; Wed, 7 Sep 2005 12:45:08 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id D200543D46; Wed, 7 Sep 2005 12:45:03 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j87CiCp0042493; Wed, 7 Sep 2005 16:44:12 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j87CiBti042492; Wed, 7 Sep 2005 16:44:11 +0400 (MSD) (envelope-from yar) Date: Wed, 7 Sep 2005 16:44:11 +0400 From: Yar Tikhiy To: obrien@freebsd.org, Dmitry Pryanishnikov , Poul-Henning Kamp , bug-followup@freebsd.org, freebsd-arch@freebsd.org Message-ID: <20050907124411.GB38943@comp.chem.msu.su> References: <35184.1125657474@phk.freebsd.dk> <20050905134006.B73214@atlantis.atlantis.dp.ua> <20050907103416.GB91876@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050907103416.GB91876@dragon.NUXI.org> User-Agent: Mutt/1.5.9i Cc: Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 12:45:08 -0000 On Wed, Sep 07, 2005 at 03:34:16AM -0700, David O'Brien wrote: > On Mon, Sep 05, 2005 at 01:50:01PM +0300, Dmitry Pryanishnikov wrote: > > ftp://external.atlantis.dp.ua/FreeBSD/PR/85503/msdosfs.patch > > > > problem has gone away. Please, if possible, review and commit it. I think > > this > > patch is a good MFC candidate for RELENG_6 and RELENG_6_0, since it > > prevents panic in quite common environment. > > I've committed it to HEAD. It is up to the RE's to get it into RELENG_6. David, I'm afraid there is certain misunderstanding here. First, the RE team will hardly take care of getting the fix to RELENG_6 without your initiative. Second, the PR kern/85503 shouldn't be closed until the problem is fixed in all relevant branches: It should be put in the "patched" state instead according to the project's well-established policy. Thanks. -- Yar From owner-freebsd-arch@FreeBSD.ORG Wed Sep 7 14:35:43 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CDBF16A41F for ; Wed, 7 Sep 2005 14:35:43 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89F7243D53 for ; Wed, 7 Sep 2005 14:35:42 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from localhost (ip68-105-180-11.dc.dc.cox.net [68.105.180.11]) (authenticated bits=0) by pittgoth.com (8.13.3/8.13.3) with ESMTP id j87EZeHo047071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Sep 2005 10:35:41 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Wed, 7 Sep 2005 10:34:34 -0400 From: Tom Rhodes To: freebsd-arch@FreeBSD.org Message-ID: <20050907103434.5cba35da@localhost> In-Reply-To: <20050907124411.GB38943@comp.chem.msu.su> References: <35184.1125657474@phk.freebsd.dk> <20050905134006.B73214@atlantis.atlantis.dp.ua> <20050907103416.GB91876@dragon.NUXI.org> <20050907124411.GB38943@comp.chem.msu.su> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 14:35:43 -0000 On Wed, 7 Sep 2005 16:44:11 +0400 Yar Tikhiy wrote: > On Wed, Sep 07, 2005 at 03:34:16AM -0700, David O'Brien wrote: > > On Mon, Sep 05, 2005 at 01:50:01PM +0300, Dmitry Pryanishnikov > > wrote: > > > ftp://external.atlantis.dp.ua/FreeBSD/PR/85503/msdosfs.patch > > > > > > problem has gone away. Please, if possible, review and commit it. > > > I think this > > > patch is a good MFC candidate for RELENG_6 and RELENG_6_0, since > > > it prevents panic in quite common environment. > > > > I've committed it to HEAD. It is up to the RE's to get it into > > RELENG_6. > > David, I'm afraid there is certain misunderstanding here. First, > the RE team will hardly take care of getting the fix to RELENG_6 > without your initiative. Second, the PR kern/85503 shouldn't be > closed until the problem is fixed in all relevant branches: It > should be put in the "patched" state instead according to the > project's well-established policy. Thanks. > I'll follow it. -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Wed Sep 7 16:28:16 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9E1416A41F; Wed, 7 Sep 2005 16:28:16 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2173143D53; Wed, 7 Sep 2005 16:28:16 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j87GRFXY003660; Wed, 7 Sep 2005 09:27:15 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j87GRC3O003659; Wed, 7 Sep 2005 09:27:12 -0700 (PDT) (envelope-from obrien) Date: Wed, 7 Sep 2005 09:27:12 -0700 From: "David O'Brien" To: Yar Tikhiy Message-ID: <20050907162712.GA3533@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Yar Tikhiy , Dmitry Pryanishnikov , Poul-Henning Kamp , bug-followup@freebsd.org, freebsd-arch@freebsd.org References: <35184.1125657474@phk.freebsd.dk> <20050905134006.B73214@atlantis.atlantis.dp.ua> <20050907103416.GB91876@dragon.NUXI.org> <20050907124411.GB38943@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050907124411.GB38943@comp.chem.msu.su> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: Dmitry Pryanishnikov , Poul-Henning Kamp , bug-followup@freebsd.org, freebsd-arch@freebsd.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 16:28:16 -0000 On Wed, Sep 07, 2005 at 04:44:11PM +0400, Yar Tikhiy wrote: > On Wed, Sep 07, 2005 at 03:34:16AM -0700, David O'Brien wrote: > > On Mon, Sep 05, 2005 at 01:50:01PM +0300, Dmitry Pryanishnikov wrote: > > > ftp://external.atlantis.dp.ua/FreeBSD/PR/85503/msdosfs.patch > > > > > > problem has gone away. Please, if possible, review and commit it. I think > > > this > > > patch is a good MFC candidate for RELENG_6 and RELENG_6_0, since it > > > prevents panic in quite common environment. > > > > I've committed it to HEAD. It is up to the RE's to get it into RELENG_6. > > David, I'm afraid there is certain misunderstanding here. First, > the RE team will hardly take care of getting the fix to RELENG_6 > without your initiative. There is zero misunderstanding here. I'm not going to get into a public debate or fight over this. My experiences to date is that it is too much effort to get all but the most critical bug fixes into a frozen branch. Someone else may take up the MFC during the freeze cause. > Second, the PR kern/85503 shouldn't be > closed until the problem is fixed in all relevant branches: It > should be put in the "patched" state instead according to the > project's well-established policy. Thanks. I've been a FreeBSD committer for almost 10 years now - what you claim is "well established" isn't. When a patch from a PR is committed to head the PR may be closed. The new practice of some committers to change the state to patched is something some committers may like to do, but I don't. The same for the MFC reminder and statement in the commit message is also newer thing that some like to use, but I don't. When I am free to commit to a branch and I have the time to adequately test in the branch, I look for all the commits I've done to HEAD, I do a code merge them and MFC them. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Wed Sep 7 21:42:43 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47EB616A41F; Wed, 7 Sep 2005 21:42:43 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id D983643D45; Wed, 7 Sep 2005 21:42:38 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j87LgXX0066641; Thu, 8 Sep 2005 01:42:33 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j87LgVBp066640; Thu, 8 Sep 2005 01:42:31 +0400 (MSD) (envelope-from yar) Date: Thu, 8 Sep 2005 01:42:31 +0400 From: Yar Tikhiy To: obrien@freebsd.org Message-ID: <20050907214231.GA65898@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050907162712.GA3533@dragon.NUXI.org> User-Agent: Mutt/1.5.9i Cc: freebsd-arch@freebsd.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 21:42:43 -0000 On Wed, Sep 07, 2005 at 09:27:12AM -0700, David O'Brien wrote: > On Wed, Sep 07, 2005 at 04:44:11PM +0400, Yar Tikhiy wrote: > > On Wed, Sep 07, 2005 at 03:34:16AM -0700, David O'Brien wrote: > > > On Mon, Sep 05, 2005 at 01:50:01PM +0300, Dmitry Pryanishnikov wrote: > > > > ftp://external.atlantis.dp.ua/FreeBSD/PR/85503/msdosfs.patch > > > > > > > > problem has gone away. Please, if possible, review and commit it. I think > > > > this > > > > patch is a good MFC candidate for RELENG_6 and RELENG_6_0, since it > > > > prevents panic in quite common environment. > > > > > > I've committed it to HEAD. It is up to the RE's to get it into RELENG_6. > > > > David, I'm afraid there is certain misunderstanding here. First, > > the RE team will hardly take care of getting the fix to RELENG_6 > > without your initiative. > > There is zero misunderstanding here. I'm not going to get into a public > debate or fight over this. My experiences to date is that it is too much > effort to get all but the most critical bug fixes into a frozen branch. > Someone else may take up the MFC during the freeze cause. > > > Second, the PR kern/85503 shouldn't be > > closed until the problem is fixed in all relevant branches: It > > should be put in the "patched" state instead according to the > > project's well-established policy. Thanks. > > I've been a FreeBSD committer for almost 10 years now - what you claim is > "well established" isn't. When a patch from a PR is committed to head > the PR may be closed. The new practice of some committers to change the > state to patched is something some committers may like to do, but I > don't. The same for the MFC reminder and statement in the commit message > is also newer thing that some like to use, but I don't. > When I am free to commit to a branch and I have the time to adequately > test in the branch, I look for all the commits I've done to HEAD, I do a > code merge them and MFC them. Nevertheless the FreeBSD community still can rely on bugs being fixed on frozen branches and PR's handled according to the Problem Report Handling Guidelines, because it's among the project's current best practice. IMHO it would be a real shame if people judged from your, actually private, position that the opposite was true. Frankly, this was the misunderstanding I was really afraid of. -- Yar From owner-freebsd-arch@FreeBSD.ORG Thu Sep 8 00:59:30 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D21D16A41F for ; Thu, 8 Sep 2005 00:59:30 +0000 (GMT) (envelope-from nlanza@premodern.org) Received: from dzerzhinsky.premodern.org (dzerzhinsky.dsl.telerama.com [205.201.10.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98F6F43D46 for ; Thu, 8 Sep 2005 00:59:29 +0000 (GMT) (envelope-from nlanza@premodern.org) Received: from [205.201.10.90] (liebot [205.201.10.90]) (authenticated bits=0) by dzerzhinsky.premodern.org (8.13.3/8.13.3) with ESMTP id j880xCR1053164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2005 20:59:16 -0400 (EDT) (envelope-from nlanza@premodern.org) Message-ID: <431F8CDE.9070801@premodern.org> Date: Wed, 07 Sep 2005 20:59:10 -0400 From: Nat Lanza User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <44924.1125814452@phk.freebsd.dk> In-Reply-To: <44924.1125814452@phk.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on dzerzhinsky.premodern.org Cc: Dmitry Pryanishnikov , freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 00:59:30 -0000 Poul-Henning Kamp wrote: > Even on very fast storage media, fsck would take for ever and you > wouldn't be able to run it in parallel. This is not a bullet-proof assumption -- there are certainly distributed filesystems out there which implement parallel fsck already, and I expect the number of them to only increase with time. It's not realistic to implement >4G files on a local-disk filesystem anytime soon, but there are already users who expect to be able to do so on distributed / clustered systems. --nat From owner-freebsd-arch@FreeBSD.ORG Thu Sep 8 01:01:59 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E54ED16A41F for ; Thu, 8 Sep 2005 01:01:59 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73A0343D46 for ; Thu, 8 Sep 2005 01:01:59 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j8811r0r021717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2005 21:01:53 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j8811q6P017078; Wed, 7 Sep 2005 21:01:52 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A8AF651210; Wed, 7 Sep 2005 21:01:51 -0400 (EDT) Date: Wed, 7 Sep 2005 21:01:51 -0400 From: Kris Kennaway To: Nat Lanza Message-ID: <20050908010151.GA51599@xor.obsecurity.org> References: <44924.1125814452@phk.freebsd.dk> <431F8CDE.9070801@premodern.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <431F8CDE.9070801@premodern.org> User-Agent: Mutt/1.4.2.1i Cc: Dmitry Pryanishnikov , Poul-Henning Kamp , freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 01:02:00 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 07, 2005 at 08:59:10PM -0400, Nat Lanza wrote: > It's not realistic to implement >4G files on a local-disk filesystem=20 > anytime soon ??? > but there are already users who expect to be able to do so=20 > on distributed / clustered systems. Kris --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDH41/Wry0BWjoQKURAlGcAKCUn26HdZ+pj/8j2/uOR0qhf7ttzQCdHf2S E4DYU4SeuFPwzatD5kIRpd4= =gXhB -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 8 01:04:56 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5A3016A41F for ; Thu, 8 Sep 2005 01:04:56 +0000 (GMT) (envelope-from nlanza@premodern.org) Received: from dzerzhinsky.premodern.org (dzerzhinsky.dsl.telerama.com [205.201.10.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D85843D48 for ; Thu, 8 Sep 2005 01:04:56 +0000 (GMT) (envelope-from nlanza@premodern.org) Received: from [205.201.10.90] (liebot [205.201.10.90]) (authenticated bits=0) by dzerzhinsky.premodern.org (8.13.3/8.13.3) with ESMTP id j8814lGA053193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2005 21:04:50 -0400 (EDT) (envelope-from nlanza@premodern.org) Message-ID: <431F8E2D.8090700@premodern.org> Date: Wed, 07 Sep 2005 21:04:45 -0400 From: Nat Lanza User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <44924.1125814452@phk.freebsd.dk> <431F8CDE.9070801@premodern.org> <20050908010151.GA51599@xor.obsecurity.org> In-Reply-To: <20050908010151.GA51599@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on dzerzhinsky.premodern.org Cc: Dmitry Pryanishnikov , Poul-Henning Kamp , freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 01:04:57 -0000 Kris Kennaway wrote: >>It's not realistic to implement >4G files on a local-disk filesystem >>anytime soon > > > ??? In context, I mean "more than 4 billion files per filesystem, thus requiring a >32bit inode". --nat From owner-freebsd-arch@FreeBSD.ORG Thu Sep 8 06:53:33 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71D1D16A41F for ; Thu, 8 Sep 2005 06:53:33 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B4F643D46 for ; Thu, 8 Sep 2005 06:53:33 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id A92BBBC66; Thu, 8 Sep 2005 06:53:28 +0000 (UTC) To: Nat Lanza From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 07 Sep 2005 20:59:10 EDT." <431F8CDE.9070801@premodern.org> Date: Thu, 08 Sep 2005 08:53:30 +0200 Message-ID: <74570.1126162410@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Dmitry Pryanishnikov , freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 06:53:33 -0000 In message <431F8CDE.9070801@premodern.org>, Nat Lanza writes: >Poul-Henning Kamp wrote: >> Even on very fast storage media, fsck would take for ever and you >> wouldn't be able to run it in parallel. > >This is not a bullet-proof assumption -- there are certainly distributed >filesystems out there which implement parallel fsck already, and I >expect the number of them to only increase with time. > >It's not realistic to implement >4G files on a local-disk filesystem >anytime soon, but there are already users who expect to be able to do so >on distributed / clustered systems. Just like time_t, the cost of going to 64bit inode_t is still too high for use to make the switch. -- 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-arch@FreeBSD.ORG Thu Sep 8 08:51:01 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46EC716A41F; Thu, 8 Sep 2005 08:51:01 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEB4843D46; Thu, 8 Sep 2005 08:51:00 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 7594B60FE; Thu, 8 Sep 2005 10:50:42 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 2BA7260F8; Thu, 8 Sep 2005 10:50:42 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id E421C33DD4; Thu, 8 Sep 2005 10:50:51 +0200 (CEST) To: obrien@freebsd.org References: <35184.1125657474@phk.freebsd.dk> <20050905134006.B73214@atlantis.atlantis.dp.ua> <20050907103416.GB91876@dragon.NUXI.org> <20050907124411.GB38943@comp.chem.msu.su> <20050907162712.GA3533@dragon.NUXI.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 08 Sep 2005 10:50:51 +0200 In-Reply-To: <20050907162712.GA3533@dragon.NUXI.org> (David O'Brien's message of "Wed, 7 Sep 2005 09:27:12 -0700") Message-ID: <86y868ndsk.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -5.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on tim.des.no Cc: Dmitry Pryanishnikov , Yar Tikhiy , freebsd-arch@freebsd.org, bug-followup@freebsd.org, Poul-Henning Kamp Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 08:51:01 -0000 "David O'Brien" writes: > On Wed, Sep 07, 2005 at 04:44:11PM +0400, Yar Tikhiy wrote: > > Second, the PR kern/85503 shouldn't be > > closed until the problem is fixed in all relevant branches: It > > should be put in the "patched" state instead according to the > > project's well-established policy. Thanks. > I've been a FreeBSD committer for almost 10 years now - what you claim is > "well established" isn't. When a patch from a PR is committed to head > the PR may be closed. The new practice of some committers to change the > state to patched is something some committers may like to do, but I > don't. It is the *documented policy* of the project and has been for several years. As a committer, you are expected to have read and understood the following document: http://www.freebsd.org/doc/en/articles/pr-guidelines/article.html DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Sep 8 15:31:43 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 792D916A41F; Thu, 8 Sep 2005 15:31:43 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE6D743D45; Thu, 8 Sep 2005 15:31:41 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:eGwum2CXhJznky8MKtoYSQLVEKs+s0GdhIEtlmJ6y9ascSvl6ejEi2buhtJF8a2U@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.4/8.13.4) with ESMTP/inet6 id j88FVUjA008147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2005 00:31:34 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 09 Sep 2005 00:31:30 +0900 Message-ID: From: Hajimu UMEMOTO To: Doug Barton In-Reply-To: <430FCAF5.90701@FreeBSD.org> References: <430FCAF5.90701@FreeBSD.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA4 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Fri, 09 Sep 2005 00:31:35 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: arch@FreeBSD.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 15:31:43 -0000 Hi, >>>>> On Fri, 26 Aug 2005 19:07:49 -0700 >>>>> Doug Barton said: dougb> I've been following this thread with interest, and while I applaud the dougb> effort that's gone into this I'm not sure it has a very high cost/benefit dougb> ratio for the majority of FreeBSD systems. This would potentially be useful dougb> for mobile systems that will often be moved into different networks, but dougb> frankly I don't see a benefit for the vast majority of systems that will dougb> have the same resolv.conf file for weeks, months, or years. I'm also dougb> thinking of various types of high performance systems that actually do dougb> thousands of DNS queries a minute. While a stat() call in the resolver path dougb> for every query might not be noticeable on a "typical" system, they would dougb> add up on systems that are already being stressed. Yup, there might be no benefit for non-mobile users. However, I believe it is still useful for mobile users. So, I changed to look a kernel environment variable. If resolver_reread_conf is set, the feature will be activated. You can find my new patches from: http://www.imasy.or.jp/~ume/FreeBSD/resolver-check-resolv.conf-20050908.diff http://www.imasy.or.jp/~ume/FreeBSD/dhclient-script-renew-20050908.diff dougb> Personally, I would much rather we add some method of "HUPing" the resolver dougb> to re-read resolv.conf. That way we could add that command to dougb> dhclient-script and send it whenever the resolv.conf file is actually dougb> changed. This could also be used by sysadmins for typically "static" systems dougb> instead of having to restart services on those systems. Since a resolver is in each applications, I think it is hard to send a HUP signal to resolvers without having a daemon which does DNS query. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Thu Sep 8 18:10:53 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F32516A41F; Thu, 8 Sep 2005 18:10:53 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8A3443D49; Thu, 8 Sep 2005 18:10:52 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j88IAqoG002058; Thu, 8 Sep 2005 11:10:52 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j88IAq2N002057; Thu, 8 Sep 2005 11:10:52 -0700 Date: Thu, 8 Sep 2005 11:10:52 -0700 From: Brooks Davis To: "Matthew N. Dodd" Message-ID: <20050908181052.GH31354@odin.ac.hmc.edu> References: <20050826202713.X1915@sasami.jurai.net> <20050827014153.GA14720@odin.ac.hmc.edu> <20050826221016.B1915@sasami.jurai.net> <20050827170600.GB14720@odin.ac.hmc.edu> <20050828022351.F63789@sasami.jurai.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fd5uyaI9j6xoeUBo" Content-Disposition: inline In-Reply-To: <20050828022351.F63789@sasami.jurai.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=LINES_OF_YELLING autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: arch@FreeBSD.ORG Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 18:10:53 -0000 --fd5uyaI9j6xoeUBo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 28, 2005 at 02:25:05AM -0400, Matthew N. Dodd wrote: > On Sat, 27 Aug 2005, Brooks Davis wrote: > >I'd like to see dhclient-script pull in /etc/rc.conf. >=20 > Attached. I've looked this over and while I like the concept, I think the implementation could be improved. First, it looks like named.conf has an include directive what is conveniently undocumented in the manpage, but in the BIND 9 Administrator Reference Manual at: http://www.bind9.net/manual/bind/9.3.1/Bv9ARM.ch06.html#AEN1534 so if it actually works, we should use that instead of rebuiling the config file each time. Second, the forwarders file should default to living in the /var/run of the named chroot since we default to chrooted operation these day. Third, I think we need to kick the server with "rndc reconfig" once the file is updated. Thanks, Brooks > --=20 > 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 > Index: sbin/dhclient/dhclient-script > =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/cvs/src/sbin/dhclient/dhclient-script,v > retrieving revision 1.8 > diff -u -u -r1.8 dhclient-script > --- sbin/dhclient/dhclient-script 26 Aug 2005 20:31:04 -0000 1.8 > +++ sbin/dhclient/dhclient-script 28 Aug 2005 06:02:16 -0000 > @@ -19,6 +19,9 @@ > # > # > =20 > +. /etc/rc.subr > +load_rc_config dhclient-script > + > NETSTAT=3D/usr/bin/netstat > AWK=3D/usr/bin/awk > HOSTNAME=3D/bin/hostname > @@ -127,6 +130,23 @@ > fi > } > =20 > +make_named_forwarders() { > + if [ -z "$new_domain_name_servers" ]; then > + return 1 > + fi > + > + rm -f /var/run/named.forwarders > + echo " forwarders {" > /var/run/named.forwarders > + for nameserver in $new_domain_name_servers; do > + echo " $nameserver;" >> /var/run/named.forwarders > + done > + echo " };" >> /var/run/named.forwarders > + > + cd /etc/namedb && make -f make-named.conf > + > + return 0 > +} > + > add_new_resolv_conf() { > # XXX Old code did not create/update resolv.conf unless both > # $new_domain_name and $new_domain_name_servers were provided. PR > @@ -238,7 +258,12 @@ > if [ "$new_ip_address" !=3D "$alias_ip_address" ]; then > add_new_alias > fi > - add_new_resolv_conf > + if checkyesno dhclient_script_resolv_conf; then > + add_new_resolv_conf > + fi > + if checkyesno dhclient_script_named_forwarders; then > + make_named_forwarders > + fi > ;; > =20 > EXPIRE|FAIL) > @@ -266,8 +291,13 @@ > add_new_alias > fi > add_new_routes > - if add_new_resolv_conf; then > - exit_with_hooks 0 > + if checkyesno dhclient_script_named_forwarders; then > + make_named_forwarders > + fi > + if checkyesno dhclient_script_resolv_conf; then > + if add_new_resolv_conf; then > + exit_with_hooks 0 > + fi > fi > fi > fi > Index: etc/defaults/rc.conf > =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/cvs/src/etc/defaults/rc.conf,v > retrieving revision 1.259 > diff -u -u -r1.259 rc.conf > --- etc/defaults/rc.conf 24 Aug 2005 16:25:47 -0000 1.259 > +++ etc/defaults/rc.conf 28 Aug 2005 05:46:18 -0000 > @@ -93,6 +93,9 @@ > nisdomainname=3D"NO" # Set to NIS domain if using NIS (or NO). > dhclient_program=3D"/sbin/dhclient" # Path to dhcp client program. > dhclient_flags=3D"" # Additional flags to pass to dhcp client. > +dhclient_script_resolv_conf=3D"YES" # Update /etc/resolv.conf > +dhclient_script_named_forwarders=3D"NO" # Update /var/run/named.forwarde= rs and > + # rebuild /etc/namedb/named.conf > background_dhclient=3D"NO" # Start dhcp client in the background. > firewall_enable=3D"NO" # Set to YES to enable firewall functionality > firewall_script=3D"/etc/rc.firewall" # Which script to run to set up the= firewall > Index: etc/namedb/Makefile > =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/cvs/src/etc/namedb/Makefile,v > retrieving revision 1.4 > diff -u -u -r1.4 Makefile > --- etc/namedb/Makefile 21 Dec 2004 08:46:50 -0000 1.4 > +++ etc/namedb/Makefile 28 Aug 2005 06:14:50 -0000 > @@ -1,7 +1,7 @@ > -# $FreeBSD$ > +# $FreeBSD: src/etc/namedb/Makefile,v 1.4 2004/12/21 08:46:50 ru Exp $ > =20 > FILES=3D PROTO.localhost.rev PROTO.localhost-v6.rev named.conf named.roo= t \ > - make-localhost > + make-localhost make-named.conf > NO_OBJ=3D > FILESDIR=3D /etc/namedb > FILESMODE=3D 644 > Index: etc/namedb/make-named.conf > =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: etc/namedb/make-named.conf > diff -N etc/namedb/make-named.conf > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ etc/namedb/make-named.conf 28 Aug 2005 05:59:12 -0000 > @@ -0,0 +1,17 @@ > +# $FreeBSD$ > +# > + > +# > +# Move /etc/named.conf to /etc/named.conf.in and add the following > +# lines to the options section. > +# > +# forward only; > +# #include "/var/run/named.forwarders" > +# > + > +named.conf: named.conf.in /var/run/named.forwarders > + cpp -P -C named.conf.in > $@ > + /etc/rc.d/named restart > + > +/var/run/named.forwarders: > + @touch /var/run/named.forwarders --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --fd5uyaI9j6xoeUBo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD4DBQFDIH6rXY6L6fI4GtQRAppOAJjyEPWVxH8ysVq8yLZP+8Y7cGn9AJ4gapj4 +JZryv5l/keB/pAUYknnfA== =2PMp -----END PGP SIGNATURE----- --fd5uyaI9j6xoeUBo-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 8 18:19:11 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42A8016A41F for ; Thu, 8 Sep 2005 18:19:11 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id B052143D46 for ; Thu, 8 Sep 2005 18:19:08 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j88IOFu3027087 for ; Thu, 8 Sep 2005 14:24:15 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-arch@FreeBSD.org Date: Thu, 8 Sep 2005 14:18:44 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_HCIID6syY0rPUQu" Message-Id: <200509081418.47794.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/1069/Wed Sep 7 11:08:51 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: Bigger boot block size? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 18:19:11 -0000 --Boundary-00=_HCIID6syY0rPUQu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline I have been working on boot2 recently. I faced constant problem with boot2 size limitation. Can we have bigger boot block size (aka BBSIZE)? In the future, we may have to support different file system to boot from and we won't have any space to add the support without dropping UFS1 support. In fact, I am using 32-sector boot block and I don't see any problem so far. The patch that I've been using is attached. Cheers, Jung-uk Kim --Boundary-00=_HCIID6syY0rPUQu Content-Type: text/x-diff; charset="us-ascii"; name="32sect.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="32sect.diff" Index: src/sys/boot/i386/boot2/Makefile =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/boot2/Makefile,v retrieving revision 1.59 diff -u -r1.59 Makefile --- src/sys/boot/i386/boot2/Makefile 15 Jul 2005 12:22:14 -0000 1.59 +++ src/sys/boot/i386/boot2/Makefile 8 Sep 2005 18:13:32 -0000 @@ -60,9 +60,9 @@ boot2.s boot2.s.tmp boot2.h sio.o boot2: boot2.ld - @set -- `ls -l boot2.ld`; x=$$((7680-$$5)); \ + @set -- `ls -l boot2.ld`; x=$$((15872-$$5)); \ echo "$$x bytes available"; test $$x -ge 0 - dd if=boot2.ld of=${.TARGET} obs=7680 conv=osync + dd if=boot2.ld of=${.TARGET} obs=15872 conv=osync boot2.ld: boot2.ldr boot2.bin ${BTXKERN} btxld -v -E ${ORG2} -f bin -b ${BTXKERN} -l boot2.ldr \ Index: src/sys/boot/i386/boot2/boot1.S =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/boot2/boot1.S,v retrieving revision 1.30 diff -u -r1.30 boot1.S --- src/sys/boot/i386/boot2/boot1.S 28 Aug 2004 08:32:23 -0000 1.30 +++ src/sys/boot/i386/boot2/boot1.S 8 Sep 2005 18:13:32 -0000 @@ -37,7 +37,7 @@ .set SIZ_PAG,0x1000 # Page size .set SIZ_SEC,0x200 # Sector size - .set NSECT,0x10 + .set NSECT,0x20 .globl start .globl xread .code16 Index: src/sys/sys/disklabel.h =================================================================== RCS file: /home/ncvs/src/sys/sys/disklabel.h,v retrieving revision 1.107 diff -u -r1.107 disklabel.h --- src/sys/sys/disklabel.h 7 Apr 2005 22:09:02 -0000 1.107 +++ src/sys/sys/disklabel.h 8 Sep 2005 18:13:32 -0000 @@ -68,7 +68,7 @@ #endif /* Size of bootblock area in sector-size neutral bytes */ -#define BBSIZE 8192 +#define BBSIZE 16384 #define LABEL_PART 2 /* partition containing label */ #define RAW_PART 2 /* partition containing whole disk */ --Boundary-00=_HCIID6syY0rPUQu-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 8 23:52:57 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E272116A41F; Thu, 8 Sep 2005 23:52:57 +0000 (GMT) (envelope-from peter@wemm.org) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25D1243D60; Thu, 8 Sep 2005 23:52:57 +0000 (GMT) (envelope-from peter@wemm.org) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 177B019761; Thu, 8 Sep 2005 16:52:57 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Thu, 8 Sep 2005 16:52:56 -0700 User-Agent: KMail/1.8.2 References: <200509081418.47794.jkim@FreeBSD.org> In-Reply-To: <200509081418.47794.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509081652.56550.peter@wemm.org> Cc: Jung-uk Kim Subject: Re: Bigger boot block size? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 23:52:58 -0000 On Thursday 08 September 2005 11:18 am, Jung-uk Kim wrote: > I have been working on boot2 recently. I faced constant problem with > boot2 size limitation. Can we have bigger boot block size (aka > BBSIZE)? In the future, we may have to support different file system > to boot from and we won't have any space to add the support without > dropping UFS1 support. In fact, I am using 32-sector boot block and > I don't see any problem so far. The patch that I've been using is > attached. > > Cheers, > > Jung-uk Kim Well, the obvious problem is that this can't be used on a UFS1 partition which has just 8K reserved.. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Fri Sep 9 07:11:37 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A1B316A41F; Fri, 9 Sep 2005 07:11:37 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9862743D45; Fri, 9 Sep 2005 07:11:36 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail26.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j897BXwq017628 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 9 Sep 2005 17:11:34 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id j897BWCv009168; Fri, 9 Sep 2005 17:11:32 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.13.4/8.13.1/Submit) id j897BWBb009167; Fri, 9 Sep 2005 17:11:32 +1000 (EST) (envelope-from peter) Date: Fri, 9 Sep 2005 17:11:32 +1000 From: Peter Jeremy To: Jung-uk Kim Message-ID: <20050909071132.GA9121@server.vk2pj.dyndns.org> References: <200509081418.47794.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509081418.47794.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@freebsd.org Subject: Re: Bigger boot block size? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 07:11:37 -0000 On Thu, Sep 08, 2005 at 02:18:44PM -0400, Jung-uk Kim wrote: >I have been working on boot2 recently. I faced constant problem with >boot2 size limitation. Can we have bigger boot block size (aka >BBSIZE)? In the future, we may have to support different file system >to boot from and we won't have any space to add the support without >dropping UFS1 support. I don't see why we need a one-size-fits-all boot2. boot2 has to be installed onto a specific filesystem so there's no reason why we can't have different boot2 binaries for CD9660, UFS1, UFS2 etc. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Fri Sep 9 09:12:02 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D220F16A41F; Fri, 9 Sep 2005 09:12:02 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0411443D45; Fri, 9 Sep 2005 09:12:01 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id D3D861641F; Fri, 9 Sep 2005 11:12:00 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 90722405A; Fri, 9 Sep 2005 11:12:10 +0200 (CEST) Date: Fri, 9 Sep 2005 11:12:10 +0200 From: Jeremie Le Hen To: Brooks Davis Message-ID: <20050909091210.GX659@obiwan.tataz.chchile.org> References: <20050826202713.X1915@sasami.jurai.net> <20050827014153.GA14720@odin.ac.hmc.edu> <20050826221016.B1915@sasami.jurai.net> <20050827170600.GB14720@odin.ac.hmc.edu> <20050828022351.F63789@sasami.jurai.net> <20050908181052.GH31354@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050908181052.GH31354@odin.ac.hmc.edu> User-Agent: Mutt/1.5.9i Cc: arch@FreeBSD.ORG, "Matthew N. Dodd" Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 09:12:02 -0000 Hi Matthew, Brooks, On Thu, Sep 08, 2005 at 11:10:52AM -0700, Brooks Davis wrote: > On Sun, Aug 28, 2005 at 02:25:05AM -0400, Matthew N. Dodd wrote: > > On Sat, 27 Aug 2005, Brooks Davis wrote: > > >I'd like to see dhclient-script pull in /etc/rc.conf. > > > > Attached. > > I've looked this over and while I like the concept, I think the > implementation could be improved. First, it looks like named.conf has > an include directive what is conveniently undocumented in the manpage, > but in the BIND 9 Administrator Reference Manual at: > > http://www.bind9.net/manual/bind/9.3.1/Bv9ARM.ch06.html#AEN1534 > > so if it actually works, we should use that instead of rebuiling the > config file each time. Second, the forwarders file should default to > living in the /var/run of the named chroot since we default to chrooted > operation these day. Third, I think we need to kick the server with > "rndc reconfig" once the file is updated. Just to say that this work in _greatly_ appreciated. Many thanks. I hope to see this commited soon. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-arch@FreeBSD.ORG Fri Sep 9 09:18:52 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67DCB16A41F for ; Fri, 9 Sep 2005 09:18:52 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8734843D49 for ; Fri, 9 Sep 2005 09:18:51 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.3/8.13.3) with ESMTP id j899Ikf9050181; Fri, 9 Sep 2005 13:18:50 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Fri, 9 Sep 2005 13:18:46 +0400 (MSD) From: Maxim Konovalov To: Brooks Davis In-Reply-To: <20050908181052.GH31354@odin.ac.hmc.edu> Message-ID: <20050909131747.B83895@mp2.macomnet.net> References: <20050826202713.X1915@sasami.jurai.net> <20050827014153.GA14720@odin.ac.hmc.edu> <20050826221016.B1915@sasami.jurai.net> <20050827170600.GB14720@odin.ac.hmc.edu> <20050828022351.F63789@sasami.jurai.net> <20050908181052.GH31354@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 09:18:52 -0000 [...] > I've looked this over and while I like the concept, I think the > implementation could be improved. First, it looks like named.conf has > an include directive what is conveniently undocumented in the manpage, > but in the BIND 9 Administrator Reference Manual at: > > http://www.bind9.net/manual/bind/9.3.1/Bv9ARM.ch06.html#AEN1534 > > so if it actually works, we should use that instead of rebuiling the > config file each time. Second, the forwarders file should default to We are using "include" directive for ages. -- Maxim Konovalov From owner-freebsd-arch@FreeBSD.ORG Fri Sep 9 15:45:48 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CDB116A41F for ; Fri, 9 Sep 2005 15:45:48 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD55943D48 for ; Fri, 9 Sep 2005 15:45:43 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j89FovlZ054016; Fri, 9 Sep 2005 11:50:57 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Peter Jeremy Date: Fri, 9 Sep 2005 11:45:20 -0400 User-Agent: KMail/1.6.2 References: <200509081418.47794.jkim@FreeBSD.org> <20050909071132.GA9121@server.vk2pj.dyndns.org> In-Reply-To: <20050909071132.GA9121@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Message-Id: <200509091145.27676.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-arch@FreeBSD.org Subject: Re: Bigger boot block size? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 15:45:48 -0000 On Friday 09 September 2005 03:11 am, Peter Jeremy wrote: > On Thu, Sep 08, 2005 at 02:18:44PM -0400, Jung-uk Kim wrote: > >I have been working on boot2 recently. I faced constant problem > > with boot2 size limitation. Can we have bigger boot block size > > (aka BBSIZE)? In the future, we may have to support different > > file system to boot from and we won't have any space to add the > > support without dropping UFS1 support. > > I don't see why we need a one-size-fits-all boot2. boot2 has to be > installed onto a specific filesystem so there's no reason why we > can't have different boot2 binaries for CD9660, UFS1, UFS2 etc. Huh? boot2 is not installed onto a specific file system and cd9660 is not supported natively AFAIK. '-C' option only lets you mount cd9660 as a root file system. Jung-uk Kim From owner-freebsd-arch@FreeBSD.ORG Fri Sep 9 16:14:57 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 114F916A41F for ; Fri, 9 Sep 2005 16:14:57 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94F2543D45 for ; Fri, 9 Sep 2005 16:14:56 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j89GKA35055060; Fri, 9 Sep 2005 12:20:11 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Peter Wemm Date: Fri, 9 Sep 2005 12:14:37 -0400 User-Agent: KMail/1.6.2 References: <200509081418.47794.jkim@FreeBSD.org> <200509081652.56550.peter@wemm.org> In-Reply-To: <200509081652.56550.peter@wemm.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Message-Id: <200509091214.41429.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/1073/Fri Sep 9 11:13:08 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-arch@FreeBSD.org Subject: Re: Bigger boot block size? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 16:14:57 -0000 On Thursday 08 September 2005 07:52 pm, Peter Wemm wrote: > On Thursday 08 September 2005 11:18 am, Jung-uk Kim wrote: > > I have been working on boot2 recently. I faced constant problem > > with boot2 size limitation. Can we have bigger boot block size > > (aka BBSIZE)? In the future, we may have to support different > > file system to boot from and we won't have any space to add the > > support without dropping UFS1 support. In fact, I am using > > 32-sector boot block and I don't see any problem so far. The > > patch that I've been using is attached. > > > > Cheers, > > > > Jung-uk Kim > > Well, the obvious problem is that this can't be used on a UFS1 > partition which has just 8K reserved.. Sigh... But bsdlabel(8) should be able to handle this case when '-B' option is given and first partition of the slice is UFS1, i. e., we keep 'historical' boot1/boot2 for a while and drop the support later. ;-) Jung-uk Kim From owner-freebsd-arch@FreeBSD.ORG Fri Sep 9 21:44:41 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6394816A41F for ; Fri, 9 Sep 2005 21:44:41 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7AD343D46 for ; Fri, 9 Sep 2005 21:44:40 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j89LnviK065325 for ; Fri, 9 Sep 2005 17:49:57 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-arch@FreeBSD.org Date: Fri, 9 Sep 2005 17:44:24 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200509091744.26505.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/1073/Fri Sep 9 11:13:08 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: time_second vs. time_uptime X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 21:44:41 -0000 If I read the source correctly, time_second can go backwards or forwards when there is a leap second but time_uptime cannot. Am I right? If my assumption is right, it seems we have some misuses in kernel, e. g., sched_sync() in sys/kern/vfs_subr.c. It may not be critical but it worries me a little because a leap second is scheduled to occur at the end of this year. ;-) Thanks, Jung-uk Kim From owner-freebsd-arch@FreeBSD.ORG Fri Sep 9 21:48:11 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06A5116A41F; Fri, 9 Sep 2005 21:48:11 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FD0A43D53; Fri, 9 Sep 2005 21:48:08 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j89Lm8AQ006504; Fri, 9 Sep 2005 14:48:08 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j89Lm8Qs006503; Fri, 9 Sep 2005 14:48:08 -0700 Date: Fri, 9 Sep 2005 14:48:08 -0700 From: Brooks Davis To: Jung-uk Kim Message-ID: <20050909214808.GA6021@odin.ac.hmc.edu> References: <200509091744.26505.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <200509091744.26505.jkim@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-arch@freebsd.org Subject: Re: time_second vs. time_uptime X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 21:48:11 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 09, 2005 at 05:44:24PM -0400, Jung-uk Kim wrote: > If I read the source correctly, time_second can go backwards or=20 > forwards when there is a leap second but time_uptime cannot. Am I=20 > right? If my assumption is right, it seems we have some misuses in=20 > kernel, e. g., sched_sync() in sys/kern/vfs_subr.c. It may not be=20 > critical but it worries me a little because a leap second is=20 > scheduled to occur at the end of this year. ;-) Yes, uptime increases monotonically, but leap seconds and adjustments such as those made by ntpdate will make simple time values jump around. This bit me when I first did the interface epochs since absolute times are not necessarily unique. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDIgMXXY6L6fI4GtQRAtQNAKCMX1XcuDcKAVttGi+93s6dzs9NtgCgtNhq AKlqajzYsIAwLnSa5kfv7tw= =ep7X -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 9 22:36:11 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C542E16A41F for ; Fri, 9 Sep 2005 22:36:11 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 399AA43D4C for ; Fri, 9 Sep 2005 22:36:11 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j89MfNdA066449; Fri, 9 Sep 2005 18:41:28 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Brooks Davis Date: Fri, 9 Sep 2005 18:35:50 -0400 User-Agent: KMail/1.6.2 References: <200509091744.26505.jkim@FreeBSD.org> <20050909214808.GA6021@odin.ac.hmc.edu> In-Reply-To: <20050909214808.GA6021@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_I5gIDbVAtC4Hjq/" Message-Id: <200509091835.52470.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/1073/Fri Sep 9 11:13:08 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-arch@FreeBSD.org Subject: Re: time_second vs. time_uptime X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 22:36:11 -0000 --Boundary-00=_I5gIDbVAtC4Hjq/ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 09 September 2005 05:48 pm, Brooks Davis wrote: > On Fri, Sep 09, 2005 at 05:44:24PM -0400, Jung-uk Kim wrote: > > If I read the source correctly, time_second can go backwards or > > forwards when there is a leap second but time_uptime cannot. Am > > I right? If my assumption is right, it seems we have some > > misuses in kernel, e. g., sched_sync() in sys/kern/vfs_subr.c. > > It may not be critical but it worries me a little because a leap > > second is scheduled to occur at the end of this year. ;-) > > Yes, uptime increases monotonically, but leap seconds and > adjustments such as those made by ntpdate will make simple time > values jump around. This bit me when I first did the interface > epochs since absolute times are not necessarily unique. It seems the most commonly misused places are networks stacks. It's understandable because time_uptime is relatively new. :-) http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_tc.c.diff?r1=1.140&r2=1.141 Anyway let's start fixing! Thanks, Jung-uk Kim --Boundary-00=_I5gIDbVAtC4Hjq/ Content-Type: text/x-diff; charset="euc-kr"; name="sched_sync.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sched_sync.diff" Index: src/sys/kern/vfs_subr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.643 diff -u -r1.643 vfs_subr.c --- src/sys/kern/vfs_subr.c 28 Aug 2005 23:00:11 -0000 1.643 +++ src/sys/kern/vfs_subr.c 9 Sep 2005 22:25:42 -0000 @@ -1584,7 +1584,7 @@ syncer_final_iter = 0; first_printf = 1; syncer_state = SYNCER_RUNNING; - starttime = time_second; + starttime = time_uptime; EVENTHANDLER_REGISTER(shutdown_pre_sync, syncer_shutdown, td->td_proc, SHUTDOWN_PRI_LAST); @@ -1599,14 +1599,14 @@ } net_worklist_len = syncer_worklist_len - sync_vnode_count; if (syncer_state != SYNCER_RUNNING && - starttime != time_second) { + starttime != time_uptime) { if (first_printf) { printf("\nSyncing disks, vnodes remaining..."); first_printf = 0; } printf("%d ", net_worklist_len); } - starttime = time_second; + starttime = time_uptime; /* * Push files whose dirty time has expired. Be careful @@ -1695,7 +1695,7 @@ if (syncer_state != SYNCER_RUNNING) tsleep(&dummychan, PPAUSE, "syncfnl", hz / SYNCER_SHUTDOWN_SPEEDUP); - else if (time_second == starttime) + else if (time_uptime == starttime) tsleep(&lbolt, PPAUSE, "syncer", 0); } } --Boundary-00=_I5gIDbVAtC4Hjq/-- From owner-freebsd-arch@FreeBSD.ORG Sat Sep 10 08:22:48 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 392A516A41F; Sat, 10 Sep 2005 08:22:48 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC45943D45; Sat, 10 Sep 2005 08:22:47 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 03946BC93; Sat, 10 Sep 2005 08:22:46 +0000 (UTC) To: Jung-uk Kim From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Sep 2005 17:44:24 EDT." <200509091744.26505.jkim@FreeBSD.org> Date: Sat, 10 Sep 2005 10:22:45 +0200 Message-ID: <8153.1126340565@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: freebsd-arch@FreeBSD.org Subject: Re: time_second vs. time_uptime X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2005 08:22:48 -0000 In message <200509091744.26505.jkim@FreeBSD.org>, Jung-uk Kim writes: >If I read the source correctly, time_second can go backwards or >forwards when there is a leap second but time_uptime cannot. Am I >right? Correct. >If my assumption is right, it seems we have some misuses in >kernel, e. g., sched_sync() in sys/kern/vfs_subr.c. It may not be >critical but it worries me a little because a leap second is >scheduled to occur at the end of this year. ;-) Yes, almost nothing should use time_second in the kernel. -- 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-arch@FreeBSD.ORG Sat Sep 10 08:38:21 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F00816A41F; Sat, 10 Sep 2005 08:38:21 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1B0743D4C; Sat, 10 Sep 2005 08:38:20 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id DA095BC96; Sat, 10 Sep 2005 08:38:18 +0000 (UTC) To: Jung-uk Kim From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 09 Sep 2005 12:14:37 EDT." <200509091214.41429.jkim@FreeBSD.org> Date: Sat, 10 Sep 2005 10:38:17 +0200 Message-ID: <8350.1126341497@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: freebsd-arch@FreeBSD.org Subject: Re: Bigger boot block size? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2005 08:38:21 -0000 In message <200509091214.41429.jkim@FreeBSD.org>, Jung-uk Kim writes: >Sigh... But bsdlabel(8) should be able to handle this case when '-B' >option is given and first partition of the slice is UFS1, i. e., we >keep 'historical' boot1/boot2 for a while and drop the support >later. ;-) Guys, bsdlabel has no future, we need to migrate to something that is A: 64 capable B: supports more than 7/8 partitions C: understands that metadata should not be exposed in-band. -- 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-arch@FreeBSD.ORG Sat Sep 10 17:48:11 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05E7716A41F; Sat, 10 Sep 2005 17:48:11 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD8B843D46; Sat, 10 Sep 2005 17:48:01 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j8AHlqW7051294; Sat, 10 Sep 2005 11:47:54 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <43231C48.80008@samsco.org> Date: Sat, 10 Sep 2005 11:47:52 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <8350.1126341497@phk.freebsd.dk> In-Reply-To: <8350.1126341497@phk.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Jung-uk Kim , freebsd-arch@freebsd.org Subject: Re: Bigger boot block size? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2005 17:48:11 -0000 Poul-Henning Kamp wrote: > In message <200509091214.41429.jkim@FreeBSD.org>, Jung-uk Kim writes: > > >>Sigh... But bsdlabel(8) should be able to handle this case when '-B' >>option is given and first partition of the slice is UFS1, i. e., we >>keep 'historical' boot1/boot2 for a while and drop the support >>later. ;-) > > > Guys, bsdlabel has no future, we need to migrate to something > that is > A: 64 capable > B: supports more than 7/8 partitions > C: understands that metadata should not be exposed in-band. > Yes, and you've been waving your hands about this for a long time =-) GPT is a nice sucessor, but our support for it is not ready for prime time, IMHO. What is required to actually make the switch: 1) appropriate support in all stages of the bootloader for i386 and amd64. 2) appropriate support in sysinstall for all platforms. 3) docs that describe GPT on FreeBSD, how to install a system to it, and how to upgrade a system to it. 4) visual editor for GPT. You might laugh that bsdlabel/disklabel only uses vi, but it's worlds better than what the gpt utility provides now. Scott From owner-freebsd-arch@FreeBSD.ORG Sat Sep 10 18:02:04 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6958116A41F; Sat, 10 Sep 2005 18:02:04 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1410743D58; Sat, 10 Sep 2005 18:02:04 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 83ED4BC96; Sat, 10 Sep 2005 18:02:02 +0000 (UTC) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 10 Sep 2005 11:47:52 MDT." <43231C48.80008@samsco.org> Date: Sat, 10 Sep 2005 20:02:02 +0200 Message-ID: <15126.1126375322@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Jung-uk Kim , freebsd-arch@freebsd.org Subject: Re: Bigger boot block size? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2005 18:02:04 -0000 In message <43231C48.80008@samsco.org>, Scott Long writes: >> >> Guys, bsdlabel has no future, we need to migrate to something >> that is >> A: 64 capable >> B: supports more than 7/8 partitions >> C: understands that metadata should not be exposed in-band. >> > >Yes, and you've been waving your hands about this for a long time =-) Yeah, well, sorry, but I havn't had enough time myself :-( >GPT is a nice sucessor, but our support for it is not ready for prime >time, IMHO. What is required to actually make the switch: > >1) appropriate support in all stages of the bootloader for i386 and >amd64. >2) appropriate support in sysinstall for all platforms. >3) docs that describe GPT on FreeBSD, how to install a system to it, and >how to upgrade a system to it. >4) visual editor for GPT. You might laugh that bsdlabel/disklabel only >uses vi, but it's worlds better than what the gpt utility provides now. I *love* the bsdlabel $EDITOR use, and would highly recommend that any future tools adopt the principle. I particularly like it because $EDITOR can also be a shell script. -- 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.