From owner-freebsd-fs@FreeBSD.ORG Mon Aug 27 11:08:16 2007 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2602816A47C for ; Mon, 27 Aug 2007 11:08:16 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 13D6113C45A for ; Mon, 27 Aug 2007 11:08:16 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7RB8FC6020504 for ; Mon, 27 Aug 2007 11:08:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7RB8Dcn020500 for freebsd-fs@FreeBSD.org; Mon, 27 Aug 2007 11:08:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Aug 2007 11:08:13 GMT Message-Id: <200708271108.l7RB8Dcn020500@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 11:08:16 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o kern/114856 fs [ntfs] [patch] Bug in NTFS allows bogus file modes. o bin/115165 fs [PATCH] amd(8): add functionality of mount_nfs' -L -a 4 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/114847 fs [ntfs] [patch] dirmask support for NTFS ala MSDOSFS 1 problem total. From owner-freebsd-fs@FreeBSD.ORG Mon Aug 27 10:41:16 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04AA916A417 for ; Mon, 27 Aug 2007 10:41:16 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: from web45612.mail.sp1.yahoo.com (web45612.mail.sp1.yahoo.com [68.180.197.153]) by mx1.freebsd.org (Postfix) with SMTP id E343113C45E for ; Mon, 27 Aug 2007 10:41:15 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: (qmail 68561 invoked by uid 60001); 27 Aug 2007 10:14:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=rFMW1wYW1NYqH4VSmlNh4hsnJLZs/+HEHjew8sKApPqFaOqYRmhWBEUXX+hZh4CUZTfydpFbjxphLCXhAtFzyav/+fv1oxDJ46NGx38qFUomnrDRE3cx1aOjHSMmpC4DgYrgdIfTc7u9l3c4SrcFWMJvlUur4c5FTf5zJx8h/dY=; X-YMail-OSG: _bYEjTAVM1n17.OwSjm6cQyIAFVp52.ni0JmgpasExKzo9wWJCVh3i_9GdnCY0sQ0rTifno74wuDPJ8jWzQ0zJf6YAcoPBgDnaot Received: from [71.63.232.32] by web45612.mail.sp1.yahoo.com via HTTP; Mon, 27 Aug 2007 03:14:01 PDT Date: Mon, 27 Aug 2007 03:14:01 -0700 (PDT) From: Juri Mianovich To: freebsd-fs@freebsd.org MIME-Version: 1.0 Message-ID: <72418.68169.qm@web45612.mail.sp1.yahoo.com> X-Mailman-Approved-At: Mon, 27 Aug 2007 11:31:50 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: How do I get back my previous minfree level of performance ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 10:41:16 -0000 I know of a way to beat up (stress) an aac controller that will cause it to crash. I have put safeguards in place to make sure that this never happens. It is well known that going to a minfree level of ZERO on a disk that is near-full is very stressful on the system. Last night, I took a 1.8 TB filesystem with only 10 GB of free space and changed it from: minfree=1 to: minfree=0 and suddenly the aac0 controller starts dying on me. OOPS. Ok, no problem, I did not use any of the space I gained yet, so I will just go right back to a minfree of "1". So basically, I changed my minfree: 1 -> 0 -> 1 But the problem is, the crashes that going to zero caused _persist_ after going back to one. So my question is, what did I leave behind ? And how do I get back to a "real" minfree of 1, and not this broken minfree of 1 that I currently have ? The environment has been carefully controlled - this is the only change that has occurred and this aac0 controller halting has not happened in 300+ days of continuous operation ... it is definitely the move to a minfree of zero that stressed out the aac driver... Comments ? --------------------------------- Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. From owner-freebsd-fs@FreeBSD.ORG Mon Aug 27 13:00:58 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AB0116A418 for ; Mon, 27 Aug 2007 13:00:58 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: from web36609.mail.mud.yahoo.com (web36609.mail.mud.yahoo.com [209.191.85.26]) by mx1.freebsd.org (Postfix) with SMTP id 0BA1613C45D for ; Mon, 27 Aug 2007 13:00:57 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: (qmail 94076 invoked by uid 60001); 27 Aug 2007 12:34:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=XiIu3E0yeln+c3k49C20QI/4wE4beSlxEPRH3jY9lMxHa2knj1GgR9JxcUop+yBQkaDalW2cPtVf4sCyvkc805+KMY2K9IN+6Ejzgdcd4OkV0Umfzq3V7SyjomM4aPmW/kNL45sK5g/TSEDTB0h+mK8FJ0alXAu/Mkp3xv/cons=; X-YMail-OSG: LpFzzSoVM1kldw6nESA9RFXeaxVlsnGTm.PH7jDpYYuRdIIwQ73.3FLGl4cKVzCKbZRqGsG4s_hGntXjXRJQg.LWKJ2bUb4XsmvTHm2zNBv6eNm0S7tbdHWVp9M2FQ-- Received: from [213.147.110.159] by web36609.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2007 05:34:16 PDT Date: Mon, 27 Aug 2007 05:34:16 -0700 (PDT) From: Simun Mikecin To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <461381.93183.qm@web36609.mail.mud.yahoo.com> Subject: zfs: Use wholedisk or not? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 13:00:58 -0000 Is it safe to create zpool using whole disks instead of partitioning (making a GPT partition)? I know that using whole disks gives the benefit that zfs will to try to enable disk write cache on it. But I'm scared of what would happen if I plug such a disk on some other machine, that runs some other OS (Windows for example) since that disk will not have a valid MBR. Will it try to restore a valid MBR and destroy a zpool in the process? ____________________________________________________________________________________ Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 From owner-freebsd-fs@FreeBSD.ORG Mon Aug 27 14:43:45 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7604E16A419 for ; Mon, 27 Aug 2007 14:43:45 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 08CC213C4B6 for ; Mon, 27 Aug 2007 14:43:44 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1195051nfb for ; Mon, 27 Aug 2007 07:43:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bx3yiS5GnwCs2Ip7Sm/xfvUfE7tBfG1L/Jj8R9RoVbUXwzrCceNOfSUojADWq1kSBZGU5cMDeHsrw9cZVWtg7MNWyy/SJ7+7v6Y8/bQt0JottRA2HShGfMt8PwhrASiOIjy27Mr4wJCxTzq+ryDg8QY+47+iNYWoQk7YVZ9wwn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RNcsQBX2cfiR8znpnUoWj88s97fZ6Bz8UHR0RHDtdluOu8lt1g9BsCbqloQN0ufyIGhPQ9PX9485AN5xxND5HEg2oKwD8n1EqI9FdiUKJ6vnvt120XuweLl/1vhtOPQpBN4jhcftosT43MUbsi5CJziuk+y7QhSNB1hZZoKmFKo= Received: by 10.78.204.1 with SMTP id b1mr3971975hug.1188224141860; Mon, 27 Aug 2007 07:15:41 -0700 (PDT) Received: by 10.78.187.16 with HTTP; Mon, 27 Aug 2007 07:15:36 -0700 (PDT) Message-ID: <70e8236f0708270715l51238a8ai50ad5daaa1f71eb8@mail.gmail.com> Date: Mon, 27 Aug 2007 15:15:36 +0100 From: "Joao Barros" To: "Simun Mikecin" In-Reply-To: <461381.93183.qm@web36609.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <461381.93183.qm@web36609.mail.mud.yahoo.com> Cc: freebsd-fs@freebsd.org Subject: Re: zfs: Use wholedisk or not? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 14:43:45 -0000 On 8/27/07, Simun Mikecin wrote: > Is it safe to create zpool using whole disks instead of partitioning (making a GPT partition)? > I know that using whole disks gives the benefit that zfs will to try to enable disk write cache on it. Not only is it safe, it's recommended by Sun. > But I'm scared of what would happen if I plug such a disk on some other machine, that runs some > other OS (Windows for example) since that disk will not have a valid MBR. > Will it try to restore a valid MBR and destroy a zpool in the process? Windows does not restore MBRs unless you ask it to. -- Joao Barros From owner-freebsd-fs@FreeBSD.ORG Mon Aug 27 14:35:30 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 711A216A419 for ; Mon, 27 Aug 2007 14:35:30 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: from web45601.mail.sp1.yahoo.com (web45601.mail.sp1.yahoo.com [68.180.197.54]) by mx1.freebsd.org (Postfix) with SMTP id 5D28B13C458 for ; Mon, 27 Aug 2007 14:35:30 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: (qmail 31951 invoked by uid 60001); 27 Aug 2007 14:35:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=tIWRuioUfpJeqF8Tuwz9JqwH6LmzeY4jfRxI9obLq+pm4DaNhtjZBkbLGp8JAfd+HJpErGCNBQkBVvtOLyMDwHk5MVOCiCW8WCI14eXAN0oYidHovlWIbmSjhJKklpvsvkGI4I+sHw9+POCPhabOy07Ppozv2SOajP3x81xi7iQ=; X-YMail-OSG: MDxsVdwVM1kg9evSKhZXOwJmWgVpyOwZMX19NLhigN4SBj7mXgaU5GoShpCTW7CdCUhNmy5GWjAeB6H79sKrg4EzvA-- Received: from [71.63.232.32] by web45601.mail.sp1.yahoo.com via HTTP; Mon, 27 Aug 2007 07:35:28 PDT Date: Mon, 27 Aug 2007 07:35:28 -0700 (PDT) From: Juri Mianovich To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <149421.31053.qm@web45601.mail.sp1.yahoo.com> X-Mailman-Approved-At: Mon, 27 Aug 2007 14:57:09 +0000 Subject: Re: How do I get back my previous minfree level of performance ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 14:35:30 -0000 --- JH wrote: > Setting minfree very very low probably isn't wise, > but I'm sure you knew > about cylinder groups and block allocation before > your change, so I won't > flog *that* horse. Please do... I knew it was a "bad" idea, but given how it was working perfectly with a minfree of one, I didn't think it would be the end of the world moving it to zero. But more to the point, I thought that if I did not use up the space that I gained by going to zero, I could always go back to one without any repurcussions. It turns out I can't, and that is the point of this post. > On 8/27/07, Juri Mianovich > wrote: > > > the crashes that going to zero caused _persist_ > after going back to one. > > > Please describe "crash" in a follow-up message to > the list. > Maybe some output from "bt" (backtrace) or similar > would be helpful? Advice > on reporting kernel trouble may be found at System floods the console with: Warning! Controller is no longer running! code=0xbcef0100 (after a page or so of aac0 timeout messages) It's not interesting - anyone can crash the aac card with too much filesystem stress. I have seen it many times before. The problem is that this time, I cannot reduce the stress by doing anything but leaving that particular filesysem unmounted. But troubleshooting and reducing causes has made it perfectly clear that _it really is_ the change of minfree from 1 -> 0 -> 1 that has caused this problem. So the questions remains: 1. what did I do to my filesystem when I changed the minfree from 1 to 0 to 1 ? How is my current minfree-of-1 filesystem different from my old minfree-of-1 filesystem ? 2. How do I get back my old minfree-of-1 filesystem ? I have enough free space to do it (of course, since it currently _is_ at minfree of 1) ... do I need to defragment, or maybe delete some more files and go to a minfree of 2 ? Or has that filesystem become too jumbled for any amount of minfree to get it back to normal ? Thanks. > > ____________________________________________________________________________________ > Building a website is a piece of cake. Yahoo! Small > Business gives you all the tools to get online. > http://smallbusiness.yahoo.com/webhosting > ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz From owner-freebsd-fs@FreeBSD.ORG Mon Aug 27 17:32:21 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7F9216A41A for ; Mon, 27 Aug 2007 17:32:21 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: from web36608.mail.mud.yahoo.com (web36608.mail.mud.yahoo.com [209.191.85.25]) by mx1.freebsd.org (Postfix) with SMTP id 8841413C467 for ; Mon, 27 Aug 2007 17:32:21 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: (qmail 84092 invoked by uid 60001); 27 Aug 2007 17:32:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=PTMs82UIVmJekpP7AtagmW9edch+meEToC8SJEIVOwWXNEGgTV3EQGwlBQHYugAnDnp+Tz96Z50dRtNpbfJPMP6qcIXahB56ddgNfGEuUpofYn0Kbkgd/AmqByrfGUfoO0tVWlDw0oxcUOOr6D7mEFZ28BvGpB6j59BMAYNkxe4=; X-YMail-OSG: 5x5bfO4VM1nVBvREoVGXCEvlG4OAyA9isbgQDDLR7QGmKIEaHnzucem7E2eniG5BgKNakk3YCTo2xZixqxSfn3S1byQNOgCkypWfxXLNGtimfUlcNFdwaf2q9ooGVA-- Received: from [85.10.57.161] by web36608.mail.mud.yahoo.com via HTTP; Mon, 27 Aug 2007 10:32:18 PDT Date: Mon, 27 Aug 2007 10:32:18 -0700 (PDT) From: Simun Mikecin To: Joao Barros In-Reply-To: <70e8236f0708270715l51238a8ai50ad5daaa1f71eb8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <658848.81904.qm@web36608.mail.mud.yahoo.com> Cc: freebsd-fs@freebsd.org Subject: Re: zfs: Use wholedisk or not? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 17:32:21 -0000 --- Joao Barros wrote: > On 8/27/07, Simun Mikecin wrote: > > Is it safe to create zpool using whole disks instead of partitioning (making a GPT partition)? > > I know that using whole disks gives the benefit that zfs will to try to enable disk write > cache on it. > > Not only is it safe, it's recommended by Sun. When creating zpool on the whole disk on Solaris it will create EFI label. FreeBSD does not do that. ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ From owner-freebsd-fs@FreeBSD.ORG Mon Aug 27 20:43:28 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0911A16A417 for ; Mon, 27 Aug 2007 20:43:28 +0000 (UTC) (envelope-from cb@severious.net) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id E8D2013C46C for ; Mon, 27 Aug 2007 20:43:27 +0000 (UTC) (envelope-from cb@severious.net) Received: by ion.gank.org (Postfix, from userid 1001) id D501511A7F; Mon, 27 Aug 2007 15:24:19 -0500 (CDT) Date: Mon, 27 Aug 2007 15:24:18 -0500 From: Craig Boston To: Simun Mikecin Message-ID: <20070827202418.GA71789@nowhere> Mail-Followup-To: Craig Boston , Simun Mikecin , freebsd-fs@freebsd.org References: <461381.93183.qm@web36609.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461381.93183.qm@web36609.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org Subject: Re: zfs: Use wholedisk or not? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 20:43:28 -0000 On Mon, Aug 27, 2007 at 05:34:16AM -0700, Simun Mikecin wrote: > Is it safe to create zpool using whole disks instead of partitioning > (making a GPT partition)? It depends on what you mean by "safe". I have a couple of my machines set up that way without problems... > But I'm scared of what would happen if I plug such a disk on some > other machine, that runs some other OS (Windows for example) since > that disk will not have a valid MBR. ...however I haven't exposed the disks to a Windows monster^Wmachine to see if it eats them. > Will it try to restore a valid MBR and destroy a zpool in the process? I can't say with 100% certainty, but I think so long as you answer "no" to the prompt about writing a signature to the disk you'll be okay. > I know that using whole disks gives the benefit that zfs will to try > to enable disk write cache on it. FWIW, FreeBSD, unlike Solaris, always leaves the write cache enabled unless you explicitly turn it off, so there is no difference whether you're using a whole disk or an fdisk/gpt partition. Since device access is handled through GEOM, it may be impossible or at least difficult for ZFS to tell if what you put into the zpool is a physical disk or something else. Craig From owner-freebsd-fs@FreeBSD.ORG Mon Aug 27 19:24:27 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7677016A420 for ; Mon, 27 Aug 2007 19:24:27 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: from web45611.mail.sp1.yahoo.com (web45611.mail.sp1.yahoo.com [68.180.197.144]) by mx1.freebsd.org (Postfix) with SMTP id 4B97D13C47E for ; Mon, 27 Aug 2007 19:24:27 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: (qmail 28890 invoked by uid 60001); 27 Aug 2007 19:24:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=K3r+jNTYbA6iqLBOWLprViQ+EXSquuSZWPrSW/GGmw2U8c/YG3x6XnjwauudYGcWvH6r/OqXFCRmQLeXCQ8ioX8ADgPnOXSEGLp6iciwN6d/aPVGOUbfGH6m2QjGm+nYcv2gYV0R2E/7hDpskDeGNmA2P3KoIQvJr7NuGnfAFQk=; X-YMail-OSG: d15h5AMVM1mNAIBtX0BqSo5sqgJzyO9pPSa5M.N6 Received: from [71.63.232.32] by web45611.mail.sp1.yahoo.com via HTTP; Mon, 27 Aug 2007 12:24:24 PDT Date: Mon, 27 Aug 2007 12:24:24 -0700 (PDT) From: Juri Mianovich To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <973566.26603.qm@web45611.mail.sp1.yahoo.com> X-Mailman-Approved-At: Tue, 28 Aug 2007 01:32:32 +0000 Subject: minfree 1 -> 0 -> 1 == death ... PLEASE HELP X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 19:24:27 -0000 Ok, my previous post was too detailed and confusing. Here it is totally stripped down: - FreeBSD 6.1-RELEASE system with 1.8 TB ufs2 filesystem - up and stable for 200+ days _with_ a minfree setting of _one_ - yesterday I did this: tunefs -m 0 /dev/aacd0s1e - KABOOM - I then decided to cut my losses and put things back right where they were previously: tunefs -m 1 /dev/aacd0s1e - KABOOM So that's that. I don't care what's happening, I don't care why, I don't care what: - HOW DO I get back the minfree=1 behavior that I had 24 hours ago ? It worked fine for 200 days with minfree=1, and I just want to go back there. I did not use ANY of the space that I gained when I went from 1->0, so there should not be any issues... but there are. Help! ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz From owner-freebsd-fs@FreeBSD.ORG Tue Aug 28 02:42:14 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E773C16A418 for ; Tue, 28 Aug 2007 02:42:14 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id BCB6413C428 for ; Tue, 28 Aug 2007 02:42:14 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l7S2gBE8028790; Mon, 27 Aug 2007 21:42:11 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46D38B81.4040200@freebsd.org> Date: Mon, 27 Aug 2007 21:42:09 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Juri Mianovich References: <973566.26603.qm@web45611.mail.sp1.yahoo.com> In-Reply-To: <973566.26603.qm@web45611.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-fs@freebsd.org Subject: Re: minfree 1 -> 0 -> 1 == death ... PLEASE HELP X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 02:42:15 -0000 Juri Mianovich wrote: > Ok, my previous post was too detailed and confusing. > Here it is totally stripped down: > > - FreeBSD 6.1-RELEASE system with 1.8 TB ufs2 > filesystem > > - up and stable for 200+ days _with_ a minfree setting > of _one_ > > - yesterday I did this: tunefs -m 0 /dev/aacd0s1e > > - KABOOM > > - I then decided to cut my losses and put things back > right where they were previously: tunefs -m 1 > /dev/aacd0s1e > > - KABOOM > > > So that's that. I don't care what's happening, I > don't care why, I don't care what: > > - HOW DO I get back the minfree=1 behavior that I had > 24 hours ago ? It worked fine for 200 days with > minfree=1, and I just want to go back there. I did > not use ANY of the space that I gained when I went > from 1->0, so there should not be any issues... but > there are. Regarding the 'KABOOM' part - is that when you mount it? How about RO? Have you fsck'ed the fs at all? Also - please send the output of this command: dumpfs /dev/aacd0s1e | head -n 40 Eric From owner-freebsd-fs@FreeBSD.ORG Tue Aug 28 03:17:30 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E12A316A417 for ; Tue, 28 Aug 2007 03:17:29 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: from web45604.mail.sp1.yahoo.com (web45604.mail.sp1.yahoo.com [68.180.197.81]) by mx1.freebsd.org (Postfix) with SMTP id CDEE013C45A for ; Tue, 28 Aug 2007 03:17:29 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: (qmail 10639 invoked by uid 60001); 28 Aug 2007 03:17:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=KgtFtJFOF5zn548+U7vOpB+HLC//rq/MGWvaAYnU5ANVzuK5Nq1b6/juXUDC9QWjQpdxJ9cXUKUy+D6ajgq0RhSMc4+1xgGDEflkX5x/C2XfMMEsBlNDxptVRopQGfG8IeI+RAylDRf+moWktI0PgTUanoM0sYJmpBMRhZzLUJE=; X-YMail-OSG: nDKvXp4VM1k_6i58.kNPqZIK6UQLQQmwqM9Llxjj Received: from [71.63.232.32] by web45604.mail.sp1.yahoo.com via HTTP; Mon, 27 Aug 2007 20:17:29 PDT Date: Mon, 27 Aug 2007 20:17:29 -0700 (PDT) From: Juri Mianovich To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <337134.4926.qm@web45604.mail.sp1.yahoo.com> X-Mailman-Approved-At: Tue, 28 Aug 2007 03:44:15 +0000 Subject: Re: minfree 1 -> 0 -> 1 == death ... PLEASE HELP X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 03:17:30 -0000 On Mon, 27 Aug 2007, Eric Anderson wrote: > Regarding the 'KABOOM' part - is that when you mount it? How about RO? No - it mounts and runs just fine. For about an hour. Once any meaningful activity is run on it for an hour or so, the aac raid controller dies, spewing "controller is no longer running" messages on console. If I skip that filesystem, and mount the other partitions, the system will stay up indefinitely. It is only by running that filesystem (that I changed from 1 to 0 to 1) that the aac controller will die off. > Have you fsck'ed the fs at all? Yes. > Also - please send the output of this command: > > dumpfs /dev/aacd0s1e | head -n 40 Here you are - sorry for the bad linewrapping: magic 19540119 (UFS2) time Mon Aug 27 19:28:15 2007 superblock location 65536 id [ 44967b53 b7c98a12 ] ncg 10379 size 976478879 blocks 945756917 bsize 16384 shift 14 mask 0xffffc000 fsize 2048 shift 11 mask 0xfffff800 frag 8 shift 3 fsbtodb 2 minfree 1% optim space symlinklen 120 maxbsize 16384 maxbpg 2048 maxcontig 8 contigsumsize 8 nbfree 1520861 ndir 1336402 nifree 233593652 nffree 1151519 bpg 11761 fpg 94088 ipg 23552 nindir 2048 inopb 64 maxfilesize 140806241583103 sbsize 2048 cgsize 16384 csaddr 3000 cssize 167936 sblkno 40 cblkno 48 iblkno 56 dblkno 3000 cgrotor 8911 fmod 0 ronly 0 clean 1 avgfpdir 64 avgfilesize 16384 flags soft-updates fsmnt /mount2 volname swuid 0 cs[].cs_(nbfree,ndir,nifree,nffree): (124,178,22483,128) (150,171,22500,183) (2,540,16912,24) (14,449,18728,29) (152,220,18441,138) (19,226,22431,227) (10,192,22465,82) (204,338,21391,40) (2,233,22284,7) (75,216,22139,6) (92,355,21364,48) (40,172,23154,310) (97,211,22912,198) (50,1059,19773,521) (103,242,22082,24) (54,645,19650,552) (124,13,22038,17) (62,629,21768,21) (66,1078,20596,256) (36,629,21739,102) (15,229,22069,60) (22,643,19857,158) (8,150,23262,77) (84,66,23341,99) (32,4,23546,19) (134,102,22993,32) (0,91,23195,5) (79,71,23416,49) (51,71,23414,10) (30,723,20253,166) (20,940,20088,107) (262,189,22423,19) (325,146,23240,11) (147,123,23241,1) (69,122,23313,34) (44,123,23205,64) (70,121,22896,102) (47,220,21946,24) (147,77,23212,106) (102,124,19674,81) (187,104,23428,1) (0,88,22631,78) (117,4,23548,49) (252,2,23550,3) (186,2,23550,8) (1184,2,23550,48) (346,2,23550,15) (6261,2,23550,82) (1745,30,23406,65) (23,0,23552,15) (63,13,23513,51) (51,73,23025,14) (99,36,23312,130) (96,18,23312,44) (52,74,23142,17) (23,73,22997,30) (112,98,22961,141) (64,494,20614,71) (7,373,16781,717) (19,665,21232,616) (0,446,19200,50) (3,84,17164,51) (71,317,22673,17) (5,986,19852,37) (72,18,23471,44) (61,17,23516,134) (101,243,22116,78) (9,176,21941,88) (44,70,22718,45) (39,99,19659,29) (11,104,18723,18) (49,94,17467,57) (147,175,17802,738) (4,53,22270,2) (55,29,23501,48) (72,60,23372,8) (72,48,23484,147) (80,68,23484,36) (134,115,22830,144) (227,256,21686,320) Like I said, I am sure there is a fascinating explanation for all of this and we can all learn a lot, but I _don't care_. Why is the aac controller dying ? Don't care. Why can't the system handle a minfree of 0 ? don't care. Why does my new minfree of 1 behave like a minfree of zero ? Don't care. All I want to know is, how do I get back the old minfree of 1 I had 24 hours ago instead of the "new and improved" minfree of 1 that I have now ? Thank you so much for looking. ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz From owner-freebsd-fs@FreeBSD.ORG Tue Aug 28 10:00:46 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 036BE16A469 for ; Tue, 28 Aug 2007 10:00:46 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: from web36613.mail.mud.yahoo.com (web36613.mail.mud.yahoo.com [209.191.85.30]) by mx1.freebsd.org (Postfix) with SMTP id ABF2513C4A3 for ; Tue, 28 Aug 2007 10:00:45 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: (qmail 79008 invoked by uid 60001); 28 Aug 2007 10:00:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ut52lYMvZ1tg1+CngsPUOZV2hWHlPEwDHQj7B1pwQDcBUv4Gmvp1xj8dxLsqEEAG8LIBWzCgCsrlR59TMxk5S5fmmgIyx974SqXh6s5RcAZ0rQLglzCcGRfC/cvWlnDe/vi/jZ5TmXunH0rgJbJWGy+vveg/pIB2xxa+rZSxJoM=; X-YMail-OSG: EaXLYugVM1lFQrN4Yo0ogQwX4RYBow_LN4josaoZ_JjWGEcef3L4a03qM0M3gHzA00AeNLZsyxHFUj0oQHckDKu3r.0KdHGymUiF5Le.Mxui3fFlf.Gg0QR_r9UgSw-- Received: from [213.147.110.159] by web36613.mail.mud.yahoo.com via HTTP; Tue, 28 Aug 2007 03:00:44 PDT Date: Tue, 28 Aug 2007 03:00:44 -0700 (PDT) From: Simun Mikecin To: freebsd-fs@freebsd.org, pjd@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <937640.78988.qm@web36613.mail.mud.yahoo.com> Cc: Subject: zfs and BIO_FLUSH on amr(4) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 10:00:46 -0000 Using storage on amr(4) controller with zfs revealed reduced write performance. It seems that writing to zfs concludes with a BIO_FLUSH call to flush the controller cache to disk. amr(4) can have onboard cache memory with or without battery backup. Is BIO_FLUSH call really needed when amr(4) is used with onboard cache memory with a battery backup? ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ From owner-freebsd-fs@FreeBSD.ORG Tue Aug 28 10:55:45 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CE7416A420 for ; Tue, 28 Aug 2007 10:55:45 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id E6B9313C45E for ; Tue, 28 Aug 2007 10:55:44 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8109E45E91; Tue, 28 Aug 2007 12:55:43 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6BC4145685; Tue, 28 Aug 2007 12:55:39 +0200 (CEST) Date: Tue, 28 Aug 2007 12:54:35 +0200 From: Pawel Jakub Dawidek To: Simun Mikecin Message-ID: <20070828105435.GC36596@garage.freebsd.pl> References: <937640.78988.qm@web36613.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vEao7xgI/oilGqZ+" Content-Disposition: inline In-Reply-To: <937640.78988.qm@web36613.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: zfs and BIO_FLUSH on amr(4) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 10:55:45 -0000 --vEao7xgI/oilGqZ+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2007 at 03:00:44AM -0700, Simun Mikecin wrote: > Using storage on amr(4) controller with zfs revealed reduced write perfor= mance. > It seems that writing to zfs concludes with a BIO_FLUSH call to flush the= controller cache to > disk. >=20 > amr(4) can have onboard cache memory with or without battery backup. Is B= IO_FLUSH call really > needed when amr(4) is used with onboard cache memory with a battery backu= p? I don't think so. The thing is that when ZFS receives information that write is done, it should be on disk (at some point) and you battery-backed cache should ensure that. You can turn off sending BIO_FLUSH by setting vfs.zfs.cache_flush_disable to 1 (in /boot/loader.conf). BTW. How big performance drop do you see with BIO_FLUSH turned on? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --vEao7xgI/oilGqZ+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG0/7rForvXbEpPzQRAoiqAKChXdHzJ+RneGfiy816ePHBHAiPTQCfQuLp pI3ni9NuGwxkL2/8XdYyotQ= =GcIO -----END PGP SIGNATURE----- --vEao7xgI/oilGqZ+-- From owner-freebsd-fs@FreeBSD.ORG Tue Aug 28 11:54:27 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC0B516A419 for ; Tue, 28 Aug 2007 11:54:27 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 667F413C48A for ; Tue, 28 Aug 2007 11:54:27 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l7SBsQJY059742; Tue, 28 Aug 2007 06:54:26 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46D40CF1.7060000@freebsd.org> Date: Tue, 28 Aug 2007 06:54:25 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Juri Mianovich References: <337134.4926.qm@web45604.mail.sp1.yahoo.com> In-Reply-To: <337134.4926.qm@web45604.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-fs@freebsd.org Subject: Re: minfree 1 -> 0 -> 1 == death ... PLEASE HELP X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 11:54:27 -0000 Juri Mianovich wrote: > On Mon, 27 Aug 2007, Eric Anderson wrote: > >> Regarding the 'KABOOM' part - is that when you mount > it? How about RO? > > > No - it mounts and runs just fine. For about an hour. > Once any meaningful activity is run on it for an hour > or so, the aac raid controller dies, spewing > "controller is no longer running" messages on console. > > If I skip that filesystem, and mount the other > partitions, the system will stay up indefinitely. It > is only by running that filesystem (that I changed > from 1 to 0 to 1) that the aac controller will die > off. > > >> Have you fsck'ed the fs at all? > > > Yes. > > > >> Also - please send the output of this command: >> >> dumpfs /dev/aacd0s1e | head -n 40 > > > Here you are - sorry for the bad linewrapping: > > > magic 19540119 (UFS2) time Mon Aug 27 19:28:15 > 2007 > superblock location 65536 id [ 44967b53 > b7c98a12 ] > ncg 10379 size 976478879 blocks > 945756917 > bsize 16384 shift 14 mask 0xffffc000 > fsize 2048 shift 11 mask 0xfffff800 > frag 8 shift 3 fsbtodb 2 > minfree 1% optim space symlinklen 120 > maxbsize 16384 maxbpg 2048 maxcontig 8 > contigsumsize 8 > nbfree 1520861 ndir 1336402 nifree 233593652 > nffree 1151519 > bpg 11761 fpg 94088 ipg 23552 > nindir 2048 inopb 64 maxfilesize > 140806241583103 > sbsize 2048 cgsize 16384 csaddr 3000 cssize > 167936 > sblkno 40 cblkno 48 iblkno 56 dblkno > 3000 > cgrotor 8911 fmod 0 ronly 0 clean > 1 > avgfpdir 64 avgfilesize 16384 > flags soft-updates > fsmnt /mount2 > volname swuid 0 > [..snip..] > Like I said, I am sure there is a fascinating > explanation for all of this and we can all learn a > lot, but I _don't care_. Why is the aac controller > dying ? Don't care. Why can't the system handle a > minfree of 0 ? don't care. Why does my new minfree > of 1 behave like a minfree of zero ? Don't care. > > All I want to know is, how do I get back the old > minfree of 1 I had 24 hours ago instead of the "new > and improved" minfree of 1 that I have now ? Can you try doing: tunefs -o time /dev/aacd0s1e and then mounting it? Eric From owner-freebsd-fs@FreeBSD.ORG Tue Aug 28 14:25:54 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C37F16A419 for ; Tue, 28 Aug 2007 14:25:53 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: from web45615.mail.sp1.yahoo.com (web45615.mail.sp1.yahoo.com [68.180.197.180]) by mx1.freebsd.org (Postfix) with SMTP id 1264D13C46E for ; Tue, 28 Aug 2007 14:25:53 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: (qmail 42072 invoked by uid 60001); 28 Aug 2007 14:25:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=EVXTdUsSeUFKX/bJan8LJfdZSrXEVYrPaA3nWQMflY4x0y5TRLOk0i/Of27mNLjPznjKH5qGwmStQRXAPfHnSiLwP5hO7z2aEoXFiQ8WQC79y5we0K0gol4oRCUaoTbGJY/18CZIZq6OF6/bsUoKFOoyr/4SO8iV93LC7Hzgduk=; X-YMail-OSG: uUjI0KYVM1lnufH5n0g06k9oF6QniX8DdfG7jRkW3tX0PdY_5SXdTMO_LD8OOrQWBPF21SlGVi6ESv2fRKpgnDkYUKSd9.0y7R10 Received: from [71.63.232.32] by web45615.mail.sp1.yahoo.com via HTTP; Tue, 28 Aug 2007 07:25:48 PDT Date: Tue, 28 Aug 2007 07:25:48 -0700 (PDT) From: Juri Mianovich To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <60619.41746.qm@web45615.mail.sp1.yahoo.com> X-Mailman-Approved-At: Tue, 28 Aug 2007 14:58:27 +0000 Cc: Subject: Re: minfree 1 -> 0 -> 1 == death ... PLEASE HELP X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 14:25:54 -0000 > > All I want to know is, how do I get back the old > > minfree of 1 I had 24 hours ago instead of the "new > > and improved" minfree of 1 that I have now ? > > Can you try doing: > > > tunefs -o time /dev/aacd0s1e > > and then mounting it? Yes, that was my first instinct, in fact. I can do that, but I am given a warning that filesystems with less than 8% minfree should be optimized for space. After using the filesystem for 10-20 minutes the kernel reverts optimization back to space, even if I explicitly optimize the filesystem for time. So it appears that you cannot force the filesystem to remain optimized for time. Do you know of a way to keep a filesystem optimized for time ? I would like to try running that way. I am currently running with this filesystem mounted, but mounted read-only, and the system is stable that way. Two things I want to try are: - forcing a perm. time optimization, if someone knows how to do that - freeing up enough space to get back to 5 or 8% minfree and seeing if it behaves better with that. But what I would like to know is, is it _known_ that it is more complicated (or perhaps impossible ?) to climb back out of a minfree hole ? Should it be considered a one way move ? Or should I expect to increase and decrease minfree, trading space for performance in whichever direction I am currently moving ? My results seem to suggest it is a one way move, and that you can't expect to regain performance by going back in a positive direction. Comments ? ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz From owner-freebsd-fs@FreeBSD.ORG Tue Aug 28 17:03:07 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3C2416A419 for ; Tue, 28 Aug 2007 17:03:06 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: from web36604.mail.mud.yahoo.com (web36604.mail.mud.yahoo.com [209.191.85.21]) by mx1.freebsd.org (Postfix) with SMTP id B6D6C13C461 for ; Tue, 28 Aug 2007 17:03:06 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: (qmail 51232 invoked by uid 60001); 28 Aug 2007 17:02:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=jscHOUf5CKGyC2M8bWVPhov4455Fl8WOVHEcxcuWT2kc8gEvzc2b6VxALOYsQLOFRh129mFcCLmeIkwVzYbgPsWduCwoCBtllBByWa6uMQ5fOPR23Qu5Zxo1Qfzt50VW/vAlee58QbD5sJ9N12mtVNdt3UdfvR5O8j9WsarAIZw=; X-YMail-OSG: _Gv3xSYVM1nzaMF_9StQ_2naZNcHVnZ76LyQOtJoPqqQYy8RtzTL8F8gYfi_jD.dwh_Vkqj3XWiZEFCxb6NQJyrqfbeOcCBaOuxRCEGxaieSRZTp5snGFuYMlMUHNg-- Received: from [85.10.60.49] by web36604.mail.mud.yahoo.com via HTTP; Tue, 28 Aug 2007 10:02:50 PDT Date: Tue, 28 Aug 2007 10:02:50 -0700 (PDT) From: Simun Mikecin To: Pawel Jakub Dawidek In-Reply-To: <20070828105435.GC36596@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <397419.50435.qm@web36604.mail.mud.yahoo.com> Cc: freebsd-fs@freebsd.org Subject: Re: zfs and BIO_FLUSH on amr(4) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:03:07 -0000 --- Pawel Jakub Dawidek wrote: > On Tue, Aug 28, 2007 at 03:00:44AM -0700, Simun Mikecin wrote: > > amr(4) can have onboard cache memory with or without battery backup. Is BIO_FLUSH call really > > needed when amr(4) is used with onboard cache memory with a battery backup? > I don't think so. The thing is that when ZFS receives information that > write is done, it should be on disk (at some point) and you > battery-backed cache should ensure that. You can turn off sending > BIO_FLUSH by setting vfs.zfs.cache_flush_disable to 1 (in > /boot/loader.conf). > > BTW. How big performance drop do you see with BIO_FLUSH turned on? Not much according to bonnie++: Results from running "bonnie++ -d /var/tmp/test -s 4g -n 100 -u someuser:somegroup" With vfs.zfs.cache_flush_disable=0: Version 1.93c ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP data.home.hr 4G 105 97 57927 15 44814 11 261 97 150219 17 281.0 4 Latency 147ms 1669ms 964ms 83179us 551ms 241ms Version 1.93c ------Sequential Create------ --------Random Create-------- data.home.hr -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 100 19034 92 28638 98 10672 91 13761 98 32042 97 14009 95 Latency 77131us 2460us 3298us 153ms 7728us3796us With vfs.zfs.cache_flush_disable=1: Version 1.93c ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP data.home.hr 4G 118 94 67671 16 41687 10 292 99 154120 20 290.1 4 Latency 764ms 1743ms 1586ms 78276us 342ms 245ms Version 1.93c ------Sequential Create------ --------Random Create-------- data.home.hr -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 100 22064 91 33277 97 13824 93 16720 86 23878 99 10182 95 Latency 68420us 2832us 3789us 727ms 7670us 3838us ____________________________________________________________________________________ Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 From owner-freebsd-fs@FreeBSD.ORG Tue Aug 28 17:46:56 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 173B216A417 for ; Tue, 28 Aug 2007 17:46:56 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: from web45604.mail.sp1.yahoo.com (web45604.mail.sp1.yahoo.com [68.180.197.81]) by mx1.freebsd.org (Postfix) with SMTP id DC4F913C478 for ; Tue, 28 Aug 2007 17:46:55 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: (qmail 95295 invoked by uid 60001); 28 Aug 2007 17:46:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=uKI1FrRepKiPrI7B5JzgmDxvMbYV62SBUqOMAMLNv+X5OxCMEkB/hy+skijvGbYIabB9M5e60yaT17935efBRXWPCvQ7O2+wCn50eiDU07s+CDaIZezIggp3W4GQp0lz8IZ0IX3Et2wXGS44eWF1J/KyQ118mcHBmgfnObMD+ng=; X-YMail-OSG: yAX4HUUVM1n3yxe.5pI1XRTjcrQ0Wyja2clJiWfs20B1Me4Kg3tde0IuytJmsQtswNedA2UT0tM5eMsgqsHg6U697UTB1ZbDr8Sk Received: from [71.63.232.32] by web45604.mail.sp1.yahoo.com via HTTP; Tue, 28 Aug 2007 10:46:55 PDT Date: Tue, 28 Aug 2007 10:46:55 -0700 (PDT) From: Juri Mianovich To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <553262.92195.qm@web45604.mail.sp1.yahoo.com> X-Mailman-Approved-At: Wed, 29 Aug 2007 02:04:09 +0000 Subject: forcing a permanent "time" optimization with tunefs ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 17:46:56 -0000 I have a filesystem with a minfree of 1 that is set for "space" optimization: tunefs: minimum percentage of free space: (-m) 1% tunefs: optimization preference: (-o) space I would like it to be optimized for "time" instead, but when I do this, it almost immediately reverts back to "space" (with a message that a filesystem with less than 8% minfree should be optimized for space) But let's pretend I know better ... and I really do want to optimize it for time - is there any way to force a permanent optimization for "time" ? Many thanks. ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ From owner-freebsd-fs@FreeBSD.ORG Wed Aug 29 04:09:27 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40FBF16A417 for ; Wed, 29 Aug 2007 04:09:27 +0000 (UTC) (envelope-from lorenl@north-winds.org) Received: from hosea.tallye.com (unknown [IPv6:2002:d863:c74e::104]) by mx1.freebsd.org (Postfix) with ESMTP id E18FB13C458 for ; Wed, 29 Aug 2007 04:09:26 +0000 (UTC) (envelope-from lorenl@north-winds.org) Received: from [IPv6:2002:d863:c74e:0:213:d4ff:fe1a:7c2a] ([IPv6:2002:d863:c74e:0:213:d4ff:fe1a:7c2a]) (authenticated bits=0) by hosea.tallye.com (8.14.1/8.13.6) with ESMTP id l7T493aB016062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2007 21:09:06 -0700 DomainKey-Signature: a=rsa-sha1; s=main; d=north-winds.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:content-type:x-greylist:received-spf:x-virus-scanned:x-virus-status; b=qAp0QwE3AHWnsaq2aC1XKNNNP0zze/UNsQzVbtLYfdmZP0qbNH/ma+T6OrsZZPgpJ tqiE7scUVPv2KjMzb9vIXeADAuIwsV9A+JnwEvNu2fnFmta4auP/QIvtsjzBXs8 Message-ID: <46D4F12D.3080107@north-winds.org> Date: Tue, 28 Aug 2007 21:08:13 -0700 From: "Loren M. Lang" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: freebsd-fs X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3468D36E3974A45E7EA54A01" X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (hosea.tallye.com [IPv6:2002:d863:c74e::2]); Tue, 28 Aug 2007 21:09:06 -0700 (PDT) Received-SPF: pass (hosea.tallye.com: is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on hosea.tallye.com X-Virus-Status: Clean Subject: Bug in Newfs setting max-extend-size X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 04:09:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3468D36E3974A45E7EA54A01 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I was reading through the newfs source code for FreeBSD 6.1-RELEASE and noticed some oddities between the man page for newfs and it's source related to max-extent-size (-d). Newfs claims that the default is 16 times the filesystem blocksize. ("... It is presently limited to its default value which is 16 times the file system blocksize.") However, in the source code, if maxbsize is not specified, it is assigned bsize, not 16*bsize. newfs.c: if (maxbsize =3D=3D 0) maxbsize =3D bsize; Also, in mkfs.c, mkfs() does some sanity checks on maxbsize, but in the second if statement on line 211, it checks sblock.fs_maxbsize, not maxbsize, but as far as I can tell, sblock.fs_maxbsize is not yet initialized. mkfs.c: if (maxbsize < bsize || !POWEROF2(maxbsize)) { sblock.fs_maxbsize =3D sblock.fs_bsize; printf("Extent size set to %d\n", sblock.fs_maxbsize); } else if (sblock.fs_maxbsize > FS_MAXCONTIG * sblock.fs_bsize) {= sblock.fs_maxbsize =3D FS_MAXCONTIG * sblock.fs_bsize; printf("Extent size reduced to %d\n", sblock.fs_maxbsize)= ; } else { sblock.fs_maxbsize =3D maxbsize; } Unless I am misunderstanding something, the else if() should read: } else if (maxbsize > FS_MAXCONTIG * sblock.fs_bsize) { This appears to be the same in FreeBSD-CURRENT as well. --=20 Loren M. Lang lorenl@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: CEE1 AAE2 F66C 59B5 34CA C415 6D35 E847 0118 A3D2 --------------enig3468D36E3974A45E7EA54A01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1PE2SHsHRHUO+igRAkbPAKDqe+DiUGz7r0AoHZNUPYYaLonywgCgnmBj M84udkGCe3H1yQWDMuw9mzY= =xLYZ -----END PGP SIGNATURE----- --------------enig3468D36E3974A45E7EA54A01-- From owner-freebsd-fs@FreeBSD.ORG Thu Aug 30 11:10:06 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62C2E16A418 for ; Thu, 30 Aug 2007 11:10:06 +0000 (UTC) (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 2682613C47E for ; Thu, 30 Aug 2007 11:10:06 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 69A072099; Thu, 30 Aug 2007 13:09:38 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id E96452098; Thu, 30 Aug 2007 13:09:37 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id CE82A84483; Thu, 30 Aug 2007 13:09:37 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Juri Mianovich References: <553262.92195.qm@web45604.mail.sp1.yahoo.com> Date: Thu, 30 Aug 2007 13:09:37 +0200 In-Reply-To: <553262.92195.qm@web45604.mail.sp1.yahoo.com> (Juri Mianovich's message of "Tue\, 28 Aug 2007 10\:46\:55 -0700 \(PDT\)") Message-ID: <86lkbtz3bi.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: forcing a permanent "time" optimization with tunefs ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 11:10:06 -0000 Juri Mianovich writes: > I would like it to be optimized for "time" instead, but when I do > this, it almost immediately reverts back to "space" (with a message > that a filesystem with less than 8% minfree should be optimized for > space) > > But let's pretend I know better ... and I really do want to optimize > it for time - is there any way to force a permanent optimization for > "time" ? Sure, raise minfree back to 8%. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Thu Aug 30 14:41:37 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B6C216A417 for ; Thu, 30 Aug 2007 14:41:37 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: from web45609.mail.sp1.yahoo.com (web45609.mail.sp1.yahoo.com [68.180.197.126]) by mx1.freebsd.org (Postfix) with SMTP id 389BA13C46A for ; Thu, 30 Aug 2007 14:41:37 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: (qmail 19364 invoked by uid 60001); 30 Aug 2007 14:31:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=s6EEXKsva8q/ATcE8FgA+8BDphcQXh87s+CbVsgyn8djyP5ljY1xs5QTGC4NYw0R+RrMCRh8FpEhR1wjCg2gGrYtVNW0qjcw1WecojfEW66xOIBzzgDKfZzuo3mUP5J50vuD80feJnZXY9e2As1p1+HpKyW78nIhuamPNIB7fs0=; X-YMail-OSG: 76kOFj0VM1k7diATQVl7NWfLx2rN.O6.u7xnb6z_QqtgoyZl_ytV_wvDAenSJGGI9jcn..siSPxOFPQADIHbXeIiDGJEKnDGjv4B Received: from [71.63.232.32] by web45609.mail.sp1.yahoo.com via HTTP; Thu, 30 Aug 2007 07:31:28 PDT Date: Thu, 30 Aug 2007 07:31:28 -0700 (PDT) From: Juri Mianovich To: Dag-Erling "Smørgrav" In-Reply-To: <86lkbtz3bi.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <113837.11318.qm@web45609.mail.sp1.yahoo.com> Cc: freebsd-fs@freebsd.org Subject: Re: forcing a permanent "time" optimization with tunefs ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 14:41:37 -0000 --- Dag-Erling Smørgrav wrote: > Juri Mianovich writes: > > I would like it to be optimized for "time" > instead, but when I do > > this, it almost immediately reverts back to > "space" (with a message > > that a filesystem with less than 8% minfree should > be optimized for > > space) > > > > But let's pretend I know better ... and I really > do want to optimize > > it for time - is there any way to force a > permanent optimization for > > "time" ? > > Sure, raise minfree back to 8%. Thanks - very helpful of you. Your annoying, useless answer aside, for the sake of the archives I will note that 6% is the magic number, below which the kernel will not respect your switch to "time" optimization, but at which it will. You will still receive a warning: tunefs: should optimize for space with minfree < 8% but the time optimization setting will stick, as long as you have at least 6% minfree. This is documented in the tunefs man page, in fact. The answer to my original question "can I force time optimization if I am below 6%" appears to be "no". You can successfully set optimization to time, but the kernel will always (almost immediately) switch it back to space optimization. ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 From owner-freebsd-fs@FreeBSD.ORG Thu Aug 30 15:09:20 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78AF216A41B for ; Thu, 30 Aug 2007 15:09:20 +0000 (UTC) (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 3865D13C480 for ; Thu, 30 Aug 2007 15:09:19 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 6FD112096; Thu, 30 Aug 2007 17:09:13 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id D407A2094; Thu, 30 Aug 2007 17:09:12 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id ACF9184483; Thu, 30 Aug 2007 17:09:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Juri Mianovich References: <113837.11318.qm@web45609.mail.sp1.yahoo.com> Date: Thu, 30 Aug 2007 17:09:12 +0200 In-Reply-To: <113837.11318.qm@web45609.mail.sp1.yahoo.com> (Juri Mianovich's message of "Thu\, 30 Aug 2007 07\:31\:28 -0700 \(PDT\)") Message-ID: <868x7tys87.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: forcing a permanent "time" optimization with tunefs ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 15:09:20 -0000 Juri Mianovich writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Juri Mianovich writes: > > > But let's pretend I know better ... and I really do want to optimize > > > it for time - is there any way to force a permanent optimization for > > > "time" ? > > Sure, raise minfree back to 8%. > Thanks - very helpful of you. You're welcome. > Your annoying, useless answer aside, for the sake of the archives I > will note that 6% is the magic number, below which the kernel will not > respect your switch to "time" optimization, but at which it will. Yes, this is documented in tunefs(8). > You will still receive a warning: > > tunefs: should optimize for space with minfree < 8% You really don't get it, do you? The time optimizations which you so dearly wish to hold on to are based on assumptions about the amount of free space available. The purpose of minfree is (partly) to ensure that those assumptions hold. When you reduce minfree (or the disk fills up anyway because of a runaway cron job or whatever), the file system must switch to a different set of optimizations. BTW, explain this: if you don't care about conserving space, why did you lower minfree in the first place? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Thu Aug 30 16:04:11 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEDD016A420 for ; Thu, 30 Aug 2007 16:04:11 +0000 (UTC) (envelope-from tzhuan@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id E17D613C48D for ; Thu, 30 Aug 2007 16:04:10 +0000 (UTC) (envelope-from tzhuan@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so445541nfd for ; Thu, 30 Aug 2007 09:04:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=iMEQxYofV2pkISwDnwgK+vg8/P0Vn2kQIk+AwNiHseuNIg3QJ9Z5mi1M3XG2PMAOy5VvHy9jqxYDsCVhWjp2l5zXf0f83wVcvOKlWDQmkXPl8HUI/+X+TXmu2+a4rkj4tsCdvqr8VLeUkjhX31/5PxYaXu/Seq9v+aN81r8/FWs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=CmgL7OppOq75LVowqGqZk99Y+nvjis2Kwg5QUIpffJyEOKsyus4b1ZrSi3fSOxjpS0R/4GBG0fA2Toe7ybieLqtL+kd8TdPlgmGGSj2FEtF43Y0XQyq4zQZAGh8jpL1OvE5xBTMBTsPx4c3ZYuynOCu3ksdJ8lVTyKCZ1OIuxpw= Received: by 10.86.100.7 with SMTP id x7mr492608fgb.1188488159543; Thu, 30 Aug 2007 08:35:59 -0700 (PDT) Received: by 10.86.30.5 with HTTP; Thu, 30 Aug 2007 08:35:59 -0700 (PDT) Message-ID: <6a7033710708300835n5ac95063o6331ede5fcc80662@mail.gmail.com> Date: Thu, 30 Aug 2007 23:35:59 +0800 From: "Tz-Huan Huang" Sender: tzhuan@gmail.com To: "Bruce Evans" In-Reply-To: <20070814154812.J24186@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1837_22684143.1188488159514" References: <20070712084115.GA2200@deviant.kiev.zoral.com.ua> <20070716195556.P12807@besplex.bde.org> <20070721063434.GI2200@deviant.kiev.zoral.com.ua> <20070721233613.Q3366@besplex.bde.org> <20070804075730.GP2738@deviant.kiev.zoral.com.ua> <20070808004001.O926@besplex.bde.org> <20070807170259.GJ2738@deviant.kiev.zoral.com.ua> <20070810133946.H769@besplex.bde.org> <20070810124153.GW2738@deviant.kiev.zoral.com.ua> <20070814154812.J24186@besplex.bde.org> X-Google-Sender-Auth: aa805301d233eda1 Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 16:04:11 -0000 ------=_Part_1837_22684143.1188488159514 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hi, I have a patch that remove the global variables nambuf_ptr, nambuf_len and nambuf_last_id entirely. It should be applied on recent 7-current. Please give it a try, thanks a lot. http://w.csie.org/~tzhuan/freebsd/msdosfs.diff Tz-Huan 2007/8/14, Bruce Evans : > On Fri, 10 Aug 2007, Kostik Belousov wrote: > > > On Fri, Aug 10, 2007 at 01:54:48PM +1000, Bruce Evans wrote: > >> I wrote yet another patch, with allocation on the stack so that no locking > >> is required. This is simpler and doesn't require any new functions. > >> Unfortunately, it is larger because it changes the interfaces for most > >> functions. The interface changes are routine, so this is probably better. > >> Note that 'struct dirent's are already allocated on the stack. This > >> patch adds allocation of 'struct mbnambuf's which are slightly smaller > >> (~256 bytes). I think this is just small enough for stack allocation. > > > > I agree that this is the best approach. The size of the on-stack > > structure still make me worry, although ~270 bytes seems to be not too > > large for 3-pages stack. > > Stack growth seems to be nowhere near a problem. With the extra ~270 > bytes. ls -lR on i386 uses less than a 1-page stack (about 3.5K, > including 0x270 bytes for the pcb). I think the maximum stack depth > is attained when a debugger trap traps a fast interrupt interrupting > a page fault in an i/o routine called from msdosfs_readdir(). Unlike > in RELENG_4, nested interrupts can't occur, so a 1-page stack should > be enough for everything on i386 (but of course isn't quite enough). > I didn't try hard to attain the maximum depth, and just looked at where > the stack got to after running a large ls -lR for a while. msdosfs_readdir() > now allocates 0x2b0 bytes on the stack using "subl $0x2b0,%esp" and > that is now the largest single allocation. This is without INVARIANTS > etc. > > Bruce > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > ------=_Part_1837_22684143.1188488159514 Content-Type: application/octet-stream; name="msdosfs.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="msdosfs.diff"; filename="msdosfs.diff" X-Attachment-Id: f_f5zf53v6 ZGlmZiAtcnVOIG1zZG9zZnMub3JpZy9kaXJlbnRyeS5oIG1zZG9zZnMvZGlyZW50cnkuaAotLS0g bXNkb3Nmcy5vcmlnL2RpcmVudHJ5LmgJMjAwNi0xMC0yNCAxOToxNDowNS4wMDAwMDAwMDAgKzA4 MDAKKysrIG1zZG9zZnMvZGlyZW50cnkuaAkyMDA3LTA4LTMwIDE1OjE0OjA0LjAwMDAwMDAwMCAr MDgwMApAQCAtMTM2LDE4ICsxMzYsMTUgQEAKIHN0cnVjdCBkaXJlbnQ7CiBzdHJ1Y3QgbXNkb3Nm c21vdW50OwogCi1jaGFyCSptYm5hbWJ1Zl9mbHVzaChzdHJ1Y3QgZGlyZW50ICpkcCk7Ci12b2lk CW1ibmFtYnVmX2luaXQodm9pZCk7Ci12b2lkCW1ibmFtYnVmX3dyaXRlKGNoYXIgKm5hbWUsIGlu dCBpZCk7CiBpbnQJZG9zMnVuaXhmbih1X2NoYXIgZG5bMTFdLCB1X2NoYXIgKnVuLCBpbnQgbG93 ZXIsCiAJICAgIHN0cnVjdCBtc2Rvc2ZzbW91bnQgKnBtcCk7CiBpbnQJdW5peDJkb3Nmbihjb25z dCB1X2NoYXIgKnVuLCB1X2NoYXIgZG5bMTJdLCBzaXplX3QgdW5sZW4sIHVfaW50IGdlbiwKIAkg ICAgc3RydWN0IG1zZG9zZnNtb3VudCAqcG1wKTsKIGludAl1bml4MndpbmZuKGNvbnN0IHVfY2hh ciAqdW4sIHNpemVfdCB1bmxlbiwgc3RydWN0IHdpbmVudHJ5ICp3ZXAsIGludCBjbnQsCiAJICAg IGludCBjaGtzdW0sIHN0cnVjdCBtc2Rvc2ZzbW91bnQgKnBtcCk7Ci1pbnQJd2luQ2hrTmFtZShj b25zdCB1X2NoYXIgKnVuLCBzaXplX3QgdW5sZW4sIGludCBjaGtzdW0sCitpbnQJd2luQ2hrTmFt ZShjb25zdCB1X2NoYXIgKnVuLCBzaXplX3QgdW5sZW4sIHN0cnVjdCBkaXJlbnQgKmRpcmJ1ZnB0 ciwgaW50IGNoa3N1bSwKIAkgICAgc3RydWN0IG1zZG9zZnNtb3VudCAqcG1wKTsKLWludAl3aW4y dW5peGZuKHN0cnVjdCB3aW5lbnRyeSAqd2VwLCBpbnQgY2hrc3VtLCBzdHJ1Y3QgbXNkb3Nmc21v dW50ICpwbXApOworaW50CXdpbjJ1bml4Zm4oc3RydWN0IHdpbmVudHJ5ICp3ZXAsIHN0cnVjdCBk aXJlbnQgKmRpcmJ1ZnB0ciwgaW50IGNoa3N1bSwgc3RydWN0IG1zZG9zZnNtb3VudCAqcG1wKTsK IHVfaW50OF90IHdpbkNoa3N1bShzdHJ1Y3QgZGlyZW50cnkgKmRlcCk7CiBpbnQJd2luU2xvdENu dChjb25zdCB1X2NoYXIgKnVuLCBzaXplX3QgdW5sZW4sIHN0cnVjdCBtc2Rvc2ZzbW91bnQgKnBt cCk7CiBzaXplX3QJd2luTGVuRml4dXAoY29uc3QgdV9jaGFyICp1biwgc2l6ZV90IHVubGVuKTsK ZGlmZiAtcnVOIG1zZG9zZnMub3JpZy9tc2Rvc2ZzX2NvbnYuYyBtc2Rvc2ZzL21zZG9zZnNfY29u di5jCi0tLSBtc2Rvc2ZzLm9yaWcvbXNkb3Nmc19jb252LmMJMjAwNy0wOC0zMCAxMTozMzoyMi4w MDAwMDAwMDAgKzA4MDAKKysrIG1zZG9zZnMvbXNkb3Nmc19jb252LmMJMjAwNy0wOC0zMCAxNjo1 NzoxNS4wMDAwMDAwMDAgKzA4MDAKQEAgLTY0LDEzICs2NCw5IEBACiBzdGF0aWMgaW50IG1ic2Fk anBvcyhjb25zdCBjaGFyICoqLCBzaXplX3QsIHNpemVfdCwgaW50LCBpbnQsIHZvaWQgKmhhbmRs ZSk7CiBzdGF0aWMgdV9pbnQxNl90IGRvczJ1bml4Y2hyKGNvbnN0IHVfY2hhciAqKiwgc2l6ZV90 ICosIGludCwgc3RydWN0IG1zZG9zZnNtb3VudCAqKTsKIHN0YXRpYyB1X2ludDE2X3QgdW5peDJk b3NjaHIoY29uc3QgdV9jaGFyICoqLCBzaXplX3QgKiwgc3RydWN0IG1zZG9zZnNtb3VudCAqKTsK LXN0YXRpYyB1X2ludDE2X3Qgd2luMnVuaXhjaHIodV9pbnQxNl90LCBzdHJ1Y3QgbXNkb3Nmc21v dW50ICopOworc3RhdGljIHNpemVfdCB3aW4ydW5peGNocih1X2ludDE2X3Qgd2MsIHN0cnVjdCBk aXJlbnQgKmRpcmJ1ZnB0ciwgc3RydWN0IG1zZG9zZnNtb3VudCAqcG1wKTsKIHN0YXRpYyB1X2lu dDE2X3QgdW5peDJ3aW5jaHIoY29uc3QgdV9jaGFyICoqLCBzaXplX3QgKiwgaW50LCBzdHJ1Y3Qg bXNkb3Nmc21vdW50ICopOwogCi1zdGF0aWMgY2hhcgkqbmFtYnVmX3B0cjsKLXN0YXRpYyBzaXpl X3QJbmFtYnVmX2xlbjsKLXN0YXRpYyBpbnQJbmFtYnVmX2xhc3RfaWQ7Ci0KIC8qCiAgKiAwIC0g Y2hhcmFjdGVyIGRpc2FsbG93ZWQgaW4gbG9uZyBmaWxlIG5hbWUuCiAgKiAxIC0gY2hhcmFjdGVy IHNob3VsZCBiZSByZXBsYWNlZCBieSAnXycgaW4gRE9TIGZpbGUgbmFtZSwgCkBAIC0yNDksNiAr MjQ1LDExIEBACiAJaW50IHRoaXNsb25nID0gMDsKIAl1X2ludDE2X3QgYzsKIAorI2lmZGVmIE1T RE9TRlNfREVCVUcKKwl1X2NoYXIgKnVuX3B0ciA9IHVuOworCXByaW50ZigiZG9zMnVuaXhmbigp OiBkbiAlcyIsIGRuKTsKKyNlbmRpZiAKKwogCS8qCiAJICogSWYgZmlyc3QgY2hhciBvZiB0aGUg ZmlsZW5hbWUgaXMgU0xPVF9FNSAoMHgwNSksIHRoZW4gdGhlIHJlYWwKIAkgKiBmaXJzdCBjaGFy IG9mIHRoZSBmaWxlbmFtZSBzaG91bGQgYmUgMHhlNS4gQnV0LCB0aGV5IGNvdWxkbid0CkBAIC0y OTMsNiArMjk0LDEwIEBACiAJfQogCSp1bisrID0gMDsKIAorI2lmZGVmIE1TRE9TRlNfREVCVUcK KwlwcmludGYoIiAtPiB1biAlcywgc2l6ZSAlZFxuIiwgdW5fcHRyLCB0aGlzbG9uZyk7CisjZW5k aWYgCisKIAlyZXR1cm4gKHRoaXNsb25nKTsKIH0KIApAQCAtNjAxLDM3ICs2MDYsMzggQEAKICAq IFJldHVybnMgdGhlIGNoZWNrc3VtIG9yIC0xIGlmIG5vIG1hdGNoCiAgKi8KIGludAotd2luQ2hr TmFtZSh1biwgdW5sZW4sIGNoa3N1bSwgcG1wKQord2luQ2hrTmFtZSh1biwgdW5sZW4sIGRpcmJ1 ZnB0ciwgY2hrc3VtLCBwbXApCiAJY29uc3QgdV9jaGFyICp1bjsKIAlzaXplX3QgdW5sZW47CisJ c3RydWN0IGRpcmVudCAqZGlyYnVmcHRyOwogCWludCBjaGtzdW07CiAJc3RydWN0IG1zZG9zZnNt b3VudCAqcG1wOwogewogCXNpemVfdCBsZW47CiAJdV9pbnQxNl90IGMxLCBjMjsKIAl1X2NoYXIg Km5wOwotCXN0cnVjdCBkaXJlbnQgZGlyYnVmOwogCi0JLyoKLQkgKiBXZSBhbHJlYWQgaGF2ZSB3 aW5lbnRyeSBpbiBtYm5hbWJ1ZgotCSAqLwotCWlmICghbWJuYW1idWZfZmx1c2goJmRpcmJ1Zikg fHwgIWRpcmJ1Zi5kX25hbWxlbikKKwlpZiAoIWRpcmJ1ZnB0ci0+ZF9uYW1sZW4pCiAJCXJldHVy biAtMTsKIAogI2lmZGVmIE1TRE9TRlNfREVCVUcKLQlwcmludGYoIndpbkNoa05hbWUoKTogdW49 JXM6JWQsZF9uYW1lPSVzOiVkXG4iLCB1biwgdW5sZW4sCi0JCQkJCQkJZGlyYnVmLmRfbmFtZSwK LQkJCQkJCQlkaXJidWYuZF9uYW1sZW4pOworCXByaW50Zigid2luQ2hrTmFtZSgpOiB1bj0weCIp OworCWZvciAoY29uc3QgdV9jaGFyICpjID0gdW47ICpjOyArK2MpCisJCXByaW50ZigiJTAyeCIs ICh1bnNpZ25lZCBjaGFyKSpjKTsKKwlwcmludGYoIjolZCwgZF9uYW1lPTB4IiwgdW5sZW4pOwor CWZvciAoY2hhciAqYyA9IGRpcmJ1ZnB0ci0+ZF9uYW1lOyAqYzsgKytjKQorCQlwcmludGYoIiUw MngiLCAodW5zaWduZWQgY2hhcikqYyk7CisJcHJpbnRmKCI6JWRcbiIsIGRpcmJ1ZnB0ci0+ZF9u YW1sZW4pOwogI2VuZGlmCiAKIAkvKgogCSAqIENvbXBhcmUgdGhlIG5hbWUgcGFydHMKIAkgKi8K LQlsZW4gPSBkaXJidWYuZF9uYW1sZW47CisJbGVuID0gZGlyYnVmcHRyLT5kX25hbWxlbjsKIAlp ZiAodW5sZW4gIT0gbGVuKQogCQlyZXR1cm4gLTI7CiAKLQlmb3IgKG5wID0gZGlyYnVmLmRfbmFt ZTsgdW5sZW4gPiAwICYmIGxlbiA+IDA7KSB7CisJZm9yIChucCA9IGRpcmJ1ZnB0ci0+ZF9uYW1l OyB1bmxlbiA+IDAgJiYgbGVuID4gMDspIHsKIAkJLyoKIAkJICogQ29tcGFyaXNvbiBtdXN0IGJl IGNhc2UgaW5zZW5zaXRpdmUsIGJlY2F1c2UgRkFUIGRpc2FsbG93cwogCQkgKiB0byBsb29rIHVw IG9yIGNyZWF0ZSBmaWxlcyBpbiBjYXNlIHNlbnNpdGl2ZSBldmVuIHdoZW4KQEAgLTY0NiwxOSAr NjUyLDM2IEBACiB9CiAKIC8qCi0gKiBDb252ZXJ0IFdpbjk1IGZpbGVuYW1lIHRvIGRpcmJ1Zi4K KyAqIFJldmVyc2UgQy1TdHJpbmcKKyAqIGZvciBleGFtcGxlLCAxMjM0NSAtPiA1NDMyMQorICov CitzdGF0aWMgdm9pZAorc3RycmV2ZXJzZShjaGFyICpzdHIsIHNpemVfdCBuKQoreworCWNoYXIg YzsKKwlzaXplX3QgaTsKKwlmb3IgKGkgPSAwOyBpIDwgbi8yOyArK2kpIHsKKwkJYyA9IHN0cltp XTsKKwkJc3RyW2ldID0gc3RyW24taS0xXTsKKwkJc3RyW24taS0xXSA9IGM7CisJfQorfQorCisv KgorICogQ29udmVydCBXaW45NSBmaWxlbmFtZSB0byBkaXJidWYgKCpkaXJidWZwdHIpLgogICog UmV0dXJucyB0aGUgY2hlY2tzdW0gb3IgLTEgaWYgaW1wb3NzaWJsZQogICovCiBpbnQKLXdpbjJ1 bml4Zm4od2VwLCBjaGtzdW0sIHBtcCkKK3dpbjJ1bml4Zm4od2VwLCBkaXJidWZwdHIsIGNoa3N1 bSwgcG1wKQogCXN0cnVjdCB3aW5lbnRyeSAqd2VwOworCXN0cnVjdCBkaXJlbnQgKmRpcmJ1ZnB0 cjsKIAlpbnQgY2hrc3VtOwogCXN0cnVjdCBtc2Rvc2ZzbW91bnQgKnBtcDsKIHsKIAl1X2ludDhf dCAqY3A7Ci0JdV9pbnQ4X3QgKm5wLCBuYW1lW1dJTl9DSEFSUyAqIDIgKyAxXTsKIAl1X2ludDE2 X3QgY29kZTsKIAlpbnQgaTsKKwljb25zdCBzaXplX3QgZF9uYW1sZW4gPSBkaXJidWZwdHItPmRf bmFtbGVuOyAvKiBzYXZlIGZvciByZXZlcnNlICovCiAKIAlpZiAoKHdlcC0+d2VDbnQmV0lOX0NO VCkgPiBob3dtYW55KFdJTl9NQVhMRU4sIFdJTl9DSEFSUykKIAkgICAgfHwgISh3ZXAtPndlQ250 JldJTl9DTlQpKQpAQCAtNjc3LDIyICs3MDAsMTggQEAKIAkvKgogCSAqIENvbnZlcnQgdGhlIG5h bWUgcGFydHMKIAkgKi8KLQlucCA9IG5hbWU7CiAJZm9yIChjcCA9IHdlcC0+d2VQYXJ0MSwgaSA9 IHNpemVvZih3ZXAtPndlUGFydDEpLzI7IC0taSA+PSAwOykgewogCQljb2RlID0gKGNwWzFdIDw8 IDgpIHwgY3BbMF07CiAJCXN3aXRjaCAoY29kZSkgewogCQljYXNlIDA6Ci0JCQkqbnAgPSAnXDAn OwotCQkJbWJuYW1idWZfd3JpdGUobmFtZSwgKHdlcC0+d2VDbnQgJiBXSU5fQ05UKSAtIDEpOwor CQkJZGlyYnVmcHRyLT5kX25hbWVbZGlyYnVmcHRyLT5kX25hbWxlbl0gPSAnXDAnOwogCQkJcmV0 dXJuIGNoa3N1bTsKIAkJY2FzZSAnLyc6Ci0JCQkqbnAgPSAnXDAnOworCQkJZGlyYnVmcHRyLT5k X25hbWVbZGlyYnVmcHRyLT5kX25hbWxlbl0gPSAnXDAnOwogCQkJcmV0dXJuIC0xOwogCQlkZWZh dWx0OgotCQkJY29kZSA9IHdpbjJ1bml4Y2hyKGNvZGUsIHBtcCk7Ci0JCQlpZiAoY29kZSAmIDB4 ZmYwMCkKLQkJCQkqbnArKyA9IGNvZGUgPj4gODsKLQkJCSpucCsrID0gY29kZTsKKwkJCWNvZGUg PSB3aW4ydW5peGNocihjb2RlLCBkaXJidWZwdHIsIHBtcCk7CisJCQlpZiAoY29kZSkgcmV0dXJu IC0xOwogCQkJYnJlYWs7CiAJCX0KIAkJY3AgKz0gMjsKQEAgLTcwMSwxNyArNzIwLDE0IEBACiAJ CWNvZGUgPSAoY3BbMV0gPDwgOCkgfCBjcFswXTsKIAkJc3dpdGNoIChjb2RlKSB7CiAJCWNhc2Ug MDoKLQkJCSpucCA9ICdcMCc7Ci0JCQltYm5hbWJ1Zl93cml0ZShuYW1lLCAod2VwLT53ZUNudCAm IFdJTl9DTlQpIC0gMSk7CisJCQlkaXJidWZwdHItPmRfbmFtZVtkaXJidWZwdHItPmRfbmFtbGVu XSA9ICdcMCc7CiAJCQlyZXR1cm4gY2hrc3VtOwogCQljYXNlICcvJzoKLQkJCSpucCA9ICdcMCc7 CisJCQlkaXJidWZwdHItPmRfbmFtZVtkaXJidWZwdHItPmRfbmFtbGVuXSA9ICdcMCc7CiAJCQly ZXR1cm4gLTE7CiAJCWRlZmF1bHQ6Ci0JCQljb2RlID0gd2luMnVuaXhjaHIoY29kZSwgcG1wKTsK LQkJCWlmIChjb2RlICYgMHhmZjAwKQotCQkJCSpucCsrID0gY29kZSA+PiA4OwotCQkJKm5wKysg PSBjb2RlOworCQkJY29kZSA9IHdpbjJ1bml4Y2hyKGNvZGUsIGRpcmJ1ZnB0ciwgcG1wKTsKKwkJ CWlmIChjb2RlKSByZXR1cm4gLTE7CiAJCQlicmVhazsKIAkJfQogCQljcCArPSAyOwpAQCAtNzIw LDIzICs3MzYsMjUgQEAKIAkJY29kZSA9IChjcFsxXSA8PCA4KSB8IGNwWzBdOwogCQlzd2l0Y2gg KGNvZGUpIHsKIAkJY2FzZSAwOgotCQkJKm5wID0gJ1wwJzsKLQkJCW1ibmFtYnVmX3dyaXRlKG5h bWUsICh3ZXAtPndlQ250ICYgV0lOX0NOVCkgLSAxKTsKKwkJCWRpcmJ1ZnB0ci0+ZF9uYW1lW2Rp cmJ1ZnB0ci0+ZF9uYW1sZW5dID0gJ1wwJzsKIAkJCXJldHVybiBjaGtzdW07CiAJCWNhc2UgJy8n OgotCQkJKm5wID0gJ1wwJzsKKwkJCWRpcmJ1ZnB0ci0+ZF9uYW1lW2RpcmJ1ZnB0ci0+ZF9uYW1s ZW5dID0gJ1wwJzsKIAkJCXJldHVybiAtMTsKIAkJZGVmYXVsdDoKLQkJCWNvZGUgPSB3aW4ydW5p eGNocihjb2RlLCBwbXApOwotCQkJaWYgKGNvZGUgJiAweGZmMDApCi0JCQkJKm5wKysgPSBjb2Rl ID4+IDg7Ci0JCQkqbnArKyA9IGNvZGU7CisJCQljb2RlID0gd2luMnVuaXhjaHIoY29kZSwgZGly YnVmcHRyLCBwbXApOworCQkJaWYgKGNvZGUpIHJldHVybiAtMTsKIAkJCWJyZWFrOwogCQl9CiAJ CWNwICs9IDI7CiAJfQotCSpucCA9ICdcMCc7Ci0JbWJuYW1idWZfd3JpdGUobmFtZSwgKHdlcC0+ d2VDbnQgJiBXSU5fQ05UKSAtIDEpOworCWRpcmJ1ZnB0ci0+ZF9uYW1lW2RpcmJ1ZnB0ci0+ZF9u YW1sZW5dID0gJ1wwJzsKKworCS8qIHN3YXAgdGhlIGRpcmJ1ZnB0ci0+ZF9uYW1lICovCisJc3Ry cmV2ZXJzZShkaXJidWZwdHItPmRfbmFtZSwgZGlyYnVmcHRyLT5kX25hbWxlbik7CisJc3RycmV2 ZXJzZShkaXJidWZwdHItPmRfbmFtZSwgZGlyYnVmcHRyLT5kX25hbWxlbiAtIGRfbmFtbGVuKTsK KwlzdHJyZXZlcnNlKGRpcmJ1ZnB0ci0+ZF9uYW1lICsgZGlyYnVmcHRyLT5kX25hbWxlbiAtIGRf bmFtbGVuLCBkX25hbWxlbik7CisKIAlyZXR1cm4gY2hrc3VtOwogfQogCkBAIC05NTIsMTAgKzk3 MCwxMCBAQAogLyoKICAqIENvbnZlcnQgV2luZG93cyBjaGFyIHRvIExvY2FsIGNoYXIKICAqLwot c3RhdGljIHVfaW50MTZfdAotd2luMnVuaXhjaHIodV9pbnQxNl90IHdjLCBzdHJ1Y3QgbXNkb3Nm c21vdW50ICpwbXApCitzdGF0aWMgc2l6ZV90Cit3aW4ydW5peGNocih1X2ludDE2X3Qgd2MsIHN0 cnVjdCBkaXJlbnQgKmRpcmJ1ZnB0ciwgc3RydWN0IG1zZG9zZnNtb3VudCAqcG1wKQogewotCXVf Y2hhciAqaW5wLCAqb3V0cCwgaW5idWZbM10sIG91dGJ1ZlszXTsKKwl1X2NoYXIgKmlucCwgKm91 dHAsIGluYnVmWzNdOwogCXNpemVfdCBpbGVuLCBvbGVuLCBsZW47CiAKIAlpZiAod2MgPT0gMCkK QEAgLTk2NiwzMSArOTg0LDQ5IEBACiAJCWluYnVmWzFdID0gKHVfY2hhcil3YzsKIAkJaW5idWZb Ml0gPSAnXDAnOwogCi0JCWlsZW4gPSBvbGVuID0gbGVuID0gMjsKKwkJaWxlbiA9IDI7CisJCW9s ZW4gPSBsZW4gPSBzaXplb2YoZGlyYnVmcHRyLT5kX25hbWUpIC0gZGlyYnVmcHRyLT5kX25hbWxl biAtIDE7CiAJCWlucCA9IGluYnVmOwotCQlvdXRwID0gb3V0YnVmOworCQlvdXRwID0gZGlyYnVm cHRyLT5kX25hbWUgKyBkaXJidWZwdHItPmRfbmFtbGVuOworCiAJCW1zZG9zZnNfaWNvbnYtPmNv bnZjaHIocG1wLT5wbV93MnUsIChjb25zdCBjaGFyICoqKSZpbnAsICZpbGVuLAogCQkJCSAgICAg KGNoYXIgKiopJm91dHAsICZvbGVuKTsKLQkJbGVuIC09IG9sZW47CiAKLQkJLyoKLQkJICogcmV0 dXJuICc/JyBpZiBmYWlsZWQgdG8gY29udmVydAotCQkgKi8KLQkJaWYgKGxlbiA9PSAwKSB7Ci0J CQl3YyA9ICc/JzsKLQkJCXJldHVybiAod2MpOwotCQl9CisJCWRpcmJ1ZnB0ci0+ZF9uYW1sZW4g Kz0gbGVuIC0gb2xlbjsKIAotCQl3YyA9IDA7Ci0JCXdoaWxlKGxlbi0tKQotCQkJd2MgfD0gKCoo b3V0cCAtIGxlbiAtIDEpICYgMHhmZikgPDwgKGxlbiA8PCAzKTsKLQkJcmV0dXJuICh3Yyk7CisJ CWlmIChpbGVuICE9IDApIHsgCisJCQkvKiBmYWlsZWQgdG8gY29udmVydCAqLworCQkJaWYgKG9s ZW4gPT0gMCkgeyAKKwkJCQkvKiBmaWxlbmFtZSBsb25nZXIgdGhlbiBNQVhOQU1MRU4gKi8KKwkJ CQlnb3RvIHRvb19sb25nOworCQkJfSBlbHNlIHsgCisJCQkJLyogc29tZSBjaGFyYWN0ZXIgY2Fu bm90IGJlIGNvbnZlcnRlZCAqLworCQkJCWdvdG8gZmFpbGVkOworCQkJfQorCQl9IAorCisJCWdv dG8gb2s7CiAJfQogCi0JaWYgKHdjICYgMHhmZjAwKQotCQl3YyA9ICc/JzsKKwlpZiAoc2l6ZW9m KGRpcmJ1ZnB0ci0+ZF9uYW1lKSA8PSBkaXJidWZwdHItPmRfbmFtbGVuICsgMikgeworCQkvKiBm aWxlbmFtZSBsb25nZXIgdGhlbiBNQVhOQU1MRU4gKi8KKwkJZ290byB0b29fbG9uZzsKKwl9IGVs c2UgaWYgKHdjICYgMHhmZjAwKSB7CisJCWdvdG8gZmFpbGVkOworCX0KKwlkaXJidWZwdHItPmRf bmFtZVtkaXJidWZwdHItPmRfbmFtbGVuKytdID0gKHVfY2hhcikod2M+PjgpOworCWRpcmJ1ZnB0 ci0+ZF9uYW1lW2RpcmJ1ZnB0ci0+ZF9uYW1sZW4rK10gPSAodV9jaGFyKXdjOworCWdvdG8gb2s7 CiAKLQlyZXR1cm4gKHdjKTsKK29rOgorCXJldHVybiAwOworCit0b29fbG9uZzoKKwlyZXR1cm4g MTsKKworZmFpbGVkOgorCWRpcmJ1ZnB0ci0+ZF9uYW1lW2RpcmJ1ZnB0ci0+ZF9uYW1sZW4rK10g PSAnPyc7CisJcmV0dXJuIDI7CiB9CiAKIC8qCkBAIC0xMDM1LDc4ICsxMDcxLDMgQEAKIAkoKmlu c3RyKSsrOwogCXJldHVybiAod2MpOwogfQotCi0vKgotICogSW5pdGlhbGl6ZSB0aGUgdGVtcG9y YXJ5IGNvbmNhdGVuYXRpb24gYnVmZmVyIChvbmNlKSBhbmQgbWFyayBpdCBhcwotICogZW1wdHkg b24gc3Vic2VxdWVudCBjYWxscy4KLSAqLwotdm9pZAotbWJuYW1idWZfaW5pdCh2b2lkKQotewot Ci0gICAgICAgIGlmIChuYW1idWZfcHRyID09IE5VTEwpIHsgCi0JCW5hbWJ1Zl9wdHIgPSBtYWxs b2MoTUFYTkFNTEVOICsgMSwgTV9NU0RPU0ZTTU5ULCBNX1dBSVRPSyk7Ci0JCW5hbWJ1Zl9wdHJb TUFYTkFNTEVOXSA9ICdcMCc7Ci0JfQotCW5hbWJ1Zl9sZW4gPSAwOwotCW5hbWJ1Zl9sYXN0X2lk ID0gLTE7Ci19Ci0KLS8qCi0gKiBGaWxsIG91dCBvdXIgY29uY2F0ZW5hdGlvbiBidWZmZXIgd2l0 aCB0aGUgZ2l2ZW4gc3Vic3RyaW5nLCBhdCB0aGUgb2Zmc2V0Ci0gKiBzcGVjaWZpZWQgYnkgaXRz IGlkLiAgU2luY2UgdGhpcyBmdW5jdGlvbiBtdXN0IGJlIGNhbGxlZCB3aXRoIGlkcyBpbgotICog ZGVzY2VuZGluZyBvcmRlciwgd2UgdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGZhY3QgdGhhdCBBU0NJ SSBzdWJzdHJpbmdzIGFyZQotICogZXhhY3RseSBXSU5fQ0hBUlMgaW4gbGVuZ3RoLiAgRm9yIG5v bi1BU0NJSSBzdWJzdHJpbmdzLCB3ZSBzaGlmdCBhbGwKLSAqIHByZXZpb3VzIChpLmUuIGhpZ2hl ciBpZCkgc3Vic3RyaW5ncyB1cHdhcmRzIHRvIG1ha2Ugcm9vbSBmb3IgdGhpcyBvbmUuCi0gKiBU aGlzIG9ubHkgcGVuYWxpemVzIHBvcnRpb25zIG9mIHN1YnN0cmluZ3MgdGhhdCBjb250YWluIG1v cmUgdGhhbgotICogV0lOX0NIQVJTIGJ5dGVzIHdoZW4gdGhleSBhcmUgZmlyc3QgZW5jb3VudGVy ZWQuCi0gKi8KLXZvaWQKLW1ibmFtYnVmX3dyaXRlKGNoYXIgKm5hbWUsIGludCBpZCkKLXsKLQlz aXplX3QgY291bnQ7Ci0JY2hhciAqc2xvdDsKLQotCUtBU1NFUlQobmFtYnVmX2xlbiA9PSAwIHx8 IGlkID09IG5hbWJ1Zl9sYXN0X2lkIC0gMSwKLQkgICAgKCJub24tZGVjcmVhc2luZyBpZCwgaWQg JWQgbGFzdCBpZCAlZCIsIGlkLCBuYW1idWZfbGFzdF9pZCkpOwotCi0JLyogU3RvcmUgdGhpcyBz dWJzdHJpbmcgaW4gYSBXSU5fQ0hBUi1hbGlnbmVkIHNsb3QuICovCi0Jc2xvdCA9IG5hbWJ1Zl9w dHIgKyAoaWQgKiBXSU5fQ0hBUlMpOwotCWNvdW50ID0gc3RybGVuKG5hbWUpOwotCWlmIChuYW1i dWZfbGVuICsgY291bnQgPiBNQVhOQU1MRU4pIHsKLQkJcHJpbnRmKCJtc2Rvc2ZzOiBmaWxlIG5h bWUgJXp1IHRvbyBsb25nXG4iLCBuYW1idWZfbGVuICsgY291bnQpOwotCQlyZXR1cm47Ci0JfQot Ci0JLyogU2hpZnQgc3VmZml4IHVwd2FyZHMgYnkgdGhlIGFtb3VudCBsZW5ndGggZXhjZWVkcyBX SU5fQ0hBUlMuICovCi0JaWYgKGNvdW50ID4gV0lOX0NIQVJTICYmIG5hbWJ1Zl9sZW4gIT0gMCkK LQkJYmNvcHkoc2xvdCArIFdJTl9DSEFSUywgc2xvdCArIGNvdW50LCBuYW1idWZfbGVuKTsKLQot CS8qIENvcHkgaW4gdGhlIHN1YnN0cmluZyB0byBpdHMgc2xvdCBhbmQgdXBkYXRlIGxlbmd0aCBz byBmYXIuICovCi0JYmNvcHkobmFtZSwgc2xvdCwgY291bnQpOwotCW5hbWJ1Zl9sZW4gKz0gY291 bnQ7Ci0JbmFtYnVmX2xhc3RfaWQgPSBpZDsKLX0KLQotLyoKLSAqIFRha2UgdGhlIGNvbXBsZXRl ZCBzdHJpbmcgYW5kIHVzZSBpdCB0byBzZXR1cCB0aGUgc3RydWN0IGRpcmVudC4KLSAqIEJlIHN1 cmUgdG8gYWx3YXlzIG51bC10ZXJtaW5hdGUgdGhlIGRfbmFtZSBhbmQgdGhlbiBjb3B5IHRoZSBz dHJpbmcKLSAqIGZyb20gb3VyIGJ1ZmZlci4gIE5vdGUgdGhhdCB0aGlzIGZ1bmN0aW9uIGFzc3Vt ZXMgdGhlIGZ1bGwgc3RyaW5nIGhhcwotICogYmVlbiByZWFzc2VtYmxlZCBpbiB0aGUgYnVmZmVy LiAgSWYgaXQncyBjYWxsZWQgYmVmb3JlIGFsbCBzdWJzdHJpbmdzCi0gKiBoYXZlIGJlZW4gd3Jp dHRlbiB2aWEgbWJuYW1idWZfd3JpdGUoKSwgdGhlIHJlc3VsdCB3aWxsIGJlIGluY29ycmVjdC4K LSAqLwotY2hhciAqCi1tYm5hbWJ1Zl9mbHVzaChzdHJ1Y3QgZGlyZW50ICpkcCkKLXsKLQotCWlm IChuYW1idWZfbGVuID4gc2l6ZW9mKGRwLT5kX25hbWUpIC0gMSkgewotCQltYm5hbWJ1Zl9pbml0 KCk7Ci0JCXJldHVybiAoTlVMTCk7Ci0JfQotCWJjb3B5KG5hbWJ1Zl9wdHIsIGRwLT5kX25hbWUs IG5hbWJ1Zl9sZW4pOwotCWRwLT5kX25hbWVbbmFtYnVmX2xlbl0gPSAnXDAnOwotCWRwLT5kX25h bWxlbiA9IG5hbWJ1Zl9sZW47Ci0KLQltYm5hbWJ1Zl9pbml0KCk7Ci0JcmV0dXJuIChkcC0+ZF9u YW1lKTsKLX0KZGlmZiAtcnVOIG1zZG9zZnMub3JpZy9tc2Rvc2ZzX2xvb2t1cC5jIG1zZG9zZnMv bXNkb3Nmc19sb29rdXAuYwotLS0gbXNkb3Nmcy5vcmlnL21zZG9zZnNfbG9va3VwLmMJMjAwNy0w OC0wNyAxMDoyNTo1Ni4wMDAwMDAwMDAgKzA4MDAKKysrIG1zZG9zZnMvbXNkb3Nmc19sb29rdXAu YwkyMDA3LTA4LTMwIDE2OjQ0OjUwLjAwMDAwMDAwMCArMDgwMApAQCAtNTQsNiArNTQsNyBAQAog I2luY2x1ZGUgPHN5cy9tb3VudC5oPgogI2luY2x1ZGUgPHN5cy9uYW1laS5oPgogI2luY2x1ZGUg PHN5cy92bm9kZS5oPgorI2luY2x1ZGUgPHN5cy9kaXJlbnQuaD4KIAogI2luY2x1ZGUgPGZzL21z ZG9zZnMvYnBiLmg+CiAjaW5jbHVkZSA8ZnMvbXNkb3Nmcy9kaXJlbnRyeS5oPgpAQCAtMTE1LDcg KzExNiwxMCBAQAogCWludCBvbGRkb3MgPSAxOwogCiAjaWZkZWYgTVNET1NGU19ERUJVRwotCXBy aW50ZigibXNkb3Nmc19sb29rdXAoKTogbG9va2luZyBmb3IgJXNcbiIsIGNucC0+Y25fbmFtZXB0 cik7CisJcHJpbnRmKCJtc2Rvc2ZzX2xvb2t1cCgpOiBsb29raW5nIGZvciAweCIpOworCWZvciAo Y2hhciAqYyA9IGNucC0+Y25fbmFtZXB0cjsgKmM7ICsrYykKKwkJcHJpbnRmKCIlMDJ4IiwgKHVu c2lnbmVkIGNoYXIpKmMpOworCXByaW50ZigiXG4iKTsKICNlbmRpZgogCWRwID0gVlRPREUodmRw KTsKIAlwbXAgPSBkcC0+ZGVfcG1wOwpAQCAtMTc3LDE1ICsxODEsMTggQEAKIAkJc2xvdGNvdW50 ID0gMDsKIAogI2lmZGVmIE1TRE9TRlNfREVCVUcKLQlwcmludGYoIm1zZG9zZnNfbG9va3VwKCk6 IGRvcyB2ZXJzaW9uIG9mIGZpbGVuYW1lICVzLCBsZW5ndGggJWxkXG4iLAotCSAgICBkb3NmaWxl bmFtZSwgY25wLT5jbl9uYW1lbGVuKTsKKwlwcmludGYoIm1zZG9zZnNfbG9va3VwKCk6IGRvcyB2 ZXJzaW9uIG9mIGZpbGVuYW1lIDB4Iik7CisJZm9yIChjaGFyICpjID0gZG9zZmlsZW5hbWU7ICpj OyArK2MpCisJCXByaW50ZigiJTAyeCIsICh1bnNpZ25lZCBjaGFyKSpjKTsKKwlwcmludGYoIiAs IGxlbmd0aCAlbGRcbiIsIGNucC0+Y25fbmFtZWxlbik7CiAjZW5kaWYKIAkvKgogCSAqIFNlYXJj aCB0aGUgZGlyZWN0b3J5IHBvaW50ZWQgYXQgYnkgdmRwIGZvciB0aGUgbmFtZSBwb2ludGVkIGF0 CiAJICogYnkgY25wLT5jbl9uYW1lcHRyLgogCSAqLwogCXRkcCA9IE5VTEw7Ci0JbWJuYW1idWZf aW5pdCgpOworCXN0cnVjdCBkaXJlbnQgbmFtZWJ1ZjsKKwluYW1lYnVmLmRfbmFtbGVuID0gMDsK IAkvKgogCSAqIFRoZSBvdXRlciBsb29wIHJhbmdlcyBvdmVyIHRoZSBjbHVzdGVycyB0aGF0IG1h a2UgdXAgdGhlCiAJICogZGlyZWN0b3J5LiAgTm90ZSB0aGF0IHRoZSByb290IGRpcmVjdG9yeSBp cyBkaWZmZXJlbnQgZnJvbSBhbGwKQEAgLTIyNSw3ICsyMzIsNyBAQAogCQkJCSAqIERyb3AgbWVt b3J5IG9mIHByZXZpb3VzIGxvbmcgbWF0Y2hlcwogCQkJCSAqLwogCQkJCWNoa3N1bSA9IC0xOwot CQkJCW1ibmFtYnVmX2luaXQoKTsKKwkJCQluYW1lYnVmLmRfbmFtbGVuID0gMDsKIAogCQkJCWlm IChzbG90Y291bnQgPCB3aW5jbnQpIHsKIAkJCQkJc2xvdGNvdW50Kys7CkBAIC0yNTEsNiArMjU4 LDcgQEAKIAkJCQkJCWNvbnRpbnVlOwogCiAJCQkJCWNoa3N1bSA9IHdpbjJ1bml4Zm4oKHN0cnVj dCB3aW5lbnRyeSAqKWRlcCwKKwkJCQkJCQkJJm5hbWVidWYsCiAJCQkJCQkJICAgIGNoa3N1bSwK IAkJCQkJCQkgICAgcG1wKTsKIAkJCQkJY29udGludWU7CkBAIC0yNTgsOSArMjY2LDExIEBACiAK IAkJCQljaGtzdW0gPSB3aW5DaGtOYW1lKChjb25zdCB1X2NoYXIgKiljbnAtPmNuX25hbWVwdHIs CiAJCQkJCQkgICAgdW5sZW4sCisJCQkJCQkJJm5hbWVidWYsCiAJCQkJCQkgICAgY2hrc3VtLAog CQkJCQkJICAgIHBtcCk7CiAJCQkJaWYgKGNoa3N1bSA9PSAtMikgeworCQkJCQluYW1lYnVmLmRf bmFtbGVuID0gMDsKIAkJCQkJY2hrc3VtID0gLTE7CiAJCQkJCWNvbnRpbnVlOwogCQkJCX0KZGlm ZiAtcnVOIG1zZG9zZnMub3JpZy9tc2Rvc2ZzX3Zub3BzLmMgbXNkb3Nmcy9tc2Rvc2ZzX3Zub3Bz LmMKLS0tIG1zZG9zZnMub3JpZy9tc2Rvc2ZzX3Zub3BzLmMJMjAwNy0wOC0wNyAxODozNToyNy4w MDAwMDAwMDAgKzA4MDAKKysrIG1zZG9zZnMvbXNkb3Nmc192bm9wcy5jCTIwMDctMDgtMzAgMTU6 MTU6NDUuMDAwMDAwMDAwICswODAwCkBAIC0xNjI5LDcgKzE2MjksOCBAQAogCQl9CiAJfQogCi0J bWJuYW1idWZfaW5pdCgpOworCWRpcmJ1Zi5kX25hbWxlbiA9IDA7CisKIAlvZmYgPSBvZmZzZXQ7 CiAJd2hpbGUgKHVpby0+dWlvX3Jlc2lkID4gMCkgewogCQlsYm4gPSBkZV9jbHVzdGVyKHBtcCwg b2Zmc2V0IC0gYmlhcyk7CkBAIC0xNjc2LDcgKzE2NzcsNyBAQAogCQkJICovCiAJCQlpZiAoZGVu dHAtPmRlTmFtZVswXSA9PSBTTE9UX0RFTEVURUQpIHsKIAkJCQljaGtzdW0gPSAtMTsKLQkJCQlt Ym5hbWJ1Zl9pbml0KCk7CisJCQkJZGlyYnVmLmRfbmFtbGVuID0gMDsKIAkJCQljb250aW51ZTsK IAkJCX0KIApAQCAtMTY4Niw3ICsxNjg3LDcgQEAKIAkJCWlmIChkZW50cC0+ZGVBdHRyaWJ1dGVz ID09IEFUVFJfV0lOOTUpIHsKIAkJCQlpZiAocG1wLT5wbV9mbGFncyAmIE1TRE9TRlNNTlRfU0hP UlROQU1FKQogCQkJCQljb250aW51ZTsKLQkJCQljaGtzdW0gPSB3aW4ydW5peGZuKChzdHJ1Y3Qg d2luZW50cnkgKilkZW50cCwKKwkJCQljaGtzdW0gPSB3aW4ydW5peGZuKChzdHJ1Y3Qgd2luZW50 cnkgKilkZW50cCwgJmRpcmJ1ZiwKIAkJCQkJY2hrc3VtLCBwbXApOwogCQkJCWNvbnRpbnVlOwog CQkJfQpAQCAtMTY5Niw3ICsxNjk3LDcgQEAKIAkJCSAqLwogCQkJaWYgKGRlbnRwLT5kZUF0dHJp YnV0ZXMgJiBBVFRSX1ZPTFVNRSkgewogCQkJCWNoa3N1bSA9IC0xOwotCQkJCW1ibmFtYnVmX2lu aXQoKTsKKwkJCQlkaXJidWYuZF9uYW1sZW4gPSAwOwogCQkJCWNvbnRpbnVlOwogCQkJfQogCQkJ LyoKQEAgLTE3MzgsOSArMTczOSw4IEBACiAJCQkJCSgocG1wLT5wbV9mbGFncyAmIE1TRE9TRlNN TlRfU0hPUlROQU1FKSA/CiAJCQkJCShMQ0FTRV9CQVNFIHwgTENBU0VfRVhUKSA6IDApLAogCQkJ CSAgICBwbXApOwotCQkJCW1ibmFtYnVmX2luaXQoKTsKLQkJCX0gZWxzZQotCQkJCW1ibmFtYnVm X2ZsdXNoKCZkaXJidWYpOworCQkJfSAKKwogCQkJY2hrc3VtID0gLTE7CiAJCQlkaXJidWYuZF9y ZWNsZW4gPSBHRU5FUklDX0RJUlNJWigmZGlyYnVmKTsKIAkJCWlmICh1aW8tPnVpb19yZXNpZCA8 IGRpcmJ1Zi5kX3JlY2xlbikgewpAQCAtMTc2MCw2ICsxNzYwLDggQEAKIAkJCQl9CiAJCQl9CiAJ CQlvZmYgPSBvZmZzZXQgKyBzaXplb2Yoc3RydWN0IGRpcmVudHJ5KTsKKworCQkJZGlyYnVmLmRf bmFtbGVuID0gMDsKIAkJfQogCQlicmVsc2UoYnApOwogCX0K ------=_Part_1837_22684143.1188488159514-- From owner-freebsd-fs@FreeBSD.ORG Thu Aug 30 16:57:38 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2BF516A417 for ; Thu, 30 Aug 2007 16:57:38 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from spacemail2-out.mgmt.space.net (spacemail2-out.mgmt.space.net [194.97.149.148]) by mx1.freebsd.org (Postfix) with ESMTP id 807AA13C45D for ; Thu, 30 Aug 2007 16:57:38 +0000 (UTC) (envelope-from se@FreeBSD.org) X-SpaceNet-SBRS: None X-IronPort-AV: E=Sophos;i="4.19,326,1183327200"; d="scan'208";a="40540128" Received: from mail.atsec.com ([195.30.252.105]) by spacemail2-out.mgmt.space.net with ESMTP; 30 Aug 2007 18:28:13 +0200 Received: from [10.2.2.88] (frueh.atsec.com [217.110.13.170]) (Authenticated sender: se@atsec.com) by mail.atsec.com (Postfix) with ESMTP id 200807209B4; Thu, 30 Aug 2007 18:28:12 +0200 (CEST) Message-ID: <46D6F016.7020005@FreeBSD.org> Date: Thu, 30 Aug 2007 18:28:06 +0200 From: Stefan Esser User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Juri Mianovich References: <113837.11318.qm@web45609.mail.sp1.yahoo.com> In-Reply-To: <113837.11318.qm@web45609.mail.sp1.yahoo.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, =?ISO-8859-1?Q?=22Dag-Erling_=5C=22Sm=F8rgrav=5C=22=22?= Subject: Re: forcing a permanent "time" optimization with tunefs ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 16:57:39 -0000 Juri Mianovich wrote: > tunefs: should optimize for space with minfree < 8% > > but the time optimization setting will stick, as long > as you have at least 6% minfree. This is documented > in the tunefs man page, in fact. > > The answer to my original question "can I force time > optimization if I am below 6%" appears to be "no". > You can successfully set optimization to time, but the > kernel will always (almost immediately) switch it back > to space optimization. Have you ever read the (now ancient) paper about FFS? The file-system needs free space to avoid fragmentation (not the one reported by fsck), which would slow down large file access by several orders of magnitude. So you pay a high price for using up those last few percent of capacity (except in special usage cases). You can easily achieve the effect of always optimizing for time if you create your file system with identical block and fragment sizes. (I'm wondering, whether you know, what optimization for time or space is about???) Optimization for time causes file ends to be stored in full blocks (leaving the rest of the block unused). All, the optimization for space does, is put several files smaller than one block (or file ends) into one block (e.g. if you have got 16KB blocks and 2KB fragments then 2KB + 4KB + 20KB could be put into two 16KB blocks, while optimization for time would require 4 blocks of 16KB to store those same files). In fact, optimization for space allows to fill up all the (previously only partly allocated) blocks for use by small files. And if you start too late to do this, you'll have too many blocks used only to a fraction. Back to the example: If you have only 4 blocks of 16KB, then storing 2KB, 4KB, 20KB will use up those blocks, if you are optimizing for time: F1: Block 1: 2KB (14KB left free) F2: Block 2: 4KB (12KB left free) F3: Block 3: 16KB (full block) Block 4: 4KB (12KB left free) In that case, your disk was full and no more data could be written. If you had switched to optimize for space early (the correct time to switch modes does not so much depend on a percentage of free space, but rather on the ratio of partial blocks to full blocks and to free blocks), this could have all been stored in 2 blocks, leaving half of your space available: F1 + F2 + F3(tail) Block 1: 2KB // 4KB // 4KB (6KB left) F3: Block 2: 16KB (full block) Block 3: (16KB free) Block 4: (16KB free) So if you are willing to waste space for small files (or if you do not expect to store many small files, since the optimization is only used for files that do not require indirect blocks), then create your file system with fragment size equal to block size and waste some space. But I thought you wanted to put as much data on your disk and did not want to waste space? Well, then better let those well thought out optimizations (TM) do their job and do not step in their way ;-) You never mentioned what you are trying to achieve. Their are cases, where a very low min-free man make sense (static file systems consisting of files that are larger than some 200KB). In all other cases you are going to be hurt. All this (and much more) is explained in much detail in the FFS paper by McKusick et.al., see: /usr/share/doc/smm/05.fastfs/paper.ascii.gz Regards, STefan From owner-freebsd-fs@FreeBSD.ORG Thu Aug 30 21:00:52 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F1A316A419 for ; Thu, 30 Aug 2007 21:00:52 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: from web45607.mail.sp1.yahoo.com (web45607.mail.sp1.yahoo.com [68.180.197.108]) by mx1.freebsd.org (Postfix) with SMTP id 062B113C45B for ; Thu, 30 Aug 2007 21:00:51 +0000 (UTC) (envelope-from juri_mian@yahoo.com) Received: (qmail 63722 invoked by uid 60001); 30 Aug 2007 20:11:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ir1QEw40NJNJUAnR8iQ7WKX9ijcIm+eY9yF+hC/hyIHrhtQtonfZhAdO+AjxO0tmU08A3BauxDzCn7fJSgyMc+NeaGFr5BuH2fZyYPugJiwbAOTP8nBVfo93/1l8fjfB2sjto0yxBabnt3WT0eTW4ZfOzwTeG/OGrwSyAT5matU=; X-YMail-OSG: pTYwYgYVM1kKDLkzaZ0fW9LccqiHyf5IBlERPzjcou0EWgAcTGTTtbJjvBfiFOIzV3i7VpEVU8f_MX8WaEIlxy1HaYJMGsxuqjIn Received: from [71.63.232.32] by web45607.mail.sp1.yahoo.com via HTTP; Thu, 30 Aug 2007 13:11:37 PDT Date: Thu, 30 Aug 2007 13:11:37 -0700 (PDT) From: Juri Mianovich To: Dag-Erling "Sm�rgrav" In-Reply-To: <868x7tys87.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <588014.62881.qm@web45607.mail.sp1.yahoo.com> Cc: freebsd-fs@freebsd.org Subject: Re: forcing a permanent "time" optimization with tunefs ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 21:00:52 -0000 --- Dag-Erling Sm�rgrav wrote: > BTW, explain this: if you don't care about > conserving space, why did you > lower minfree in the first place? As per the original thread, I _did_ care about conserving space, and in fact would _very much like_ to optimize for space. However, it turns out that the 6.2-RELEASE version of aac combined with a adaptec 2820sa is overwhelmed by the combination of: - 0% minfree - quotas - a few rsync processes So I _immediately_ tuned it right back to 1% minfree where it had been for 200+ days. Oops - it turns out that going downwards in minfree is a one-way operation, in some aspects - and going back to 1% did not reduce the stress on the controller. So what I needed very desperately was to find a way to force it to optimize for time, and not for space, even though I had not yet freed up enough bytes to move all the way to 6% minfree. Days later, I was able to move to 6% minfree, and my immediate problems are over. So there's your answer. It turns out that I _did_ have a reason to quickly force a filesystem into "time" optimized, even though its not the best thing overall. ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ From owner-freebsd-fs@FreeBSD.ORG Thu Aug 30 21:13:52 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9476816A419 for ; Thu, 30 Aug 2007 21:13:52 +0000 (UTC) (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 4F7BF13C457 for ; Thu, 30 Aug 2007 21:13:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 7D17E2096; Thu, 30 Aug 2007 23:13:46 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id E92212094; Thu, 30 Aug 2007 23:13:45 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id C237584483; Thu, 30 Aug 2007 23:13:45 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Juri Mianovich References: <588014.62881.qm@web45607.mail.sp1.yahoo.com> Date: Thu, 30 Aug 2007 23:13:45 +0200 In-Reply-To: <588014.62881.qm@web45607.mail.sp1.yahoo.com> (Juri Mianovich's message of "Thu\, 30 Aug 2007 13\:11\:37 -0700 \(PDT\)") Message-ID: <86wsvciv3q.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: forcing a permanent "time" optimization with tunefs ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 21:13:52 -0000 Juri Mianovich writes: > So what I needed very desperately was to find a way to force it to > optimize for time, and not for space, even though I had not yet freed > up enough bytes to move all the way to 6% minfree. ...so you still don't get it. I give up. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Fri Aug 31 00:06:20 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCEBF16A46B for ; Fri, 31 Aug 2007 00:06:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx02.syd.optusnet.com.au (fallbackmx02.syd.optusnet.com.au [211.29.133.72]) by mx1.freebsd.org (Postfix) with ESMTP id D7E4613C468 for ; Fri, 31 Aug 2007 00:06:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by fallbackmx02.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l7V068Ae006847 for ; Fri, 31 Aug 2007 10:06:08 +1000 Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l7V00wnx026703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2007 10:01:07 +1000 Date: Fri, 31 Aug 2007 10:00:58 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Tz-Huan Huang In-Reply-To: <6a7033710708300835n5ac95063o6331ede5fcc80662@mail.gmail.com> Message-ID: <20070831092907.K8647@besplex.bde.org> References: <20070712084115.GA2200@deviant.kiev.zoral.com.ua> <20070716195556.P12807@besplex.bde.org> <20070721063434.GI2200@deviant.kiev.zoral.com.ua> <20070721233613.Q3366@besplex.bde.org> <20070804075730.GP2738@deviant.kiev.zoral.com.ua> <20070808004001.O926@besplex.bde.org> <20070807170259.GJ2738@deviant.kiev.zoral.com.ua> <20070810133946.H769@besplex.bde.org> <20070810124153.GW2738@deviant.kiev.zoral.com.ua> <20070814154812.J24186@besplex.bde.org> <6a7033710708300835n5ac95063o6331ede5fcc80662@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 00:06:20 -0000 On Thu, 30 Aug 2007, Tz-Huan Huang wrote: > I have a patch that remove the global variables nambuf_ptr, nambuf_len and > nambuf_last_id entirely. It should be applied on recent 7-current. Please give > it a try, thanks a lot. > > http://w.csie.org/~tzhuan/freebsd/msdosfs.diff This is too late. I just got approval to commit my version mailed here on 10 Aug, and will commit it today. That version also removes the globals, but doesn't change the algorithm so much. Your version seems to be simpler but has too many style bugs for me. If you want to do more work on this, please adjust your patch to apply to the version that I will commit and clean it up. Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Aug 31 09:15:40 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F08516A420 for ; Fri, 31 Aug 2007 09:15:40 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from zzz.ee (kalah.zzz.ee [194.204.30.253]) by mx1.freebsd.org (Postfix) with ESMTP id 0E36913C4B7 for ; Fri, 31 Aug 2007 09:15:39 +0000 (UTC) (envelope-from antik@bsd.ee) Received: by zzz.ee (Postfix, from userid 3019) id 1B4A2198413; Fri, 31 Aug 2007 11:15:23 +0300 (EEST) Received: from [192.168.1.26] (adsl215.uninet.ee [194.204.62.215]) by zzz.ee (Postfix) with ESMTP id 9FCE6198416 for ; Fri, 31 Aug 2007 11:15:19 +0300 (EEST) From: Andrei Kolu To: freebsd-fs@freebsd.org Date: Fri, 31 Aug 2007 11:15:18 +0300 User-Agent: KMail/1.9.7 References: <20070801122122.GA59065@harmless.hu> <1185979074.1264.14.camel@herring.rabson.org> In-Reply-To: <1185979074.1264.14.camel@herring.rabson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708311115.19057.antik@bsd.ee> X-Spam-Checker-Version: SpamAssassin on spamassassin.zzz.ee X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,BAYES_50 Subject: ZFS - Port mapper failure - RPC: Timed out X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 09:15:40 -0000 I followed this quick guide http://wiki.freebsd.org/ZFSQuickStartGuide and encountered following problem: # zfs snapshot tank/ufs@31082007 # mount /dev/ad4s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad4s1e on /tmp (ufs, local, soft-updates) /dev/ad4s1f on /usr (ufs, local, soft-updates) /dev/ad4s1d on /var (ufs, local, soft-updates) tank on /tank (zfs, local, noatime) tank/usr on /tank/usr (zfs, local, noatime) tank/usr/ports on /tank/usr/ports (zfs, local, noatime) tank/usr/ports/distfiles on /tank/usr/ports/distfiles (zfs, local, noatime) /dev/zvol/tank/ufs on /ufs (ufs, local) # mount -r /dev/zvol/tank/ufs@31082007 /ufs31082007 mount: /ufs31082007: No such file or directory # mkdir /ufs31082007 # mount -r /dev/zvol/tank/ufs@31082007 /ufs31082007 mount_nfs: path@server syntax is deprecated, use server:path [udp] 31082007:/dev/zvol/tank/ufs: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out [udp] 31082007:/dev/zvol/tank/ufs: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out [udp] 31082007:/dev/zvol/tank/ufs: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out From owner-freebsd-fs@FreeBSD.ORG Fri Aug 31 12:10:55 2007 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4B0F16A419; Fri, 31 Aug 2007 12:10:55 +0000 (UTC) (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 502BC13C4F5; Fri, 31 Aug 2007 12:10:53 +0000 (UTC) (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.4/8.13.4) with ESMTP id l7VBeR0h091141; Fri, 31 Aug 2007 15:40:27 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l7VBZK45091036; Fri, 31 Aug 2007 15:35:21 +0400 (MSD) (envelope-from yar) Date: Fri, 31 Aug 2007 15:35:19 +0400 From: Yar Tikhiy To: "Loren M. Lang" Message-ID: <20070831113519.GE85633@comp.chem.msu.su> References: <46D4F12D.3080107@north-winds.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D4F12D.3080107@north-winds.org> User-Agent: Mutt/1.5.9i Cc: freebsd-fs , mckusick@FreeBSD.org Subject: Re: Bug in Newfs setting max-extend-size X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 12:10:55 -0000 On Tue, Aug 28, 2007 at 09:08:13PM -0700, Loren M. Lang wrote: > I was reading through the newfs source code for FreeBSD 6.1-RELEASE and > noticed some oddities between the man page for newfs and it's source > related to max-extent-size (-d). Newfs claims that the default is 16 > times the filesystem blocksize. ("... It is presently limited to its > default value which is 16 times the file system blocksize.") However, > in the source code, if maxbsize is not specified, it is assigned bsize, > not 16*bsize. > newfs.c: > > if (maxbsize == 0) > maxbsize = bsize; As I can judge from the fact that the fs_maxbsize field isn't really used by the kernel UFS code (except for one unrelated place dealing with UFS1 superblock update), extent allocation hasn't been implemented yet. In his paper on UFS2, Kirk said it would be future work. See . When it's actually there, its maximum value will be FS_MAXCONTIG * bsize. I don't think that the paragraph in the manpage should be considered incorrect -- note the word "may" in it. :-) > Also, in mkfs.c, mkfs() does some sanity checks on maxbsize, but in the > second if statement on line 211, it checks sblock.fs_maxbsize, not > maxbsize, but as far as I can tell, sblock.fs_maxbsize is not yet > initialized. > mkfs.c: > > if (maxbsize < bsize || !POWEROF2(maxbsize)) { > sblock.fs_maxbsize = sblock.fs_bsize; > printf("Extent size set to %d\n", sblock.fs_maxbsize); > } else if (sblock.fs_maxbsize > FS_MAXCONTIG * sblock.fs_bsize) { > sblock.fs_maxbsize = FS_MAXCONTIG * sblock.fs_bsize; > printf("Extent size reduced to %d\n", sblock.fs_maxbsize); > } else { > sblock.fs_maxbsize = maxbsize; > } > > Unless I am misunderstanding something, the else if() should read: > > } else if (maxbsize > FS_MAXCONTIG * sblock.fs_bsize) { > > This appears to be the same in FreeBSD-CURRENT as well. This code indeed looks buggy. Besides using uninitialzed sblock.fs_maxbsize, it uses bsize, which is a user-supplied approximation, not a final value from the superblock. I think it should read as follows to be correct: if (maxbsize < sblock.fs_bsize || !POWEROF2(maxbsize)) { ^^^^^^^^^^^^^^^ sblock.fs_maxbsize = sblock.fs_bsize; printf("Extent size set to %d\n", sblock.fs_maxbsize); } else if (maxbsize > FS_MAXCONTIG * sblock.fs_bsize) { ^^^^^^^^ sblock.fs_maxbsize = FS_MAXCONTIG * sblock.fs_bsize; printf("Extent size reduced to %d\n", sblock.fs_maxbsize); } else { sblock.fs_maxbsize = maxbsize; } -- Yar From owner-freebsd-fs@FreeBSD.ORG Fri Aug 31 21:05:07 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9146316A420; Fri, 31 Aug 2007 21:05:07 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 585B013C458; Fri, 31 Aug 2007 21:05:07 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from coruscant.local (naboo.binarysolutions.dk [80.196.17.173]) by solow.pil.dk (Postfix) with ESMTP id B3C8E1CC117; Fri, 31 Aug 2007 23:04:38 +0200 (CEST) Received: by coruscant.local (Postfix, from userid 502) id 04BBF5D656A; Fri, 31 Aug 2007 23:04:37 +0200 (CEST) To: Pawel Jakub Dawidek References: <20070820112946.GC16977@garage.freebsd.pl> From: Kenneth Vestergaard Schmidt Date: Fri, 31 Aug 2007 23:04:37 +0200 In-Reply-To: (Kenneth Vestergaard Schmidt's message of "Mon\, 20 Aug 2007 14\:20\:33 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: 'checksum mismatch' all over the place X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 21:05:07 -0000 Kenneth Vestergaard Schmidt writes: >> How do you know it was fine? Did you have something that did >> checksumming? You could try geli with integrity verification feature >> turned on, fill the disks with some random data and then read it back, >> if your controller corrupts the data, geli should tell you this. > > I may have to do this. The previous drive was almost filled to the brim > with data, which rsync looked at each day, and we didn't have a lot of > re-transfer, but that doesn't necessarily mean anything. *blush* This turned out to be a firmware-issue with the Eonstor RAID-enclosure. After upgrading to v3.47, everything is fine in the checksum-department. Now, however, I can't seem to keep the box running. We've rsync'd 1.56 TB data to an 8.18 TB raidz2 pool, and we're getting panics all the time. It's an x86 with 4 GB RAM. I've got the following in /boot/loader.conf: vfs.zfs.prefetch_disable="1" vfs.zfs.arc_max="107772160" vm.kmem_size_max="629145600" vm.kmem_size_min="629145600" and kern.maxvnodes is set to 50000. When the machine is finished booting, 'vmstat -m' says: Type InUse MemUse HighUse Requests Size(s) solaris 49972 158199K - 455307 16,32,64,128,256,512,1024,2048,4096 and after about an hours worth of rsync'ing, we get: Type InUse MemUse HighUse Requests Size(s) solaris 198797 449675K - 404226785 16,32,64,128,256,512,1024,2048,4096 panic: kmem_malloc(28672): kmem_map too small: 614682624 total allocated I'm not quite sure what knobs to twiddle with, or what values to watch, so any help in this department would be much appreciated. I'm sure it'd be nice to update the Wiki, too, with that info, since the values there don't make things stable. -- Kenneth Schmidt pil.dk From owner-freebsd-fs@FreeBSD.ORG Fri Aug 31 21:39:37 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5755516A418 for ; Fri, 31 Aug 2007 21:39:37 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id B1E8313C45A for ; Fri, 31 Aug 2007 21:39:36 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 6267545EBA; Fri, 31 Aug 2007 23:39:31 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A601C456AB; Fri, 31 Aug 2007 23:39:25 +0200 (CEST) Date: Fri, 31 Aug 2007 23:38:13 +0200 From: Pawel Jakub Dawidek To: Kenneth Vestergaard Schmidt Message-ID: <20070831213812.GB13098@garage.freebsd.pl> References: <20070820112946.GC16977@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: 'checksum mismatch' all over the place X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 21:39:37 -0000 --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 31, 2007 at 11:04:37PM +0200, Kenneth Vestergaard Schmidt wrote: > Kenneth Vestergaard Schmidt writes: > >> How do you know it was fine? Did you have something that did > >> checksumming? You could try geli with integrity verification feature > >> turned on, fill the disks with some random data and then read it back, > >> if your controller corrupts the data, geli should tell you this. > > > > I may have to do this. The previous drive was almost filled to the brim > > with data, which rsync looked at each day, and we didn't have a lot of > > re-transfer, but that doesn't necessarily mean anything. >=20 > *blush* >=20 > This turned out to be a firmware-issue with the Eonstor > RAID-enclosure. After upgrading to v3.47, everything is fine in the > checksum-department. >=20 > Now, however, I can't seem to keep the box running. We've rsync'd 1.56 > TB data to an 8.18 TB raidz2 pool, and we're getting panics all the > time. >=20 > It's an x86 with 4 GB RAM. I've got the following in /boot/loader.conf: >=20 > vfs.zfs.prefetch_disable=3D"1" > vfs.zfs.arc_max=3D"107772160" > vm.kmem_size_max=3D"629145600" > vm.kmem_size_min=3D"629145600" >=20 > and kern.maxvnodes is set to 50000. When the machine is finished > booting, 'vmstat -m' says: >=20 > Type InUse MemUse HighUse Requests Size(s) > solaris 49972 158199K - 455307 16,32,64,128,256,512,1024,2= 048,4096 >=20 > and after about an hours worth of rsync'ing, we get: >=20 > Type InUse MemUse HighUse Requests Size(s) > solaris 198797 449675K - 404226785 16,32,64,128,256,512,1024= ,2048,4096 > panic: kmem_malloc(28672): kmem_map too small: 614682624 total allocated >=20 > I'm not quite sure what knobs to twiddle with, or what values to watch, > so any help in this department would be much appreciated. I'm sure it'd > be nice to update the Wiki, too, with that info, since the values there > don't make things stable. Is this recent HEAD? If so, this may be because of too much metadata caching in ZFS. This was fixed in ZFS, so now ARC can limit metadata cache, but this change is not yet in the tree (only in my perforce branch). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG2IpEForvXbEpPzQRAqsAAKCiO4IWQmzSHLAONUJjLqPpktzQZgCgq6Zf 8vwO0vp6HNC+R5JWWgOaTFA= =PuMI -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- From owner-freebsd-fs@FreeBSD.ORG Fri Aug 31 23:02:58 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53E5816A419; Fri, 31 Aug 2007 23:02:58 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 1B40713C46B; Fri, 31 Aug 2007 23:02:57 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from coruscant.local (naboo.binarysolutions.dk [80.196.17.173]) by solow.pil.dk (Postfix) with ESMTP id 2F55F1CC0ED; Sat, 1 Sep 2007 01:02:57 +0200 (CEST) Received: by coruscant.local (Postfix, from userid 502) id C2A4D5D73B7; Sat, 1 Sep 2007 01:02:55 +0200 (CEST) To: Pawel Jakub Dawidek References: <20070820112946.GC16977@garage.freebsd.pl> <20070831213812.GB13098@garage.freebsd.pl> From: Kenneth Vestergaard Schmidt Date: Sat, 01 Sep 2007 01:02:55 +0200 In-Reply-To: <20070831213812.GB13098@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Fri\, 31 Aug 2007 23\:38\:13 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: 'checksum mismatch' all over the place X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 23:02:58 -0000 Pawel Jakub Dawidek writes: >> I'm not quite sure what knobs to twiddle with, or what values to watch, >> so any help in this department would be much appreciated. I'm sure it'd >> be nice to update the Wiki, too, with that info, since the values there >> don't make things stable. > > Is this recent HEAD? If so, this may be because of too much metadata > caching in ZFS. This was fixed in ZFS, so now ARC can limit metadata > cache, but this change is not yet in the tree (only in my perforce > branch). FreeBSD 7.0-CURRENT #1: Wed Aug 29 15:12:02 CEST 2007 Let me know if you need any testing - the box is pretty unusable in its current state :) -- Kenneth Schmidt pil.dk From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 08:10:13 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B507616A420 for ; Sat, 1 Sep 2007 08:10:13 +0000 (UTC) (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 C629C13C457 for ; Sat, 1 Sep 2007 08:10:12 +0000 (UTC) (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.4/8.13.4) with ESMTP id l817m4AI016403 for ; Sat, 1 Sep 2007 11:48:04 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l817m3l6016397 for fs@freebsd.org; Sat, 1 Sep 2007 11:48:04 +0400 (MSD) (envelope-from yar) Date: Sat, 1 Sep 2007 11:48:03 +0400 From: Yar Tikhiy To: fs@freebsd.org Message-ID: <20070901074803.GM85633@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 08:10:13 -0000 Hi all, With some geom(4) modules saving their metadata in the last sectors of block devices such as disks and partitions, it can be convenient to reserve space at the end of the device when creating a new file system in it. Now newfs(8) allows for specification of file system size, which can be used for the purpose, but additional calculations by hand are needed. OTOH, with the below patch, newfs(8) will grow a new option to specify the reserved space size directly and in a error-free way. The idea and implementation are by Dmitry Morozovsky and yours truly. Any comments or objections? Thanks! -- Yar --- //depot/vendor/freebsd/src/sbin/newfs/mkfs.c 2006/10/31 22:39:49 +++ //depot/user/yar/hack/sbin/newfs/mkfs.c 2007/08/31 09:06:24 @@ -107,7 +107,7 @@ int fragsperinode, optimalfpg, origdensity, minfpg, lastminfpg; long i, j, cylno, csfrags; time_t utime; - quad_t sizepb; + off_t sizepb; int width; char tmpbuf[100]; /* XXX this will break in about 2,500 years */ union { --- //depot/vendor/freebsd/src/sbin/newfs/newfs.8 2006/10/31 22:39:49 +++ //depot/user/yar/hack/sbin/newfs/newfs.8 2007/08/31 11:55:35 @@ -52,6 +52,7 @@ .Op Fl i Ar bytes .Op Fl m Ar free-space .Op Fl o Ar optimization +.Op Fl r Ar reserved .Op Fl s Ar size .Ar special .Sh DESCRIPTION @@ -196,14 +197,30 @@ See .Xr tunefs 8 for more details on how to set this option. +.It Fl r Ar reserved +The size, in sectors, of reserved space +at the end of the partition specified in +.Ar special . +This space will not be occupied by the file system; +it can be used by other consumers such as +.Xr geom 4 . +Defaults to 0. .It Fl s Ar size The size of the file system in sectors. This value defaults to the size of the raw partition specified in .Ar special -(in other words, -.Nm -will use the entire partition for the file system). +less the +.Ar reserved +space at its end (see +.Fl r ) . +A +.Ar size +of 0 can also be used to choose the default value. +A valid +.Ar size +value cannot be larger than the default one, +which means that the file system cannot extend into the reserved space. .El .Pp The following options override the standard sizes for the disk geometry. @@ -237,6 +254,7 @@ on file systems that contain many small files. .Sh SEE ALSO .Xr fdformat 1 , +.Xr geom 4 , .Xr disktab 5 , .Xr fs 5 , .Xr bsdlabel 8 , --- //depot/vendor/freebsd/src/sbin/newfs/newfs.c 2007/03/03 00:43:12 +++ //depot/user/yar/hack/sbin/newfs/newfs.c 2007/08/31 11:55:35 @@ -120,7 +120,7 @@ int Jflag; /* enable gjournal for file system */ int lflag; /* enable multilabel for file system */ int nflag; /* do not create .snap directory */ -quad_t fssize; /* file system size */ +off_t fssize; /* file system size */ int sectorsize; /* bytes/sector */ int realsectorsize; /* bytes/sector in hardware */ int fsize = 0; /* fragment size */ @@ -141,6 +141,7 @@ static char *disktype; static int unlabeled; +static void getfssize(off_t *, const char *p, off_t, off_t); static struct disklabel *getdisklabel(char *s); static void rewritelabel(char *s, struct disklabel *lp); static void usage(void); @@ -154,10 +155,11 @@ struct stat st; char *cp, *special; int ch, i; - off_t mediasize; + off_t mediasize, reserved; + reserved = 0; while ((ch = getopt(argc, argv, - "EJL:NO:RS:T:Ua:b:c:d:e:f:g:h:i:lm:no:s:")) != -1) + "EJL:NO:RS:T:Ua:b:c:d:e:f:g:h:i:lm:no:r:s:")) != -1) switch (ch) { case 'E': Eflag++; @@ -262,11 +264,15 @@ "%s: unknown optimization preference: use `space' or `time'", optarg); break; + case 'r': + reserved = strtoimax(optarg, &cp, 0); + if (*cp || reserved < 0) + errx(1, "%s: bad reserved size", optarg); + break; case 's': - errno = 0; - fssize = strtoimax(optarg, NULL, 0); - if (errno != 0) - err(1, "%s: bad file system size", optarg); + fssize = strtoimax(optarg, &cp, 0); + if (*cp || fssize < 0) + errx(1, "%s: bad file system size", optarg); break; case '?': default: @@ -302,13 +308,8 @@ if (sectorsize == 0) ioctl(disk.d_fd, DIOCGSECTORSIZE, §orsize); - if (sectorsize && !ioctl(disk.d_fd, DIOCGMEDIASIZE, &mediasize)) { - if (fssize == 0) - fssize = mediasize / sectorsize; - else if (fssize > mediasize / sectorsize) - errx(1, "%s: maximum file system size is %jd", - special, (intmax_t)(mediasize / sectorsize)); - } + if (sectorsize && !ioctl(disk.d_fd, DIOCGMEDIASIZE, &mediasize)) + getfssize(&fssize, special, mediasize / sectorsize, reserved); pp = NULL; lp = getdisklabel(special); if (lp != NULL) { @@ -328,11 +329,7 @@ if (pp->p_fstype == FS_BOOT) errx(1, "%s: `%c' partition overlaps boot program", special, *cp); - if (fssize == 0) - fssize = pp->p_size; - if (fssize > pp->p_size) - errx(1, - "%s: maximum file system size %d", special, pp->p_size); + getfssize(&fssize, special, pp->p_size, reserved); if (sectorsize == 0) sectorsize = lp->d_secsize; if (fsize == 0) @@ -385,6 +382,23 @@ exit(0); } +void +getfssize(off_t *fsz, const char *s, off_t disksize, off_t reserved) +{ + off_t available; + + available = disksize - reserved; + if (available <= 0) + errx(1, "%s: reserved size must be less " + "than partition size %jd", + s, (intmax_t)disksize); + if (*fsz == 0) + *fsz = available; + else if (*fsz > available) + errx(1, "%s: maximum file system size is %jd", + s, (intmax_t)available); +} + struct disklabel * getdisklabel(char *s) { @@ -443,6 +457,7 @@ fprintf(stderr, "\t-n do not create .snap directory\n"); fprintf(stderr, "\t-m minimum free space %%\n"); fprintf(stderr, "\t-o optimization preference (`space' or `time')\n"); - fprintf(stderr, "\t-s file systemsize (sectors)\n"); + fprintf(stderr, "\t-r reserved sectors at the end of device\n"); + fprintf(stderr, "\t-s file system size (sectors)\n"); exit(1); } --- //depot/vendor/freebsd/src/sbin/newfs/newfs.h 2006/10/31 22:39:49 +++ //depot/user/yar/hack/sbin/newfs/newfs.h 2007/08/31 09:06:24 @@ -52,7 +52,7 @@ extern int Jflag; /* enable gjournal for file system */ extern int lflag; /* enable multilabel MAC for file system */ extern int nflag; /* do not create .snap directory */ -extern quad_t fssize; /* file system size */ +extern off_t fssize; /* file system size */ extern int sectorsize; /* bytes/sector */ extern int realsectorsize; /* bytes/sector in hardware*/ extern int fsize; /* fragment size */ ----- End ----- From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 08:38:50 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10AB316A41B for ; Sat, 1 Sep 2007 08:38:50 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BF45E13C45B for ; Sat, 1 Sep 2007 08:38:49 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.5]) by phk.freebsd.dk (Postfix) with ESMTP id 8957B17104; Sat, 1 Sep 2007 08:13:08 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l818D7gU003843; Sat, 1 Sep 2007 08:13:07 GMT (envelope-from phk@critter.freebsd.dk) To: Yar Tikhiy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 01 Sep 2007 11:48:03 +0400." <20070901074803.GM85633@comp.chem.msu.su> Date: Sat, 01 Sep 2007 08:13:07 +0000 Message-ID: <3842.1188634387@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: fs@freebsd.org Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 08:38:50 -0000 In message <20070901074803.GM85633@comp.chem.msu.su>, Yar Tikhiy writes: >Hi all, > >With some geom(4) modules saving their metadata in the last sectors >of block devices such as disks and partitions, 1. If those geom modules do not reduce their providers to prevent this metadata from being overwritten, they are buggy. 2. Why not simply allow the -s argument to newfs to be negative so "-s -200" means "reserve 200 sectors" ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 09:24:04 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7CE816A419 for ; Sat, 1 Sep 2007 09:24:04 +0000 (UTC) (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 7DB8213C469 for ; Sat, 1 Sep 2007 09:24:01 +0000 (UTC) (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.4/8.13.4) with ESMTP id l819NBCL017493; Sat, 1 Sep 2007 13:23:11 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l819NAAW017492; Sat, 1 Sep 2007 13:23:10 +0400 (MSD) (envelope-from yar) Date: Sat, 1 Sep 2007 13:23:10 +0400 From: Yar Tikhiy To: Poul-Henning Kamp Message-ID: <20070901092310.GO85633@comp.chem.msu.su> References: <20070901074803.GM85633@comp.chem.msu.su> <3842.1188634387@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3842.1188634387@critter.freebsd.dk> User-Agent: Mutt/1.5.9i Cc: Dmitry Morozovsky , fs@freebsd.org Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 09:24:04 -0000 On Sat, Sep 01, 2007 at 08:13:07AM +0000, Poul-Henning Kamp wrote: > In message <20070901074803.GM85633@comp.chem.msu.su>, Yar Tikhiy writes: > >Hi all, > > > >With some geom(4) modules saving their metadata in the last sectors > >of block devices such as disks and partitions, > > 1. If those geom modules do not reduce their providers to prevent > this metadata from being overwritten, they are buggy. In some scenarios, it can be desirable to newfs first, geom later. > 2. Why not simply allow the -s argument to newfs to be negative so > "-s -200" means "reserve 200 sectors" ? A negative argument to -s has been invalid till now, so we propose a new option for people to express their intentions explicitly. Personally, I don't mind the "-s -200" syntax, but many people consider overloaded arguments unintuitive and error-prone. -- Yar From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 10:00:38 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B977C16A417 for ; Sat, 1 Sep 2007 10:00:38 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 420EF13C442 for ; Sat, 1 Sep 2007 10:00:38 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id D9A1B7C008A; Sat, 1 Sep 2007 11:30:36 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id lnsaoBYCaFyp; Sat, 1 Sep 2007 11:30:36 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 488E27BFF67; Sat, 1 Sep 2007 11:30:35 +0200 (CEST) Date: Sat, 1 Sep 2007 11:30:35 +0200 From: Gergely CZUCZY To: Yar Tikhiy Message-ID: <20070901093035.GA18069@harmless.hu> References: <20070901074803.GM85633@comp.chem.msu.su> <3842.1188634387@critter.freebsd.dk> <20070901092310.GO85633@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <20070901092310.GO85633@comp.chem.msu.su> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Poul-Henning Kamp , Dmitry Morozovsky , fs@freebsd.org Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 10:00:38 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 01, 2007 at 01:23:10PM +0400, Yar Tikhiy wrote: > On Sat, Sep 01, 2007 at 08:13:07AM +0000, Poul-Henning Kamp wrote: > > In message <20070901074803.GM85633@comp.chem.msu.su>, Yar Tikhiy writes: > > >Hi all, > > > > > >With some geom(4) modules saving their metadata in the last sectors > > >of block devices such as disks and partitions,=20 > >=20 > > 1. If those geom modules do not reduce their providers to prevent > > this metadata from being overwritten, they are buggy. >=20 > In some scenarios, it can be desirable to newfs first, geom later. True, done it many time myself. Since sysinstall doesn't allow you to install onto a gmirror array, many install via sysinstall, and gmirror the system afterwards, which is exactly this situation. >=20 > > 2. Why not simply allow the -s argument to newfs to be negative so > > "-s -200" means "reserve 200 sectors" ? >=20 > A negative argument to -s has been invalid till now, so we propose > a new option for people to express their intentions explicitly. > Personally, I don't mind the "-s -200" syntax, but many people > consider overloaded arguments unintuitive and error-prone. I think this "-s " syntax is just fine. As far as the manual will mention this, there's no problem with it. Introducing a new exclusive option could result in people trying to use both at the same time :) Though for this, geom class manuals should mention how much space do they need for the metadata at the end. Or to simplify thing an option for like "reserve some space for (gmirror|gstripe|gfoobar)" should be introduced. Or specifing the module and newfs could "ask" the geom class for its metadata size that should be reserved. Just thinking, sorry if it was too wild... Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owF1VTGP3EQYvSRCSJYoQoGgQPp0QiRH1sZ7d9xdNsklIUByoCiRclKEqGbtz/Zw 9oyZGe+eoxRINEGiQEhUNPkDSBEKNBSUFEhQpKIAKioEJaLkje29PSFxxd6uPX7f +9573+dPnzm1cvL0j48ev3fuk8++OPHl079PX6ka51QeVsLMpArHcTwOxzvx1vlw M9zayaabG9vr46317SSbvvXz+MI1rRwrF+63NU/I8aF7tS6FVBcoKYSx7C41Lgt3 gsW5N6SttZVOajUhqUqp+OjevhHKZmzCN1WiU6nyCX3QaMdpWBupnJiWHAS3FN0R bkR3uKZ4PKL1ON4m4fB9sr4xGce3b9K5eDOOR/SuMLQvDwrZ0twAZhLs0v8+vTMZ b0zi7av+6dg/fVs3ZXiDlQIPekdU9RJkl/YUVWytyJkueoj4fDyOtzd34o3o+s2d 17Y2Nq4kuqqjpOAqqmwT2Wb3P4SkY9uD7d6QJMpy1P/oP+9KV5DVFVPOujq7uUaV TpuSLVkx84xcwdKAhBOpcAJK+itUCuvIcuK0sT2Qzmha6uSAUp7JxD/fJAUJS6m0 B5aESqkWxnWG2NGl9dg/NvyjcUS0lwFZ257IEYtUk9KODKdNwgOZ2uiZTNlYcho/ eAZPOxhXSLukmhngTNk3oWdsvBJwf+RBWhKGadrkeRsFAwtI3elgE1bCSG1HJB0l QgEDTVlpfC58ScXzzFImjYXBHdtSODZRsG8aHoGyYv9oJVRLTgKyai2XWUR3pEIT trVSWQcncJStOuO8K3pOrW4CwC9uIqyaBOWVNEYbMDaiHfWoiyMzKY7BjTqVh/OB twn3HFckMtCbC5Oip3kh4Qt04kORuLLtRcOgNMJbEwXBkSvrcOVu0XYGWFnVONwT 9dAhPDV5U0H7pSb4ArEU58CaobzucPzfKs6HSPAq/MHw0aphywZncG0RpFW6vCh+ dQlyvApACkRqyqygwUyUMoXCEELp+QjlaM4+HRh8BojwrEjXvi/KIGHNuu4t5EPk xtohULJbCz6Y/kYpEwlhEAy6jZBphaYh/J43Fl5VEiJ7BZYt2RZL43CEQA2u94UA kADTR7VLYKlFyulRQ5YazLxrZN8mUNkbhx2EAEXBnndGHfT++FoXF5LsLip6G99v MIkZtltEVxFKTL6wnfcg0oiS5l6eqm+vw+oGwPAZC9G8WAh1hVNYA9KhqnIGo5f4 qen148OkbKynOCiZYGGlmEjblM7vg6FZZ9puX2hqMMRTDUDsuy6FAjPQDcJkLQj2 C93kRedHT6eboAQbxQ6cEceiq7GgXSBzFdZJYGuBAcJO6GZYMdTscXg59kNRVmlE t4zn02VXZm3gBUVb6ngmSnnAyzT2G6Cr4m+eHYbpfm6dkTXfzzOtp8KsrQYDRcRd DpJxX9DWnMhsWJ3DHuvc7UekV29V2IPVzqZj3fuK0h3bYFbe8zsPHS2rDUzTKHjb O99lBMV8+o3BZsj86pkLP4vam59GEWa62zyGkeMguM4mxze6dq9J7rVBJWTp9ARE ustR0l2+gpdqhQVso6IJgjD0Y3kXYyexk/FCcRFdxw84DbN0OeNFkmzPFwvUIsMP Lp96asW/vRdv/tMnf/t15eEDeSL84/uXPv9w+oJ88s3X6v4/3/208vDR30/+fP7F X/769tlHj796/eXn8o9/+Ohf =j1Q/ -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 10:40:04 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A290316A417 for ; Sat, 1 Sep 2007 10:40:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6B513C45D for ; Sat, 1 Sep 2007 10:40:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.5]) by phk.freebsd.dk (Postfix) with ESMTP id 8E34417104; Sat, 1 Sep 2007 10:39:36 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l81AdXGa004457; Sat, 1 Sep 2007 10:39:33 GMT (envelope-from phk@critter.freebsd.dk) To: Gergely CZUCZY From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 01 Sep 2007 11:30:35 +0200." <20070901093035.GA18069@harmless.hu> Date: Sat, 01 Sep 2007 10:39:33 +0000 Message-ID: <4456.1188643173@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Yar Tikhiy , Dmitry Morozovsky , fs@freebsd.org Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 10:40:04 -0000 In message <20070901093035.GA18069@harmless.hu>, Gergely CZUCZY writes: >Though for this, geom class manuals should mention how much >space do they need for the metadata at the end. Or to simplify >thing an option for like "reserve some space for (gmirror|gstripe|gfoobar)" >should be introduced. Or specifing the module and newfs could "ask" >the geom class for its metadata size that should be reserved. >Just thinking, sorry if it was too wild... THe original intent was that you would stick the geom class there first, then make the filesystem. Doing things in the other order is asking for trouble. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 10:58:08 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A50116A418; Sat, 1 Sep 2007 10:58:08 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id 13F5313C467; Sat, 1 Sep 2007 10:58:08 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from prometheus.scode.org (85.229.22.84) by proxy1.bredband.net (7.3.127) id 46D6D3CB0009A900; Sat, 1 Sep 2007 12:15:04 +0200 Received: from localhost (localhost [127.0.0.1]) by prometheus.scode.org (Postfix) with ESMTP id 65FA71CC7B; Sat, 1 Sep 2007 12:15:20 +0200 (CEST) From: Peter Schuller To: freebsd-fs@freebsd.org Date: Sat, 1 Sep 2007 12:15:19 +0200 User-Agent: KMail/1.9.7 References: <20070901074803.GM85633@comp.chem.msu.su> <3842.1188634387@critter.freebsd.dk> <20070901092310.GO85633@comp.chem.msu.su> In-Reply-To: <20070901092310.GO85633@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709011215.20048.peter.schuller@infidyne.com> Cc: Yar Tikhiy , Poul-Henning Kamp , Dmitry Morozovsky , fs@freebsd.org Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 10:58:08 -0000 > In some scenarios, it can be desirable to newfs first, geom later. In particular, moving to root-on-gmirror or root-on-glabel after an installation using standard FreeBSD installation media. Not having to jump between two disks or otherwise jumping through hoops would be very nice. A newfs arg would be controllable through the standard installer, thus making this a lot easier. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 10:58:08 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A50116A418; Sat, 1 Sep 2007 10:58:08 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id 13F5313C467; Sat, 1 Sep 2007 10:58:08 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from prometheus.scode.org (85.229.22.84) by proxy1.bredband.net (7.3.127) id 46D6D3CB0009A900; Sat, 1 Sep 2007 12:15:04 +0200 Received: from localhost (localhost [127.0.0.1]) by prometheus.scode.org (Postfix) with ESMTP id 65FA71CC7B; Sat, 1 Sep 2007 12:15:20 +0200 (CEST) From: Peter Schuller To: freebsd-fs@freebsd.org Date: Sat, 1 Sep 2007 12:15:19 +0200 User-Agent: KMail/1.9.7 References: <20070901074803.GM85633@comp.chem.msu.su> <3842.1188634387@critter.freebsd.dk> <20070901092310.GO85633@comp.chem.msu.su> In-Reply-To: <20070901092310.GO85633@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709011215.20048.peter.schuller@infidyne.com> Cc: Yar Tikhiy , Poul-Henning Kamp , Dmitry Morozovsky , fs@freebsd.org Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 10:58:08 -0000 > In some scenarios, it can be desirable to newfs first, geom later. In particular, moving to root-on-gmirror or root-on-glabel after an installation using standard FreeBSD installation media. Not having to jump between two disks or otherwise jumping through hoops would be very nice. A newfs arg would be controllable through the standard installer, thus making this a lot easier. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 12:10:35 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8A0A16A417 for ; Sat, 1 Sep 2007 12:10:35 +0000 (UTC) (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 1CE3913C45B for ; Sat, 1 Sep 2007 12:10:34 +0000 (UTC) (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.4/8.13.4) with ESMTP id l81C9huO019364; Sat, 1 Sep 2007 16:09:43 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l81C9gYf019363; Sat, 1 Sep 2007 16:09:42 +0400 (MSD) (envelope-from yar) Date: Sat, 1 Sep 2007 16:09:42 +0400 From: Yar Tikhiy To: Gergely CZUCZY Message-ID: <20070901120941.GQ85633@comp.chem.msu.su> References: <20070901074803.GM85633@comp.chem.msu.su> <3842.1188634387@critter.freebsd.dk> <20070901092310.GO85633@comp.chem.msu.su> <20070901093035.GA18069@harmless.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070901093035.GA18069@harmless.hu> User-Agent: Mutt/1.5.9i Cc: Poul-Henning Kamp , Dmitry Morozovsky , fs@freebsd.org Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 12:10:35 -0000 On Sat, Sep 01, 2007 at 11:30:35AM +0200, Gergely CZUCZY wrote: > On Sat, Sep 01, 2007 at 01:23:10PM +0400, Yar Tikhiy wrote: > > On Sat, Sep 01, 2007 at 08:13:07AM +0000, Poul-Henning Kamp wrote: > > > > > > 2. Why not simply allow the -s argument to newfs to be negative so > > > "-s -200" means "reserve 200 sectors" ? > > > > A negative argument to -s has been invalid till now, so we propose > > a new option for people to express their intentions explicitly. > > Personally, I don't mind the "-s -200" syntax, but many people > > consider overloaded arguments unintuitive and error-prone. > > I think this "-s " syntax is just fine. As far as > the manual will mention this, there's no problem with it. > Introducing a new exclusive option could result in people > trying to use both at the same time :) FWIW, the code proposed is robust to specifying both options and has the following semanics: attemt to create the file system in the first S sectors but make sure that there are at least R spare sectors left at the end. It's documented in the manpage patch. :-) -- Yar From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 12:16:10 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE29916A419 for ; Sat, 1 Sep 2007 12:16:10 +0000 (UTC) (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 62DFA13C467 for ; Sat, 1 Sep 2007 12:16:10 +0000 (UTC) (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.4/8.13.4) with ESMTP id l81CFh4u019438; Sat, 1 Sep 2007 16:15:44 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l81CFhZe019437; Sat, 1 Sep 2007 16:15:43 +0400 (MSD) (envelope-from yar) Date: Sat, 1 Sep 2007 16:15:43 +0400 From: Yar Tikhiy To: Poul-Henning Kamp Message-ID: <20070901121543.GR85633@comp.chem.msu.su> References: <20070901093035.GA18069@harmless.hu> <4456.1188643173@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4456.1188643173@critter.freebsd.dk> User-Agent: Mutt/1.5.9i Cc: Dmitry Morozovsky , fs@freebsd.org Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 12:16:11 -0000 On Sat, Sep 01, 2007 at 10:39:33AM +0000, Poul-Henning Kamp wrote: > In message <20070901093035.GA18069@harmless.hu>, Gergely CZUCZY writes: > > >Though for this, geom class manuals should mention how much > >space do they need for the metadata at the end. Or to simplify > >thing an option for like "reserve some space for (gmirror|gstripe|gfoobar)" > >should be introduced. Or specifing the module and newfs could "ask" > >the geom class for its metadata size that should be reserved. > >Just thinking, sorry if it was too wild... > > THe original intent was that you would stick the geom class there > first, then make the filesystem. Doing things in the other order > is asking for trouble. It can be trickier than putting the geom class there first, but if the requirements of the geom class are well documented, as in the gmirror case, there should be nothing wrong with the trick, granting one knows what he's doing. After all, we aren't a commercial vendor trying to hide all dangerous things from the customer to make support easier. :-) Or am I missing some particular point about geom? -- Yar From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 12:33:05 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AF5216A419 for ; Sat, 1 Sep 2007 12:33:05 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 972F513C45D for ; Sat, 1 Sep 2007 12:33:04 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l81CADH9047211; Sat, 1 Sep 2007 16:10:13 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sat, 1 Sep 2007 16:10:13 +0400 (MSD) From: Dmitry Morozovsky To: Poul-Henning Kamp In-Reply-To: <4456.1188643173@critter.freebsd.dk> Message-ID: <20070901160713.V14738@woozle.rinet.ru> References: <4456.1188643173@critter.freebsd.dk> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Sat, 01 Sep 2007 16:10:13 +0400 (MSD) Cc: fs@freebsd.org, Yar Tikhiy Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 12:33:05 -0000 On Sat, 1 Sep 2007, Poul-Henning Kamp wrote: PK> In message <20070901093035.GA18069@harmless.hu>, Gergely CZUCZY writes: PK> PK> >Though for this, geom class manuals should mention how much PK> >space do they need for the metadata at the end. Or to simplify PK> >thing an option for like "reserve some space for (gmirror|gstripe|gfoobar)" PK> >should be introduced. Or specifing the module and newfs could "ask" PK> >the geom class for its metadata size that should be reserved. PK> >Just thinking, sorry if it was too wild... PK> PK> THe original intent was that you would stick the geom class there PK> first, then make the filesystem. Doing things in the other order PK> is asking for trouble. Well, while in general I agree with you, there are situations where such functionality is desired (hence the patch I originally wrote). Besides migrating to gmirror already mentioned, there were situations where I decided to insert gcache layers between graid3 and partitions. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 12:49:24 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B627016A417 for ; Sat, 1 Sep 2007 12:49:24 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 300CD13C45B for ; Sat, 1 Sep 2007 12:49:23 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l81CTOsI061776; Sat, 1 Sep 2007 14:29:24 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l81CTFZD079579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Sep 2007 14:29:15 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l81CTEl6061341; Sat, 1 Sep 2007 14:29:14 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l81CTE41061340; Sat, 1 Sep 2007 14:29:14 +0200 (CEST) (envelope-from ticso) Date: Sat, 1 Sep 2007 14:29:14 +0200 From: Bernd Walter To: Gergely CZUCZY Message-ID: <20070901122913.GE54895@cicely12.cicely.de> References: <20070901074803.GM85633@comp.chem.msu.su> <3842.1188634387@critter.freebsd.dk> <20070901092310.GO85633@comp.chem.msu.su> <20070901093035.GA18069@harmless.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070901093035.GA18069@harmless.hu> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: Yar Tikhiy , Poul-Henning Kamp , Dmitry Morozovsky , fs@freebsd.org Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 12:49:25 -0000 On Sat, Sep 01, 2007 at 11:30:35AM +0200, Gergely CZUCZY wrote: > On Sat, Sep 01, 2007 at 01:23:10PM +0400, Yar Tikhiy wrote: > > On Sat, Sep 01, 2007 at 08:13:07AM +0000, Poul-Henning Kamp wrote: > > > In message <20070901074803.GM85633@comp.chem.msu.su>, Yar Tikhiy writes: > > > >Hi all, > > > > > > > >With some geom(4) modules saving their metadata in the last sectors > > > >of block devices such as disks and partitions, > > > > > > 1. If those geom modules do not reduce their providers to prevent > > > this metadata from being overwritten, they are buggy. > > > > In some scenarios, it can be desirable to newfs first, geom later. > True, done it many time myself. Since sysinstall doesn't allow you > to install onto a gmirror array, many install via sysinstall, and gmirror > the system afterwards, which is exactly this situation. Sysinstall easily allows you to not partition the last few sectors. The newfs option is only usefull if you are mirroring at fs level, which is note quite common for system disks, where you really need partitions. > Though for this, geom class manuals should mention how much > space do they need for the metadata at the end. Or to simplify > thing an option for like "reserve some space for (gmirror|gstripe|gfoobar)" > should be introduced. Or specifing the module and newfs could "ask" > the geom class for its metadata size that should be reserved. > Just thinking, sorry if it was too wild... And there is currently no way to find out if your calculations were wrong, other than try and fail. I guess it would be good if a mount tries to read the last sector and gives a warning if the read fails. I expect many systems were build by adding gmirror later without taking the last sector into account. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 12:58:23 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4E1416A469 for ; Sat, 1 Sep 2007 12:58:23 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 4895913C480 for ; Sat, 1 Sep 2007 12:58:23 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l81CvspI047746; Sat, 1 Sep 2007 16:57:54 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sat, 1 Sep 2007 16:57:54 +0400 (MSD) From: Dmitry Morozovsky To: ticso@cicely.de In-Reply-To: <20070901122913.GE54895@cicely12.cicely.de> Message-ID: <20070901165544.H14738@woozle.rinet.ru> References: <20070901074803.GM85633@comp.chem.msu.su> <3842.1188634387@critter.freebsd.dk> <20070901092310.GO85633@comp.chem.msu.su> <20070901093035.GA18069@harmless.hu> <20070901122913.GE54895@cicely12.cicely.de> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Sat, 01 Sep 2007 16:57:54 +0400 (MSD) Cc: Poul-Henning Kamp , fs@freebsd.org, Yar Tikhiy Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 12:58:23 -0000 On Sat, 1 Sep 2007, Bernd Walter wrote: BW> > > In some scenarios, it can be desirable to newfs first, geom later. BW> > True, done it many time myself. Since sysinstall doesn't allow you BW> > to install onto a gmirror array, many install via sysinstall, and gmirror BW> > the system afterwards, which is exactly this situation. BW> BW> Sysinstall easily allows you to not partition the last few sectors. BW> The newfs option is only usefull if you are mirroring at fs level, BW> which is note quite common for system disks, where you really need BW> partitions. I concur, as all servers (rather entry-level, yeah; and excluding these that have large storage) we deploy last 2 years have two SATA disks with mirrored file systems. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 13:49:05 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78D5F16A419 for ; Sat, 1 Sep 2007 13:49:05 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id E8E8913C4A5 for ; Sat, 1 Sep 2007 13:49:04 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l81DmJrZ064510; Sat, 1 Sep 2007 15:48:19 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l81DmAPq080252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Sep 2007 15:48:10 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l81DmAPt061524; Sat, 1 Sep 2007 15:48:10 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l81Dm9gI061523; Sat, 1 Sep 2007 15:48:09 +0200 (CEST) (envelope-from ticso) Date: Sat, 1 Sep 2007 15:48:09 +0200 From: Bernd Walter To: Dmitry Morozovsky Message-ID: <20070901134809.GF54895@cicely12.cicely.de> References: <20070901074803.GM85633@comp.chem.msu.su> <3842.1188634387@critter.freebsd.dk> <20070901092310.GO85633@comp.chem.msu.su> <20070901093035.GA18069@harmless.hu> <20070901122913.GE54895@cicely12.cicely.de> <20070901165544.H14738@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070901165544.H14738@woozle.rinet.ru> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: Poul-Henning Kamp , ticso@cicely.de, fs@freebsd.org, Yar Tikhiy Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 13:49:05 -0000 On Sat, Sep 01, 2007 at 04:57:54PM +0400, Dmitry Morozovsky wrote: > On Sat, 1 Sep 2007, Bernd Walter wrote: > > BW> > > In some scenarios, it can be desirable to newfs first, geom later. > BW> > True, done it many time myself. Since sysinstall doesn't allow you > BW> > to install onto a gmirror array, many install via sysinstall, and gmirror > BW> > the system afterwards, which is exactly this situation. > BW> > BW> Sysinstall easily allows you to not partition the last few sectors. > BW> The newfs option is only usefull if you are mirroring at fs level, > BW> which is note quite common for system disks, where you really need > BW> partitions. > > I concur, as all servers (rather entry-level, yeah; and excluding these that > have large storage) we deploy last 2 years have two SATA disks with mirrored > file systems. What is the big win if you mirror all partitions/filesystems and not the whole disk? -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 14:00:39 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D0E416A417 for ; Sat, 1 Sep 2007 14:00:39 +0000 (UTC) (envelope-from tzhuan@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 9CEEC13C442 for ; Sat, 1 Sep 2007 14:00:38 +0000 (UTC) (envelope-from tzhuan@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so847273nfd for ; Sat, 01 Sep 2007 07:00:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ldReXjOtutrYyszB+gGqGyceiiKUJOEA49Q+3hPLFAjr50oYqm44QrnMFuUzvRAPej2Pg3BrNL6IgTmUhFhny6YpCjXqs0JZ2mWpstoyX5amNa8fcwDY1kLYPbutHB7bhY7Yb7JE6zIXreVSxP5sJ0vd74ppPONdNCtyyuxgv5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=iZNt6H37kGQmNaG9WujkNMl6HqJi3Wf9eSx9Le32PTPRcdN3z7wGDlMpUA/ZtdjRsE/EYR8kLMSZU9V1/HQO7npwV2Sfypl5EiXfZsR14UssEHLeVBvlSFW6Pl8lifmxt0vE/IzVe9+9hOVsBno4yAVlI/2+4tlImx9s9+5ZVmo= Received: by 10.86.49.13 with SMTP id w13mr1669108fgw.1188654788913; Sat, 01 Sep 2007 06:53:08 -0700 (PDT) Received: by 10.86.30.5 with HTTP; Sat, 1 Sep 2007 06:53:08 -0700 (PDT) Message-ID: <6a7033710709010653i2e43f517y953885b67160c1cd@mail.gmail.com> Date: Sat, 1 Sep 2007 21:53:08 +0800 From: "Tz-Huan Huang" Sender: tzhuan@gmail.com To: "Bruce Evans" In-Reply-To: <20070831092907.K8647@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_864_14572580.1188654788867" References: <20070712084115.GA2200@deviant.kiev.zoral.com.ua> <20070721233613.Q3366@besplex.bde.org> <20070804075730.GP2738@deviant.kiev.zoral.com.ua> <20070808004001.O926@besplex.bde.org> <20070807170259.GJ2738@deviant.kiev.zoral.com.ua> <20070810133946.H769@besplex.bde.org> <20070810124153.GW2738@deviant.kiev.zoral.com.ua> <20070814154812.J24186@besplex.bde.org> <6a7033710708300835n5ac95063o6331ede5fcc80662@mail.gmail.com> <20070831092907.K8647@besplex.bde.org> X-Google-Sender-Auth: 30a9918288a1584d Cc: bugs@freebsd.org, fs@freebsd.org Subject: Re: msdosfs not MPSAFE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 14:00:39 -0000 ------=_Part_864_14572580.1188654788867 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2007/8/31, Bruce Evans : > This is too late. I just got approval to commit my version mailed > here on 10 Aug, and will commit it today. That version also removes > the globals, but doesn't change the algorithm so much. Your version > seems to be simpler but has too many style bugs for me. If you want > to do more work on this, please adjust your patch to apply to the > version that I will commit and clean it up. (sorry that I forgot to replay to all in the previous mail) Ok, the attachment is the new version. I think it's worth committing because it doesn't only solve the global variables problem but also solve the kiconv problem. In original interface the win2unixchr() return a 2-byte int thus it's impossible to convert from UTF-16BE to UTF-8 because the size of a character in UTF-8 may be from 1 byte to 6 bytes. Tz-Huan Huang ------=_Part_864_14572580.1188654788867 Content-Type: application/octet-stream; name=msdosfs.diff Content-Transfer-Encoding: base64 X-Attachment-Id: f_f626ch0u Content-Disposition: attachment; filename="msdosfs.diff" ZGlmZiAtdXJOIG1zZG9zZnMub3JpZy9kaXJlbnRyeS5oIG1zZG9zZnMvZGlyZW50cnkuaAotLS0g bXNkb3Nmcy5vcmlnL2RpcmVudHJ5LmgJMjAwNy0wOS0wMSAwNjoyOTo1NS4wMDAwMDAwMDAgKzA4 MDAKKysrIG1zZG9zZnMvZGlyZW50cnkuaAkyMDA3LTA5LTAxIDIxOjE3OjI1LjAwMDAwMDAwMCAr MDgwMApAQCAtMTMzLDI3ICsxMzMsMTggQEAKICNkZWZpbmUgRERfWUVBUl9TSElGVAkJOQogCiAj aWZkZWYgX0tFUk5FTAotc3RydWN0IG1ibmFtYnVmIHsKLQlzaXplX3QJbmJfbGVuOwotCWludAlu Yl9sYXN0X2lkOwotCWNoYXIJbmJfYnVmW1dJTl9NQVhMRU4gKyAxXTsKLX07Ci0KIHN0cnVjdCBk aXJlbnQ7CiBzdHJ1Y3QgbXNkb3Nmc21vdW50OwogCi1jaGFyCSptYm5hbWJ1Zl9mbHVzaChzdHJ1 Y3QgbWJuYW1idWYgKm5icCwgc3RydWN0IGRpcmVudCAqZHApOwotdm9pZAltYm5hbWJ1Zl9pbml0 KHN0cnVjdCBtYm5hbWJ1ZiAqbmJwKTsKLXZvaWQJbWJuYW1idWZfd3JpdGUoc3RydWN0IG1ibmFt YnVmICpuYnAsIGNoYXIgKm5hbWUsIGludCBpZCk7CiBpbnQJZG9zMnVuaXhmbih1X2NoYXIgZG5b MTFdLCB1X2NoYXIgKnVuLCBpbnQgbG93ZXIsCiAJICAgIHN0cnVjdCBtc2Rvc2ZzbW91bnQgKnBt cCk7CiBpbnQJdW5peDJkb3Nmbihjb25zdCB1X2NoYXIgKnVuLCB1X2NoYXIgZG5bMTJdLCBzaXpl X3QgdW5sZW4sIHVfaW50IGdlbiwKIAkgICAgc3RydWN0IG1zZG9zZnNtb3VudCAqcG1wKTsKLWlu dAl1bml4MndpbmZuKGNvbnN0IHVfY2hhciAqdW4sIHNpemVfdCB1bmxlbiwgc3RydWN0IHdpbmVu dHJ5ICp3ZXAsIGludCBjbnQsCi0JICAgIGludCBjaGtzdW0sIHN0cnVjdCBtc2Rvc2ZzbW91bnQg KnBtcCk7Ci1pbnQJd2luQ2hrTmFtZShzdHJ1Y3QgbWJuYW1idWYgKm5icCwgY29uc3QgdV9jaGFy ICp1biwgc2l6ZV90IHVubGVuLAoraW50CXVuaXgyd2luZm4oY29uc3QgdV9jaGFyICp1biwgc2l6 ZV90IHVubGVuLCBzdHJ1Y3Qgd2luZW50cnkgKndlcCwgCisJICAgIGludCBjbnQsIGludCBjaGtz dW0sIHN0cnVjdCBtc2Rvc2ZzbW91bnQgKnBtcCk7CitpbnQJd2luQ2hrTmFtZShjb25zdCB1X2No YXIgKnVuLCBzaXplX3QgdW5sZW4sIHN0cnVjdCBkaXJlbnQgKmRpcmJ1ZnB0ciwKIAkgICAgaW50 IGNoa3N1bSwgc3RydWN0IG1zZG9zZnNtb3VudCAqcG1wKTsKLWludAl3aW4ydW5peGZuKHN0cnVj dCBtYm5hbWJ1ZiAqbmJwLCBzdHJ1Y3Qgd2luZW50cnkgKndlcCwgaW50IGNoa3N1bSwKK2ludAl3 aW4ydW5peGZuKHN0cnVjdCB3aW5lbnRyeSAqd2VwLCBzdHJ1Y3QgZGlyZW50ICpkaXJidWZwdHIs IGludCBjaGtzdW0sIAogCSAgICBzdHJ1Y3QgbXNkb3Nmc21vdW50ICpwbXApOwogdV9pbnQ4X3Qg d2luQ2hrc3VtKHN0cnVjdCBkaXJlbnRyeSAqZGVwKTsKIGludAl3aW5TbG90Q250KGNvbnN0IHVf Y2hhciAqdW4sIHNpemVfdCB1bmxlbiwgc3RydWN0IG1zZG9zZnNtb3VudCAqcG1wKTsKZGlmZiAt dXJOIG1zZG9zZnMub3JpZy9tc2Rvc2ZzX2NvbnYuYyBtc2Rvc2ZzL21zZG9zZnNfY29udi5jCi0t LSBtc2Rvc2ZzLm9yaWcvbXNkb3Nmc19jb252LmMJMjAwNy0wOS0wMSAwNjoyOTo1NS4wMDAwMDAw MDAgKzA4MDAKKysrIG1zZG9zZnMvbXNkb3Nmc19jb252LmMJMjAwNy0wOS0wMSAyMTozNDoxMS4w MDAwMDAwMDAgKzA4MDAKQEAgLTUyLDYgKzUyLDcgQEAKICNpbmNsdWRlIDxzeXMvc3lzdG0uaD4K ICNpbmNsdWRlIDxzeXMvZGlyZW50Lmg+CiAjaW5jbHVkZSA8c3lzL2ljb252Lmg+CisjaW5jbHVk ZSA8c3lzL21hbGxvYy5oPgogI2luY2x1ZGUgPHN5cy9tb3VudC5oPgogCiAjaW5jbHVkZSA8ZnMv bXNkb3Nmcy9icGIuaD4KQEAgLTYxLDEwICs2MiwxNCBAQAogZXh0ZXJuIHN0cnVjdCBpY29udl9m dW5jdGlvbnMgKm1zZG9zZnNfaWNvbnY7CiAKIHN0YXRpYyBpbnQgbWJzYWRqcG9zKGNvbnN0IGNo YXIgKiosIHNpemVfdCwgc2l6ZV90LCBpbnQsIGludCwgdm9pZCAqaGFuZGxlKTsKLXN0YXRpYyB1 X2ludDE2X3QgZG9zMnVuaXhjaHIoY29uc3QgdV9jaGFyICoqLCBzaXplX3QgKiwgaW50LCBzdHJ1 Y3QgbXNkb3Nmc21vdW50ICopOworc3RhdGljIHVfaW50MTZfdCBkb3MydW5peGNocihjb25zdCB1 X2NoYXIgKiosIHNpemVfdCAqLCBpbnQsIAorCSAgICBzdHJ1Y3QgbXNkb3Nmc21vdW50ICopOwog c3RhdGljIHVfaW50MTZfdCB1bml4MmRvc2Nocihjb25zdCB1X2NoYXIgKiosIHNpemVfdCAqLCBz dHJ1Y3QgbXNkb3Nmc21vdW50ICopOwotc3RhdGljIHVfaW50MTZfdCB3aW4ydW5peGNocih1X2lu dDE2X3QsIHN0cnVjdCBtc2Rvc2ZzbW91bnQgKik7Ci1zdGF0aWMgdV9pbnQxNl90IHVuaXgyd2lu Y2hyKGNvbnN0IHVfY2hhciAqKiwgc2l6ZV90ICosIGludCwgc3RydWN0IG1zZG9zZnNtb3VudCAq KTsKK3N0YXRpYyBzaXplX3Qgd2luMnVuaXhjaHIodV9pbnQxNl90IHdjLCBzdHJ1Y3QgZGlyZW50 ICpkaXJidWZwdHIsIAorCSAgICBzdHJ1Y3QgbXNkb3Nmc21vdW50ICpwbXApOworc3RhdGljIHVf aW50MTZfdCB1bml4MndpbmNocihjb25zdCB1X2NoYXIgKiosIHNpemVfdCAqLCBpbnQsCisJICAg IHN0cnVjdCBtc2Rvc2ZzbW91bnQgKik7CitzdGF0aWMgdm9pZCBzdHJyZXZlcnNlKGNoYXIgKiwg c2l6ZV90KTsKIAogLyoKICAqIDAgLSBjaGFyYWN0ZXIgZGlzYWxsb3dlZCBpbiBsb25nIGZpbGUg bmFtZS4KQEAgLTU5NiwzOCArNjAxLDMzIEBACiAgKiBSZXR1cm5zIHRoZSBjaGVja3N1bSBvciAt MSBpZiBubyBtYXRjaAogICovCiBpbnQKLXdpbkNoa05hbWUobmJwLCB1biwgdW5sZW4sIGNoa3N1 bSwgcG1wKQotCXN0cnVjdCBtYm5hbWJ1ZiAqbmJwOword2luQ2hrTmFtZSh1biwgdW5sZW4sIGRp cmJ1ZnB0ciwgY2hrc3VtLCBwbXApCiAJY29uc3QgdV9jaGFyICp1bjsKIAlzaXplX3QgdW5sZW47 CisJc3RydWN0IGRpcmVudCAqZGlyYnVmcHRyOwogCWludCBjaGtzdW07CiAJc3RydWN0IG1zZG9z ZnNtb3VudCAqcG1wOwogewogCXNpemVfdCBsZW47CiAJdV9pbnQxNl90IGMxLCBjMjsKIAl1X2No YXIgKm5wOwotCXN0cnVjdCBkaXJlbnQgZGlyYnVmOwogCi0JLyoKLQkgKiBXZSBhbHJlYWR5IGhh dmUgd2luZW50cnkgaW4gKm5icC4KLQkgKi8KLQlpZiAoIW1ibmFtYnVmX2ZsdXNoKG5icCwgJmRp cmJ1ZikgfHwgZGlyYnVmLmRfbmFtbGVuID09IDApCi0JCXJldHVybiAtMTsKKwlpZiAoZGlyYnVm cHRyLT5kX25hbWxlbiA9PSAwKQorCQlyZXR1cm4gKC0xKTsKIAogI2lmZGVmIE1TRE9TRlNfREVC VUcKLQlwcmludGYoIndpbkNoa05hbWUoKTogdW49JXM6JWQsZF9uYW1lPSVzOiVkXG4iLCB1biwg dW5sZW4sCi0JCQkJCQkJZGlyYnVmLmRfbmFtZSwKLQkJCQkJCQlkaXJidWYuZF9uYW1sZW4pOwor CXByaW50Zigid2luQ2hrTmFtZSgpOiB1bj0lczolZCxkX25hbWU9JXM6JWRcbiIsIHVuLCB1bmxl biwgCisJICAgIGRpcmJ1ZnB0ci0+ZF9uYW1lLCBkaXJidWZwdHItPmRfbmFtbGVuKTsKICNlbmRp ZgogCiAJLyoKIAkgKiBDb21wYXJlIHRoZSBuYW1lIHBhcnRzCiAJICovCi0JbGVuID0gZGlyYnVm LmRfbmFtbGVuOworCWxlbiA9IGRpcmJ1ZnB0ci0+ZF9uYW1sZW47CiAJaWYgKHVubGVuICE9IGxl bikKLQkJcmV0dXJuIC0yOworCQlyZXR1cm4gKC0yKTsKIAotCWZvciAobnAgPSBkaXJidWYuZF9u YW1lOyB1bmxlbiA+IDAgJiYgbGVuID4gMDspIHsKKwlmb3IgKG5wID0gZGlyYnVmcHRyLT5kX25h bWU7IHVubGVuID4gMCAmJiBsZW4gPiAwOykgewogCQkvKgogCQkgKiBDb21wYXJpc29uIG11c3Qg YmUgY2FzZSBpbnNlbnNpdGl2ZSwgYmVjYXVzZSBGQVQgZGlzYWxsb3dzCiAJCSAqIHRvIGxvb2sg dXAgb3IgY3JlYXRlIGZpbGVzIGluIGNhc2Ugc2Vuc2l0aXZlIGV2ZW4gd2hlbgpAQCAtNjM2LDI0 ICs2MzYsMjQgQEAKIAkJYzEgPSB1bml4MndpbmNocigoY29uc3QgdV9jaGFyICoqKSZucCwgJmxl biwgTENBU0VfQkFTRSwgcG1wKTsKIAkJYzIgPSB1bml4MndpbmNocigmdW4sICZ1bmxlbiwgTENB U0VfQkFTRSwgcG1wKTsKIAkJaWYgKGMxICE9IGMyKQotCQkJcmV0dXJuIC0yOworCQkJcmV0dXJu ICgtMik7CiAJfQotCXJldHVybiBjaGtzdW07CisJcmV0dXJuIChjaGtzdW0pOwogfQogCiAvKgot ICogQ29udmVydCBXaW45NSBmaWxlbmFtZSB0byBkaXJidWYuCisgKiBDb252ZXJ0IFdpbjk1IGZp bGVuYW1lIHRvIGRpcmJ1ZnB0ci0+ZF9uYW1lLgogICogUmV0dXJucyB0aGUgY2hlY2tzdW0gb3Ig LTEgaWYgaW1wb3NzaWJsZQogICovCiBpbnQKLXdpbjJ1bml4Zm4obmJwLCB3ZXAsIGNoa3N1bSwg cG1wKQotCXN0cnVjdCBtYm5hbWJ1ZiAqbmJwOword2luMnVuaXhmbih3ZXAsIGRpcmJ1ZnB0ciwg Y2hrc3VtLCBwbXApCiAJc3RydWN0IHdpbmVudHJ5ICp3ZXA7CisJc3RydWN0IGRpcmVudCAqZGly YnVmcHRyOwogCWludCBjaGtzdW07CiAJc3RydWN0IG1zZG9zZnNtb3VudCAqcG1wOwogeworCWNv bnN0IHNpemVfdCBkX25hbWxlbiA9IGRpcmJ1ZnB0ci0+ZF9uYW1sZW47IC8qIHNhdmUgZm9yIHJl dmVyc2UgKi8KIAl1X2ludDhfdCAqY3A7Ci0JdV9pbnQ4X3QgKm5wLCBuYW1lW1dJTl9DSEFSUyAq IDIgKyAxXTsKIAl1X2ludDE2X3QgY29kZTsKIAlpbnQgaTsKIApAQCAtNjc0LDIyICs2NzQsMTkg QEAKIAkvKgogCSAqIENvbnZlcnQgdGhlIG5hbWUgcGFydHMKIAkgKi8KLQlucCA9IG5hbWU7CiAJ Zm9yIChjcCA9IHdlcC0+d2VQYXJ0MSwgaSA9IHNpemVvZih3ZXAtPndlUGFydDEpLzI7IC0taSA+ PSAwOykgewogCQljb2RlID0gKGNwWzFdIDw8IDgpIHwgY3BbMF07CiAJCXN3aXRjaCAoY29kZSkg ewogCQljYXNlIDA6Ci0JCQkqbnAgPSAnXDAnOwotCQkJbWJuYW1idWZfd3JpdGUobmJwLCBuYW1l LCAod2VwLT53ZUNudCAmIFdJTl9DTlQpIC0gMSk7Ci0JCQlyZXR1cm4gY2hrc3VtOworCQkJZGly YnVmcHRyLT5kX25hbWVbZGlyYnVmcHRyLT5kX25hbWxlbl0gPSAnXDAnOworCQkJcmV0dXJuIChj aGtzdW0pOwogCQljYXNlICcvJzoKLQkJCSpucCA9ICdcMCc7Ci0JCQlyZXR1cm4gLTE7CisJCQlk aXJidWZwdHItPmRfbmFtZVtkaXJidWZwdHItPmRfbmFtbGVuXSA9ICdcMCc7CisJCQlyZXR1cm4g KC0xKTsKIAkJZGVmYXVsdDoKLQkJCWNvZGUgPSB3aW4ydW5peGNocihjb2RlLCBwbXApOwotCQkJ aWYgKGNvZGUgJiAweGZmMDApCi0JCQkJKm5wKysgPSBjb2RlID4+IDg7Ci0JCQkqbnArKyA9IGNv ZGU7CisJCQljb2RlID0gd2luMnVuaXhjaHIoY29kZSwgZGlyYnVmcHRyLCBwbXApOworCQkJaWYg KGNvZGUgIT0gMCkKKwkJCQlyZXR1cm4gKC0xKTsKIAkJCWJyZWFrOwogCQl9CiAJCWNwICs9IDI7 CkBAIC02OTgsMTcgKzY5NSwxNSBAQAogCQljb2RlID0gKGNwWzFdIDw8IDgpIHwgY3BbMF07CiAJ CXN3aXRjaCAoY29kZSkgewogCQljYXNlIDA6Ci0JCQkqbnAgPSAnXDAnOwotCQkJbWJuYW1idWZf d3JpdGUobmJwLCBuYW1lLCAod2VwLT53ZUNudCAmIFdJTl9DTlQpIC0gMSk7Ci0JCQlyZXR1cm4g Y2hrc3VtOworCQkJZGlyYnVmcHRyLT5kX25hbWVbZGlyYnVmcHRyLT5kX25hbWxlbl0gPSAnXDAn OworCQkJcmV0dXJuIChjaGtzdW0pOwogCQljYXNlICcvJzoKLQkJCSpucCA9ICdcMCc7Ci0JCQly ZXR1cm4gLTE7CisJCQlkaXJidWZwdHItPmRfbmFtZVtkaXJidWZwdHItPmRfbmFtbGVuXSA9ICdc MCc7CisJCQlyZXR1cm4gKC0xKTsKIAkJZGVmYXVsdDoKLQkJCWNvZGUgPSB3aW4ydW5peGNocihj b2RlLCBwbXApOwotCQkJaWYgKGNvZGUgJiAweGZmMDApCi0JCQkJKm5wKysgPSBjb2RlID4+IDg7 Ci0JCQkqbnArKyA9IGNvZGU7CisJCQljb2RlID0gd2luMnVuaXhjaHIoY29kZSwgZGlyYnVmcHRy LCBwbXApOworCQkJaWYgKGNvZGUgIT0gMCkKKwkJCQlyZXR1cm4gKC0xKTsKIAkJCWJyZWFrOwog CQl9CiAJCWNwICs9IDI7CkBAIC03MTcsMjQgKzcxMiwyOCBAQAogCQljb2RlID0gKGNwWzFdIDw8 IDgpIHwgY3BbMF07CiAJCXN3aXRjaCAoY29kZSkgewogCQljYXNlIDA6Ci0JCQkqbnAgPSAnXDAn OwotCQkJbWJuYW1idWZfd3JpdGUobmJwLCBuYW1lLCAod2VwLT53ZUNudCAmIFdJTl9DTlQpIC0g MSk7Ci0JCQlyZXR1cm4gY2hrc3VtOworCQkJZGlyYnVmcHRyLT5kX25hbWVbZGlyYnVmcHRyLT5k X25hbWxlbl0gPSAnXDAnOworCQkJcmV0dXJuIChjaGtzdW0pOwogCQljYXNlICcvJzoKLQkJCSpu cCA9ICdcMCc7Ci0JCQlyZXR1cm4gLTE7CisJCQlkaXJidWZwdHItPmRfbmFtZVtkaXJidWZwdHIt PmRfbmFtbGVuXSA9ICdcMCc7CisJCQlyZXR1cm4gKC0xKTsKIAkJZGVmYXVsdDoKLQkJCWNvZGUg PSB3aW4ydW5peGNocihjb2RlLCBwbXApOwotCQkJaWYgKGNvZGUgJiAweGZmMDApCi0JCQkJKm5w KysgPSBjb2RlID4+IDg7Ci0JCQkqbnArKyA9IGNvZGU7CisJCQljb2RlID0gd2luMnVuaXhjaHIo Y29kZSwgZGlyYnVmcHRyLCBwbXApOworCQkJaWYgKGNvZGUgIT0gMCkKKwkJCQlyZXR1cm4gKC0x KTsKIAkJCWJyZWFrOwogCQl9CiAJCWNwICs9IDI7CiAJfQotCSpucCA9ICdcMCc7Ci0JbWJuYW1i dWZfd3JpdGUobmJwLCBuYW1lLCAod2VwLT53ZUNudCAmIFdJTl9DTlQpIC0gMSk7Ci0JcmV0dXJu IGNoa3N1bTsKKwlkaXJidWZwdHItPmRfbmFtZVtkaXJidWZwdHItPmRfbmFtbGVuXSA9ICdcMCc7 CisKKwkvKiBzd2FwIHRoZSBkaXJidWZwdHItPmRfbmFtZSAqLworCXN0cnJldmVyc2UoZGlyYnVm cHRyLT5kX25hbWUsIGRpcmJ1ZnB0ci0+ZF9uYW1sZW4pOworCXN0cnJldmVyc2UoZGlyYnVmcHRy LT5kX25hbWUsIGRpcmJ1ZnB0ci0+ZF9uYW1sZW4gLSBkX25hbWxlbik7CisJc3RycmV2ZXJzZShk aXJidWZwdHItPmRfbmFtZSArIGRpcmJ1ZnB0ci0+ZF9uYW1sZW4gLSBkX25hbWxlbiwKKwkgICAg ZF9uYW1sZW4pOworCisJcmV0dXJuIChjaGtzdW0pOwogfQogCiAvKgpAQCAtOTQ5LDEwICs5NDgs MTAgQEAKIC8qCiAgKiBDb252ZXJ0IFdpbmRvd3MgY2hhciB0byBMb2NhbCBjaGFyCiAgKi8KLXN0 YXRpYyB1X2ludDE2X3QKLXdpbjJ1bml4Y2hyKHVfaW50MTZfdCB3Yywgc3RydWN0IG1zZG9zZnNt b3VudCAqcG1wKQorc3RhdGljIHNpemVfdAord2luMnVuaXhjaHIodV9pbnQxNl90IHdjLCBzdHJ1 Y3QgZGlyZW50ICpkaXJidWZwdHIsIHN0cnVjdCBtc2Rvc2ZzbW91bnQgKnBtcCkKIHsKLQl1X2No YXIgKmlucCwgKm91dHAsIGluYnVmWzNdLCBvdXRidWZbM107CisJdV9jaGFyICppbnAsICpvdXRw LCBpbmJ1ZlszXTsKIAlzaXplX3QgaWxlbiwgb2xlbiwgbGVuOwogCiAJaWYgKHdjID09IDApCkBA IC05NjMsMzEgKzk2Miw0NCBAQAogCQlpbmJ1ZlsxXSA9ICh1X2NoYXIpd2M7CiAJCWluYnVmWzJd ID0gJ1wwJzsKIAotCQlpbGVuID0gb2xlbiA9IGxlbiA9IDI7CisJCWlsZW4gPSAyOworCQlvbGVu ID0gbGVuID0gc2l6ZW9mKGRpcmJ1ZnB0ci0+ZF9uYW1lKSAtIGRpcmJ1ZnB0ci0+ZF9uYW1sZW4g LSAxOwogCQlpbnAgPSBpbmJ1ZjsKLQkJb3V0cCA9IG91dGJ1ZjsKKwkJb3V0cCA9IGRpcmJ1ZnB0 ci0+ZF9uYW1lICsgZGlyYnVmcHRyLT5kX25hbWxlbjsKKwogCQltc2Rvc2ZzX2ljb252LT5jb252 Y2hyKHBtcC0+cG1fdzJ1LCAoY29uc3QgY2hhciAqKikmaW5wLCAmaWxlbiwKLQkJCQkgICAgIChj aGFyICoqKSZvdXRwLCAmb2xlbik7Ci0JCWxlbiAtPSBvbGVuOworCQkgICAgKGNoYXIgKiopJm91 dHAsICZvbGVuKTsKIAotCQkvKgotCQkgKiByZXR1cm4gJz8nIGlmIGZhaWxlZCB0byBjb252ZXJ0 Ci0JCSAqLwotCQlpZiAobGVuID09IDApIHsKLQkJCXdjID0gJz8nOwotCQkJcmV0dXJuICh3Yyk7 Ci0JCX0KKwkJZGlyYnVmcHRyLT5kX25hbWxlbiArPSBsZW4gLSBvbGVuOwogCi0JCXdjID0gMDsK LQkJd2hpbGUobGVuLS0pCi0JCQl3YyB8PSAoKihvdXRwIC0gbGVuIC0gMSkgJiAweGZmKSA8PCAo bGVuIDw8IDMpOwotCQlyZXR1cm4gKHdjKTsKKwkJaWYgKGlsZW4gIT0gMCkgeworCQkJaWYgKG9s ZW4gPT0gMCkKKwkJCQlnb3RvIHRvb19sb25nOwkvKiBsb25nZXIgdGhhbiBNQVhOQU1MRU4gKi8K KwkJCWVsc2UKKwkJCQlnb3RvIGZhaWxlZDsJLyogY29udmVydCBmYWlsZWQgKi8KKwkJfSAKKwor CQlnb3RvIG9rOwogCX0KIAotCWlmICh3YyAmIDB4ZmYwMCkKLQkJd2MgPSAnPyc7CisJaWYgKHNp emVvZihkaXJidWZwdHItPmRfbmFtZSkgPD0gZGlyYnVmcHRyLT5kX25hbWxlbiArIDIpCisJCWdv dG8gdG9vX2xvbmc7CS8qIGxvbmdlciB0aGVuIE1BWE5BTUxFTiAqLworCWVsc2UgaWYgKHdjICYg MHhmZjAwKQorCQlnb3RvIGZhaWxlZDsJLyogaWxsZWdhbCBjaGFyYWN0ZXI/ICovCiAKLQlyZXR1 cm4gKHdjKTsKKwlkaXJidWZwdHItPmRfbmFtZVtkaXJidWZwdHItPmRfbmFtbGVuKytdID0gKHVf Y2hhcikod2M+PjgpOworCWRpcmJ1ZnB0ci0+ZF9uYW1lW2RpcmJ1ZnB0ci0+ZF9uYW1sZW4rK10g PSAodV9jaGFyKXdjOworCWdvdG8gb2s7CisKK29rOgorCXJldHVybiAoMCk7CisKK3Rvb19sb25n OgorCXJldHVybiAoMSk7CisKK2ZhaWxlZDoKKwlkaXJidWZwdHItPmRfbmFtZVtkaXJidWZwdHIt PmRfbmFtbGVuKytdID0gJz8nOworCXJldHVybiAoMik7CiB9CiAKIC8qCkBAIC0xMDM0LDczICsx MDQ2LDE3IEBACiB9CiAKIC8qCi0gKiBJbml0aWFsaXplIHRoZSB0ZW1wb3JhcnkgY29uY2F0ZW5h dGlvbiBidWZmZXIuCi0gKi8KLXZvaWQKLW1ibmFtYnVmX2luaXQoc3RydWN0IG1ibmFtYnVmICpu YnApCi17Ci0KLQluYnAtPm5iX2xlbiA9IDA7Ci0JbmJwLT5uYl9sYXN0X2lkID0gLTE7Ci0JbmJw LT5uYl9idWZbc2l6ZW9mKG5icC0+bmJfYnVmKSAtIDFdID0gJ1wwJzsKLX0KLQotLyoKLSAqIEZp bGwgb3V0IG91ciBjb25jYXRlbmF0aW9uIGJ1ZmZlciB3aXRoIHRoZSBnaXZlbiBzdWJzdHJpbmcs IGF0IHRoZSBvZmZzZXQKLSAqIHNwZWNpZmllZCBieSBpdHMgaWQuICBTaW5jZSB0aGlzIGZ1bmN0 aW9uIG11c3QgYmUgY2FsbGVkIHdpdGggaWRzIGluCi0gKiBkZXNjZW5kaW5nIG9yZGVyLCB3ZSB0 YWtlIGFkdmFudGFnZSBvZiB0aGUgZmFjdCB0aGF0IEFTQ0lJIHN1YnN0cmluZ3MgYXJlCi0gKiBl eGFjdGx5IFdJTl9DSEFSUyBpbiBsZW5ndGguICBGb3Igbm9uLUFTQ0lJIHN1YnN0cmluZ3MsIHdl IHNoaWZ0IGFsbAotICogcHJldmlvdXMgKGkuZS4gaGlnaGVyIGlkKSBzdWJzdHJpbmdzIHVwd2Fy ZHMgdG8gbWFrZSByb29tIGZvciB0aGlzIG9uZS4KLSAqIFRoaXMgb25seSBwZW5hbGl6ZXMgcG9y dGlvbnMgb2Ygc3Vic3RyaW5ncyB0aGF0IGNvbnRhaW4gbW9yZSB0aGFuCi0gKiBXSU5fQ0hBUlMg Ynl0ZXMgd2hlbiB0aGV5IGFyZSBmaXJzdCBlbmNvdW50ZXJlZC4KKyAqIFJldmVyc2UgYy1zdHJp bmcgaW4gbGVuZ3RoIG4sIGZvciBleGFtcGxlLCAiMTIzNDUiIC0+ICI1NDMyMSIuCiAgKi8KLXZv aWQKLW1ibmFtYnVmX3dyaXRlKHN0cnVjdCBtYm5hbWJ1ZiAqbmJwLCBjaGFyICpuYW1lLCBpbnQg aWQpCitzdGF0aWMgdm9pZAorc3RycmV2ZXJzZShjaGFyICpzdHIsIHNpemVfdCBuKQogewotCWNo YXIgKnNsb3Q7Ci0Jc2l6ZV90IGNvdW50LCBuZXdsZW47Ci0KLQlLQVNTRVJUKG5icC0+bmJfbGVu ID09IDAgfHwgaWQgPT0gbmJwLT5uYl9sYXN0X2lkIC0gMSwKLQkgICAgKCJub24tZGVjcmVhc2lu ZyBpZDogaWQgJWQsIGxhc3QgaWQgJWQiLCBpZCwgbmJwLT5uYl9sYXN0X2lkKSk7Ci0KLQkvKiBX aWxsIHN0b3JlIHRoaXMgc3Vic3RyaW5nIGluIGEgV0lOX0NIQVJTLWFsaWduZWQgc2xvdC4gKi8K LQlzbG90ID0gJm5icC0+bmJfYnVmW2lkICogV0lOX0NIQVJTXTsKLQljb3VudCA9IHN0cmxlbihu YW1lKTsKLQluZXdsZW4gPSBuYnAtPm5iX2xlbiArIGNvdW50OwotCWlmIChuZXdsZW4gPiBXSU5f TUFYTEVOIHx8IG5ld2xlbiA+IE1BWE5BTUxFTikgewotCQlwcmludGYoIm1zZG9zZnM6IGZpbGUg bmFtZSBsZW5ndGggJXp1IHRvbyBsYXJnZVxuIiwgbmV3bGVuKTsKLQkJcmV0dXJuOwotCX0KLQot CS8qIFNoaWZ0IHN1ZmZpeCB1cHdhcmRzIGJ5IHRoZSBhbW91bnQgbGVuZ3RoIGV4Y2VlZHMgV0lO X0NIQVJTLiAqLwotCWlmIChjb3VudCA+IFdJTl9DSEFSUyAmJiBuYnAtPm5iX2xlbiAhPSAwKQot CQliY29weShzbG90ICsgV0lOX0NIQVJTLCBzbG90ICsgY291bnQsIG5icC0+bmJfbGVuKTsKLQot CS8qIENvcHkgaW4gdGhlIHN1YnN0cmluZyB0byBpdHMgc2xvdCBhbmQgdXBkYXRlIGxlbmd0aCBz byBmYXIuICovCi0JYmNvcHkobmFtZSwgc2xvdCwgY291bnQpOwotCW5icC0+bmJfbGVuID0gbmV3 bGVuOwotCW5icC0+bmJfbGFzdF9pZCA9IGlkOwotfQotCi0vKgotICogVGFrZSB0aGUgY29tcGxl dGVkIHN0cmluZyBhbmQgdXNlIGl0IHRvIHNldHVwIHRoZSBzdHJ1Y3QgZGlyZW50LgotICogQmUg c3VyZSB0byBhbHdheXMgbnVsLXRlcm1pbmF0ZSB0aGUgZF9uYW1lIGFuZCB0aGVuIGNvcHkgdGhl IHN0cmluZwotICogZnJvbSBvdXIgYnVmZmVyLiAgTm90ZSB0aGF0IHRoaXMgZnVuY3Rpb24gYXNz dW1lcyB0aGUgZnVsbCBzdHJpbmcgaGFzCi0gKiBiZWVuIHJlYXNzZW1ibGVkIGluIHRoZSBidWZm ZXIuICBJZiBpdCdzIGNhbGxlZCBiZWZvcmUgYWxsIHN1YnN0cmluZ3MKLSAqIGhhdmUgYmVlbiB3 cml0dGVuIHZpYSBtYm5hbWJ1Zl93cml0ZSgpLCB0aGUgcmVzdWx0IHdpbGwgYmUgaW5jb3JyZWN0 LgotICovCi1jaGFyICoKLW1ibmFtYnVmX2ZsdXNoKHN0cnVjdCBtYm5hbWJ1ZiAqbmJwLCBzdHJ1 Y3QgZGlyZW50ICpkcCkKLXsKLQotCWlmIChuYnAtPm5iX2xlbiA+IHNpemVvZihkcC0+ZF9uYW1l KSAtIDEpIHsKLQkJbWJuYW1idWZfaW5pdChuYnApOwotCQlyZXR1cm4gKE5VTEwpOwotCX0KLQli Y29weSgmbmJwLT5uYl9idWZbMF0sIGRwLT5kX25hbWUsIG5icC0+bmJfbGVuKTsKLQlkcC0+ZF9u YW1lW25icC0+bmJfbGVuXSA9ICdcMCc7Ci0JZHAtPmRfbmFtbGVuID0gbmJwLT5uYl9sZW47CisJ c2l6ZV90IGk7CisJY2hhciBjOwogCi0JbWJuYW1idWZfaW5pdChuYnApOwotCXJldHVybiAoZHAt PmRfbmFtZSk7CisJZm9yIChpID0gMDsgaSA8IG4vMjsgKytpKSB7CisJCWMgPSBzdHJbaV07CisJ CXN0cltpXSA9IHN0cltuIC0gaSAtIDFdOworCQlzdHJbbiAtIGkgLSAxXSA9IGM7CisJfQogfQpk aWZmIC11ck4gbXNkb3Nmcy5vcmlnL21zZG9zZnNfbG9va3VwLmMgbXNkb3Nmcy9tc2Rvc2ZzX2xv b2t1cC5jCi0tLSBtc2Rvc2ZzLm9yaWcvbXNkb3Nmc19sb29rdXAuYwkyMDA3LTA5LTAxIDA2OjI5 OjU1LjAwMDAwMDAwMCArMDgwMAorKysgbXNkb3Nmcy9tc2Rvc2ZzX2xvb2t1cC5jCTIwMDctMDkt MDEgMjE6MzU6MDAuMDAwMDAwMDAwICswODAwCkBAIC01NCw2ICs1NCw3IEBACiAjaW5jbHVkZSA8 c3lzL21vdW50Lmg+CiAjaW5jbHVkZSA8c3lzL25hbWVpLmg+CiAjaW5jbHVkZSA8c3lzL3Zub2Rl Lmg+CisjaW5jbHVkZSA8c3lzL2RpcmVudC5oPgogCiAjaW5jbHVkZSA8ZnMvbXNkb3Nmcy9icGIu aD4KICNpbmNsdWRlIDxmcy9tc2Rvc2ZzL2RpcmVudHJ5Lmg+CkBAIC04NCw3ICs4NSw2IEBACiAJ CXN0cnVjdCBjb21wb25lbnRuYW1lICphX2NucDsKIAl9ICovICphcDsKIHsKLQlzdHJ1Y3QgbWJu YW1idWYgbmI7CiAJc3RydWN0IHZub2RlICp2ZHAgPSBhcC0+YV9kdnA7CiAJc3RydWN0IHZub2Rl ICoqdnBwID0gYXAtPmFfdnBwOwogCXN0cnVjdCBjb21wb25lbnRuYW1lICpjbnAgPSBhcC0+YV9j bnA7CkBAIC0xMDQsNiArMTA0LDcgQEAKIAlzdHJ1Y3QgZGVub2RlICp0ZHA7CiAJc3RydWN0IG1z ZG9zZnNtb3VudCAqcG1wOwogCXN0cnVjdCBidWYgKmJwID0gMDsKKwlzdHJ1Y3QgZGlyZW50IG5h bWVidWY7CiAJc3RydWN0IGRpcmVudHJ5ICpkZXAgPSBOVUxMOwogCXVfY2hhciBkb3NmaWxlbmFt ZVsxMl07CiAJaW50IGZsYWdzID0gY25wLT5jbl9mbGFnczsKQEAgLTE4Niw3ICsxODcsNyBAQAog CSAqIGJ5IGNucC0+Y25fbmFtZXB0ci4KIAkgKi8KIAl0ZHAgPSBOVUxMOwotCW1ibmFtYnVmX2lu aXQoJm5iKTsKKwluYW1lYnVmLmRfbmFtbGVuID0gMDsKIAkvKgogCSAqIFRoZSBvdXRlciBsb29w IHJhbmdlcyBvdmVyIHRoZSBjbHVzdGVycyB0aGF0IG1ha2UgdXAgdGhlCiAJICogZGlyZWN0b3J5 LiAgTm90ZSB0aGF0IHRoZSByb290IGRpcmVjdG9yeSBpcyBkaWZmZXJlbnQgZnJvbSBhbGwKQEAg LTIyNiw3ICsyMjcsNyBAQAogCQkJCSAqIERyb3AgbWVtb3J5IG9mIHByZXZpb3VzIGxvbmcgbWF0 Y2hlcwogCQkJCSAqLwogCQkJCWNoa3N1bSA9IC0xOwotCQkJCW1ibmFtYnVmX2luaXQoJm5iKTsK KwkJCQluYW1lYnVmLmRfbmFtbGVuID0gMDsKIAogCQkJCWlmIChzbG90Y291bnQgPCB3aW5jbnQp IHsKIAkJCQkJc2xvdGNvdW50Kys7CkBAIC0yNTEsMTYgKzI1MiwxNyBAQAogCQkJCQlpZiAocG1w LT5wbV9mbGFncyAmIE1TRE9TRlNNTlRfU0hPUlROQU1FKQogCQkJCQkJY29udGludWU7CiAKLQkJ CQkJY2hrc3VtID0gd2luMnVuaXhmbigmbmIsCi0JCQkJCSAgICAoc3RydWN0IHdpbmVudHJ5ICop ZGVwLCBjaGtzdW0sCi0JCQkJCSAgICBwbXApOworCQkJCQljaGtzdW0gPSB3aW4ydW5peGZuKAor CQkJCQkgICAgKHN0cnVjdCB3aW5lbnRyeSAqKWRlcCwgJm5hbWVidWYsCisJCQkJCSAgICBjaGtz dW0sIHBtcCk7CiAJCQkJCWNvbnRpbnVlOwogCQkJCX0KIAotCQkJCWNoa3N1bSA9IHdpbkNoa05h bWUoJm5iLAorCQkJCWNoa3N1bSA9IHdpbkNoa05hbWUoCiAJCQkJICAgIChjb25zdCB1X2NoYXIg KiljbnAtPmNuX25hbWVwdHIsIHVubGVuLAotCQkJCSAgICBjaGtzdW0sIHBtcCk7CisJCQkJICAg ICZuYW1lYnVmLCBjaGtzdW0sIHBtcCk7CiAJCQkJaWYgKGNoa3N1bSA9PSAtMikgeworCQkJCQlu YW1lYnVmLmRfbmFtbGVuID0gMDsKIAkJCQkJY2hrc3VtID0gLTE7CiAJCQkJCWNvbnRpbnVlOwog CQkJCX0KZGlmZiAtdXJOIG1zZG9zZnMub3JpZy9tc2Rvc2ZzX3Zub3BzLmMgbXNkb3Nmcy9tc2Rv c2ZzX3Zub3BzLmMKLS0tIG1zZG9zZnMub3JpZy9tc2Rvc2ZzX3Zub3BzLmMJMjAwNy0wOS0wMSAw NjoyOTo1NS4wMDAwMDAwMDAgKzA4MDAKKysrIG1zZG9zZnMvbXNkb3Nmc192bm9wcy5jCTIwMDct MDktMDEgMjE6MzA6NDAuMDAwMDAwMDAwICswODAwCkBAIC0xNTEwLDcgKzE1MTAsNiBAQAogCQl1 X2xvbmcgKiphX2Nvb2tpZXM7CiAJfSAqLyAqYXA7CiB7Ci0Jc3RydWN0IG1ibmFtYnVmIG5iOwog CWludCBlcnJvciA9IDA7CiAJaW50IGRpZmY7CiAJbG9uZyBuOwpAQCAtMTU0OSw2ICsxNTQ4LDcg QEAKIAkvKgogCSAqIFRvIGJlIHNhZmUsIGluaXRpYWxpemUgZGlyYnVmCiAJICovCisJZGlyYnVm LmRfbmFtbGVuID0gMDsKIAliemVybyhkaXJidWYuZF9uYW1lLCBzaXplb2YoZGlyYnVmLmRfbmFt ZSkpOwogCiAJLyoKQEAgLTE2MzAsNyArMTYzMCw3IEBACiAJCX0KIAl9CiAKLQltYm5hbWJ1Zl9p bml0KCZuYik7CisJZGlyYnVmLmRfbmFtbGVuID0gMDsKIAlvZmYgPSBvZmZzZXQ7CiAJd2hpbGUg KHVpby0+dWlvX3Jlc2lkID4gMCkgewogCQlsYm4gPSBkZV9jbHVzdGVyKHBtcCwgb2Zmc2V0IC0g Ymlhcyk7CkBAIC0xNjc3LDcgKzE2NzcsNyBAQAogCQkJICovCiAJCQlpZiAoZGVudHAtPmRlTmFt ZVswXSA9PSBTTE9UX0RFTEVURUQpIHsKIAkJCQljaGtzdW0gPSAtMTsKLQkJCQltYm5hbWJ1Zl9p bml0KCZuYik7CisJCQkJZGlyYnVmLmRfbmFtbGVuID0gMDsKIAkJCQljb250aW51ZTsKIAkJCX0K IApAQCAtMTY4Nyw4ICsxNjg3LDggQEAKIAkJCWlmIChkZW50cC0+ZGVBdHRyaWJ1dGVzID09IEFU VFJfV0lOOTUpIHsKIAkJCQlpZiAocG1wLT5wbV9mbGFncyAmIE1TRE9TRlNNTlRfU0hPUlROQU1F KQogCQkJCQljb250aW51ZTsKLQkJCQljaGtzdW0gPSB3aW4ydW5peGZuKCZuYiwKLQkJCQkgICAg KHN0cnVjdCB3aW5lbnRyeSAqKWRlbnRwLCBjaGtzdW0sIHBtcCk7CisJCQkJY2hrc3VtID0gd2lu MnVuaXhmbigoc3RydWN0IHdpbmVudHJ5ICopZGVudHAsCisJCQkJICAgICZkaXJidWYsIGNoa3N1 bSwgcG1wKTsKIAkJCQljb250aW51ZTsKIAkJCX0KIApAQCAtMTY5Nyw3ICsxNjk3LDcgQEAKIAkJ CSAqLwogCQkJaWYgKGRlbnRwLT5kZUF0dHJpYnV0ZXMgJiBBVFRSX1ZPTFVNRSkgewogCQkJCWNo a3N1bSA9IC0xOwotCQkJCW1ibmFtYnVmX2luaXQoJm5iKTsKKwkJCQlkaXJidWYuZF9uYW1sZW4g PSAwOwogCQkJCWNvbnRpbnVlOwogCQkJfQogCQkJLyoKQEAgLTE3MzksOSArMTczOSw4IEBACiAJ CQkJCSgocG1wLT5wbV9mbGFncyAmIE1TRE9TRlNNTlRfU0hPUlROQU1FKSA/CiAJCQkJCShMQ0FT RV9CQVNFIHwgTENBU0VfRVhUKSA6IDApLAogCQkJCSAgICBwbXApOwotCQkJCW1ibmFtYnVmX2lu aXQoJm5iKTsKLQkJCX0gZWxzZQotCQkJCW1ibmFtYnVmX2ZsdXNoKCZuYiwgJmRpcmJ1Zik7CisJ CQl9IAorCiAJCQljaGtzdW0gPSAtMTsKIAkJCWRpcmJ1Zi5kX3JlY2xlbiA9IEdFTkVSSUNfRElS U0laKCZkaXJidWYpOwogCQkJaWYgKHVpby0+dWlvX3Jlc2lkIDwgZGlyYnVmLmRfcmVjbGVuKSB7 CkBAIC0xNzYxLDYgKzE3NjAsNyBAQAogCQkJCX0KIAkJCX0KIAkJCW9mZiA9IG9mZnNldCArIHNp emVvZihzdHJ1Y3QgZGlyZW50cnkpOworCQkJZGlyYnVmLmRfbmFtbGVuID0gMDsKIAkJfQogCQli cmVsc2UoYnApOwogCX0K ------=_Part_864_14572580.1188654788867-- From owner-freebsd-fs@FreeBSD.ORG Sat Sep 1 14:33:17 2007 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A810316A417 for ; Sat, 1 Sep 2007 14:33:17 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4AE13C45B for ; Sat, 1 Sep 2007 14:33:16 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id l81ESSuF048656; Sat, 1 Sep 2007 18:28:28 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Sat, 1 Sep 2007 18:28:28 +0400 (MSD) From: Dmitry Morozovsky To: ticso@cicely.de In-Reply-To: <20070901134809.GF54895@cicely12.cicely.de> Message-ID: <20070901182634.A14738@woozle.rinet.ru> References: <20070901074803.GM85633@comp.chem.msu.su> <3842.1188634387@critter.freebsd.dk> <20070901092310.GO85633@comp.chem.msu.su> <20070901093035.GA18069@harmless.hu> <20070901122913.GE54895@cicely12.cicely.de> <20070901165544.H14738@woozle.rinet.ru> <20070901134809.GF54895@cicely12.cicely.de> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Sat, 01 Sep 2007 18:28:28 +0400 (MSD) Cc: Yar Tikhiy , Poul-Henning Kamp , fs@freebsd.org Subject: Re: New option for newfs(3) to make life with GEOM easier X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 14:33:17 -0000 On Sat, 1 Sep 2007, Bernd Walter wrote: BW> > BW> Sysinstall easily allows you to not partition the last few sectors. BW> > BW> The newfs option is only usefull if you are mirroring at fs level, BW> > BW> which is note quite common for system disks, where you really need BW> > BW> partitions. BW> > BW> > I concur, as all servers (rather entry-level, yeah; and excluding these that BW> > have large storage) we deploy last 2 years have two SATA disks with mirrored BW> > file systems. BW> BW> What is the big win if you mirror all partitions/filesystems and not BW> the whole disk? Time of syncronysation in case of a crash. In our case, usually, large partitions are mostly read and have not to be syncronized. This was originally the recommendation from pjd@ Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------