From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 17:05:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6BE0106566B for ; Sun, 24 Jun 2012 17:05:37 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id E30EA8FC08 for ; Sun, 24 Jun 2012 17:05:36 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5OH5Zaw073166 for ; Sun, 24 Jun 2012 19:05:35 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5OH5ZlX073163 for ; Sun, 24 Jun 2012 19:05:35 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 24 Jun 2012 19:05:35 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org In-Reply-To: Message-ID: References: <20120623162415.303430@gmx.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 24 Jun 2012 19:05:35 +0200 (CEST) Subject: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 17:05:37 -0000 i've got third crash third week in a row. Every time in sunday after 18:00, every time with rsync process (which means rsync based backup that is done every day, not just in sunday!), you may see a crash (viewed from KVM) at http://www.tensor.gdynia.pl/~wojtek/crash.png what is important - syncing disk doesn't go on, system hangs here. For 99% system is not overheating at sunday, but i will be 100% sure as i added ipmitool sensor logged from cron every 5 minutes. Please give me an idea what to check. There is nothing in cron that is done at sunday. i don't run "periodic" stuff in /etc/crontab From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 17:18:03 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AE4C1065678 for ; Sun, 24 Jun 2012 17:18:03 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9CF978FC14 for ; Sun, 24 Jun 2012 17:18:02 +0000 (UTC) Received: by lbon10 with SMTP id n10so6771496lbo.13 for ; Sun, 24 Jun 2012 10:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aeukrvVEd8lQKPmNpozK76lJF2eTLHATnbbLZypzPe4=; b=s9y6kAKZ6GzT/KnVjq8GQ91iZr5Mi8ufZ++BJuyVcamnb8kWhamW/cD9cKyeM8kmub yJMDlXl8QwCqf3oApxhFBGa8wLKZROPbbfabfgqKufOQKcohixFGVideNV4jK+oASnsA JK6y1uG77FgvwW2QhKaOs+EtqekODmbcFbJDb9X9ws1PDW9ZzmRky5Fg6I8ZVxlEE0Tf T2tOnpJhQb7zwF0pX6W70ARFLPk4huL9e2/hFjsRnAp2PW1G1FRYncRp2d1z3zVO3JUv iJ0mINjdq5lmO/KW7kpLe2wMaUVgjLdRshglNAOs1CaiWwwBoln5AJ+K63DPpk6+1l8b CG9A== MIME-Version: 1.0 Received: by 10.152.109.198 with SMTP id hu6mr9088777lab.21.1340558281189; Sun, 24 Jun 2012 10:18:01 -0700 (PDT) Received: by 10.152.24.131 with HTTP; Sun, 24 Jun 2012 10:18:01 -0700 (PDT) In-Reply-To: References: <20120623162415.303430@gmx.com> Date: Sun, 24 Jun 2012 19:18:01 +0200 Message-ID: From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 17:18:03 -0000 On Sun, Jun 24, 2012 at 7:05 PM, Wojciech Puchar wrote: > i've got third crash third week in a row. >From you 5 days ago[1]: "it is unimportant as FreeBSD don't crash." Man, I really don't understand a thing... [1] http://freebsd.1045724.n5.nabble.com/Replacing-rc-8-Was-FreeBSD-Boot-Times-td5718636.html > > Every time in sunday after 18:00, every time with rsync process (which means > rsync based backup that is done every day, not just in sunday!), > > you may see a crash (viewed from KVM) at > > http://www.tensor.gdynia.pl/~wojtek/crash.png > > what is important - syncing disk doesn't go on, system hangs here. > > For 99% system is not overheating at sunday, but i will be 100% sure as i > added ipmitool sensor logged from cron every 5 minutes. > > Please give me an idea what to check. > > > There is nothing in cron that is done at sunday. > > i don't run "periodic" stuff in /etc/crontab > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 17:34:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79FB81065674 for ; Sun, 24 Jun 2012 17:34:19 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id DA4AA8FC15 for ; Sun, 24 Jun 2012 17:34:18 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5OHYMiJ073278; Sun, 24 Jun 2012 19:34:23 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5OHYMIp073275; Sun, 24 Jun 2012 19:34:22 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 24 Jun 2012 19:34:22 +0200 (CEST) From: Wojciech Puchar To: =?ISO-8859-15?Q?Fernando_Apestegu=EDa?= In-Reply-To: Message-ID: References: <20120623162415.303430@gmx.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 24 Jun 2012 19:34:23 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 17:34:19 -0000 > > [1] http://freebsd.1045724.n5.nabble.com/Replacing-rc-8-Was-FreeBSD-Boot-Times-td5718636.html this <2 minute boot time that will follow doesn't matter as it doesn't crash every now and then - it is nothing compared to the fact you have to travel there. >> >> Please give me an idea what to check. >> >> >> There is nothing in cron that is done at sunday. >> >> i don't run "periodic" stuff in /etc/crontab >> any idea to help? From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 18:05:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6EC21106566B for ; Sun, 24 Jun 2012 18:05:38 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id F1F8F8FC0A for ; Sun, 24 Jun 2012 18:05:37 +0000 (UTC) Received: by eabm6 with SMTP id m6so1275361eab.13 for ; Sun, 24 Jun 2012 11:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=9Pd0UkJAesGAgdqXl29aCEG2h/euQV6yt2/moZJ/RD4=; b=BCI14DUn2aXU3Q16yA/T5l7IUk0bKg/wC7dLcxES4gdwDQg2ZsKSUm4sgzYykMCWDD jddBjZ9tKLl0bJU1GUQuMQ/RSaVLdbg3X5PBIEg5MzgfKFXVYAnzO0DIqFju5P9zwASq iHYb5CtamSETsYLB8biGHsns7v+nhAtNp36Mwe8kwTBSFuwe+fqS0pfraXqE4JETLDY3 xU2zSjfTcwJGBP/uiAAdqiCqMBUDR9tQaY1MGT8GUCGLRrkso9hLrxGqGF+ODcvN5aba zQBacfGfnVfLb6cTUkKG3pTGdzHB/WsfvBothWjmmLE2XYvq8JfE4wp5DRvdX8Ozkl7y F5Uw== Received: by 10.14.189.14 with SMTP id b14mr1354037een.141.1340561136878; Sun, 24 Jun 2012 11:05:36 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id h53sm131245567eea.1.2012.06.24.11.05.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jun 2012 11:05:35 -0700 (PDT) Date: Sun, 24 Jun 2012 20:05:27 +0200 From: Mateusz Guzik To: Wojciech Puchar Message-ID: <20120624180526.GA15899@dft-labs.eu> References: <20120623162415.303430@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 18:05:38 -0000 On Sun, Jun 24, 2012 at 07:05:35PM +0200, Wojciech Puchar wrote: > i've got third crash third week in a row. > > Every time in sunday after 18:00, every time with rsync process > (which means rsync based backup that is done every day, not just in > sunday!), > > you may see a crash (viewed from KVM) at > > http://www.tensor.gdynia.pl/~wojtek/crash.png > > what is important - syncing disk doesn't go on, system hangs here. > > For 99% system is not overheating at sunday, but i will be 100% sure > as i added ipmitool sensor logged from cron every 5 minutes. > > Please give me an idea what to check. > > > There is nothing in cron that is done at sunday. > > i don't run "periodic" stuff in /etc/crontab > Compile the kernel with the following: makeoptions DEBUG="-O0 -g" options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options DIAGNOSTIC After kernel panic ddb prompt will be waiting for you. Type in: dump reset Make sure you have swap that can handle crashdumps. See this for more details: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html You can check if everything works correctly by issuing panic manually: sysctl debug.kdb.panic=1 then typing aforementioned ddb commands. After reboot you should get core in /var/crash. Also provide the following: - system version - filesystems involved in rsync with mount details (e.g. UFS with SU+J) - dmesg Hopefully this will be enough for someone to help. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 18:05:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB6C4106578A for ; Sun, 24 Jun 2012 18:05:51 +0000 (UTC) (envelope-from nec556@retena.com) Received: from resmaa13.ono.com (smtp13.ono.com [62.42.230.16]) by mx1.freebsd.org (Postfix) with ESMTP id 798658FC18 for ; Sun, 24 Jun 2012 18:05:51 +0000 (UTC) Received: from GogPortatil.retena.com (37.11.164.89) by resmaa13.ono.com (8.5.113) (authenticated as nec556@retena.com) id 4FA8827200C6C400 for freebsd-hackers@freebsd.org; Sun, 24 Jun 2012 20:05:44 +0200 Message-ID: <4FA8827200C6C400@> (added by postmaster@resmaa13.ono.com) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 24 Jun 2012 20:08:23 +0200 To: freebsd-hackers@freebsd.org From: Eduardo Morras In-Reply-To: References: <20120623162415.303430@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Antivirus: AVG for E-mail 2012.0.2180 [2437/5090] Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 18:05:51 -0000 At 19:05 24/06/2012, Wojciech Puchar wrote: >i've got third crash third week in a row. > >Every time in sunday after 18:00, every time with rsync process >(which means rsync based backup that is done every day, not just in sunday!), Is it the same rsync everyday, including sundays, or the sunday rsync is different? Perhaps you have some part of the filesystem corrupted or hd damaged zone and the sundays rsync is the only one that backups/touchs that part. From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 18:25:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 771D91065676 for ; Sun, 24 Jun 2012 18:25:21 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2598FC0C for ; Sun, 24 Jun 2012 18:25:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=kYn/qx2VkWsF8YDzyOVEP4nh9Z2wxzAHkyb4dqP1wlU=; b=ShvZ4PJcpoRt55KtE9SMFGqmZUHPLzrwd396qkqCbogFMDVXwvF6Zdi6FG195tGuScD1zmToU84L6gIWBDM2j+J3Eul2Emr3bhxIfX4yVjRWXuXS5NqBfNr+Zd0/nPrz; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SirUu-0006e8-Fa for freebsd-hackers@freebsd.org; Sun, 24 Jun 2012 13:25:20 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1340562314-94480-94479/5/51; Sun, 24 Jun 2012 18:25:14 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org References: <20120623162415.303430@gmx.com> Date: Sun, 24 Jun 2012 13:25:13 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: User-Agent: Opera Mail/12.00 (FreeBSD) X-SA-Score: -1.5 Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 18:25:21 -0000 Have you proven beyond reasonable doubt that there is no filesystem corruption or silent filesystem corruption due to bad hardware? From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 18:33:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55A0D106567B for ; Sun, 24 Jun 2012 18:33:02 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id D307D8FC0C for ; Sun, 24 Jun 2012 18:33:01 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q5OIWxjh050140 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 24 Jun 2012 19:32:59 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FE75D10.3050507@unsane.co.uk> Date: Sun, 24 Jun 2012 19:31:44 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Wojciech Puchar References: <20120623162415.303430@gmx.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 18:33:02 -0000 On 24/06/2012 18:05, Wojciech Puchar wrote: > i've got third crash third week in a row. > > Every time in sunday after 18:00, every time with rsync process (which > means rsync based backup that is done every day, not just in sunday!), > > you may see a crash (viewed from KVM) at > > http://www.tensor.gdynia.pl/~wojtek/crash.png > > what is important - syncing disk doesn't go on, system hangs here. > > For 99% system is not overheating at sunday, but i will be 100% sure > as i added ipmitool sensor logged from cron every 5 minutes. > > Please give me an idea what to check. >From the FAQ http://www.freebsd.org/doc/en/books/faq/troubleshoot.html#TRAP-12-PANIC and http://www.freebsd.org/doc/en/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING Hope that helps. Vince > > > There is nothing in cron that is done at sunday. > > i don't run "periodic" stuff in /etc/crontab > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 18:50:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E21B81065677 for ; Sun, 24 Jun 2012 18:50:38 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1318FC19 for ; Sun, 24 Jun 2012 18:50:37 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5OIogqo073683; Sun, 24 Jun 2012 20:50:42 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5OIofJ6073680; Sun, 24 Jun 2012 20:50:42 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 24 Jun 2012 20:50:41 +0200 (CEST) From: Wojciech Puchar To: Mateusz Guzik In-Reply-To: <20120624180526.GA15899@dft-labs.eu> Message-ID: References: <20120623162415.303430@gmx.com> <20120624180526.GA15899@dft-labs.eu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 24 Jun 2012 20:50:42 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 18:50:39 -0000 >> >> >> There is nothing in cron that is done at sunday. >> >> i don't run "periodic" stuff in /etc/crontab >> > > Compile the kernel with the following: > > makeoptions DEBUG="-O0 -g" > > options KDB # Enable kernel debugger support. > options DDB # Support DDB. > options GDB # Support remote GDB. > options DEADLKRES # Enable the deadlock resolver > options INVARIANTS # Enable calls of extra sanity checking > options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS > options WITNESS # Enable checks to detect deadlocks and cycles > options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed > options DIAGNOSTIC > > After kernel panic ddb prompt will be waiting for you. Type in: > dump > reset > > Make sure you have swap that can handle crashdumps. already did this part and debug part, but not DDB. As you see - hang not crashdump how much would it slow down whole thing? If less than 2 times it can be - CPU are rerely half loaded From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 18:51:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AB2F106566B for ; Sun, 24 Jun 2012 18:51:12 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 83E718FC12 for ; Sun, 24 Jun 2012 18:51:11 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5OIpFdd073689; Sun, 24 Jun 2012 20:51:15 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5OIpFGU073686; Sun, 24 Jun 2012 20:51:15 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 24 Jun 2012 20:51:15 +0200 (CEST) From: Wojciech Puchar To: Eduardo Morras In-Reply-To: <4FA8827200C6C400@> (added by postmaster@resmaa13.ono.com) Message-ID: References: <20120623162415.303430@gmx.com> <4FA8827200C6C400@> (added by postmaster@resmaa13.ono.com) User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 24 Jun 2012 20:51:15 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 18:51:12 -0000 >> i've got third crash third week in a row. >> >> Every time in sunday after 18:00, every time with rsync process (which >> means rsync based backup that is done every day, not just in sunday!), > > Is it the same rsync everyday, including sundays, or the sunday rsync is > different? the funny part is that it is exactly the same. > Perhaps you have some part of the filesystem corrupted or hd > damaged zone and the sundays rsync is the only one that backups/touchs that > part. full fsck_ffs was done week ago From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 18:57:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D4A4106564A for ; Sun, 24 Jun 2012 18:57:28 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id A08F98FC0A for ; Sun, 24 Jun 2012 18:57:27 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5OIvQaO073719; Sun, 24 Jun 2012 20:57:26 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5OIvQrs073716; Sun, 24 Jun 2012 20:57:26 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 24 Jun 2012 20:57:26 +0200 (CEST) From: Wojciech Puchar To: Mark Felder In-Reply-To: Message-ID: References: <20120623162415.303430@gmx.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 24 Jun 2012 20:57:26 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 18:57:28 -0000 > Have you proven beyond reasonable doubt that there is no filesystem > corruption or silent filesystem corruption due to bad hardware? after last crash fsck_ffs found nothing suggesting such a case. Actually the only change i made to this system (running flawless close to two years) is upgrading to latest 8.* from sources less than month ago. but still - even assuming that system update introduced a bug - i cannot understand why it happens at sunday when it is least loaded. Only rarely visited WWW that time, few mails, and no load present as in work days. since last crash i inserted pendrive and set it as dump device (FreeBSD doesn't seem to reliably crashdump to gmirrored+geli devices, i don't have others available). but as you see it halted, no crash dump From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 19:09:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D336E1065673 for ; Sun, 24 Jun 2012 19:09:09 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 60EC28FC12 for ; Sun, 24 Jun 2012 19:09:09 +0000 (UTC) Received: by eeke49 with SMTP id e49so1293001eek.13 for ; Sun, 24 Jun 2012 12:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=nmF2sJxS12GWcr2LCiq1dKbveNXgW88giOCY621gilo=; b=VyEPOnALgOjoj2/3Xcs9fGj0/uiICeWdFOQz/Jl5IZY7VGhDlfcLXbkI3PNBfdWHeS 3X70NXlkNK+OB5qrw/VmMZ3OQAiiVXYhmyj6mCSzpPpDlNO9HwpHdJaSpDsOd67ms2Ha hmcEIteRFqWlNk5wfFQHWNIZwzf5aXVj4Vk4rUPLUH355TOgVYzFyeyVtK0lcrCeBJjk Zo40Ld/0x9wUjn5CwJyA3V8h4PX6R7OFzbHzuqZ7mxvW6lP+9uA4S8dPxlW0lfZ7NWqd Xr5h9F9wci1Zm7ChVZUVnL/xnCYVlmCZ+fKiXiPLZXwVBTnzSmSHQoJMpqPZkOu9bQrO Fj6A== Received: by 10.14.28.202 with SMTP id g50mr1824065eea.167.1340564948366; Sun, 24 Jun 2012 12:09:08 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id u16sm131590636eeb.16.2012.06.24.12.09.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jun 2012 12:09:07 -0700 (PDT) Date: Sun, 24 Jun 2012 21:08:53 +0200 From: Mateusz Guzik To: Wojciech Puchar Message-ID: <20120624190853.GB15899@dft-labs.eu> References: <20120623162415.303430@gmx.com> <20120624180526.GA15899@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 19:09:09 -0000 On Sun, Jun 24, 2012 at 08:50:41PM +0200, Wojciech Puchar wrote: > >> > >> > >>There is nothing in cron that is done at sunday. > >> > >>i don't run "periodic" stuff in /etc/crontab > >> > > > >Compile the kernel with the following: > > > >makeoptions DEBUG="-O0 -g" > > > >options KDB # Enable kernel debugger support. > >options DDB # Support DDB. > >options GDB # Support remote GDB. > >options DEADLKRES # Enable the deadlock resolver > >options INVARIANTS # Enable calls of extra sanity checking > >options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS > >options WITNESS # Enable checks to detect deadlocks and cycles > >options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed > >options DIAGNOSTIC > > > >After kernel panic ddb prompt will be waiting for you. Type in: > >dump > >reset > > > >Make sure you have swap that can handle crashdumps. > > already did this part and debug part, but not DDB. As you see - hang > not crashdump > > how much would it slow down whole thing? > > If less than 2 times it can be - CPU are rerely half loaded Are you asking about overhead of DDB or all debug options? I don't think that DDB support can be accounted for slowdown. As for the rest, it's hard to say. I guess it depends on your workload, also I never performed any benchmarks to compare this and I'm unaware of any. In other words, you have to test it yourself. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 24 19:30:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7AEE1065675 for ; Sun, 24 Jun 2012 19:30:57 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 2E46E8FC0C for ; Sun, 24 Jun 2012 19:30:56 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5OJV1JY073864; Sun, 24 Jun 2012 21:31:01 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5OJV0Xr073861; Sun, 24 Jun 2012 21:31:00 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 24 Jun 2012 21:31:00 +0200 (CEST) From: Wojciech Puchar To: Mateusz Guzik In-Reply-To: <20120624190853.GB15899@dft-labs.eu> Message-ID: References: <20120623162415.303430@gmx.com> <20120624180526.GA15899@dft-labs.eu> <20120624190853.GB15899@dft-labs.eu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 24 Jun 2012 21:31:01 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 19:30:58 -0000 > > Are you asking about overhead of DDB or all debug options? all. invariants, witness etc. > > I don't think that DDB support can be accounted for slowdown. > > As for the rest, it's hard to say. I guess it depends on your workload, > also I never performed any benchmarks to compare this and I'm unaware of > any. > > In other words, you have to test it yourself. we will see. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 25 09:21:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 792B31065688 for ; Mon, 25 Jun 2012 09:21:55 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id D536E8FC08 for ; Mon, 25 Jun 2012 09:21:54 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5P9LpEw078026 for ; Mon, 25 Jun 2012 11:21:51 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5P9LpRJ078023 for ; Mon, 25 Jun 2012 11:21:51 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 25 Jun 2012 11:21:51 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org In-Reply-To: <20120624190853.GB15899@dft-labs.eu> Message-ID: References: <20120623162415.303430@gmx.com> <20120624180526.GA15899@dft-labs.eu> <20120624190853.GB15899@dft-labs.eu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 25 Jun 2012 11:21:51 +0200 (CEST) Subject: Re: reason for "magic" crashes. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 09:21:55 -0000 thanks first for all suggestions. Now the (not really)funny part begins. After turning on all this checks in kernel the system crashes repeatable even before ending fully bootstrap sequence. Before this i've got tons of warning about lock order reversal. On seems strange as it is lock order reversal: 1st 0xffffff80f5c4ba80 bufwait (bufwait) @ kern/vfs_bio.c:2636 2nd 0xffffff0005cb0600 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x80a _sx_xlock() at _sx_xlock+0x5d ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_remove() at ufsdirhash_remove+0x16 ufs_dirremove() at ufs_dirremove+0x181 ufs_remove() at ufs_remove+0x85 VOP_REMOVE_APV() at VOP_REMOVE_APV+0x93 kern_unlinkat() at kern_unlinkat+0x211 amd64_syscall() at amd64_syscall+0x2e0 Xfast_syscall() at Xfast_syscall+0xfc --- syscall (10, FreeBSD ELF64, unlink), rip = 0xeede070c, rsp = 0x7fffffffdb08, rbp = 0x7fffffffef58 --- every now and then when files are deleted. The rest seems to be a problem with not really good and it sync 3-rd party kernel addons. After fixing that part i would post again. Still - what may be a cause of this messages? From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 25 14:03:00 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E57EF106564A for ; Mon, 25 Jun 2012 14:03:00 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 72AA18FC0C for ; Mon, 25 Jun 2012 14:03:00 +0000 (UTC) Received: by bkvi18 with SMTP id i18so3991809bkv.13 for ; Mon, 25 Jun 2012 07:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:in-reply-to:references:x-mailer; bh=pYz0kG9NxHICYj3z0yVT64lpHHINSAiHIL4C1SiLfDU=; b=GSocF+xg9kHxcDfMNS3ssoRApE7Lbkq2/x2mBesSwHCklwe0k013JbzP+EC1x1Owgl GLCYMX29IJ1gO7aWQzMKnv18OT4gUnDcmziG11vSUHQlGyYzvacafxi8UQ1F+blMl1N6 7atI1JBTTs/EAUy/VlsHN+Iva9gDKdKN4SFiOMyoJJajnSKRWOwXtVeef5sllqRzwJMx uctlBu0bY0kfpJJTNDI8jWBF6BwSFXd+nuazsI1hzTKVhTUt4C0urUL6uwgMQV4mFv8U hv3nS25dhhtqUaUdAVo4OJEea0TJyIYYSo8xGtNoI9m0a17wJ8DL+Z3aVc/e5GuDd91v iuog== Received: by 10.204.154.142 with SMTP id o14mr3839297bkw.116.1340632979449; Mon, 25 Jun 2012 07:02:59 -0700 (PDT) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id u8sm46719872bks.0.2012.06.25.07.02.33 (version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 07:02:57 -0700 (PDT) Message-ID: <20120625.140256.620.1@DOMY-PC> From: rank1seeker@gmail.com To: "Johan van Selst" , hackers@freebsd.org Date: Mon, 25 Jun 2012 16:02:56 +0200 In-Reply-To: <20120623171407.GA32232@mud.stack.nl> References: <20120622.192538.734.2@DOMY-PC> <20120623171407.GA32232@mud.stack.nl> X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: Re: tcsh's exit codes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 14:03:01 -0000 ----- Original Message ----- From: Johan van Selst To: rank1seeker@gmail.com Cc: hackers@freebsd.org Date: Sat, 23 Jun 2012 19:14:07 +0200 Subject: Re: tcsh's exit codes > rank1seeker@gmail.com wrote: > > There is something wrong with tcsh shell: > > > > # mergemaster -V | grep '\--run-updates' > > Returned exit code 1 > > # mergemaster -V | grep -q '\--run-updates' > > Returned exit code 141 > > I believe this has been a feature of csh and tcsh since the dark ages. > Negative status codes propagate through pipelines (and through backtick > sub-commands as well). In fact the returned $status value is the value > of the last command that returned an error (non-zero) status code. > This makes it easy to determine if a pipeline command sequence has > failed. > > The 141 status code indicates a sigpipe: the pipeline was not completely > read (as described in the grep manual for this case). This also is the > common exit code when using head(1) for example. > > This error-propagation behaviour can be suppessed with 'unset anyerror' > in tcsh. In that case it should work as you expect. But note that your > commands are no longer compatible with 'good old' csh behaviour then. > > > Regards, > Johan Thanks for clarification J. D. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 25 14:38:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EAAE106566C for ; Mon, 25 Jun 2012 14:38:09 +0000 (UTC) (envelope-from atte.peltomaki@iki.fi) Received: from kameli.org (kameli.org [83.150.86.93]) by mx1.freebsd.org (Postfix) with ESMTP id 2514D8FC22 for ; Mon, 25 Jun 2012 14:38:09 +0000 (UTC) Received: by kameli.org (Postfix, from userid 1001) id B9DE611F81E; Mon, 25 Jun 2012 17:38:01 +0300 (EEST) Date: Mon, 25 Jun 2012 17:38:01 +0300 From: Atte =?iso-8859-1?Q?Peltom=E4ki?= To: Wojciech Puchar Message-ID: <20120625143801.GN96212@ass.kameli.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: MAGIC with HP KVM - someone will help? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 14:38:09 -0000 On Wed, Jun 20, 2012 at 08:14:09AM +0200, Wojciech Puchar wrote: > I bought used IP 16 port KVM connected to few servers, in between them > FreeBSD 8 server running on Dell PowerEdge T110. > > As this KVM have PS/2 connectors to keyboard and mouse i added USB to > dual-PS/2 converter. This is ancient history now, but I used HP KVM switches 6-12 years ago and they weren't without problems. Regardless of OS and hardware behind the switches, they often acted up. Some combinations were more prone to problems, but since switching back and forth between targets would solve the problem over 99% of the time, I never put any further effort into it. If it's any consolation, I've used other brand KVM switches as well and the only one I've found quite reliable were Raritan and those cost an arm and a leg. -- Atte Peltomäki atte.peltomaki@iki.fi <> http://kameli.org "Your effort to remain what you are is what limits you" From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 25 15:34:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA8E710656B8 for ; Mon, 25 Jun 2012 15:34:50 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id A13118FC15 for ; Mon, 25 Jun 2012 15:34:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Content-Transfer-Encoding:Mime-Version:Date:References:Subject:To:Content-Type; bh=tLkLHQ2pVQn9P/gGbkiz2LSNQB1gtmNXzwouiQ8zyVA=; b=WnqsI1njglFIffe9CxZO8V1O5fcUK1Nt4eEDaPYSlboyeGoi+SY9mDQVVEJ1MkWUPmNuCDV3e99hF2uAcANS/vQuO/MWzpoOt07lJzabxxmUA+z7N3dqE4kHExAJMR3h; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjBJR-000Js0-De for freebsd-hackers@freebsd.org; Mon, 25 Jun 2012 10:34:50 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1340638483-94480-94479/5/54; Mon, 25 Jun 2012 15:34:43 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org References: <20120625143801.GN96212@ass.kameli.org> Date: Mon, 25 Jun 2012 10:34:43 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Mark Felder Message-Id: In-Reply-To: <20120625143801.GN96212@ass.kameli.org> User-Agent: Opera Mail/12.00 (FreeBSD) X-SA-Score: -0.6 Subject: Re: MAGIC with HP KVM - someone will help? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 15:34:52 -0000 On Mon, 25 Jun 2012 09:38:01 -0500, Atte Peltom=C3=A4ki =20 wrote: > If it's any consolation, I've used other brand KVM switches as well and > the only one I've found quite reliable were Raritan and those cost an > arm and a leg. raritan userstation $65.00 http://www.ebay.com/itm/Raritan-Paragon-II-P2-UST-IP-CAT5-KVM-Keyboard-Vi= deo-Mouse-User-Station-/150743344570?pt=3DUS_KVM_Switches_KVM_Cables&hash= =3Ditem231900e5ba 10 dongles $50.00 http://www.ebay.com/itm/LOT-of-10-NEW-Raritan-Paragon-II-KVM-CIM-P2CIM-PS= 2-Computer-Interface-Module-/221042459695?pt=3DCOMP_EN_Hubs&hash=3Ditem33= 7728442f We use these at work, as well as the daisy-chain versions of this line = and =20 they work quite well. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 25 16:58:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 645D1106564A for ; Mon, 25 Jun 2012 16:58:00 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id C718B8FC0A for ; Mon, 25 Jun 2012 16:57:59 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5PGw2u0081335; Mon, 25 Jun 2012 18:58:02 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5PGw2vo081332; Mon, 25 Jun 2012 18:58:02 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 25 Jun 2012 18:58:02 +0200 (CEST) From: Wojciech Puchar To: =?ISO-8859-15?Q?Atte_Peltom=E4ki?= In-Reply-To: <20120625143801.GN96212@ass.kameli.org> Message-ID: References: <20120625143801.GN96212@ass.kameli.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 25 Jun 2012 18:58:02 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: MAGIC with HP KVM - someone will help? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 16:58:00 -0000 > This is ancient history now, but I used HP KVM switches 6-12 years ago > and they weren't without problems. Regardless of OS and hardware behind > the switches, they often acted up. Some combinations were more prone to today i did a bit of work being locally connected with monitor to KVM and it stopped work too with system running multiuser. removing USB-PS/2 converted and putting it back "solved" it. > problems, but since switching back and forth between targets would solve > the problem over 99% of the time, I never put any further effort into > it. > you mean different brands or pieces? From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 25 21:56:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBCBB1065672 for ; Mon, 25 Jun 2012 21:56:02 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 42DCF8FC0A for ; Mon, 25 Jun 2012 21:56:02 +0000 (UTC) Received: by lbon10 with SMTP id n10so8687572lbo.13 for ; Mon, 25 Jun 2012 14:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=j6gJJDi5BMtt4sSImghL8DedMDRIKHi6J63zaiHPBeE=; b=cLzQjiCY7qEjl0m7WGSYDd2ku6djV2ha+JdGmvimOkscZ6i5Dn2Jyf97UFeVaw9KXq pDTVgaxyA6fsN1c3u18kSc1XUBrBIebvV9sA08ikEAawRDBCWxzC2e3NXLryJmLsFiF0 KjQuMeU3dngDW3zqe6xLO/B07AjRiiqm9Pa1zGT+fXuKVqi+agRD0qiY0pF061PzoEut 8qSXuhPnEgYiPz5TJmdJIZkr+j/m0eD11Aq3CVI9/9jrkwxU9nvabLcpBNVxbPuM2ZQg z/JlizExoaPzfu5Rh4wzpRv3af41N9ZuK24mYhAhSn+ve2A8XB3m6CBH3wobSyi+BwFV u/TQ== MIME-Version: 1.0 Received: by 10.152.144.99 with SMTP id sl3mr13584113lab.44.1340661361174; Mon, 25 Jun 2012 14:56:01 -0700 (PDT) Received: by 10.112.115.6 with HTTP; Mon, 25 Jun 2012 14:56:01 -0700 (PDT) Date: Tue, 26 Jun 2012 03:26:01 +0530 Message-ID: From: Shrikanth Kamath To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: DTrace 32 bit on 64 bit machine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 21:56:02 -0000 Can the DTrace user space application compiled as 32 bit app be run on machine with x86_64 kernel I have this DTrace port done for code base based on FreeBSD 6.1, and the app is crashing on the amd64 machine with assert Assertion failed: (fsz > 0), function _libelf_getphdr, file ../../../../src/bsd/lib/libelf/libelf_phdr.c, lie 83. I do not have the user space DTrace enabled. Pretty much stuff picked up from FreeBSD 8.1 Looking at libdtrace code, there is this section in function "dt_module_update", #if defined(__i386__) /* * Find the first load section and figure out the relocation * offset for the symbols. The kernel module will not need * relocation, but the kernel linker modules will. */ for (i = 0; gelf_getphdr(dmp->dm_elf, i, &ph) != NULL; i++) { But the actual failure is because of faulty elf header... #2 0xc822bb02 in abort () from /usr/lib/libc.so.6 #3 0xc8205aea in __assert from /usr/lib/libc.so.6 #4 0xc812fbb4 in _libelf_getphdr (e=0xffefc4c4, ec=2) at libelf_phdr.c:83 <<== The same is not getting passed down, 'e' is now different and gibberish. #5 0xc812c3ac in gelf_getphdr (e=0x805df80, index=0, ...) at libelf/gelf_phdr.c:87 <<== The struct _Elf 'e' is sane #6 0xc80ea26c in dt_module_update at dt_module.c:934 But the elf header read from the kernel module is sane. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 00:03:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6536A106566C; Tue, 26 Jun 2012 00:03:59 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBFE8FC15; Tue, 26 Jun 2012 00:03:55 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so1348554wib.13 for ; Mon, 25 Jun 2012 17:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=nsPADtjgVm4Fw31DHzhjPLpVSGWGUh6cMauzgwvGaak=; b=ZDOnXtVUzBKOtkSR/+2250cXvpR/TdL6OtZ3G0XoJc+9Y56g5mcI5sQbZbM+3gVxgu Nlz24O9zx8GL7Qy7pZggXlBz5vK+StgRg9f5xyGdGlpboA8Zw/Rm7Y687J5OR0FBVgRK 31O/NVVtq/f8ivhOwvon5+Zis6M2yCvSS8NUuFPg2kDm9aAvvVlJbyhCD9WY7VSxaBdb l5hpPmC2pa2e9nc7dtH6agxXpXYFn/gQsexiWQ4hdd7aTSgh2d2jMaKJ4HdGzl6sIaS+ KSGV5wteWgpS7x6CuJpUFpcDz3OX0z00O29zAmdvv009E7jVJRX3fynSTfmBGB4h6zAx PtTA== MIME-Version: 1.0 Received: by 10.216.196.166 with SMTP id r38mr6526517wen.161.1340669034277; Mon, 25 Jun 2012 17:03:54 -0700 (PDT) Received: by 10.216.214.101 with HTTP; Mon, 25 Jun 2012 17:03:54 -0700 (PDT) Date: Mon, 25 Jun 2012 20:03:54 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Cc: bp@FreeBSD.org, kby@FreeBSD.org Subject: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 00:03:59 -0000 Hi folks, I find myself in a situation where I need to directly explore the sysctl(8) tree from my program. The tricky part is this: from `src/sbin/sysctl.c': /* * These functions uses a presently undocumented interface to the kernel * to walk the tree and get the type so it can print the value. * This interface is under work and consideration, and should probably * be killed with a big axe by the first person who can find the time. * (be aware though, that the proper interface isn't as obvious as it * may seem, there are various conflicting requirements. */ AFAIT, the whole interface used by sysctl(8) to explore the sysctl tree (ie. list, name, get description) is undocumented. This comment has been there for about, well... 17 years. No matter to say that it is highly unlikely anyone is ever gonna design that perfect interface. Right now, I am left with no choice but to figure out how that stuff work, which I foresee will be a real PITA. No choice ? Well, not so much. About 12 years ago a filesystem interface was written for sysctl, namely scfs(4). It was authored by Kelly Yancey and (?) Boris Popov. Unfortunately, time passed and no code is any longer publicly available. URLs are either no longer valid or password-protected. This interface would just be perfect for my use-case. No need to spend time decoding a prehistoric interface, no need to craft custom accessors. I would just have to use standard POSIX file interface... if the code was available. I was hoping some of the people on this list would either, have the scfs(4) code on their drives/tapes, or have a way to contact the original author(s) and thus have a chance to get that code ? Thanks in advance, - Arnaud ps: I know the code will certainly have to be fixed, but that is still the best option I've got so far. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 00:10:28 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 984CA1065674 for ; Tue, 26 Jun 2012 00:10:28 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) by mx1.freebsd.org (Postfix) with ESMTP id 6263F8FC1B for ; Tue, 26 Jun 2012 00:10:28 +0000 (UTC) X-Envelope-To: Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id q5PNuQWq019198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jun 2012 16:56:28 -0700 (PDT) Message-ID: <4FE8FAAA.80106@jetcafe.org> Date: Mon, 25 Jun 2012 16:56:26 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120612 Thunderbird/13.0 MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: libgeom documentation? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 00:10:28 -0000 Libgeom has these functions geom_gettree() and geom_getxml but there is no documentation in the man page. Was this intentional? Is there a place these functions are documented other than their source code? :) Thanks in advance. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< Nasrudin loaded his donkey with wood for the fire and instead of sitting in its saddle, sat astride one of the logs. "Why don't you sit in the saddle?" someone asked. "What? And add my weight to what the poor animal has to carry? My weight is on the _wood_ and it is going to stay there." From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 00:13:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4E7F106566C; Tue, 26 Jun 2012 00:13:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 211B58FC2B; Tue, 26 Jun 2012 00:13:24 +0000 (UTC) Received: by obbun3 with SMTP id un3so9218258obb.13 for ; Mon, 25 Jun 2012 17:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HC4/mWNQSj8y7inIacE/Rtv6FSU3ix2/YnsbqqO5w4c=; b=e79oAgb3yXNLvwLvgrLvCfTTJE/qqv94Ji+ImorM+JLlY31t46mh7Q6g+PNsuWEzdD aeqJUFg8zdf+UqsYcl7dhqcpurhtXeiYMA+QFCTbrsWDk+TW3nJyPQOUI+QmnpHxdd47 RJcCJcC8lTG1vSSi4ZowzmaJ7SWcQu9W1XNiXxWS9KfCWWCXcUVTNaaeNRfUZ5KRfvfN uRJ9SOcoxtBe36qBa9fuESInq/OHb5zUX+tt8z/dOyheTT1EFLxm93kTpIh9IEdHKvAo v5e/sQ2VF5Uv8/BhHjTdJBEIYcOIamHlJZ/GjjtO+ofGGJaEVbXKElvWEEMyDwGbMJln BiUQ== MIME-Version: 1.0 Received: by 10.60.20.136 with SMTP id n8mr3891674oee.54.1340669603645; Mon, 25 Jun 2012 17:13:23 -0700 (PDT) Received: by 10.76.95.194 with HTTP; Mon, 25 Jun 2012 17:13:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 17:13:23 -0700 Message-ID: From: Garrett Cooper To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 00:13:27 -0000 On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe wrote: > Hi folks, > > I find myself in a situation where I need to directly explore the > sysctl(8) tree from my program. The tricky part is this: > > from `src/sbin/sysctl.c': > /* > =A0* These functions uses a presently undocumented interface to the kerne= l > =A0* to walk the tree and get the type so it can print the value. > =A0* This interface is under work and consideration, and should probably > =A0* be killed with a big axe by the first person who can find the time. > =A0* (be aware though, that the proper interface isn't as obvious as it > =A0* may seem, there are various conflicting requirements. > =A0*/ > > AFAIT, the whole interface used by sysctl(8) to explore the sysctl > tree (ie. list, name, get description) is undocumented. This comment > has been there for about, well... 17 years. No matter to say that it > is highly unlikely anyone is ever gonna design that perfect interface. > Right now, I am left with no choice but to figure out how that stuff > work, which I foresee will be a real PITA. No choice ? Well, not so > much. About 12 years ago a filesystem interface was written for > sysctl, namely scfs(4). It was authored by Kelly Yancey and (?) Boris > Popov. Unfortunately, time passed and no code is any longer publicly > available. URLs are either no longer valid or password-protected. > > This interface would just be perfect for my use-case. No need to spend > time decoding a prehistoric interface, no need to craft custom > accessors. I would just have to use standard POSIX file interface... > if the code was available. > > I was hoping some of the people on this list would either, have the > scfs(4) code on their drives/tapes, or have a way to contact the > original author(s) and thus have a chance to get that code ? > > Thanks in advance, > =A0- Arnaud > > ps: I know the code will certainly have to be fixed, but that is still > the best option I've got so far. Alternatively, the interface could just be documented (from sys/kern/kern_sysctl.c): /* * "Staff-functions" * * These functions implement a presently undocumented interface * used by the sysctl program to walk the tree, and get the type * so it can print the value. * This interface is under work and consideration, and should probably * be killed with a big axe by the first person who can find the time. * (be aware though, that the proper interface isn't as obvious as it * may seem, there are various conflicting requirements. * * {0,0} printf the entire MIB-tree. * {0,1,...} return the name of the "..." OID. * {0,2,...} return the next OID. * {0,3} return the OID of the name in "new" * {0,4,...} return the kind & format info for the "..." OID. * {0,5,...} return the description the "..." OID. */ I know 2 closed-source versions that have wholesale stolen/"borrowed" the code from sysctl(3), and I adapted the sysctl(8) code for my own uses for the cython derivative I made here [1]. Thanks, -Garrett 1. http://sourceforge.net/projects/sysctl/ From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 00:21:12 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACE9B106566B for ; Tue, 26 Jun 2012 00:21:12 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 759D68FC14 for ; Tue, 26 Jun 2012 00:21:12 +0000 (UTC) Received: by obbun3 with SMTP id un3so9228143obb.13 for ; Mon, 25 Jun 2012 17:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1dT4fiW6iKvxFmFkBW5Jsyi+8amylDuJG/t/PN6tZJI=; b=NCZHLOhDrqjEC+A7D8aDkqc5iJ8i8ExtVu26FVsOEKhxzVRPguyCclubtGQArBhNTu xAMEo1W5crs+px7LaSbDBOAhEmVpf6So6fxPHyuQpNzWUitagxLqviBOFBTqGcHBH/z+ ZpXLEynWdMozVEKdbSIjMWcUQenEmUSMh8N3fyrQYWUP2b4roLRYCMLeqgBfzmTuTnBi 2G55AtERyoXAPYSnafZsU6miQf7/sEWj8KvkJsuFxMIzdXXAGRIS/+CnR8RMXIvB1Sjm 3umch9QjzgNhQ/PCf+iFRtb1ZyzBM148q4ibAh403yuQUqAeCzkB5wI21Zkk6OXjGHTb /0TA== MIME-Version: 1.0 Received: by 10.182.112.102 with SMTP id ip6mr14230795obb.39.1340670072016; Mon, 25 Jun 2012 17:21:12 -0700 (PDT) Received: by 10.76.95.194 with HTTP; Mon, 25 Jun 2012 17:21:11 -0700 (PDT) In-Reply-To: <4FE8FAAA.80106@jetcafe.org> References: <4FE8FAAA.80106@jetcafe.org> Date: Mon, 25 Jun 2012 17:21:11 -0700 Message-ID: From: Garrett Cooper To: Dave Hayes Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: Re: libgeom documentation? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 00:21:12 -0000 On Mon, Jun 25, 2012 at 4:56 PM, Dave Hayes wrote: > Libgeom has these functions geom_gettree() and geom_getxml but there is no > documentation in the man page. Was this intentional? Is there a place these > functions are documented other than their source code? :) I can't really say 100%, but I found some documentation about it here: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/geom-class/article.html . It was probably discussed in a previous BSDCan as well. You can access this via sysctl -b kern.geom.confxml, but the problem that I see based on the above article is that the printout content and format is GEOM-class topology dependent. Cheers, -Garrett PS freebsd-geom might be a better list.. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 00:30:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24CF0106564A; Tue, 26 Jun 2012 00:30:40 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 20F058FC17; Tue, 26 Jun 2012 00:30:38 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so4456920wgb.31 for ; Mon, 25 Jun 2012 17:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CMjyb/C03tq4mutcOl7Z1kNGauwMRIJH2XKOKgdAEyw=; b=eYg72kLMxxNz22BVwOGKt3lVaNM585rSks1ApNRbc6TK/j4FBkSlWDR1yOkaqHBfCu OG7kSctGiL69WkEq2lyc0mq9M2Q7fpoAiebxNCcESETxeFshVDsO00sgurwVBkLlhoEq 6+j2BAA2SvgpAugPffmAZaz9oj5Di89mqrrayawigLqnJ6MUuALNwQWs5z5LdWTYSfa6 oxSceVM2i3eLqEvGVq1RncucyadNFeufd6DCh6lSSRi4LogfbtPgy7Itrd+PxkTaPQjM KIeDID0jRdZtwBMLKPoN0T5fh0FjkZk97uO3R9M8ZCfVOL8TVa0NH81hYBrIWW6LVSXs JQ/Q== MIME-Version: 1.0 Received: by 10.180.102.228 with SMTP id fr4mr28245560wib.6.1340670638150; Mon, 25 Jun 2012 17:30:38 -0700 (PDT) Received: by 10.223.88.155 with HTTP; Mon, 25 Jun 2012 17:30:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 19:30:37 -0500 Message-ID: From: Adam Vande More To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers , FreeBSD Current , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 00:30:40 -0000 On Mon, Jun 25, 2012 at 7:03 PM, Arnaud Lacombe wrote: > Hi folks, > > I find myself in a situation where I need to directly explore the > sysctl(8) tree from my program. The tricky part is this: > There is this: http://svnweb.freebsd.org/base/releng/4.7/sys/miscfs/kernfs/ -- Adam Vande More From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 00:56:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3E4A1065675; Tue, 26 Jun 2012 00:56:04 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id E41AF8FC1A; Tue, 26 Jun 2012 00:56:03 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so1370161wib.13 for ; Mon, 25 Jun 2012 17:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QgeuBGUjLNwUDnuLxZBzvHrr4KThw7B1+6YkTULL5TY=; b=JwR8HOXZ58ng96LqGYQSJc6fJyngqGIMcEg/b/dbBYw5C/R63yFj7kQ3KP3f4cGVT8 BR5sTsvTSzz5aEi3C1fnOxqSnr/CvWDo/V8MtA3aDo/f7+Eevb8DH3nCUPJT9BgaKK0R QUi9AoTtQTTMd3ffUR35fGKnC/Ik0WE0OPU31aPKLoYORsrf6KgHnwcfrAlWOSDLZu+N HHGply7vjlM0nzbtfvAC1/ADEKtRetDxKQIk34gOxQe9VxFjNd6AfwPr0ey3HYiCLUI1 0Cn8tofNuPnEg3NhROyEfo1/CBNyXL9OgJQuahXNklzY8kZbNToYtcPBpV6/KZNne9hV iMKQ== MIME-Version: 1.0 Received: by 10.180.14.165 with SMTP id q5mr28307170wic.8.1340672163041; Mon, 25 Jun 2012 17:56:03 -0700 (PDT) Received: by 10.216.214.101 with HTTP; Mon, 25 Jun 2012 17:56:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 20:56:02 -0400 Message-ID: From: Arnaud Lacombe To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 00:56:04 -0000 Hi, On Mon, Jun 25, 2012 at 8:30 PM, Adam Vande More wrote: > On Mon, Jun 25, 2012 at 7:03 PM, Arnaud Lacombe wrote: >> >> Hi folks, >> >> I find myself in a situation where I need to directly explore the >> sysctl(8) tree from my program. The tricky part is this: > > There is this: > > http://svnweb.freebsd.org/base/releng/4.7/sys/miscfs/kernfs/ > yes, `kernfs' is mentioned in some of the thread about a sysctl filesystem as a potential code base, and has been used in such purpose. However, if I can avoid to re-design that wheel too, by getting access to scfs(4) code, I will. - Arnaud > -- > Adam Vande More From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 01:24:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8631106564A; Tue, 26 Jun 2012 01:24:28 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E4A6A8FC1A; Tue, 26 Jun 2012 01:24:27 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so4481954wgb.31 for ; Mon, 25 Jun 2012 18:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RjX88LddFI9Y7cutb20kzrPYlzQ+zN19w6SaQdgeSao=; b=W0eIewdw4kIpZ2SQRLjvaRykIXPseKuw5GmZr7+KcDIwgOFyeCrnnbfRMql95B0TE5 M2A7XWRqU80uxVQwCCSpN3N4+IwqLpDwTFMn7A7bdjAOCyokqa7ml2za9LevNMSd7PSI NsmJqmYxSgJ6POsCGHyN0RH9Sjktqv6pAeT5YPGlJGWtFgRTPYeHnfFiBoOT3sF+4TVg yFffme1yTFFUR4gbHMEcTudibgoVFYIdf7Tr4zGJQwdsljs64JkzMddDm5yv/J4uDyl4 4cvIl11/yClvcXDa4926QMHPq1Q/eaE/i7UWxvNbM3AvfsLJBwy8+kBzbCb0KPk8hakX hdeA== MIME-Version: 1.0 Received: by 10.216.196.166 with SMTP id r38mr6612952wen.161.1340673866890; Mon, 25 Jun 2012 18:24:26 -0700 (PDT) Received: by 10.216.214.101 with HTTP; Mon, 25 Jun 2012 18:24:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 21:24:26 -0400 Message-ID: From: Arnaud Lacombe To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 01:24:29 -0000 On Mon, Jun 25, 2012 at 8:13 PM, Garrett Cooper wrote: > On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe wrot= e: >> Hi folks, >> >> I find myself in a situation where I need to directly explore the >> sysctl(8) tree from my program. The tricky part is this: >> >> from `src/sbin/sysctl.c': >> /* >> =A0* These functions uses a presently undocumented interface to the kern= el >> =A0* to walk the tree and get the type so it can print the value. >> =A0* This interface is under work and consideration, and should probably >> =A0* be killed with a big axe by the first person who can find the time. >> =A0* (be aware though, that the proper interface isn't as obvious as it >> =A0* may seem, there are various conflicting requirements. >> =A0*/ >> >> AFAIT, the whole interface used by sysctl(8) to explore the sysctl >> tree (ie. list, name, get description) is undocumented. This comment >> has been there for about, well... 17 years. No matter to say that it >> is highly unlikely anyone is ever gonna design that perfect interface. >> Right now, I am left with no choice but to figure out how that stuff >> work, which I foresee will be a real PITA. No choice ? Well, not so >> much. About 12 years ago a filesystem interface was written for >> sysctl, namely scfs(4). It was authored by Kelly Yancey and (?) Boris >> Popov. Unfortunately, time passed and no code is any longer publicly >> available. URLs are either no longer valid or password-protected. >> >> This interface would just be perfect for my use-case. No need to spend >> time decoding a prehistoric interface, no need to craft custom >> accessors. I would just have to use standard POSIX file interface... >> if the code was available. >> >> I was hoping some of the people on this list would either, have the >> scfs(4) code on their drives/tapes, or have a way to contact the >> original author(s) and thus have a chance to get that code ? >> >> Thanks in advance, >> =A0- Arnaud >> >> ps: I know the code will certainly have to be fixed, but that is still >> the best option I've got so far. > > Alternatively, the interface could just be documented (from > sys/kern/kern_sysctl.c): > > /* > =A0* "Staff-functions" > =A0* > =A0* These functions implement a presently undocumented interface > =A0* used by the sysctl program to walk the tree, and get the type > =A0* so it can print the value. > =A0* This interface is under work and consideration, and should probably > =A0* be killed with a big axe by the first person who can find the time. > =A0* (be aware though, that the proper interface isn't as obvious as it > =A0* may seem, there are various conflicting requirements. > =A0* > =A0* {0,0} =A0 =A0 =A0 =A0printf the entire MIB-tree. > =A0* {0,1,...} =A0 =A0return the name of the "..." OID. > =A0* {0,2,...} =A0 =A0return the next OID. > =A0* {0,3} =A0 =A0 =A0 =A0return the OID of the name in "new" > =A0* {0,4,...} =A0 =A0return the kind & format info for the "..." OID. > =A0* {0,5,...} =A0 =A0return the description the "..." OID. > =A0*/ > > I know 2 closed-source versions that have wholesale stolen/"borrowed" > the code from sysctl(3), and I adapted the sysctl(8) code for my own > uses for the cython derivative I made here [1]. > I guess I will have no choice but to write a third... - Arnaud > Thanks, > -Garrett > > 1. http://sourceforge.net/projects/sysctl/ From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 02:51:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DE41106564A; Tue, 26 Jun 2012 02:51:47 +0000 (UTC) (envelope-from borisxm@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 8357B8FC08; Tue, 26 Jun 2012 02:51:46 +0000 (UTC) Received: by wibhq12 with SMTP id hq12so3251665wib.1 for ; Mon, 25 Jun 2012 19:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ui0u/AJxljlEVS4UCoooaFtYHuPeFV8mFyS1CgUKVc8=; b=x+Q5gH1pxZ+bF09RO5d9KPe6kFM8dHVywLquAxpksrUJ2Fn9euqKoaaOXyQmXcvpt4 H1W//a5Us+Wz4AfdeeI3+FuKLHGxW1AjTJCfnPy3xq31tyOOeRb0cv1oKhEL4+hY2orC ZNXpL96JEuyD87QWD1Z4yd6sTGXmrmYcQyepDR9JGTm2U79gS1CQtKWKt+YAQZwp0BCc WiL01HTnLti6waNzkvHgvPARTwfA0efq/sBzOsw/B+ymeCegnrnP4J5D6gMUHf4tCl1W EkAP1bBWCtVNYvE+2e8w3MjN/ng1ru/Li1xu9GIZyhxr2hRLcnaPwNitpyKUNzlxZZqs AQGg== Received: by 10.181.13.142 with SMTP id ey14mr190070wid.19.1340679099296; Mon, 25 Jun 2012 19:51:39 -0700 (PDT) Received: from 10.0.22.54 ([178.88.204.75]) by mx.google.com with ESMTPS id bc2sm2997284wib.0.2012.06.25.19.51.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 19:51:38 -0700 (PDT) Sender: Boris Popov Message-ID: <4FE923B6.7080108@freebsd.org> Date: Tue, 26 Jun 2012 08:51:34 +0600 From: Boris Popov User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adam Vande More , FreeBSD Current , kby@freebsd.org, FreeBSD Hackers Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 02:51:47 -0000 On 26.06.2012 6:56, Arnaud Lacombe wrote: > purpose. However, if I can avoid to re-design that wheel too, by > getting access to scfs(4) code, I will. It is interesting, that the old drive with this code are still alive. Most likely, FS related part will need serious attention because of numerous changes in the VFS subsystem. Here is the link: http://www.vertex.kz/scfs.tgz -- Boris Popov From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 05:11:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EACF6106566C; Tue, 26 Jun 2012 05:11:48 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E30EE8FC08; Tue, 26 Jun 2012 05:11:47 +0000 (UTC) Received: by werg1 with SMTP id g1so4270213wer.13 for ; Mon, 25 Jun 2012 22:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HXIyXNxPWehNMnPpuWvOA+P6WbB/R6z1LTVaUAOyses=; b=txUD/Xah7y9BUCrNzafG/BKknqYFpmkv/miXATshXGmy4HL8Z7dUCrVU7hyqNCfZyf lizFGC4KIxFMEttbh+dhM+v8FXR2qHdGGsC3zO973YILjG+ICrqAwTL0Y5yVn4nD6Cgx tVOYR5WmDJ8jwk/ObInrjL8QK/MVILJdv1+8ExYxPKmegkh6rKFZKlYOMC5ZPswjuTXd 1pfEmVE3pH5dyVy9bxPDvH+Litwx7aMrYhOxoPEKpskKxr8qFmQmLHz1pqnYUUplU6fv t2dkCzn+Nq9+971NWdj02OqWHY7+4mwszcL1cixrrI4nxm9eqQFtLpU1i9KdZ/6gw3MI yynQ== MIME-Version: 1.0 Received: by 10.180.82.198 with SMTP id k6mr29874530wiy.20.1340687506780; Mon, 25 Jun 2012 22:11:46 -0700 (PDT) Received: by 10.216.214.101 with HTTP; Mon, 25 Jun 2012 22:11:46 -0700 (PDT) In-Reply-To: <4FE923B6.7080108@freebsd.org> References: <4FE923B6.7080108@freebsd.org> Date: Tue, 26 Jun 2012 01:11:46 -0400 Message-ID: From: Arnaud Lacombe To: Boris Popov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adam Vande More , FreeBSD Current , kby@freebsd.org, FreeBSD Hackers Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 05:11:49 -0000 Hi, On Mon, Jun 25, 2012 at 10:51 PM, Boris Popov wrote: > On 26.06.2012 6:56, Arnaud Lacombe wrote: >> purpose. However, if I can avoid to re-design that wheel too, by >> getting access to scfs(4) code, I will. > > =A0It is interesting, that the old drive with this code are still alive. > Most likely, FS related part will need serious attention because of > numerous changes in the VFS subsystem. Here is the link: > > http://www.vertex.kz/scfs.tgz > Outstanding ! I was pointed another implementation by Jakub Dawidek made in 2002, which seems more advanced. In any case, lots of KPI changed... I guess I found a new toy for this week :-) Thanks a lot, - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 06:07:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76CDB106566B; Tue, 26 Jun 2012 06:07:02 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id D44318FC0A; Tue, 26 Jun 2012 06:07:01 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5Q66wwQ003577; Tue, 26 Jun 2012 08:06:58 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5Q66wn3003574; Tue, 26 Jun 2012 08:06:58 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 26 Jun 2012 08:06:58 +0200 (CEST) From: Wojciech Puchar To: Arnaud Lacombe In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 26 Jun 2012 08:06:59 +0200 (CEST) Cc: FreeBSD Hackers , FreeBSD Current , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 06:07:02 -0000 as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn't. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 06:35:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 816081065674; Tue, 26 Jun 2012 06:35:17 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 756328FC08; Tue, 26 Jun 2012 06:35:16 +0000 (UTC) Received: by bkvi18 with SMTP id i18so4792664bkv.13 for ; Mon, 25 Jun 2012 23:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oas635gVhoVXywuZLkMWFDkCnlQ2BBE3NK5YRVsj5ZA=; b=T9V+a+arihBNJjbeasRIF14vFul68nomSqMR/8HNGsDAWZRNdhk4HDSImi0tE0Gu5a CX+sk1byx6vGN+Z+7zpNYyBxjmE2DpUWzZ4V/rJQNf3wrV/Ew1es4l8jRbbT6Te36esV 6No92uU2FdvKSr0EB8UdywcIG1jFJ19vxohIMHSRR54bjAV0WKu9IumUtQv2GJxuG+py iq4A3bUkdCuqDnhZvdvIuGrTmWbxCC2RpoAxW8oUur7IBhj+luyJthKN4ulfXaFpy4V3 wWbRIa04kf+yP7q2MsrNltSrrdPWfYtawnKNzigEkbfX09gvVBYWYrTweNGuOMGLSFop rZ2w== MIME-Version: 1.0 Received: by 10.204.156.155 with SMTP id x27mr4915393bkw.84.1340692515295; Mon, 25 Jun 2012 23:35:15 -0700 (PDT) Received: by 10.204.49.87 with HTTP; Mon, 25 Jun 2012 23:35:15 -0700 (PDT) Received: by 10.204.49.87 with HTTP; Mon, 25 Jun 2012 23:35:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 07:35:15 +0100 Message-ID: From: Chris Rees To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, FreeBSD Current , Arnaud Lacombe , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 06:35:17 -0000 On Jun 26, 2012 7:07 AM, "Wojciech Puchar" wrote: > > as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl > > improvements are welcome, better documentation is welcome, changes to what is OK - isn't. /proc/sysctl might be useful. Just because Linux uses it doesn't make it a bad idea. Chris From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 08:50:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC5CF106564A; Tue, 26 Jun 2012 08:50:33 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 43D728FC15; Tue, 26 Jun 2012 08:50:32 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5Q8oSts001834; Tue, 26 Jun 2012 10:50:28 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5Q8oRYx001831; Tue, 26 Jun 2012 10:50:27 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 26 Jun 2012 10:50:27 +0200 (CEST) From: Wojciech Puchar To: Chris Rees In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2456600518-377125759-1340700627=:1828" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 26 Jun 2012 10:50:28 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, FreeBSD Current , Arnaud Lacombe , kby@freebsd.org, bp@freebsd.org Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 08:50:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2456600518-377125759-1340700627=:1828 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT > > > > as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl > > > > improvements are welcome, better documentation is welcome, changes to what is OK - isn't. > > /proc/sysctl might be useful.  Just because Linux uses it doesn't make it a bad idea. actually - i don't know since over 5 years what linux do. --2456600518-377125759-1340700627=:1828-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 08:59:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2219106566C; Tue, 26 Jun 2012 08:59:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 885928FC15; Tue, 26 Jun 2012 08:59:28 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 653D246B09; Tue, 26 Jun 2012 04:59:27 -0400 (EDT) Date: Tue, 26 Jun 2012 09:59:27 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Chris Rees In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bp@freebsd.org, Arnaud Lacombe , freebsd-hackers@freebsd.org, FreeBSD Current , kby@freebsd.org, Wojciech Puchar Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 08:59:28 -0000 On Tue, 26 Jun 2012, Chris Rees wrote: >> as well as we don't depend of /proc for normal operation we shouldn't for > say /proc/sysctl >> >> improvements are welcome, better documentation is welcome, changes to > what is OK - isn't. > > /proc/sysctl might be useful. Just because Linux uses it doesn't make it a > bad idea. One of the problems we've encounted with synthetic file systems is that off-the-shelf file system tools (e.g., cp, dd, cat) make simplistic (but not unreasonable) assumptions about the statistic content of files. This comes up frequently with procfs-like systems where the size of, say, memory map data can be considerably larger than the perhaps 128-byte, 256-byte, or even 8k buffers that might exist in a stock file access tool. Unless we change all of those tools to use buffers much bigger than they currently do, which even suggets changing the C library buffer to defaults for FILE *, that places an onus on the file system to provide persisting snapshots of data until it's sure that a user process is done -- e.g., over many system calls. sysctl is not immune to the requirement of atomicity, but it has explicit control over it: sysctl is a single system call, rather than an unbounded open-read-seek-repeat-etc cycle, and has been carefully crafted to provide this and other MIB-like properties, such as a basic data type model so that command line tools know how to render content rather than having to guess and/or get it wrong. sysctl has some file-system like properties, but on the whole, it's not a file system -- it's much more like an SNMP MIB. While you can map anything into anything (including Turing machines), I think the sysctl command line tool and API, despite its limitations, is a better match for accessing this sort of monitoring and control data than the POSIX file API, and would recommend against trying to move to a sysctl file system. Robert From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 12:39:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C3C11065670; Tue, 26 Jun 2012 12:39:29 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id C35388FC18; Tue, 26 Jun 2012 12:39:28 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5QCdIbG001420; Tue, 26 Jun 2012 14:39:18 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5QCdI2d001417; Tue, 26 Jun 2012 14:39:18 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 26 Jun 2012 14:39:17 +0200 (CEST) From: Wojciech Puchar To: Robert Watson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 26 Jun 2012 14:39:18 +0200 (CEST) Cc: bp@freebsd.org, Arnaud Lacombe , freebsd-hackers@freebsd.org, FreeBSD Current , kby@freebsd.org, Chris Rees Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 12:39:29 -0000 > and/or get it wrong. sysctl has some file-system like properties, but on the > whole, it's not a file system -- it's much more like an SNMP MIB. > > While you can map anything into anything (including Turing machines), I think > the sysctl command line tool and API, despite its limitations, is a better me too. i REALLY appreciate the way FreeBSD do this. pseudo-filesystems are sometimes good but making them default method is bad. Current way is simple. Or actually - less complicated as i think for example - XML in system output is not. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 12:50:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E57291065673; Tue, 26 Jun 2012 12:50:53 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [IPv6:2a02:6b8:0:602::1]) by mx1.freebsd.org (Postfix) with ESMTP id B18658FC19; Tue, 26 Jun 2012 12:50:49 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward1.mail.yandex.net (Yandex) with ESMTP id EDABC124170D; Tue, 26 Jun 2012 16:50:47 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340715048; bh=GXt6cLLBcdsmnDtZzOzY0JG7K7AXBOo3qkBQU4UkcX8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type; b=RG8re+gV2O8Jx3iXAbs4BzMQK46lzG9HMVJA6nwAW+OCiY7PlTY1IoM9yeVQkN9Rj Qyzw6hZ24hlgB0hdlyyvGzuUN+jNxKzL5SpWX9mwaxingF743j9tw39LPHgvSrlHeO qIOX8Gf3js/SYE+IXGmdR0yx7cs8/7p+qD7dWS1c= Received: from smtp1.mail.yandex.net (localhost [127.0.0.1]) by smtp1.mail.yandex.net (Yandex) with ESMTP id 701C1AA0553; Tue, 26 Jun 2012 16:50:47 +0400 (MSK) Received: from ns.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by smtp1.mail.yandex.net (nwsmtp/Yandex) with ESMTP id okAWnV8t-okAKNANs; Tue, 26 Jun 2012 16:50:47 +0400 X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: avg@FreeBSD.org X-Yandex-Rcpt-Suid: pjd@FreeBSD.org X-Yandex-Rcpt-Suid: steven.hartland@FreeBSD.org X-Yandex-Rcpt-Suid: olgeni@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340715047; bh=GXt6cLLBcdsmnDtZzOzY0JG7K7AXBOo3qkBQU4UkcX8=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: X-Enigmail-Version:Content-Type; b=ZHrcm1h7xF3ZdCs4k+Gj5xmTzBYcPALbz02XjFUF/Xfy+iHMw+6GjHmB5N25ue7s2 yCeJXBUpVGrPKC7iZk0+AgjxD5lLB1dxFwR7K2qU+52126/F+sjfX+0Aef/jEBRDLw 7451LxxoQxnHX17qyIUvvsQ0+e/LH+NxB1lnC6xE= Message-ID: <4FE9B01C.30306@yandex.ru> Date: Tue, 26 Jun 2012 16:50:36 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: freebsd-current , freebsd-hackers X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3DF35FE7979D7795EBCBB2D2" Cc: Doug Rabson , Pawel Jakub Dawidek , Andriy Gapon Subject: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 12:50:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3DF35FE7979D7795EBCBB2D2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Hi All, Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff What i already did: 1. The partition tables handling now is machine independent, and it is compatible with the kernel's GEOM_PART implementation. There is new API for disk drivers in the loader to get information about partitions and tables: common/Makefile.inc common/part.c common/part.h 2. The similar and general code from the disk drivers merged in the disk.c: common/disk.c common/disk.h i386/libi386/libi386.h i386/libi386/biosdisk.c userboot/test/test.c userboot/userboot/userboot_disk.c userboot/userboot.h 3. ZFS code now uses new API and probing on the systems with many disks should be greatly increased: zfs/zfs.c i386/loader/main.c 4. The gptboot now searches the backup GPT header in the previous sectors= , when it finds the "GEOM::" signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s 5. Also the pmbr image now contains one fake partition record. When several first sectors are damaged the kernel can't detect GPT (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) command, but the old pmbr image has an empty partition table and loader doesn't able to boot from GPT, when there is no partition record in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootc= ode' command, the kernel correctly modifies this partition record. So, this is= only for the first rescue step. 6. I have changed userboot interface. I guess there is none consumers exc= ept the one test program. But if it isn't that, i can make it compatible. Any comments are welcome. --=20 WBR, Andrey V. Elsukov --------------enig3DF35FE7979D7795EBCBB2D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJP6bAlAAoJEAHF6gQQyKF6yvwH/1+awIGkwRcAA/sKs1NGoEt7 85mZZ2t8KUKUy0Yjxe4p8doCVHQoeppBjEUChTW1yWncLWstOuoO/JQ8nUi8mlH5 WetoHH4dtShSuuaXB+N2dMv6g3ETyo0/uIMqX18V4FniLUXBwFjP2UnMc6JMJDkZ L7cUgTnvbeGU08GU9L6jDwA6xN/nwMSYN0U9fbGYbNhabtIL3JNb1MMsUAAwdijB a4EPPD3k4ZTOW/DBI+NQeYjpi3q0bEO1lmvEB/rSOq3ivMLxZHtV+Z9MMpEiPWTI q4eayZFalrT70RVjG/0Vxy3w0ISQcE5yfWMA0U2GLLt8k9kqPtePV8CH7pQXaHo= =1xLc -----END PGP SIGNATURE----- --------------enig3DF35FE7979D7795EBCBB2D2-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 12:59:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F7A91065670; Tue, 26 Jun 2012 12:59:48 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id B82F38FC15; Tue, 26 Jun 2012 12:59:47 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id EBB45997; Tue, 26 Jun 2012 14:59:39 +0200 (CEST) Date: Tue, 26 Jun 2012 14:57:37 +0200 From: Pawel Jakub Dawidek To: "Andrey V. Elsukov" Message-ID: <20120626125737.GA1372@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <4FE9B01C.30306@yandex.ru> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , Doug Rabson , freebsd-current , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 12:59:48 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote: > Hi All, >=20 > Some time ago i have started reading the code in the sys/boot. > Especially i'm interested in the partition tables handling. > I found several problems: > 1. There are several copies of the same code in the libi386/biosdisk.c > and common/disk.c, and partially libpc98/biosdisk.c. > 2. ZFS probing is very slow, because the ZFS code doesn't know how many > disks and partitions the system has: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148296 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161897 > 3. The GPT support doesn't check CRC and even doesn't know anything > about the secondary GPT header/table. Just a quick note here. At some point when I was adding GPT attributes to allow for test starts I greatly improved, at least parts of, the GPT implementation. I did implement support for both CRC checksum verification and fallback to backup GPT header when primary is broken. And the code is still in sys/boot/common/gpt.c. So my question would be what do you mean by this sentence? > So, i have created the branch and committed the changes: > http://svnweb.freebsd.org/base/user/ae/bootcode/ > The patch is here: > http://people.freebsd.org/~ae/boot.diff >=20 > What i already did: > 1. The partition tables handling now is machine independent, > and it is compatible with the kernel's GEOM_PART implementation. > There is new API for disk drivers in the loader to get information > about partitions and tables: > common/Makefile.inc > common/part.c > common/part.h >=20 > 2. The similar and general code from the disk drivers merged in the > disk.c: > common/disk.c > common/disk.h > i386/libi386/libi386.h > i386/libi386/biosdisk.c > userboot/test/test.c > userboot/userboot/userboot_disk.c > userboot/userboot.h > 3. ZFS code now uses new API and probing on the systems with many disks > should be greatly increased: > zfs/zfs.c > i386/loader/main.c > 4. The gptboot now searches the backup GPT header in the previous sectors, > when it finds the "GEOM::" signature in the last sector. PMBR code also > tries to do the same: > common/gpt.c > i386/pmbr/pmbr.s >=20 > 5. Also the pmbr image now contains one fake partition record. > When several first sectors are damaged the kernel can't detect GPT > (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) > command, but the old pmbr image has an empty partition table and > loader doesn't able to boot from GPT, when there is no partition record > in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootc= ode' > command, the kernel correctly modifies this partition record. So, this is= only > for the first rescue step. >=20 > 6. I have changed userboot interface. I guess there is none consumers exc= ept > the one test program. But if it isn't that, i can make it compatible. >=20 > Any comments are welcome. >=20 > --=20 > WBR, Andrey V. Elsukov >=20 >=20 --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/pscEACgkQForvXbEpPzRnngCgzmPlaecRHxfJkLn4Q9MhzbmT +hsAoLf2biw+RP8N9qalavPbyhMnihnL =Yxgu -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 14:01:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4676D1065677; Tue, 26 Jun 2012 14:01:46 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [IPv6:2a02:6b8:0:801::5]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1308FC08; Tue, 26 Jun 2012 14:01:45 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward15.mail.yandex.net (Yandex) with ESMTP id 83B0E9E1DE8; Tue, 26 Jun 2012 18:01:43 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340719303; bh=1UHNgwa4LP2yCMa+FrgAboQCgWmOizJUFUMPXLdWctg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=nN2Kk6DnK1Bh2viN2Yis+wx5Xd8KI3VZL2fehYtdw5/VH5DF3xQJZIyP5RLBH4Uvh Ltoo9i7ZcVPPiWO6AWhMMefOwBUiBa+/cL1tLHi2zNvkYO3K0W2ObJCjIggs2zcSbJ iy61BRcfoFqcH/8/xEsDfzwfi5sTRLBIfMf14wSs= Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id 21AD47E0554; Tue, 26 Jun 2012 18:01:43 +0400 (MSK) Received: from dynamic-178-141-5-132.kirov.comstar-r.ru (dynamic-178-141-5-132.kirov.comstar-r.ru [178.141.5.132]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 1gVi9xkS-1gVWLZ9I; Tue, 26 Jun 2012 18:01:42 +0400 X-Yandex-Rcpt-Suid: pjd@FreeBSD.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: avg@FreeBSD.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340719303; bh=1UHNgwa4LP2yCMa+FrgAboQCgWmOizJUFUMPXLdWctg=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=cqXEfn99WWFYPuQAYkyok+0JebVTngT18dfG4pfWr0eUx2ndPjbq/80IUfDmWTOt+ OBIa3T190cP/p4JOt+VQ1wlyR+gVtq4YsSqcUQbD9iwuVtrbt7H73YvMlxm66ZcdQk tVxjdY/Ue6Dq+34BBVc2dpPqZkmuFJWJCShxu9+c= Message-ID: <4FE9C0B6.5090106@yandex.ru> Date: Tue, 26 Jun 2012 18:01:26 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120406 Thunderbird/10.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4FE9B01C.30306@yandex.ru> <20120626125737.GA1372@garage.freebsd.pl> In-Reply-To: <20120626125737.GA1372@garage.freebsd.pl> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig21C87142E5DB97DE8655A57A" Cc: freebsd-hackers , Doug Rabson , freebsd-current , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:01:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig21C87142E5DB97DE8655A57A Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 26.06.2012 16:57, Pawel Jakub Dawidek wrote: > On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote: >> Hi All, >> >> Some time ago i have started reading the code in the sys/boot. >> Especially i'm interested in the partition tables handling. >> I found several problems: >> 1. There are several copies of the same code in the libi386/biosdisk.c= >> and common/disk.c, and partially libpc98/biosdisk.c. >> 2. ZFS probing is very slow, because the ZFS code doesn't know how man= y >> disks and partitions the system has: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148296 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161897 >> 3. The GPT support doesn't check CRC and even doesn't know anything >> about the secondary GPT header/table. >=20 > Just a quick note here. At some point when I was adding GPT attributes > to allow for test starts I greatly improved, at least parts of, the GPT= > implementation. I did implement support for both CRC checksum > verification and fallback to backup GPT header when primary is broken. > And the code is still in sys/boot/common/gpt.c. So my question would be= > what do you mean by this sentence? Yes, gptboot does that, but the loader/zfsloader doesn't. So there might be a situation when gptboot does boot, but loader(8) can't. --=20 WBR, Andrey V. Elsukov --------------enig21C87142E5DB97DE8655A57A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJP6cDFAAoJEAHF6gQQyKF6lsMH/Rzco/vYsCHB6SbQqMVUGb6m ODVKakOz2jUD3e+62QQ/6sDOSiQHi1FCZ0Vil/+8fH8QdK877TzfVcGxZcyff5LU On4cNxwCZBQku8uMgjniBsG3mxczCgdVjCQWLr1ntUx7eENwg43YDQqhnJ6ybc94 mpu5NOre7D2kmEo0upc66hC48EXnfr8Uyx1xCjXM6VTFVNbFuLnZbHxTYcVKB6jR 4C65a/lZa6KRvnEtQMKQCFUIdvFuO9DkwjkUrTsdq+ILVn63YDusFVrjZ5SfCO6S s1MlOT41pGXToCoj4H0R6jsrY0oCddT0bK8QkDosA3gOQmQcr7wBLb5Zjm7Irbc= =swCT -----END PGP SIGNATURE----- --------------enig21C87142E5DB97DE8655A57A-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 14:04:05 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FF041065702; Tue, 26 Jun 2012 14:04:05 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id CF7CC8FC14; Tue, 26 Jun 2012 14:04:04 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id D2F3E9C7; Tue, 26 Jun 2012 16:04:02 +0200 (CEST) Date: Tue, 26 Jun 2012 16:02:00 +0200 From: Pawel Jakub Dawidek To: "Andrey V. Elsukov" Message-ID: <20120626140200.GB1372@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <20120626125737.GA1372@garage.freebsd.pl> <4FE9C0B6.5090106@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: <4FE9C0B6.5090106@yandex.ru> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , Doug Rabson , freebsd-current , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:04:05 -0000 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 06:01:26PM +0400, Andrey V. Elsukov wrote: > On 26.06.2012 16:57, Pawel Jakub Dawidek wrote: > > On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote: > >> Hi All, > >> > >> Some time ago i have started reading the code in the sys/boot. > >> Especially i'm interested in the partition tables handling. > >> I found several problems: > >> 1. There are several copies of the same code in the libi386/biosdisk.c > >> and common/disk.c, and partially libpc98/biosdisk.c. > >> 2. ZFS probing is very slow, because the ZFS code doesn't know how many > >> disks and partitions the system has: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148296 > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161897 > >> 3. The GPT support doesn't check CRC and even doesn't know anything > >> about the secondary GPT header/table. > >=20 > > Just a quick note here. At some point when I was adding GPT attributes > > to allow for test starts I greatly improved, at least parts of, the GPT > > implementation. I did implement support for both CRC checksum > > verification and fallback to backup GPT header when primary is broken. > > And the code is still in sys/boot/common/gpt.c. So my question would be > > what do you mean by this sentence? >=20 > Yes, gptboot does that, but the loader/zfsloader doesn't. So there might > be a situation when gptboot does boot, but loader(8) can't. I see. I don't know if I'll find time for a proper review, but it is really great that you are working on cleaning up this huge mess. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --XF85m9dhOBO43t/C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/pwNgACgkQForvXbEpPzRNiACg9Jd2ghcjyMNO3acfJCWbqA5x CWIAoLBHIGoxWijoqp7QIb+fOtPETQj9 =+N3O -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 14:42:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C269B106566B; Tue, 26 Jun 2012 14:42:37 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 73FF68FC17; Tue, 26 Jun 2012 14:42:37 +0000 (UTC) Received: by dadv36 with SMTP id v36so7381191dad.13 for ; Tue, 26 Jun 2012 07:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7AJwgmKFOM7Eiohc/nf00x94+/bvifmzChfGE9/yWFU=; b=Z3ofc0dzwk38pQpaiVWljo3lEI+0jQDCZRi1BJncFk29DR2+jOP1Nt5h8mM7/23DID x7We2PdsQ9J9abP5/qdkGXiC4hhdy/cGBPs2JvAoNU5BgU1Oai7FRawhpJkyKj6x21Vk OyDpWESeiNa7XmBlt7OEW3l9hC4dKwpKU5BMk7zgJ/kFJw65LTgJTau618cMf4NJiZaZ bhBLQpeUHIO2scAcqqp0pYt8BS7iII5AiETo7uq9zyxHqvoHa2E0acL3M/awufePS4OD KbRX2rBoDaKoYiV0MzUN6R6zIWnVmK5E1jDB5lDoF8ZHMqT/h8QIICpSXWLk0igNxxBQ AjcA== MIME-Version: 1.0 Received: by 10.68.233.132 with SMTP id tw4mr52711220pbc.61.1340721756876; Tue, 26 Jun 2012 07:42:36 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.208.168 with HTTP; Tue, 26 Jun 2012 07:42:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 07:42:36 -0700 X-Google-Sender-Auth: x2biu1q5mqcvOmqUfYXD82T2AFo Message-ID: From: mdf@FreeBSD.org To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bp@freebsd.org, Arnaud Lacombe , freebsd-hackers@freebsd.org, FreeBSD Current , kby@freebsd.org, Wojciech Puchar , Chris Rees Subject: Re: sysctl filesystem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:42:38 -0000 On Tue, Jun 26, 2012 at 1:59 AM, Robert Watson wrote: > On Tue, 26 Jun 2012, Chris Rees wrote: > >>> as well as we don't depend of /proc for normal operation we shouldn't f= or >> >> say /proc/sysctl >>> >>> >>> improvements are welcome, better documentation is welcome, changes to >> >> what is OK - isn't. >> >> /proc/sysctl might be useful. =A0Just because Linux uses it doesn't make= it >> a bad idea. > > > One of the problems we've encounted with synthetic file systems is that > off-the-shelf file system tools (e.g., cp, dd, cat) make simplistic (but = not > unreasonable) assumptions about the statistic content of files. =A0This c= omes > up frequently with procfs-like systems where the size of, say, memory map > data can be considerably larger than the perhaps 128-byte, 256-byte, or e= ven > 8k buffers that might exist in a stock file access tool. =A0Unless we cha= nge > all of those tools to use buffers much bigger than they currently do, whi= ch > even suggets changing the C library buffer to defaults for FILE *, that > places an onus on the file system to provide persisting snapshots of data > until it's sure that a user process is done -- e.g., over many system cal= ls. > > sysctl is not immune to the requirement of atomicity, but it has explicit > control over it: sysctl is a single system call, rather than an unbounded > open-read-seek-repeat-etc cycle, and has been carefully crafted to provid= e > this and other MIB-like properties, such as a basic data type model so th= at > command line tools know how to render content rather than having to guess > and/or get it wrong. =A0sysctl has some file-system like properties, but = on > the whole, it's not a file system -- it's much more like an SNMP MIB. > > While you can map anything into anything (including Turing machines), I > think the sysctl command line tool and API, despite its limitations, is a > better match for accessing this sort of monitoring and control data than = the > POSIX file API, and would recommend against trying to move to a sysctl fi= le > system. While I understand the problems you allude to, the sysctl(8) binary can protect itself from them. IMO the biggest problem with sysctls not being files is that it makes no sense from the core UNIX philosophy that everything is a file. Sockets and pipes and character devices and even unseekable things like stdout are files; why aren't these other objects that allow read, write, and have their own namespace? Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 19:44:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C109D1065672 for ; Tue, 26 Jun 2012 19:44:55 +0000 (UTC) (envelope-from pchen@juniper.net) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8C08FC19 for ; Tue, 26 Jun 2012 19:44:55 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT+oRN3/kAzOe4I7l6nzR+mDcDirgzF/k@postini.com; Tue, 26 Jun 2012 12:44:55 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 26 Jun 2012 12:41:17 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 26 Jun 2012 12:41:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 26 Jun 2012 15:41:16 -0400 From: Ping Chen To: "freebsd-hackers@freebsd.org" Date: Tue, 26 Jun 2012 15:41:10 -0400 Thread-Topic: distinguish between Maxmem, realmem, physmem Thread-Index: Ac1T06L9N1QGaOrgR22jsLVqzNDeZg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {454BBE41-AFA6-4C29-9F0D-3B4183A5041B} x-cr-hashedpuzzle: AvJf BRdO CjMo ECSj Fli1 F59r GcIj HFP/ HlR6 H8tL Isec J3G/ KKvr KaDR Kl+8 LAhW; 1; ZgByAGUAZQBiAHMAZAAtAGgAYQBjAGsAZQByAHMAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {454BBE41-AFA6-4C29-9F0D-3B4183A5041B}; cABjAGgAZQBuAEAAagB1AG4AaQBwAGUAcgAuAG4AZQB0AA==; Tue, 26 Jun 2012 19:41:10 GMT; ZABpAHMAdABpAG4AZwB1AGkAcwBoACAAYgBlAHQAdwBlAGUAbgAgAE0AYQB4AG0AZQBtACwAIAByAGUAYQBsAG0AZQBtACwAIABwAGgAeQBzAG0AZQBtAA== acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 26 Jun 2012 20:38:06 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: distinguish between Maxmem, realmem, physmem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 19:44:55 -0000 Hi, I am a bit confused with all these variables defined in freebsd(especial= ly in freebsd 6.1): Which one of this represents the real memory of a syste= m? Say we bought a system with 4G ram, which one tells me the RAM is 4G? Accordign to source code: Maxmem =3D=3D> the highest page of phisycal address page : if I understand= correctly, this is the highest page number of physical memory that is usab= le? realMem --> somehow get assigned by realmem =3D Maxmem: this is confuing, = if they are the same, why bother a realmem variables physmem --> the number of usage pages : this seems the right one extract th= e memory info, however, it seems system allocate portion of memory to messg= e buffer which makes this physmem < 4G (assume RAM is 4G) Could someone explains more? Thanks Ping From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 20:42:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D306106567B; Tue, 26 Jun 2012 20:42:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2C88FC16; Tue, 26 Jun 2012 20:42:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68051B95A; Tue, 26 Jun 2012 16:42:40 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Tue, 26 Jun 2012 13:37:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> In-Reply-To: <4FE9B01C.30306@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201206261337.11741.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Jun 2012 16:42:40 -0400 (EDT) Cc: freebsd-hackers , Doug Rabson , freebsd-current , Pawel Jakub Dawidek , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 20:42:41 -0000 On Tuesday, June 26, 2012 8:50:36 am Andrey V. Elsukov wrote: > Hi All, > > Some time ago i have started reading the code in the sys/boot. > Especially i'm interested in the partition tables handling. > I found several problems: > 1. There are several copies of the same code in the libi386/biosdisk.c > and common/disk.c, and partially libpc98/biosdisk.c. > 2. ZFS probing is very slow, because the ZFS code doesn't know how many > disks and partitions the system has: > http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 > http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 > 3. The GPT support doesn't check CRC and even doesn't know anything > about the secondary GPT header/table. > > So, i have created the branch and committed the changes: > http://svnweb.freebsd.org/base/user/ae/bootcode/ > The patch is here: > http://people.freebsd.org/~ae/boot.diff > > What i already did: > 1. The partition tables handling now is machine independent, > and it is compatible with the kernel's GEOM_PART implementation. > There is new API for disk drivers in the loader to get information > about partitions and tables: > common/Makefile.inc > common/part.c > common/part.h > > 2. The similar and general code from the disk drivers merged in the > disk.c: > common/disk.c > common/disk.h > i386/libi386/libi386.h > i386/libi386/biosdisk.c > userboot/test/test.c > userboot/userboot/userboot_disk.c > userboot/userboot.h > 3. ZFS code now uses new API and probing on the systems with many disks > should be greatly increased: > zfs/zfs.c > i386/loader/main.c > 4. The gptboot now searches the backup GPT header in the previous sectors, > when it finds the "GEOM::" signature in the last sector. PMBR code also > tries to do the same: > common/gpt.c > i386/pmbr/pmbr.s GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. > 5. Also the pmbr image now contains one fake partition record. > When several first sectors are damaged the kernel can't detect GPT > (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) > command, but the old pmbr image has an empty partition table and > loader doesn't able to boot from GPT, when there is no partition record > in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootcode' > command, the kernel correctly modifies this partition record. So, this is only > for the first rescue step. As I said earlier, I do not think this is appropriate and that instead gpart should have an appropriate 'recover' command to install just the pmbr on a disk and also create a correct entry in the MBR if needed while doing so. > 6. I have changed userboot interface. I guess there is none consumers except > the one test program. But if it isn't that, i can make it compatible. One other consumer is in the bhyve branch. I think the 'kload' patches also use it. However, they can probably be adapted easily. [ Note, I haven't done a detailed review of the patch at all yet. ] -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 21:25:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05E421065672; Tue, 26 Jun 2012 21:25:13 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id A65138FC0C; Tue, 26 Jun 2012 21:25:12 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 4254BB84; Tue, 26 Jun 2012 23:25:11 +0200 (CEST) Date: Tue, 26 Jun 2012 23:23:08 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20120626212308.GE1399@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jKBxcB1XkHIR0Eqt" Content-Disposition: inline In-Reply-To: <201206261337.11741.jhb@freebsd.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:25:13 -0000 --jKBxcB1XkHIR0Eqt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: > > 4. The gptboot now searches the backup GPT header in the previous secto= rs, > > when it finds the "GEOM::" signature in the last sector. PMBR code also > > tries to do the same: > > common/gpt.c > > i386/pmbr/pmbr.s >=20 > GPT really wants the backup header at the last LBA. I know you can set i= t,=20 > but I've interpreted that as a way to see if the primary header is correc= t or=20 > not. [...] My interpretation is different: The way to verify if the header is valid is to check its checksum, not to check if the backup header location in the primary header points at the last LBA. Of course if primary header's checksum is incorrect it is hard to trust that the backup header location is correct. And we need the backup header when the primary header is invalid... > [...] It seems to me that GPT tables created in this fashion (inside a GE= OM=20 > provider) will not work properly with partition editors for other OS's. = I'm=20 > hesitant to encourage the use of this as I do think putting GPT inside of= a=20 > gmirror violates the GPT spec. I don't think so. Most common case is to configure partitions on top of a mirror. Mirroring partitions is less common. Mostly because of hardware RAIDs being popular. You don't expect hardware RAID vendor to mirror partitions. Partition editors for other OS's won't work, but only because they don't support gmirror. If they wouldn't recognize and support some hardware (or pseudo-hardware) RAIDs there will be the same problem. In other words, IMHO, our problem is that FreeBSD's boot code doesn't recognize/support gmirror's metadata. What Andrey is proposing is to recognize the metadata and act accordingly - in case of a gmirror we simply need to skip it. In the future we will have the same problem with graid - until we add support for it to the boot code, we won't be able to boot from it. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --jKBxcB1XkHIR0Eqt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/qKDsACgkQForvXbEpPzTuQQCg3kjmILCtG1x3GK+/ZmSRXGyr eQ0Anjd+C2ocL3sr5lOVZv+NlQ3+4s2Q =A8qf -----END PGP SIGNATURE----- --jKBxcB1XkHIR0Eqt-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 21:45:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A54B106566B; Tue, 26 Jun 2012 21:45:35 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id AC2898FC08; Tue, 26 Jun 2012 21:45:34 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 3CFFAB9A; Tue, 26 Jun 2012 23:45:33 +0200 (CEST) Date: Tue, 26 Jun 2012 23:43:31 +0200 From: Pawel Jakub Dawidek To: Kevin Oberman Message-ID: <20120626214330.GG1399@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nqkreNcslJAfgyzk" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:45:35 -0000 --nqkreNcslJAfgyzk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 02:41:31PM -0700, Kevin Oberman wrote: > Long ago I saw a proposal to create a dedicated partition on GPT to > hold the metadata. With the large number of partitions available on > GPT, tying up one just for GEOM seems like a low price and it moves > the device GEOM out of the realm of FreeBSD unique and subject to > serious issues when/if a disk is shared with some other OS. I have > seen little comment on this and have never seen any argument that that > it could not work. >=20 > I think this is an issue that will continue to bite users unless it is fi= xed. I don't really see how dedicating a partition for metadata can work or is good idea, sorry. As for sharing disk with other OS. If you share the disk with OS that doesn't support gmirror, you shouldn't use gmirror in the first place. You probably want to use only formats that are recognized by all your OSes. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --nqkreNcslJAfgyzk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/qLQEACgkQForvXbEpPzTlzQCdHI2jVnhsxBYTkouol8eq1q20 +QgAoIoNzb8kbd36nnE8J25zmBoL27XL =jd6L -----END PGP SIGNATURE----- --nqkreNcslJAfgyzk-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 22:33:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13A7C106564A for ; Tue, 26 Jun 2012 22:33:00 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C1C8F8FC08 for ; Tue, 26 Jun 2012 22:32:59 +0000 (UTC) Received: by vbmv11 with SMTP id v11so356451vbm.13 for ; Tue, 26 Jun 2012 15:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LAd0XbttwyU7EUzgKl//PACI5VFUQugdMh4cF+KIqHM=; b=KfSzUvSjhGtbZ+RGSS63o0sGuqchvcsYQtEFsO0mSqkcYVOgfN3SGLto423P1fh+0K dvmtz3+Fqz/ZZxkyx1BCZOk2czqFPtCf9Sd8dfdfErxykC4mXj6vU860nRPFbVW/dXu/ sqvpja+H1xXI6VWdLbzqkhbGwmG5ss1JHsDhZPs3CxrNKiQE4mwWiesIdrRmXgCxdJ3K iHCUOhd/mzDRpcWFsgrKpmd8C4VXixjwjt0lsbQYhkiOfS2utlfDxB/s+2QU783IezDR 7Qz1GZpDVlpHV15xsYEOAmFSlM6WFNCnNrIiGbYbpmTwZq6FOBGexGlBw1Dlx1Db7ooo /GYQ== MIME-Version: 1.0 Received: by 10.52.94.109 with SMTP id db13mr10337750vdb.4.1340749979125; Tue, 26 Jun 2012 15:32:59 -0700 (PDT) Received: by 10.52.16.148 with HTTP; Tue, 26 Jun 2012 15:32:58 -0700 (PDT) Date: Tue, 26 Jun 2012 18:32:58 -0400 Message-ID: From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Freeze when running freebsd-update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:33:00 -0000 I've run into a totally reproducible freeze in 9.0. There are a number of variables involved, but I'm able to reproduce this freeze 100% of the time. I'm installing very small servers in a Xen HVM virtualization environment. Each instance has 128M memory and 4G of disk space. There is 384M of swap encrypted using geli_swap_flags="-d -l 256 -s 4096". The rest of the disk space is encrypted with "geli init -b -v -a hmac/sha256 -l 256 -s 4096 /dev/ada0p4". After I've installed a VPS in this way, I run the freebsd-update fetch command and it freezes at: Applying patches... I've been trying to diagnose the problem by running top and watching what happens during this stage. I noticed the following: 1) the box runs out of physical memory at this stage (totally expected, that's why there is sufficient swap space). 2) All the processes except 2 sleep: 31 processes: 1 running, 29 sleeping, 1 waiting 3) the box is responsive to hitting enter at the console (it produces another login: prompt) 4) sshd is asleep, so I can't ssh into the box 5) if I try to login to the console, it lets me enter a username then locks up totally, it does not present me with a password: prompt. 6) it has not run out of swap, nowhere close: Mem: 54M Active, 9524K Inact, 41M Wired, 24K Cache, 21M Buf, 32K Free Swap: 384M Total, 6452K Used, 378M Free, 1% Inuse 7) the moment it runs out of physical memory it begins being unresponsive Any idea what might be going on here? From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 26 21:41:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E931D106566B; Tue, 26 Jun 2012 21:41:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id BA8328FC12; Tue, 26 Jun 2012 21:41:37 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so319193wib.13 for ; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EJULjC4LRx83lPPCAVyN1VZ3wmJAs3iDoqR8+Yb2QUU=; b=M64njnVyOA8TMFrQjLP5RSGyNbAFlr1E6y55xU6WpPNkheIbSTGbYfrx4lLX6OtlnT UTqV/gDSZDlA+tV5cfd8FVfcpl3xOjGoXx4JLNZY1rqmf8K5NTNNnyPlzSVe1iJoCDdX J19pxSuc6Tppja0y6rS/FK+skGMuDOe5jHe7H/3Qpb+wzjvQimLXkPFzqT6EnnxMBFAt eSyV458Xhb5Pcl6tY7MA4L9/Q+wfeCArayRTTUBRQVeQR0xK7bnbec6oxOuTh9ODkHQ1 PahIOqpKneBN0lGhrD/24IhkMZD/aGcG65AbpsPFQqTfido6uSu3tkR5EMJETl2l6Sh/ CYWw== MIME-Version: 1.0 Received: by 10.180.79.166 with SMTP id k6mr36239762wix.8.1340746891280; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) In-Reply-To: <20120626212308.GE1399@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> Date: Tue, 26 Jun 2012 14:41:31 -0700 Message-ID: From: Kevin Oberman To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 26 Jun 2012 22:38:17 +0000 Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:41:39 -0000 On Tue, Jun 26, 2012 at 2:23 PM, Pawel Jakub Dawidek wrot= e: > On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: >> > 4. The gptboot now searches the backup GPT header in the previous sect= ors, >> > when it finds the "GEOM::" signature in the last sector. PMBR code als= o >> > tries to do the same: >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 common/gpt.c >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 i386/pmbr/pmbr.s >> >> GPT really wants the backup header at the last LBA. =C2=A0I know you can= set it, >> but I've interpreted that as a way to see if the primary header is corre= ct or >> not. [...] > > My interpretation is different: The way to verify if the header is valid > is to check its checksum, not to check if the backup header location in > the primary header points at the last LBA. > > Of course if primary header's checksum is incorrect it is hard to trust > that the backup header location is correct. And we need the backup > header when the primary header is invalid... > >> [...] It seems to me that GPT tables created in this fashion (inside a G= EOM >> provider) will not work properly with partition editors for other OS's. = =C2=A0I'm >> hesitant to encourage the use of this as I do think putting GPT inside o= f a >> gmirror violates the GPT spec. > > I don't think so. Most common case is to configure partitions on top of > a mirror. Mirroring partitions is less common. Mostly because of > hardware RAIDs being popular. You don't expect hardware RAID vendor to > mirror partitions. Partition editors for other OS's won't work, but only > because they don't support gmirror. If they wouldn't recognize and > support some hardware (or pseudo-hardware) RAIDs there will be the same > problem. > > In other words, IMHO, our problem is that FreeBSD's boot code doesn't > recognize/support gmirror's metadata. What Andrey is proposing is to > recognize the metadata and act accordingly - in case of a gmirror we > simply need to skip it. > > In the future we will have the same problem with graid - until we add > support for it to the boot code, we won't be able to boot from it. Long ago I saw a proposal to create a dedicated partition on GPT to hold the metadata. With the large number of partitions available on GPT, tying up one just for GEOM seems like a low price and it moves the device GEOM out of the realm of FreeBSD unique and subject to serious issues when/if a disk is shared with some other OS. I have seen little comment on this and have never seen any argument that that it could not work. I think this is an issue that will continue to bite users unless it is fixe= d. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 00:22:44 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 669CE1065673 for ; Wed, 27 Jun 2012 00:22:44 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by mx1.freebsd.org (Postfix) with ESMTP id F1DA98FC15 for ; Wed, 27 Jun 2012 00:22:43 +0000 (UTC) Received: from [192.168.179.22] (vijn.xs4all.nl [80.101.129.129]) (authenticated bits=0) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id q5R0M1as061831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jun 2012 02:22:07 +0200 (CEST) (envelope-from info@martenvijn.nl) Message-ID: <4FEA5229.2060308@martenvijn.nl> Date: Wed, 27 Jun 2012 02:22:01 +0200 From: Marten Vijn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: Freeze when running freebsd-update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 00:22:44 -0000 On 06/27/2012 12:32 AM, Robert Simmons wrote: > I've run into a totally reproducible freeze in 9.0. There are a > number of variables involved, but I'm able to reproduce this freeze > 100% of the time. > > I'm installing very small servers in a Xen HVM virtualization > environment. Each instance has 128M memory and 4G of disk space. > There is 384M of swap encrypted using geli_swap_flags="-d -l 256 -s > 4096". > > The rest of the disk space is encrypted with "geli init -b -v -a > hmac/sha256 -l 256 -s 4096 /dev/ada0p4". > > After I've installed a VPS in this way, I run the freebsd-update fetch > command and it freezes at: > Applying patches... > > I've been trying to diagnose the problem by running top and watching > what happens during this stage. I noticed the following: > > 1) the box runs out of physical memory at this stage (totally > expected, that's why there is sufficient swap space). > 2) All the processes except 2 sleep: > 31 processes: 1 running, 29 sleeping, 1 waiting > 3) the box is responsive to hitting enter at the console (it produces > another login: prompt) > 4) sshd is asleep, so I can't ssh into the box > 5) if I try to login to the console, it lets me enter a username then > locks up totally, it does not present me with a password: prompt. > 6) it has not run out of swap, nowhere close: > Mem: 54M Active, 9524K Inact, 41M Wired, 24K Cache, 21M Buf, 32K Free > Swap: 384M Total, 6452K Used, 378M Free, 1% Inuse > 7) the moment it runs out of physical memory it begins being unresponsive > > Any idea what might be going on here? no sorry, but I may have encounted the same issue/behavior in a jail setup on freebsd 9.0 some month ago: jails stacked ro-mount and unionfs. In the url below is POC script to build 50 jails. I used (old) i386 hardware. More memory and faster cpu seems to delay this behavior, adding more jails on a bit faster system. http://martenvijn.nl/mk_jail.sh kind regards, Marten > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 00:54:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35F581065674 for ; Wed, 27 Jun 2012 00:54:37 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.mail.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id CF0B58FC12 for ; Wed, 27 Jun 2012 00:54:36 +0000 (UTC) Received: (qmail 2382 invoked by uid 0); 27 Jun 2012 00:54:30 -0000 Received: from 67.206.185.198 by rms-us013.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Tue, 26 Jun 2012 20:54:27 -0400 From: "Dieter BSD" Message-ID: <20120627005428.298430@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: kzyYb/cV3zOlNR3dAHAhDF1+IGRvb8DW Subject: Re: Freeze when running freebsd-update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 00:54:37 -0000 Robert writes: > 3) the box is responsive to hitting enter at the console (it produces > another login: prompt) Getty is in memory and can run. > 5) if I try to login to the console, it lets me enter a username then > locks up totally, it does not present me with a password: prompt. Login(1) is not in memory, and the kernel cannot read it from disk for some reason. I can get this symptom by writing a large file to a disk on a controller that FreeBSD doesn't support NCQ on. I assume there is a logjam in the buffer cache. Something trivial like reading login in from disk that would normally happen in well under a second can take many minutes. Perhaps geli is causing a similar logjam? Does it hang forever or is it just obscenely slow? If it truely hangs forever it is probably something else. Is there disk activity after it hangs? Can you try it without geli? systat -vmstat might provide a clue. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 00:56:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 624CF1065673 for ; Wed, 27 Jun 2012 00:56:18 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 146FF8FC15 for ; Wed, 27 Jun 2012 00:56:17 +0000 (UTC) Received: by vcbfy7 with SMTP id fy7so432374vcb.13 for ; Tue, 26 Jun 2012 17:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=mZMBetslR2+U4EL9MAMFO6tZ001B9bsr6kNbo/Dq+7g=; b=jUxsI29Kz/sITUFkAyp1nnUL1Cvs/JJe7yH/817+G0FMV9gaodO1OK9HKvE2eGGm4A jlqKBumWJm+C+hrFTP7WDZ/SapZptQJsUEOgYcr38zjitJsWSzwEYdwVKneJjVNkqfQH ESiXgDqzaJmHw5+qW78DXrlz1bm9arP4ToUNA3t55Oi5r9WTuCBHNXNN9QutyGvqNY+8 bwXt3LDkpRMM98QDXpIwHSS46R1YOp8IKnkdu3Kuolnhu90VzwniSh9+lNb17FBbo1WD YqmUsEZrEeNF9OaX2+HQ796GVxBz4jOGlDw9Di95RrZxiVRXKzTEOWoQ/7ThzTAN6FLr qytw== MIME-Version: 1.0 Received: by 10.52.28.202 with SMTP id d10mr10510091vdh.39.1340758576967; Tue, 26 Jun 2012 17:56:16 -0700 (PDT) Received: by 10.52.16.148 with HTTP; Tue, 26 Jun 2012 17:56:16 -0700 (PDT) In-Reply-To: <4FEA5229.2060308@martenvijn.nl> References: <4FEA5229.2060308@martenvijn.nl> Date: Tue, 26 Jun 2012 20:56:16 -0400 Message-ID: From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Freeze when running freebsd-update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 00:56:18 -0000 On Tue, Jun 26, 2012 at 8:22 PM, Marten Vijn wrote: > On 06/27/2012 12:32 AM, Robert Simmons wrote: >> >> I've run into a totally reproducible freeze in 9.0. =A0There are a >> number of variables involved, but I'm able to reproduce this freeze >> 100% of the time. >> >> I'm installing very small servers in a Xen HVM virtualization >> environment. =A0Each instance has 128M memory and 4G of disk space. >> There is 384M of swap encrypted using geli_swap_flags=3D"-d -l 256 -s >> 4096". >> >> The rest of the disk space is encrypted with "geli init -b -v -a >> hmac/sha256 -l 256 -s 4096 /dev/ada0p4". >> >> After I've installed a VPS in this way, I run the freebsd-update fetch >> command and it freezes at: >> Applying patches... >> >> I've been trying to diagnose the problem by running top and watching >> what happens during this stage. =A0I noticed the following: >> >> 1) the box runs out of physical memory at this stage (totally >> expected, that's why there is sufficient swap space). >> 2) All the processes except 2 sleep: >> 31 processes: =A01 running, 29 sleeping, 1 waiting >> 3) the box is responsive to hitting enter at the console (it produces >> another login: prompt) >> 4) sshd is asleep, so I can't ssh into the box >> 5) if I try to login to the console, it lets me enter a username then >> locks up totally, it does not present me with a password: prompt. >> 6) it has not run out of swap, nowhere close: >> Mem: 54M Active, 9524K Inact, 41M Wired, 24K Cache, 21M Buf, 32K Free >> Swap: 384M Total, 6452K Used, 378M Free, 1% Inuse >> 7) the moment it runs out of physical memory it begins being unresponsiv= e >> >> Any idea what might be going on here? > > no sorry, but I may have encounted the same issue/behavior in a jail setu= p > on freebsd 9.0 some month ago: > > jails stacked ro-mount and unionfs. In the url below is POC script to bui= ld > 50 jails. I used (old) i386 hardware. More memory and faster cpu seems to > delay this behavior, adding more jails on a bit faster system. > > http://martenvijn.nl/mk_jail.sh I've done some testing using a VirtualBox VM with exactly the same specs as the Xen HVM setup. I installed ports/benchmarks/forkbomb, and I am able to reproduce the exact same freeze with "forkbomb -f". From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 02:21:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35C99106564A for ; Wed, 27 Jun 2012 02:21:12 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id A362E8FC12 for ; Wed, 27 Jun 2012 02:21:11 +0000 (UTC) Received: by lbon10 with SMTP id n10so1135754lbo.13 for ; Tue, 26 Jun 2012 19:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=aeRXwvzPF6CGRZpLO1tqgOiywZMyphhRBdJhFNT0t0I=; b=F0S6StaSodZG3MdfbaN0v/mGM4/TkYvo1zVEwGZL/vZYoyiT1qsTIIPf/0mRA8NW/z NXk/eNpP0S6+15nvFIJqTbQPFA5pgNT+BdDaspBIkIX9KN8meGER7/2NUpodBVNrsGAk DwWOE8KnYibvtF3mBmes6YllWoTjzbGz+iBWD4EGRg0rWYHJ/wXOiImtkQh++PotFt7n OZHhMQpzOJS5kv6xXiOAn/8qCF6oyjtMA7W7M6R1Y1ss5BGbinU9oQ3G7mHAQAWGDH0u 2Q7DsgsZEb3yr+kSvQJi9cd4xs1Vtt0uc0Gr6U/qmHrcuWeJw4PlXika7UQGBrhwlyPm Zqdw== MIME-Version: 1.0 Received: by 10.112.30.41 with SMTP id p9mr8894678lbh.26.1340763670267; Tue, 26 Jun 2012 19:21:10 -0700 (PDT) Received: by 10.112.107.170 with HTTP; Tue, 26 Jun 2012 19:21:10 -0700 (PDT) In-Reply-To: <20120627005428.298430@gmx.com> References: <20120627005428.298430@gmx.com> Date: Tue, 26 Jun 2012 22:21:10 -0400 Message-ID: From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Freeze when running freebsd-update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 02:21:12 -0000 On Tue, Jun 26, 2012 at 8:54 PM, Dieter BSD wrote: > Robert writes: >> 3) the box is responsive to hitting enter at the console (it produces >> another login: prompt) > > Getty is in memory and can run. > >> 5) if I try to login to the console, it lets me enter a username then >> locks up totally, it does not present me with a password: prompt. > > Login(1) is not in memory, and the kernel cannot read it from disk > for some reason. > > I can get this symptom by writing a large file to a disk on a > controller that FreeBSD doesn't support NCQ on. I assume there > is a logjam in the buffer cache. Something trivial like reading > login in from disk that would normally happen in well under a > second can take many minutes. > > Perhaps geli is causing a similar logjam? Does it hang forever or > is it just obscenely slow? If it truely hangs forever it is > probably something else. Is there disk activity after it hangs? > Can you try it without geli? systat -vmstat might provide a clue. I've done some more testing with forkbomb and if I bump the memory up to 512M I just get an error message on the console about the user exceeding maxproc and approaching the limit on PV entries. At that point I'm able to Ctrl-C and stop forkbomb: no freeze. I have a number of these instances, and I will reinstall one geli-free and see what happens. I will also reproduce the initial conditions and leave it for the night to see if it comes out of it. After a certain point there is no disk activity, and the uptime counter in the corner of top eventially freezes too, so I don't think it will come out of this, but we'll see. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 02:31:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86C88106564A for ; Wed, 27 Jun 2012 02:31:56 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 057788FC19 for ; Wed, 27 Jun 2012 02:31:55 +0000 (UTC) Received: by lbon10 with SMTP id n10so1146878lbo.13 for ; Tue, 26 Jun 2012 19:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=c+h/DuWmi8oE3zyHDYZGHkmVT80zdc8GGPba3ot+AXg=; b=I3ecRyHiVspUI6/xvyHqhDdp9CI57YlEN7xHlSl2et/CvM0n6J4wI17epLJnyOxhcX HbFYi3Im7kn2aDfxz4NiEKFVh8Cd06V87fjoID71pYH8jjsp3ILqc1g6IVdBZU/IUQOB Wgl/uHhOUchJ8e0LGA49P6ydV8SK3xYva7LWlyMQZEAVNUabl2bq4aPNmK/jqPc6kZsY znOmxvXTLLhhWjNEg0y7nwlEOEGT8R5Ap9TShN0Ezp1B9h0MVRhfmGkK4b3uGHqhtr+Q S/hAq+A5gd1/sBIKph90bzOZu0VzO79dbUkyUZC2aaO+9rUPM7nVDpNY4F5fX/oACnj6 Xx8Q== MIME-Version: 1.0 Received: by 10.152.104.171 with SMTP id gf11mr18673358lab.5.1340764314850; Tue, 26 Jun 2012 19:31:54 -0700 (PDT) Received: by 10.112.107.170 with HTTP; Tue, 26 Jun 2012 19:31:54 -0700 (PDT) In-Reply-To: <20120627005428.298430@gmx.com> References: <20120627005428.298430@gmx.com> Date: Tue, 26 Jun 2012 22:31:54 -0400 Message-ID: From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Freeze when running freebsd-update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 02:31:56 -0000 On Tue, Jun 26, 2012 at 8:54 PM, Dieter BSD wrote: > Robert writes: >> 3) the box is responsive to hitting enter at the console (it produces >> another login: prompt) > > Getty is in memory and can run. > >> 5) if I try to login to the console, it lets me enter a username then >> locks up totally, it does not present me with a password: prompt. > > Login(1) is not in memory, and the kernel cannot read it from disk > for some reason. > > I can get this symptom by writing a large file to a disk on a > controller that FreeBSD doesn't support NCQ on. I assume there > is a logjam in the buffer cache. Something trivial like reading > login in from disk that would normally happen in well under a > second can take many minutes. > > Perhaps geli is causing a similar logjam? Does it hang forever or > is it just obscenely slow? If it truely hangs forever it is > probably something else. Is there disk activity after it hangs? > Can you try it without geli? systat -vmstat might provide a clue. Well, it is geli. I'm unable to reproduce the freeze on the same exact system with everything else the same except for no geli. I'm going to move this thread over to geom, and continue it there. Thanks for your help! From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 04:50:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8752106566B; Wed, 27 Jun 2012 04:50:29 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [IPv6:2a02:6b8:0:602::5]) by mx1.freebsd.org (Postfix) with ESMTP id E40748FC16; Wed, 27 Jun 2012 04:50:28 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward5.mail.yandex.net (Yandex) with ESMTP id 3049C1202173; Wed, 27 Jun 2012 08:50:27 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340772627; bh=Jcum2yLgZon2uNC2jfVxqj1hN+QO9Z8Z8GgH7dkljyw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=V0KMa3FlUKD5mTLAcU+DGAQJXYdIiIw66qZ4EYkP2ENJSLs/dCDYH+P5UPN7yWKDa UNSXrBrmWM2o9so7ozQBwzMu8QBAhj+T0rDHxc2y2fr6wUzcQzzTtrPDcREVWj8vwj +dBaRQtp3iER7uxC/cRlgLIXqLOY+9vaplEcU198= Received: from smtp4.mail.yandex.net (localhost [127.0.0.1]) by smtp4.mail.yandex.net (Yandex) with ESMTP id A54C95C03D0; Wed, 27 Jun 2012 08:50:26 +0400 (MSK) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by smtp4.mail.yandex.net (nwsmtp/Yandex) with ESMTP id oQF8H3nW-oQFuT0r9; Wed, 27 Jun 2012 08:50:26 +0400 X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: marcel@FreeBSD.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340772626; bh=Jcum2yLgZon2uNC2jfVxqj1hN+QO9Z8Z8GgH7dkljyw=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=SHkEl6mwykxDo2ZsiFh65M8SWNef1ho1iHRzLpO3kdj3UED58Q8OiuLhUDBo6yeEp 940qifykcM1LD2heDWry4ceIj6HnkjryD+G0Y/RsLjwHolF0iMHa1MBqTwMdBYhvpk 7WXif3IIHm6L4vki3NL0boSRicURNVGREWfQQPtI= Message-ID: <4FEA910C.4090305@yandex.ru> Date: Wed, 27 Jun 2012 08:50:20 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: John Baldwin References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> In-Reply-To: <201206261337.11741.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig43DFB080B9C277186794B58A" Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 04:50:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig43DFB080B9C277186794B58A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 26.06.2012 21:37, John Baldwin wrote: >> 4. The gptboot now searches the backup GPT header in the previous sect= ors, >> when it finds the "GEOM::" signature in the last sector. PMBR code als= o >> tries to do the same: >> common/gpt.c >> i386/pmbr/pmbr.s >=20 > GPT really wants the backup header at the last LBA. I know you can set= it,=20 > but I've interpreted that as a way to see if the primary header is corr= ect or=20 > not. It seems to me that GPT tables created in this fashion (inside a = GEOM=20 > provider) will not work properly with partition editors for other OS's.= I'm=20 > hesitant to encourage the use of this as I do think putting GPT inside = of a=20 > gmirror violates the GPT spec. The standard says: "The following test must be performed to determine if a GPT is valid: =E2=80=A2 Check the Signature =E2=80=A2 Check the Header CRC =E2=80=A2 Check that the MyLBA entry points to the LBA that contains the = GUID Partition Table =E2=80=A2 Check the CRC of the GUID Partition Entry Array If the GPT is the primary table, stored at LBA 1: =E2=80=A2 Check the AlternateLBA to see if it is a valid GPT If the primary GPT is corrupt, software must check the last LBA of the de= vice to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array." For the FreeBSD an each GEOM provider can be treated as disk device. So, i don't see anything criminal if we will add some quirks in the our l= oader for the better supporting of our technologies. If a user wants modify GPT in the disk editor from the another OS, he can do it, and it should work. The result depends only from the partit= ion editor, it might overwrite the last sector and might don't. >> 5. Also the pmbr image now contains one fake partition record. >> When several first sectors are damaged the kernel can't detect GPT >> (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(= 1) >> command, but the old pmbr image has an empty partition table and >> loader doesn't able to boot from GPT, when there is no partition recor= d >> in the PMBR. Now it will be able. When pmbr is installed via 'gpart=20 > bootcode' >> command, the kernel correctly modifies this partition record. So, this= is=20 > only >> for the first rescue step. >=20 > As I said earlier, I do not think this is appropriate and that instead > gpart should have an appropriate 'recover' command to install just the = pmbr on=20 > a disk and also create a correct entry in the MBR if needed while doing= so. gpart(8) is only one of several geom(8)' tools to manage objects of a GEO= M class. It only sends control requests to the kernel. If GPT is not detected, there is no geom objects to manage. And we can't write bootcode with gpar= t(8). I think that adding such functions to the gpart(8) is not good. Maybe, the boot0cfg is the better tool for that. Also we still haven't any tool = to install zfsboot. --=20 WBR, Andrey V. Elsukov --------------enig43DFB080B9C277186794B58A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJP6pERAAoJEAHF6gQQyKF6pPkH/iWeqKnlQRc7jDKVoWb8iabJ 1lmJ+cv96Ypq+DoTVaRwrRCQIRt3z2E3l4IUVgKFnJODSZt6G2Grl7IjOwD5aZ90 fU7d5qIRWih3t+w6+zH9yFzPbzc4aq/CV/7fFlrtjXSaYFe7PqEYLFxtg32prGch Jd9kqSOq0mDnue0hPfTFHgHmG3gGh+eQ3Kffs6rDMEMMArMKP7xEunESAsfO7Rl8 2EBbnP2Wz8unzqwRO+Z2gAbyTHyNRjkVVs0mzsLiFseCxdPnIOkGMYLOx9bCOwNs AUASvIYDrB9waAK59NS8S3xnw8F/F81lT2i+GWvhvsNtQWMk5kXbLWjr1i9AmV4= =9ix4 -----END PGP SIGNATURE----- --------------enig43DFB080B9C277186794B58A-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 04:58:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B2DF106564A; Wed, 27 Jun 2012 04:58:29 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [IPv6:2a02:6b8:0:602::5]) by mx1.freebsd.org (Postfix) with ESMTP id 93D3E8FC0A; Wed, 27 Jun 2012 04:58:28 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward5.mail.yandex.net (Yandex) with ESMTP id 8FF6F120012A; Wed, 27 Jun 2012 08:58:27 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340773107; bh=IOn+vWA5i0FuYEC3B+O4kVGcvgON9IREmvlGMKKFoww=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=TalgQTFGGYxzhR0PBVGdviYwRps6rVvezrCOCiBbq7kAdiTM/4e1t42L4fgLrUYwV NRKLcPURiD+NGxgmMOG0PlFpP4NMSQCxwBweG00BrrXwv89dILgBlArl6kGhHYWGt9 z7aKlEqsGWUyWMzcxHFUg8GUbuuyQOpdFaekhqD0= Received: from smtp2.mail.yandex.net (localhost [127.0.0.1]) by smtp2.mail.yandex.net (Yandex) with ESMTP id 45072E2031B; Wed, 27 Jun 2012 08:58:27 +0400 (MSK) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by smtp2.mail.yandex.net (nwsmtp/Yandex) with ESMTP id wQYWhteA-wQYqscUG; Wed, 27 Jun 2012 08:58:26 +0400 X-Yandex-Rcpt-Suid: kob6558@gmail.com X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340773107; bh=IOn+vWA5i0FuYEC3B+O4kVGcvgON9IREmvlGMKKFoww=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=K3KEKMaRNPf+HlkJIokxpWE7L6fkVRTZjxsi7nmt/4KbfpFpJcv04lb3wgYX7nvpa O+SfIbmuyFmOYAoifEWeYK4Pqi1TjtO0zIZSHGbnFsBPr+VEpEf02De7FU8AiyEk3r Tz7nGNuK8EeBoI46qP/42zF1GOpXrXjmerbI05OM= Message-ID: <4FEA92EE.8090202@yandex.ru> Date: Wed, 27 Jun 2012 08:58:22 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Kevin Oberman References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD250C2D8C236335AFD7CB710" Cc: freebsd-hackers , freebsd-current , Pawel Jakub Dawidek Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 04:58:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD250C2D8C236335AFD7CB710 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 27.06.2012 1:41, Kevin Oberman wrote: > Long ago I saw a proposal to create a dedicated partition on GPT to > hold the metadata. With the large number of partitions available on > GPT, tying up one just for GEOM seems like a low price and it moves > the device GEOM out of the realm of FreeBSD unique and subject to > serious issues when/if a disk is shared with some other OS. I have > seen little comment on this and have never seen any argument that that > it could not work. When you share some disk with another OS, it seems that much serious issue will be when other OS did some changes in your mirror without you knowing. I know about successful sharing of the disk between Windows and FreeBSD via graid on the Intel pseudo raid. Just use compatible techn= ologies. --=20 WBR, Andrey V. Elsukov --------------enigD250C2D8C236335AFD7CB710 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJP6pLyAAoJEAHF6gQQyKF6DqAH/jDCzuym1zHrJigHP3pal8HB QMRo4LF8f4OWR3EXTqFwnYhzHwpQgjUfSKsfN8vyA1QfHy4ZEBFt0Ms/+RSBA9Ec x4hsct9OeFuLCRlaSXYP+eyCSY/YMdute2M97l2Xd6j6Tzcb5FvOjh2HfdfD92Iw EiBRYjuTstSl2ZweV5ngreUt4KH2RAcdvKCtqpKW687Akc/uNi4nG2NBxjEjQnWM FXGXNMHHd6tjRTJIhm1OiWk/eKTUiZGMloW3PtwtGqTafC3yFg40W9lwNjwJJJS8 kOCwVG+3v+v45qj4BHYTrciovfolcIjEsAn8XLxOeqOpR1gBERzF4VwPZKuBWSU= =uJFg -----END PGP SIGNATURE----- --------------enigD250C2D8C236335AFD7CB710-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 05:53:53 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E209B106566C; Wed, 27 Jun 2012 05:53:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 84BD38FC0C; Wed, 27 Jun 2012 05:53:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA12918; Wed, 27 Jun 2012 08:53:50 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SjlCI-000M3I-5C; Wed, 27 Jun 2012 08:53:50 +0300 Message-ID: <4FEA9FED.9040408@FreeBSD.org> Date: Wed, 27 Jun 2012 08:53:49 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> In-Reply-To: <4FEA910C.4090305@yandex.ru> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 05:53:54 -0000 on 27/06/2012 07:50 Andrey V. Elsukov said the following: > Also we still haven't any tool to install zfsboot. Yeah, I think it would be nice if ZFS provided some interface (ioctl?) to properly write stuff to its special areas. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 06:34:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1ED1106566C for ; Wed, 27 Jun 2012 06:34:04 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 96A378FC0A for ; Wed, 27 Jun 2012 06:34:04 +0000 (UTC) Received: (qmail 4890 invoked by uid 0); 27 Jun 2012 06:34:03 -0000 Received: from 67.206.184.147 by rms-us010.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Wed, 27 Jun 2012 02:33:59 -0400 From: "Dieter BSD" Message-ID: <20120627063400.298430@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: D8yYb/cV3zOlNR3dAHAhnPN+IGRvb0A9 Subject: Re: Freeze when running freebsd-update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 06:34:05 -0000 >> Robert writes: >>> 3) the box is responsive to hitting enter at the console (it produces >>> another login: prompt) >> >> Getty is in memory and can run. >> >>> 5) if I try to login to the console, it lets me enter a username then >>> locks up totally, it does not present me with a password: prompt. >> >> Login(1) is not in memory, and the kernel cannot read it from disk >> for some reason. >> >> I can get this symptom by writing a large file to a disk on a >> controller that FreeBSD doesn't support NCQ on. I assume there >> is a logjam in the buffer cache. Something trivial like reading >> login in from disk that would normally happen in well under a >> second can take many minutes. >> >> Perhaps geli is causing a similar logjam? Does it hang forever or >> is it just obscenely slow? If it truely hangs forever it is >> probably something else. Is there disk activity after it hangs? >> Can you try it without geli? systat -vmstat might provide a clue. > > Well, it is geli. I'm unable to reproduce the freeze on the same > exact system with everything else the same except for no geli. I'm > going to move this thread over to geom, and continue it there. Thanks > for your help! It occurs to me that it will need twice as much memory for disk i/o. 1 buffer for encrypted and 1 for unencrypted. I know nothing about geli, so I don't know if it uses the buffer cache for both, or what. Could it be that the kernel isn't keeping enough memory free and manages to paint itself into a corner and not have space to store the unencrypted version of disk reads, and can't page/swap anything out to make space because it doesn't have space to store the encrypted version to write? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 12:22:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A779310657A9; Wed, 27 Jun 2012 12:22:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 75B5A8FC14; Wed, 27 Jun 2012 12:22:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CB131B945; Wed, 27 Jun 2012 08:22:48 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Wed, 27 Jun 2012 08:07:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> In-Reply-To: <4FEA910C.4090305@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201206270807.23347.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 08:22:48 -0400 (EDT) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 12:22:49 -0000 On Wednesday, June 27, 2012 12:50:20 am Andrey V. Elsukov wrote: > On 26.06.2012 21:37, John Baldwin wrote: > >> 4. The gptboot now searches the backup GPT header in the previous sect= ors, > >> when it finds the "GEOM::" signature in the last sector. PMBR code also > >> tries to do the same: > >> common/gpt.c > >> i386/pmbr/pmbr.s > >=20 > > GPT really wants the backup header at the last LBA. I know you can set= it,=20 > > but I've interpreted that as a way to see if the primary header is corr= ect or=20 > > not. It seems to me that GPT tables created in this fashion (inside a = GEOM=20 > > provider) will not work properly with partition editors for other OS's.= I'm=20 > > hesitant to encourage the use of this as I do think putting GPT inside = of a=20 > > gmirror violates the GPT spec. >=20 > The standard says: > "The following test must be performed to determine if a GPT is valid: > =E2=80=A2 Check the Signature > =E2=80=A2 Check the Header CRC > =E2=80=A2 Check that the MyLBA entry points to the LBA that contains the = GUID Partition Table > =E2=80=A2 Check the CRC of the GUID Partition Entry Array > If the GPT is the primary table, stored at LBA 1: > =E2=80=A2 Check the AlternateLBA to see if it is a valid GPT > If the primary GPT is corrupt, software must check the last LBA of the de= vice to see if it has a > valid GPT Header and point to a valid GPT Partition Entry Array." Right, we break the last rule. If you want to use a partition editor that doesn't grok gmirror (because you are using another OS's editor), to repair a GPT, it will do the wrong thing. > If a user wants modify GPT in the disk editor from the another OS, > he can do it, and it should work. The result depends only from the partit= ion editor, > it might overwrite the last sector and might don't. I would not assume it would work at all. If it can't trust the primary GPT, it has to assume the alternate is at the last LBA. > >> 5. Also the pmbr image now contains one fake partition record. > >> When several first sectors are damaged the kernel can't detect GPT > >> (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(= 1) > >> command, but the old pmbr image has an empty partition table and > >> loader doesn't able to boot from GPT, when there is no partition record > >> in the PMBR. Now it will be able. When pmbr is installed via 'gpart=20 > > bootcode' > >> command, the kernel correctly modifies this partition record. So, this= is=20 > > only > >> for the first rescue step. > >=20 > > As I said earlier, I do not think this is appropriate and that instead > > gpart should have an appropriate 'recover' command to install just the = pmbr on=20 > > a disk and also create a correct entry in the MBR if needed while doing= so. >=20 > gpart(8) is only one of several geom(8)' tools to manage objects of a GEO= M class. > It only sends control requests to the kernel. If GPT is not detected, > there is no geom objects to manage. And we can't write bootcode with gpar= t(8). > I think that adding such functions to the gpart(8) is not good. Maybe, > the boot0cfg is the better tool for that. Also we still haven't any tool = to > install zfsboot. We can't write bootcode with gpart? What do you think the 'bootcode' comma= nd does? Also, there is no reason we can't have a 'recover' command that attempts to recover a corrupted table including repairing the PMBR. gpart(8) already generates a full PMBR when you use 'gpart create' to create a GPT even thou= gh there isn't a GPT object yet. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 12:22:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EC3E10657A9; Wed, 27 Jun 2012 12:22:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D58018FC19; Wed, 27 Jun 2012 12:22:52 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DA784B9A0; Wed, 27 Jun 2012 08:22:51 -0400 (EDT) From: John Baldwin To: Pawel Jakub Dawidek Date: Wed, 27 Jun 2012 08:22:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> In-Reply-To: <20120626212308.GE1399@garage.freebsd.pl> MIME-Version: 1.0 Message-Id: <201206270822.25672.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 08:22:51 -0400 (EDT) Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 12:22:53 -0000 On Tuesday, June 26, 2012 5:23:08 pm Pawel Jakub Dawidek wrote: > On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: > > > 4. The gptboot now searches the backup GPT header in the previous sectors, > > > when it finds the "GEOM::" signature in the last sector. PMBR code also > > > tries to do the same: > > > common/gpt.c > > > i386/pmbr/pmbr.s > > > > GPT really wants the backup header at the last LBA. I know you can set it, > > but I've interpreted that as a way to see if the primary header is correct or > > not. [...] > > My interpretation is different: The way to verify if the header is valid > is to check its checksum, not to check if the backup header location in > the primary header points at the last LBA. > > Of course if primary header's checksum is incorrect it is hard to trust > that the backup header location is correct. And we need the backup > header when the primary header is invalid... Right, which is why this fails. > > [...] It seems to me that GPT tables created in this fashion (inside a GEOM > > provider) will not work properly with partition editors for other OS's. I'm > > hesitant to encourage the use of this as I do think putting GPT inside of a > > gmirror violates the GPT spec. > > I don't think so. Most common case is to configure partitions on top of > a mirror. Mirroring partitions is less common. Mostly because of > hardware RAIDs being popular. You don't expect hardware RAID vendor to > mirror partitions. Partition editors for other OS's won't work, but only > because they don't support gmirror. If they wouldn't recognize and > support some hardware (or pseudo-hardware) RAIDs there will be the same > problem. Hardware RAIDs hide the metadata from the disk that the BIOS (and disk editors) see. Thus, putting a GPT on a hardware RAID volume works fine as the logical volume is always seen by all OS's consistently. The same is even true of the "software" RAID that graid supports since the metadata is defined by the vendor and thus the logical volume is always seen other OS's consistently. My approach has been to only use gmirror with MBR so far, though I realize that doesn't work above 2TB (until recently one had to have a hardware RAID to get above 2TB anyway which made this last a moot point). I won't object to patch our tools to handle this, but I think it is a really bad idea that users will have a hard way to recover from when they are bitten by it. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 12:45:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EBCD106566B; Wed, 27 Jun 2012 12:45:50 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [IPv6:2a02:6b8:0:602::1]) by mx1.freebsd.org (Postfix) with ESMTP id 26D2A8FC0A; Wed, 27 Jun 2012 12:45:49 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward1.mail.yandex.net (Yandex) with ESMTP id 665711241787; Wed, 27 Jun 2012 16:45:47 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340801147; bh=PVgBaSsktQdbS9+UkEnby+reOAT1fMAQ04WXbr4hIs8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WeM8tCijMnGCFgFD8k2AbZ0wdOte7bbZ5so1L1VokQSW2RwIDw1cu1tgyu8hJ/hU8 v7PK20PKKYWxd4iWGQunHo/Oi0tP0bUY1Bhu3TIYklgh38W0FKgOUqarJ4Eh5CQxxQ WAWuu75zbA6IfDe/QtdYV3aAyZ4FSHdmAUPwi69A= Received: from smtp4.mail.yandex.net (localhost [127.0.0.1]) by smtp4.mail.yandex.net (Yandex) with ESMTP id ECC265C03D0; Wed, 27 Jun 2012 16:45:46 +0400 (MSK) Received: from ns.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by smtp4.mail.yandex.net (nwsmtp/Yandex) with ESMTP id jjF8mO0D-jkFKHr2u; Wed, 27 Jun 2012 16:45:46 +0400 X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: marcel@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340801146; bh=PVgBaSsktQdbS9+UkEnby+reOAT1fMAQ04WXbr4hIs8=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=gDSsrrIPivDByUjfLpQ8xPlKgqY0xsGvIUNufvG79RPHNDK02zD1RV3e4TOjL3Rez ZQJkOrPHZ95rj7SfBF5fVvs+1TIPwNuVYy6jxHlVC8Pu60gf/IMYdUkgYGMV7dO6vx MbknUl29y9liE5Kqtk+m5n2TRZnD2A+Ju0k+p2mc= Message-ID: <4FEB0079.7050008@yandex.ru> Date: Wed, 27 Jun 2012 16:45:45 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: John Baldwin References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <201206270807.23347.jhb@freebsd.org> In-Reply-To: <201206270807.23347.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 12:45:50 -0000 On 27.06.2012 16:07, John Baldwin wrote: >> • Check the Signature >> • Check the Header CRC >> • Check that the MyLBA entry points to the LBA that contains the GUID Partition Table >> • Check the CRC of the GUID Partition Entry Array >> If the GPT is the primary table, stored at LBA 1: >> • Check the AlternateLBA to see if it is a valid GPT >> If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a >> valid GPT Header and point to a valid GPT Partition Entry Array." > > Right, we break the last rule. If you want to use a partition editor > that doesn't grok gmirror (because you are using another OS's editor), > to repair a GPT, it will do the wrong thing. When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) >>> As I said earlier, I do not think this is appropriate and that instead >>> gpart should have an appropriate 'recover' command to install just the pmbr on >>> a disk and also create a correct entry in the MBR if needed while doing so. >> >> gpart(8) is only one of several geom(8)' tools to manage objects of a GEOM class. >> It only sends control requests to the kernel. If GPT is not detected, >> there is no geom objects to manage. And we can't write bootcode with gpart(8). >> I think that adding such functions to the gpart(8) is not good. Maybe, >> the boot0cfg is the better tool for that. Also we still haven't any tool to >> install zfsboot. > > We can't write bootcode with gpart? What do you think the 'bootcode' command > does? `gpart bootcode -b` reads file, creates ioctl request and sends this data to the GEOM_PART class. GEOM_PART receives the control request, checks the data and writes it to the provider. `gpart bootcode -p` works like dd(1) and writes bootcode to the given partition. gpart(8) haven't any knowledge about specific partitioning scheme. > Also, there is no reason we can't have a 'recover' command that attempts to > recover a corrupted table including repairing the PMBR. gpart(8) already > generates a full PMBR when you use 'gpart create' to create a GPT even though > there isn't a GPT object yet. `gpart create` creates only ioctl control request to the GEOM_PART class. GEOM_PART class creates new GPT geom object and this objects writes PMBR and its metadata to the provider. -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 13:14:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41BDA1065674; Wed, 27 Jun 2012 13:14:24 +0000 (UTC) (envelope-from root@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.freebsd.org (Postfix) with ESMTP id E14DC8FC12; Wed, 27 Jun 2012 13:14:23 +0000 (UTC) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id q5RDEM7R005804; Wed, 27 Jun 2012 09:14:22 -0400 (EDT) Received: (from root@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id q5RDEMPw005803; Wed, 27 Jun 2012 09:14:22 -0400 (EDT) Received: from mail1.radix.net (mail1.radix.net [207.192.128.31]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id q5QLRJ7R000428 for ; Tue, 26 Jun 2012 17:27:19 -0400 (EDT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail1.radix.net (8.13.4/8.13.4) with ESMTP id q5QLRJU0016728 for ; Tue, 26 Jun 2012 17:27:19 -0400 (EDT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 41635160A8B; Tue, 26 Jun 2012 21:25:42 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 60E081065815; Tue, 26 Jun 2012 21:25:32 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05E421065672; Tue, 26 Jun 2012 21:25:13 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id A65138FC0C; Tue, 26 Jun 2012 21:25:12 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 4254BB84; Tue, 26 Jun 2012 23:25:11 +0200 (CEST) Date: Tue, 26 Jun 2012 23:23:08 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20120626212308.GE1399@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jKBxcB1XkHIR0Eqt" Content-Disposition: inline In-Reply-To: <201206261337.11741.jhb@freebsd.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org Status: O X-Status: X-Keywords: X-UID: 98 Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 13:14:24 -0000 --jKBxcB1XkHIR0Eqt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: > > 4. The gptboot now searches the backup GPT header in the previous secto= rs, > > when it finds the "GEOM::" signature in the last sector. PMBR code also > > tries to do the same: > > common/gpt.c > > i386/pmbr/pmbr.s >=20 > GPT really wants the backup header at the last LBA. I know you can set i= t,=20 > but I've interpreted that as a way to see if the primary header is correc= t or=20 > not. [...] My interpretation is different: The way to verify if the header is valid is to check its checksum, not to check if the backup header location in the primary header points at the last LBA. Of course if primary header's checksum is incorrect it is hard to trust that the backup header location is correct. And we need the backup header when the primary header is invalid... > [...] It seems to me that GPT tables created in this fashion (inside a GE= OM=20 > provider) will not work properly with partition editors for other OS's. = I'm=20 > hesitant to encourage the use of this as I do think putting GPT inside of= a=20 > gmirror violates the GPT spec. I don't think so. Most common case is to configure partitions on top of a mirror. Mirroring partitions is less common. Mostly because of hardware RAIDs being popular. You don't expect hardware RAID vendor to mirror partitions. Partition editors for other OS's won't work, but only because they don't support gmirror. If they wouldn't recognize and support some hardware (or pseudo-hardware) RAIDs there will be the same problem. In other words, IMHO, our problem is that FreeBSD's boot code doesn't recognize/support gmirror's metadata. What Andrey is proposing is to recognize the metadata and act accordingly - in case of a gmirror we simply need to skip it. In the future we will have the same problem with graid - until we add support for it to the boot code, we won't be able to boot from it. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --jKBxcB1XkHIR0Eqt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/qKDsACgkQForvXbEpPzTuQQCg3kjmILCtG1x3GK+/ZmSRXGyr eQ0Anjd+C2ocL3sr5lOVZv+NlQ3+4s2Q =A8qf -----END PGP SIGNATURE----- --jKBxcB1XkHIR0Eqt-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 13:52:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A8C51065672; Wed, 27 Jun 2012 13:52:57 +0000 (UTC) (envelope-from root@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.freebsd.org (Postfix) with ESMTP id E81078FC19; Wed, 27 Jun 2012 13:52:56 +0000 (UTC) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id q5RDDx7R005629; Wed, 27 Jun 2012 09:13:59 -0400 (EDT) Received: (from root@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id q5RDDxTQ005628; Wed, 27 Jun 2012 09:13:59 -0400 (EDT) Received: from mail1.radix.net (mail1.radix.net [207.192.128.31]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id q5QKkb7R024664 for ; Tue, 26 Jun 2012 16:46:37 -0400 (EDT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail1.radix.net (8.13.4/8.13.4) with ESMTP id q5QKkb1r010381 for ; Tue, 26 Jun 2012 16:46:37 -0400 (EDT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 638EA2056C2; Tue, 26 Jun 2012 20:43:13 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E23ED106572B; Tue, 26 Jun 2012 20:43:01 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D306106567B; Tue, 26 Jun 2012 20:42:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2C88FC16; Tue, 26 Jun 2012 20:42:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68051B95A; Tue, 26 Jun 2012 16:42:40 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Tue, 26 Jun 2012 13:37:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> In-Reply-To: <4FE9B01C.30306@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201206261337.11741.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Jun 2012 16:42:40 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org Status: O X-Status: X-Keywords: X-UID: 32 Cc: freebsd-hackers , Doug Rabson , freebsd-current , Pawel Jakub Dawidek , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 13:52:57 -0000 On Tuesday, June 26, 2012 8:50:36 am Andrey V. Elsukov wrote: > Hi All, > > Some time ago i have started reading the code in the sys/boot. > Especially i'm interested in the partition tables handling. > I found several problems: > 1. There are several copies of the same code in the libi386/biosdisk.c > and common/disk.c, and partially libpc98/biosdisk.c. > 2. ZFS probing is very slow, because the ZFS code doesn't know how many > disks and partitions the system has: > http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 > http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 > 3. The GPT support doesn't check CRC and even doesn't know anything > about the secondary GPT header/table. > > So, i have created the branch and committed the changes: > http://svnweb.freebsd.org/base/user/ae/bootcode/ > The patch is here: > http://people.freebsd.org/~ae/boot.diff > > What i already did: > 1. The partition tables handling now is machine independent, > and it is compatible with the kernel's GEOM_PART implementation. > There is new API for disk drivers in the loader to get information > about partitions and tables: > common/Makefile.inc > common/part.c > common/part.h > > 2. The similar and general code from the disk drivers merged in the > disk.c: > common/disk.c > common/disk.h > i386/libi386/libi386.h > i386/libi386/biosdisk.c > userboot/test/test.c > userboot/userboot/userboot_disk.c > userboot/userboot.h > 3. ZFS code now uses new API and probing on the systems with many disks > should be greatly increased: > zfs/zfs.c > i386/loader/main.c > 4. The gptboot now searches the backup GPT header in the previous sectors, > when it finds the "GEOM::" signature in the last sector. PMBR code also > tries to do the same: > common/gpt.c > i386/pmbr/pmbr.s GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. > 5. Also the pmbr image now contains one fake partition record. > When several first sectors are damaged the kernel can't detect GPT > (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) > command, but the old pmbr image has an empty partition table and > loader doesn't able to boot from GPT, when there is no partition record > in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootcode' > command, the kernel correctly modifies this partition record. So, this is only > for the first rescue step. As I said earlier, I do not think this is appropriate and that instead gpart should have an appropriate 'recover' command to install just the pmbr on a disk and also create a correct entry in the MBR if needed while doing so. > 6. I have changed userboot interface. I guess there is none consumers except > the one test program. But if it isn't that, i can make it compatible. One other consumer is in the bhyve branch. I think the 'kload' patches also use it. However, they can probably be adapted easily. [ Note, I haven't done a detailed review of the patch at all yet. ] -- John Baldwin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 14:10:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E399106566C; Wed, 27 Jun 2012 14:10:28 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 066A18FC14; Wed, 27 Jun 2012 14:10:28 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id DEE02EB8; Wed, 27 Jun 2012 16:10:20 +0200 (CEST) Date: Wed, 27 Jun 2012 16:08:17 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20120627140817.GC1372@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> <201206270822.25672.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sHrvAb52M6C8blB9" Content-Disposition: inline In-Reply-To: <201206270822.25672.jhb@freebsd.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 14:10:28 -0000 --sHrvAb52M6C8blB9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2012 at 08:22:25AM -0400, John Baldwin wrote: > > I don't think so. Most common case is to configure partitions on top of > > a mirror. Mirroring partitions is less common. Mostly because of > > hardware RAIDs being popular. You don't expect hardware RAID vendor to > > mirror partitions. Partition editors for other OS's won't work, but only > > because they don't support gmirror. If they wouldn't recognize and > > support some hardware (or pseudo-hardware) RAIDs there will be the same > > problem. >=20 > Hardware RAIDs hide the metadata from the disk that the BIOS (and disk > editors) see. Thus, putting a GPT on a hardware RAID volume works fine > as the logical volume is always seen by all OS's consistently. [...] Only if you won't connect this disk to a different controller. > [...] The same > is even true of the "software" RAID that graid supports since the metadata > is defined by the vendor and thus the logical volume is always seen other > OS's consistently. But is it seen without metadata by the boot loader? What I'm trying to say is that it is fair to expect from the user to not use gmirror-configured disk on different OS. If the user wants to use this disk in different OS then he has to use format that is recognized by both. Because gmirror is supported by FreeBSD we should improve the support by teaching boot loader about it. Pretending gmirror is special and recommending to mirror partitions with it instead of raw disks is not the solution. I really can't see how gmirror is different in this regard from any other software RAID or volume manager. If you try to use disk that contains unrecognized metadata the behaviour is undefined (but hopefully not a panic). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --sHrvAb52M6C8blB9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/rE9EACgkQForvXbEpPzR3+gCg0WjbLvmRZAjPToMtNypIRg9M Pp0An0JP9JJkZp5Az6GiKR0KxzbaXXG/ =N78o -----END PGP SIGNATURE----- --sHrvAb52M6C8blB9-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 13:15:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E18AC106566B; Wed, 27 Jun 2012 13:15:23 +0000 (UTC) (envelope-from root@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.freebsd.org (Postfix) with ESMTP id 827DE8FC18; Wed, 27 Jun 2012 13:15:23 +0000 (UTC) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id q5RDFM7R006272; Wed, 27 Jun 2012 09:15:22 -0400 (EDT) Received: (from root@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id q5RDFMsO006268; Wed, 27 Jun 2012 09:15:22 -0400 (EDT) Received: from mail1.radix.net (mail1.radix.net [207.192.128.31]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id q5QLgo7R002613 for ; Tue, 26 Jun 2012 17:42:50 -0400 (EDT) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail1.radix.net (8.13.4/8.13.4) with ESMTP id q5QLgoxj018998 for ; Tue, 26 Jun 2012 17:42:50 -0400 (EDT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 083A8202C07; Tue, 26 Jun 2012 21:41:52 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B42211065713; Tue, 26 Jun 2012 21:41:47 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E931D106566B; Tue, 26 Jun 2012 21:41:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id BA8328FC12; Tue, 26 Jun 2012 21:41:37 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so319193wib.13 for ; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EJULjC4LRx83lPPCAVyN1VZ3wmJAs3iDoqR8+Yb2QUU=; b=M64njnVyOA8TMFrQjLP5RSGyNbAFlr1E6y55xU6WpPNkheIbSTGbYfrx4lLX6OtlnT UTqV/gDSZDlA+tV5cfd8FVfcpl3xOjGoXx4JLNZY1rqmf8K5NTNNnyPlzSVe1iJoCDdX J19pxSuc6Tppja0y6rS/FK+skGMuDOe5jHe7H/3Qpb+wzjvQimLXkPFzqT6EnnxMBFAt eSyV458Xhb5Pcl6tY7MA4L9/Q+wfeCArayRTTUBRQVeQR0xK7bnbec6oxOuTh9ODkHQ1 PahIOqpKneBN0lGhrD/24IhkMZD/aGcG65AbpsPFQqTfido6uSu3tkR5EMJETl2l6Sh/ CYWw== MIME-Version: 1.0 Received: by 10.180.79.166 with SMTP id k6mr36239762wix.8.1340746891280; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Tue, 26 Jun 2012 14:41:31 -0700 (PDT) In-Reply-To: <20120626212308.GE1399@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> Date: Tue, 26 Jun 2012 14:41:31 -0700 Message-ID: From: Kevin Oberman To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by saltmine.radix.net id q5QLgo7R002613 Status: O X-Status: X-Keywords: X-UID: 156 X-Mailman-Approved-At: Wed, 27 Jun 2012 15:25:34 +0000 Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 13:15:24 -0000 On Tue, Jun 26, 2012 at 2:23 PM, Pawel Jakub Dawidek wrote: > On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: >> > 4. The gptboot now searches the backup GPT header in the previous sectors, >> > when it finds the "GEOM::" signature in the last sector. PMBR code also >> > tries to do the same: >> >         common/gpt.c >> >         i386/pmbr/pmbr.s >> >> GPT really wants the backup header at the last LBA.  I know you can set it, >> but I've interpreted that as a way to see if the primary header is correct or >> not. [...] > > My interpretation is different: The way to verify if the header is valid > is to check its checksum, not to check if the backup header location in > the primary header points at the last LBA. > > Of course if primary header's checksum is incorrect it is hard to trust > that the backup header location is correct. And we need the backup > header when the primary header is invalid... > >> [...] It seems to me that GPT tables created in this fashion (inside a GEOM >> provider) will not work properly with partition editors for other OS's.  I'm >> hesitant to encourage the use of this as I do think putting GPT inside of a >> gmirror violates the GPT spec. > > I don't think so. Most common case is to configure partitions on top of > a mirror. Mirroring partitions is less common. Mostly because of > hardware RAIDs being popular. You don't expect hardware RAID vendor to > mirror partitions. Partition editors for other OS's won't work, but only > because they don't support gmirror. If they wouldn't recognize and > support some hardware (or pseudo-hardware) RAIDs there will be the same > problem. > > In other words, IMHO, our problem is that FreeBSD's boot code doesn't > recognize/support gmirror's metadata. What Andrey is proposing is to > recognize the metadata and act accordingly - in case of a gmirror we > simply need to skip it. > > In the future we will have the same problem with graid - until we add > support for it to the boot code, we won't be able to boot from it. Long ago I saw a proposal to create a dedicated partition on GPT to hold the metadata. With the large number of partitions available on GPT, tying up one just for GEOM seems like a low price and it moves the device GEOM out of the realm of FreeBSD unique and subject to serious issues when/if a disk is shared with some other OS. I have seen little comment on this and have never seen any argument that that it could not work. I think this is an issue that will continue to bite users unless it is fixed. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 17:30:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DABC106564A; Wed, 27 Jun 2012 17:30:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0FDAA8FC1D; Wed, 27 Jun 2012 17:30:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7A613B94B; Wed, 27 Jun 2012 13:30:55 -0400 (EDT) From: John Baldwin To: Pawel Jakub Dawidek Date: Wed, 27 Jun 2012 10:26:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <201206270822.25672.jhb@freebsd.org> <20120627140817.GC1372@garage.freebsd.pl> In-Reply-To: <20120627140817.GC1372@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201206271026.02473.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 13:30:55 -0400 (EDT) Cc: freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:30:56 -0000 On Wednesday, June 27, 2012 10:08:17 am Pawel Jakub Dawidek wrote: > On Wed, Jun 27, 2012 at 08:22:25AM -0400, John Baldwin wrote: > > > I don't think so. Most common case is to configure partitions on top of > > > a mirror. Mirroring partitions is less common. Mostly because of > > > hardware RAIDs being popular. You don't expect hardware RAID vendor to > > > mirror partitions. Partition editors for other OS's won't work, but only > > > because they don't support gmirror. If they wouldn't recognize and > > > support some hardware (or pseudo-hardware) RAIDs there will be the same > > > problem. > > > > Hardware RAIDs hide the metadata from the disk that the BIOS (and disk > > editors) see. Thus, putting a GPT on a hardware RAID volume works fine > > as the logical volume is always seen by all OS's consistently. [...] > > Only if you won't connect this disk to a different controller. Yes, but people do not expect to be able to yank a hardware RAID drive out and hook it up to a "raw" disk controller and have it work. > > [...] The same > > is even true of the "software" RAID that graid supports since the metadata > > is defined by the vendor and thus the logical volume is always seen other > > OS's consistently. > > But is it seen without metadata by the boot loader? Yes. The logical volume shows up as a BIOS disk device. > What I'm trying to say is that it is fair to expect from the user to not > use gmirror-configured disk on different OS. If the user wants to use > this disk in different OS then he has to use format that is recognized > by both. > > Because gmirror is supported by FreeBSD we should improve the support by > teaching boot loader about it. Pretending gmirror is special and > recommending to mirror partitions with it instead of raw disks is not > the solution. > > I really can't see how gmirror is different in this regard from any > other software RAID or volume manager. If you try to use disk that > contains unrecognized metadata the behaviour is undefined (but hopefully > not a panic). It is not gmirror I am complaining about, it is the non-standard use of GPT. Note that gmirror + MBR works fine without violating what little standard there is for the MBR. Using a dedicated GPT partition to hold the gmirrror metadata would work with GPT (but be a good bit harder to work with in terms of GEOM I realize). But as I said, I won't object to these patches. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 17:30:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF0AB1065673; Wed, 27 Jun 2012 17:30:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id AEBA48FC1F; Wed, 27 Jun 2012 17:30:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 21DBDB953; Wed, 27 Jun 2012 13:30:56 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Wed, 27 Jun 2012 10:28:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> In-Reply-To: <4FEB0079.7050008@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201206271028.54477.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 13:30:56 -0400 (EDT) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:30:57 -0000 On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: > On 27.06.2012 16:07, John Baldwin wrote: > >> =E2=80=A2 Check the Signature > >> =E2=80=A2 Check the Header CRC > >> =E2=80=A2 Check that the MyLBA entry points to the LBA that contains t= he GUID Partition Table > >> =E2=80=A2 Check the CRC of the GUID Partition Entry Array > >> If the GPT is the primary table, stored at LBA 1: > >> =E2=80=A2 Check the AlternateLBA to see if it is a valid GPT > >> If the primary GPT is corrupt, software must check the last LBA of the= device to see if it has a > >> valid GPT Header and point to a valid GPT Partition Entry Array." > >=20 > > Right, we break the last rule. If you want to use a partition editor > > that doesn't grok gmirror (because you are using another OS's editor), > > to repair a GPT, it will do the wrong thing. >=20 > When we are in the FreeBSD, our loader can detect that device size > is lower than it see and it will work. When primary header is OK, then > other OSes should work with this GPT. When it isn't OK, you just can't > load other OS :) Ah, yes. The solution to violating standards is to make sure you never use standards-compliant software. That's a great argument. :) (Although not entirely uncommon. Standards aren't always perfect, but if we had a way to not gratuitously violate them it would be nice to avoid doing so.) > > We can't write bootcode with gpart? What do you think the 'bootcode' c= ommand > > does? >=20 > `gpart bootcode -b` reads file, creates ioctl request and sends this data= to > the GEOM_PART class. GEOM_PART receives the control request, checks the d= ata > and writes it to the provider. > `gpart bootcode -p` works like dd(1) and writes bootcode to the given par= tition. > gpart(8) haven't any knowledge about specific partitioning scheme. Correct, but in both cases it writes "bootcode". > > Also, there is no reason we can't have a 'recover' command that attempt= s to > > recover a corrupted table including repairing the PMBR. gpart(8) alrea= dy > > generates a full PMBR when you use 'gpart create' to create a GPT even = though > > there isn't a GPT object yet. >=20 > `gpart create` creates only ioctl control request to the GEOM_PART class. > GEOM_PART class creates new GPT geom object and this objects writes PMBR = and its > metadata to the provider. You can't add a new ioctl? =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 17:37:29 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E2DA106566B; Wed, 27 Jun 2012 17:37:29 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 337EF8FC1B; Wed, 27 Jun 2012 17:37:29 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RHbGtc011695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 10:37:22 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <201206261337.11741.jhb@freebsd.org> Date: Wed, 27 Jun 2012 10:37:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <468988EA-AC50-451D-ACE1-17B58E0CAF67@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:37:29 -0000 On Jun 26, 2012, at 10:37 AM, John Baldwin wrote: >=20 > GPT really wants the backup header at the last LBA. I know you can = set it,=20 > but I've interpreted that as a way to see if the primary header is = correct or=20 > not. It seems to me that GPT tables created in this fashion (inside a = GEOM=20 > provider) will not work properly with partition editors for other = OS's. I'm=20 > hesitant to encourage the use of this as I do think putting GPT inside = of a=20 > gmirror violates the GPT spec. Agreed. While it is a nice trick to use the last sector for meta data, it does create 2 problems. 1 is mentioned above. The second is that when there's different metadata in the first *and* the last sector, you can't decide which is to take precedence without also looking at the other and know how to interpret it. We have not solved this second problem at all. We do get reports about the problems though. At best we're handwaving or kluging. I think it's unwise to depend on FreeBSD-specific extensions or features in industry-standard partitioning schemes and as such make the use of "foreign" tools hard if not impossible. A much more flexible approach is to support out-of-band configuration data. This allows us to mirror GPT disks without having to become non- standard as it removes the need to use the last sector for meta-data. The ability to construct GEOM hierarchies unambiguously is very important and our current approach has proven to not deliver on that. This is actually impacting existing FreeBSD consumers already, like Juniper. So, se should not go deeper into this rabbit hole. We should finally solve this problem for real... --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 17:45:49 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A11D2106564A; Wed, 27 Jun 2012 17:45:49 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 775888FC0A; Wed, 27 Jun 2012 17:45:49 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RHjeki011729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 10:45:48 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120626214330.GG1399@garage.freebsd.pl> Date: Wed, 27 Jun 2012 10:45:35 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> <20120626214330.GG1399@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) Cc: freebsd-current , freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , Kevin Oberman Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:45:49 -0000 On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote: > > As for sharing disk with other OS. If you share the disk with OS that > doesn't support gmirror, you shouldn't use gmirror in the first place. > You probably want to use only formats that are recognized by all your > OSes. This statement is ridicuous by virtue of not being in touch with reality and by making gmirror useless for such wide range of cases that one can question why we have it at all. Put differently: a mirroring class is a fairly basic and useful thing to have. Limiting it's use is nothing but artificial and follows from having to use the underlying provider to store metadata. This then changes the view of the underlying providing to consumers above gmirror in a way that makes the presence or absence of gmirror visible. Solving the visibility problem makes gmirror useful all the time. I see that as a better way of looking at it than simply blurting out that you shouldn't use gmirror when certain awkward and artifical conditions apply. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 17:51:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 670C910657E1 for ; Wed, 27 Jun 2012 17:51:22 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 211B78FC22 for ; Wed, 27 Jun 2012 17:51:22 +0000 (UTC) Received: by vcbfy7 with SMTP id fy7so1095749vcb.13 for ; Wed, 27 Jun 2012 10:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TxXYKMueRAHJA107jiZvdqKl0pzIqHgXfZTRzKpMEwo=; b=uefk+84Otmz4V0x6kPUaPpqhQ/5EP3UMZfXS83t+OjHFRz/TMfZyT+C+mTtW7JJLIy xBRg84ln3dru0QMhxg8uJ6q+n6cIapz4qh/wiWG+YTPmJ4scKEWykjll9Nv0T3yDXPqA Qp8z87+S4MR9IUeJbRITlndVJwFE2ZuKFCqJb+gT9gVX1A8hbU/2nLVTS8IoTFoTWslA 3E7qhzUg0zjipjbgAIhDWk0thnPR5MaOL+SQKw5qfxSf6YmEC8vAda8SbYL/7kX+LhI1 Bw65HDlHMbnz2JFJany1CAZ2NRimltfXtx1CmbRRGhBvN+VzjTUSNDswTeoE/t2IuY/s ApFA== MIME-Version: 1.0 Received: by 10.52.240.228 with SMTP id wd4mr12307114vdc.95.1340819481314; Wed, 27 Jun 2012 10:51:21 -0700 (PDT) Received: by 10.52.16.148 with HTTP; Wed, 27 Jun 2012 10:51:21 -0700 (PDT) In-Reply-To: <20120627063400.298430@gmx.com> References: <20120627063400.298430@gmx.com> Date: Wed, 27 Jun 2012 13:51:21 -0400 Message-ID: From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Freeze when running freebsd-update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:51:22 -0000 On Wed, Jun 27, 2012 at 2:33 AM, Dieter BSD wrote: >>> Robert writes: >>>> 3) the box is responsive to hitting enter at the console (it produces >>>> another login: prompt) >>> >>> Getty is in memory and can run. >>> >>>> 5) if I try to login to the console, it lets me enter a username then >>>> locks up totally, it does not present me with a password: prompt. >>> >>> Login(1) is not in memory, and the kernel cannot read it from disk >>> for some reason. >>> >>> I can get this symptom by writing a large file to a disk on a >>> controller that FreeBSD doesn't support NCQ on. I assume there >>> is a logjam in the buffer cache. Something trivial like reading >>> login in from disk that would normally happen in well under a >>> second can take many minutes. >>> >>> Perhaps geli is causing a similar logjam? Does it hang forever or >>> is it just obscenely slow? If it truely hangs forever it is >>> probably something else. Is there disk activity after it hangs? >>> Can you try it without geli? systat -vmstat might provide a clue. >> >> Well, it is geli. I'm unable to reproduce the freeze on the same >> exact system with everything else the same except for no geli. I'm >> going to move this thread over to geom, and continue it there. Thanks >> for your help! > > It occurs to me that it will need twice as much memory for disk i/o. > 1 buffer for encrypted and 1 for unencrypted. I know nothing about geli, > so I don't know if it uses the buffer cache for both, or what. > Could it be that the kernel isn't keeping enough memory free and > manages to paint itself into a corner and not have space to store > the unencrypted version of disk reads, and can't page/swap anything > out to make space because it doesn't have space to store the encrypted > version to write? I think that's probably about what is happening. I'm still waiting for an answer on the geom mailing list, but I will do some testing with increasing memory sizes and see where the problem stops occurring. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 17:55:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCBB11065676; Wed, 27 Jun 2012 17:55:37 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8C7748FC1C; Wed, 27 Jun 2012 17:55:37 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RHtOiC011786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 10:55:32 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <4FEA910C.4090305@yandex.ru> Date: Wed, 27 Jun 2012 10:55:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:55:37 -0000 On Jun 26, 2012, at 9:50 PM, Andrey V. Elsukov wrote: > If the primary GPT is corrupt, software must check the last LBA of the = device to see if it has a > valid GPT Header and point to a valid GPT Partition Entry Array." >=20 > For the FreeBSD an each GEOM provider can be treated as disk device. > So, i don't see anything criminal if we will add some quirks in the = our loader > for the better supporting of our technologies. You can't just re-interpret standards to match a context you know very = well isn't applicable and consequently redefine what the word "device" means. You're on a slippery slope and while you may not see it as a problem, = you do make it a problem for FreeBSD users. It's our users we should be = keeping in mind when we solve problems. > If a user wants modify GPT in the disk editor from the another OS, > he can do it, and it should work. The result depends only from the = partition editor, > it might overwrite the last sector and might don't. Right. Another happy user that sees his/her FreeBSD installation = destroyed or degraded (no mirroring, warning messages about corrupted GPT, etc) = for no apparent reason and without any kind of warning that what he/she is = doing is potentially harmful... That's the spirit! --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 18:22:45 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9C17106564A; Wed, 27 Jun 2012 18:22:45 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id DEB828FC08; Wed, 27 Jun 2012 18:22:44 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 4F0E8FFA; Wed, 27 Jun 2012 20:22:43 +0200 (CEST) Date: Wed, 27 Jun 2012 20:20:39 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20120627182038.GB1401@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <468988EA-AC50-451D-ACE1-17B58E0CAF67@xcllnt.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xXmbgvnjoT4axfJE" Content-Disposition: inline In-Reply-To: <468988EA-AC50-451D-ACE1-17B58E0CAF67@xcllnt.net> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Doug Rabson , John Baldwin , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 18:22:45 -0000 --xXmbgvnjoT4axfJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote: >=20 > On Jun 26, 2012, at 10:37 AM, John Baldwin wrote: > >=20 > > GPT really wants the backup header at the last LBA. I know you can set= it,=20 > > but I've interpreted that as a way to see if the primary header is corr= ect or=20 > > not. It seems to me that GPT tables created in this fashion (inside a = GEOM=20 > > provider) will not work properly with partition editors for other OS's.= I'm=20 > > hesitant to encourage the use of this as I do think putting GPT inside = of a=20 > > gmirror violates the GPT spec. >=20 > Agreed. Guys. This doesn't violate the GPT spec in any way. The spec is narrow-minded if it talks only about raw disks, but you should think about gmirror as pseudo-hardware RAID. That's all. If putting GPT on top of RAID array is spec violation, then I guess we just have to live with it. > While it is a nice trick to use the last sector for meta data, it does > create 2 problems. 1 is mentioned above. [...] It doesn't really matter where gmirror puts its metadata. If gmirror would keep its metadata in the first sector, gpart/gpt will find its metadata in the last sector and will complain about missing primary header. > [...] The second is that when there's > different metadata in the first *and* the last sector, you can't decide > which is to take precedence without also looking at the other and know > how to interpret it. We have not solved this second problem at all. We > do get reports about the problems though. At best we're handwaving or > kluging. This is different kind of problem. It took me a while to realize that, but now I know:) The real problem is that not all metadata formats are suitable for autodetection. That's all. The metadata I use in my GEOM classes play nice with autodetection. The solution is very easy - keep size of the disk device within metadata. This allows gmirror to figure out if it is configured on raw disk, last slice or last partition within last slice, etc. If GPT would keep disk size in its metadata the second problem you mentioned would not exist. And to be honest GPT kinda does that by having backup header's LBA stored in the primary header. And this is fine as long the primary header is valid. The same problem is with things like UFS labels. There is no way to properly support them using GEOM autodetection, because there is no provider size in UFS superblock. UFS superblock contains file system size, but it is not the same, as one can create smaller file system than the underlying disk device. > I think it's unwise to depend on FreeBSD-specific extensions or features > in industry-standard partitioning schemes and as such make the use of > "foreign" tools hard if not impossible. If you plan to use the given disk with FreeBSD only, what's the problem? Partitioning is not the end of the world. Even if you use "industry-standard partitioning schemes" what file system are you going to use to actually access your data? FAT? Of course if you do share your disk between various OSes then probably your best bet is to use MBR or GPT on raw disk and FAT file system. But if you use your disk with FreeBSD only, then I see no reason to not to leverage FreeBSD-specific features (be it gmirror, geli or zfs). > A much more flexible approach is to support out-of-band configuration > data. This allows us to mirror GPT disks without having to become non- > standard as it removes the need to use the last sector for meta-data. > The ability to construct GEOM hierarchies unambiguously is very > important and our current approach has proven to not deliver on that. > This is actually impacting existing FreeBSD consumers already, like > Juniper. So, se should not go deeper into this rabbit hole. We should > finally solve this problem for real... Marcel, nothing stops anyone from implementing GEOM mirror class that uses no on-disk metadata. GEOM is not a limiting factor here. GEOM does provide mechanism for autoconfiguration, but it is totally optional and GEOM class might choose not to use it. As an example you can take a look at two other GEOM classes of mine: gconcat(8) and gstripe(8). You can use 'label' subcommand to store metadata on component disks, which will take advantage of GEOM autodetection and autoconfiguration. You can also use 'create' subcommand to create ad hoc provider that stores no metadata and makes use of entire disks, which also means it won't be automatically created on next boot. For Juniper it might be more handy to use out-of-band configuration as you know the hardware you are running on, so you know where the disks are exactly, etc. My company build appliances too, so I have been there. For most of our users automatic configuration is simply better, as they can shuffle disks around and not wonder if the system will boot or not. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --xXmbgvnjoT4axfJE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/rTvYACgkQForvXbEpPzTZwwCgy+YI9gzwZnE6G1ZMgpOl1G0t qJcAoO/lUg0evhqdiMeX/AGhxIq2yahP =JS+Z -----END PGP SIGNATURE----- --xXmbgvnjoT4axfJE-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 18:36:52 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D49301065670; Wed, 27 Jun 2012 18:36:52 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 7C69D8FC16; Wed, 27 Jun 2012 18:36:52 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id E71C346; Wed, 27 Jun 2012 20:36:50 +0200 (CEST) Date: Wed, 27 Jun 2012 20:34:47 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20120627183446.GC1401@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> <20120626214330.GG1399@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p2kqVDKq5asng8Dg" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , Kevin Oberman Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 18:36:53 -0000 --p2kqVDKq5asng8Dg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2012 at 10:45:35AM -0700, Marcel Moolenaar wrote: >=20 > On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote: > >=20 > > As for sharing disk with other OS. If you share the disk with OS that > > doesn't support gmirror, you shouldn't use gmirror in the first place. > > You probably want to use only formats that are recognized by all your > > OSes. >=20 > This statement is ridicuous by virtue of not being in touch with > reality and by making gmirror useless for such wide range of cases > that one can question why we have it at all. >=20 > Put differently: a mirroring class is a fairly basic and useful thing > to have. Limiting it's use is nothing but artificial and follows from > having to use the underlying provider to store metadata. This then > changes the view of the underlying providing to consumers above gmirror > in a way that makes the presence or absence of gmirror visible. > Solving the visibility problem makes gmirror useful all the time. > I see that as a better way of looking at it than simply blurting out > that you shouldn't use gmirror when certain awkward and artifical > conditions apply. I'm sorry, Marcel, but what you describe here has nothing to do with reality. To be able to implement realiable mirroring you have to use on-disk metadata. There is no way around that. You can implement non-redundant GEOM classes without using on-disk metadata, but out-of-band configuration in case of mirroring is simply naive. How do you detect that components are out of sync, for example? And when it comes to visablity. Are you suggesting that gmirror should present entire underlying provider to upper layers? Including its metadata? I hope not, because we went through that hell already (remember skipping first 16 sectors by UFS, as BSDlabel metadata might be there? The same for swap?). I think I did pretty good job by making the metadata as simple as possible - I use exactly one sector at the end of the target device. I'm really having a hard time to think of a simpler format. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --p2kqVDKq5asng8Dg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/rUkYACgkQForvXbEpPzQMtgCZAREkUfa4bpLIFZc7sfKY87Vu 6hcAoLp8W6xgJg6eViZG1ZU3RXsvEgrC =ZREU -----END PGP SIGNATURE----- --p2kqVDKq5asng8Dg-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 19:05:33 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A3891065670; Wed, 27 Jun 2012 19:05:33 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id E72D98FC25; Wed, 27 Jun 2012 19:05:32 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RJ5RUp012065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 12:05:31 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120627183446.GC1401@garage.freebsd.pl> Date: Wed, 27 Jun 2012 12:05:22 -0700 Content-Transfer-Encoding: 7bit Message-Id: <05236C69-0029-4FB1-ADFA-243D64AA3079@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl> <20120626214330.GG1399@garage.freebsd.pl> <20120627183446.GC1401@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) Cc: freebsd-current , freebsd-hackers , "Andrey V. Elsukov" , Andriy Gapon , Kevin Oberman Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:05:33 -0000 On Jun 27, 2012, at 11:34 AM, Pawel Jakub Dawidek wrote: > > I'm sorry, Marcel, but what you describe here has nothing to do with > reality. To be able to implement realiable mirroring you have to use > on-disk metadata. There is no way around that. You can implement > non-redundant GEOM classes without using on-disk metadata, but > out-of-band configuration in case of mirroring is simply naive. How do > you detect that components are out of sync, for example? GEOM configuration and per-class runtime state are not to be treated the same. Out-of-band configuration is trivial. Per-class runtime state, like whether elements in a mirrored configuration are in sync or not is more difficult, but does not a priori require on-disk metadata as it's implemented now. You can have the configuration tell the GEOM where that state is being kept, so that you can put it in a partition on the disks involved, or even keep it independent from the disks, which then requires disks to be uniquely identifiable, for sure. But that's what GPT gives you anyway. But even without identification, you can invert the question from "how do I detect that components are out of sync" to "how do I prove they are in fact in sync". That question has a very simple O(n) answer. So, if time isn't a concern or your storage is small, you can always scan all sectors as such prove that the disks are in sync. The point being: the current implementation isn't the only one. Granted, it can easily be the simplest one or even the best one in some cases, but that's besides the point you were making. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 19:08:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F9781065687; Wed, 27 Jun 2012 19:08:55 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from kazon.borderworlds.dk (kazon.borderworlds.dk [IPv6:2a01:4f8:101:4201::1:1]) by mx1.freebsd.org (Postfix) with ESMTP id 0076D8FC26; Wed, 27 Jun 2012 19:08:54 +0000 (UTC) Received: from talaxian.borderworlds.dk (localhost [127.0.0.1]) by kazon.borderworlds.dk (Postfix) with ESMTP id 4D7FA5C3B; Wed, 27 Jun 2012 21:08:45 +0200 (CEST) Message-ID: <4FEB5A3C.5050900@borderworlds.dk> Date: Wed, 27 Jun 2012 21:08:44 +0200 From: Christian Laursen Organization: The Border Worlds User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: John Baldwin References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> In-Reply-To: <201206271028.54477.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-current , freebsd-hackers , Andriy Gapon , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:08:55 -0000 On 06/27/12 16:28, John Baldwin wrote: > On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: > >> When we are in the FreeBSD, our loader can detect that device size >> is lower than it see and it will work. When primary header is OK, then >> other OSes should work with this GPT. When it isn't OK, you just can't >> load other OS :) > > Ah, yes. The solution to violating standards is to make sure you never > use standards-compliant software. That's a great argument. :) > > (Although not entirely uncommon. Standards aren't always perfect, but if > we had a way to not gratuitously violate them it would be nice to avoid > doing so.) To be standards compliant and allow whole-disk based mirroring to work at the same time wouldn't nested GPT work like this? Whole disk (start) | GPT header | GPT partition of type freebsd-geom (start) | | gmirror device (start) | | | GPT header | | | | freebsd-boot | | | | freebsd-ufs | | | | freebsd-swap | | | GPT backup header | | gmirror metadata | | gmirror device (end) | GPT partition of type freebsd-geom (end) | GPT backup header Whole disk (end) Nothing but FreeBSD would understand the freebsd-geom partition type, so the inner GPT device should be valid and standards compliant. The boot loader would of course need to understand this setup but that shouldn't be impossible. Just a thought. It might be too complicated compared to the non-standards compliant way it works now which works quite well in practice though. -- Christian Laursen From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 19:12:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E56371065679; Wed, 27 Jun 2012 19:12:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9960F8FC17; Wed, 27 Jun 2012 19:12:24 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:1c1d:425:65f1:4fac] (unknown [IPv6:2001:7b8:3a7:0:1c1d:425:65f1:4fac]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DD8035C59; Wed, 27 Jun 2012 21:12:17 +0200 (CEST) Message-ID: <4FEB5B0E.8020009@FreeBSD.org> Date: Wed, 27 Jun 2012 21:12:14 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120619 Thunderbird/14.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4FE9B01C.30306@yandex.ru> In-Reply-To: <4FE9B01C.30306@yandex.ru> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , Doug Rabson , freebsd-current , Pawel Jakub Dawidek , Andriy Gapon Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:12:25 -0000 On 2012-06-26 14:50, Andrey V. Elsukov wrote: > Some time ago i have started reading the code in the sys/boot. > Especially i'm interested in the partition tables handling. > I found several problems: > 1. There are several copies of the same code in the libi386/biosdisk.c > and common/disk.c, and partially libpc98/biosdisk.c. > 2. ZFS probing is very slow, because the ZFS code doesn't know how many > disks and partitions the system has: > http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 > http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 > 3. The GPT support doesn't check CRC and even doesn't know anything > about the secondary GPT header/table. > > So, i have created the branch and committed the changes: > http://svnweb.freebsd.org/base/user/ae/bootcode/ > The patch is here: > http://people.freebsd.org/~ae/boot.diff FWIW, I verified it compiles OK with clang, and especially boot2's size isn't increased at all. It would be nice if you could check it with clang now and again, before you finally merge this project into head. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 19:12:26 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B782106566B; Wed, 27 Jun 2012 19:12:26 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id D38688FC1E; Wed, 27 Jun 2012 19:12:25 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RJCLDo012105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 12:12:25 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120627182038.GB1401@garage.freebsd.pl> Date: Wed, 27 Jun 2012 12:12:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17E70D3D-1F05-4EF2-9E66-CDCA65329EF2@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <468988EA-AC50-451D-ACE1-17B58E0CAF67@xcllnt.net> <20120627182038.GB1401@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , John Baldwin , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:12:26 -0000 On Jun 27, 2012, at 11:20 AM, Pawel Jakub Dawidek wrote: > On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote: >>=20 >> On Jun 26, 2012, at 10:37 AM, John Baldwin wrote: >>>=20 >>> GPT really wants the backup header at the last LBA. I know you can = set it,=20 >>> but I've interpreted that as a way to see if the primary header is = correct or=20 >>> not. It seems to me that GPT tables created in this fashion (inside = a GEOM=20 >>> provider) will not work properly with partition editors for other = OS's. I'm=20 >>> hesitant to encourage the use of this as I do think putting GPT = inside of a=20 >>> gmirror violates the GPT spec. >>=20 >> Agreed. >=20 > Guys. This doesn't violate the GPT spec in any way. The spec is > narrow-minded if it talks only about raw disks, but you should think > about gmirror as pseudo-hardware RAID. I'm sorry, but this is a contradiction. If it doesn't violate the spec, then the spec is not narrow-minded on the grounds of what we're discussing. If the spec *is* narrow-minded then obviously it doesn't capture our scenario, which means that we're violating the spec. Clearly we're not discussing anything that falls well within the spec, or is undebatable. This makes the whole topic dangerous anyway. When you're in the grey area (this is only for argument's sake -- we're in violation for sure) you're opening yourself up to compatibility problems. Should we deliberately go there? --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 19:14:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9097106568A; Wed, 27 Jun 2012 19:14:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id BA2558FC14; Wed, 27 Jun 2012 19:14:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 07B8DB95D; Wed, 27 Jun 2012 15:14:17 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 27 Jun 2012 15:10:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <20120626214330.GG1399@garage.freebsd.pl> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206271510.39413.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 15:14:17 -0400 (EDT) Cc: freebsd-hackers , "Andrey V. Elsukov" , Pawel Jakub Dawidek , Andriy Gapon , Marcel Moolenaar Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:14:18 -0000 On Wednesday, June 27, 2012 1:45:35 pm Marcel Moolenaar wrote: > > On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote: > > > > As for sharing disk with other OS. If you share the disk with OS that > > doesn't support gmirror, you shouldn't use gmirror in the first place. > > You probably want to use only formats that are recognized by all your > > OSes. > > This statement is ridicuous by virtue of not being in touch with > reality and by making gmirror useless for such wide range of cases > that one can question why we have it at all. > > Put differently: a mirroring class is a fairly basic and useful thing > to have. Limiting it's use is nothing but artificial and follows from > having to use the underlying provider to store metadata. This then > changes the view of the underlying providing to consumers above gmirror > in a way that makes the presence or absence of gmirror visible. > Solving the visibility problem makes gmirror useful all the time. > I see that as a better way of looking at it than simply blurting out > that you shouldn't use gmirror when certain awkward and artifical > conditions apply. I'm not sure we can force gmirror to be anything except FreeBSD-specific, but it would be nice to not make non-standard GPT tables while we are at it. The reason the metadata for things like Intel's onboard SATA RAID does work ok is because the metadata format is enforced by the vendor, so it is reasonable to assume that metadata format will work across other OS's. Anyway, I've said my piece and will let the matter drop from my end at this point. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 19:15:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D9AC106567A; Wed, 27 Jun 2012 19:15:13 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id E338C8FC18; Wed, 27 Jun 2012 19:15:12 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RJF2Eo012116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 12:15:09 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <4FEB5A3C.5050900@borderworlds.dk> Date: Wed, 27 Jun 2012 12:14:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> To: Christian Laursen X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-current , freebsd-hackers , Andriy Gapon , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:15:13 -0000 On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote: > On 06/27/12 16:28, John Baldwin wrote: >> On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: >>=20 >>> When we are in the FreeBSD, our loader can detect that device size >>> is lower than it see and it will work. When primary header is OK, = then >>> other OSes should work with this GPT. When it isn't OK, you just = can't >>> load other OS :) >>=20 >> Ah, yes. The solution to violating standards is to make sure you = never >> use standards-compliant software. That's a great argument. :) >>=20 >> (Although not entirely uncommon. Standards aren't always perfect, = but if >> we had a way to not gratuitously violate them it would be nice to = avoid >> doing so.) >=20 > To be standards compliant and allow whole-disk based mirroring to work = at the same time wouldn't nested GPT work like this? GPTs don't nest. > Nothing but FreeBSD would understand the freebsd-geom partition type, = so the inner GPT device should be valid and standards compliant. If it were standards compliant, it would be discoverable by non-FreeBSD. That clearly isn't the case -- hence it's not standards compliant. What for example if someone wanted to share the swap partition between Linux and FreeBSD? --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 19:27:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCBA41065670; Wed, 27 Jun 2012 19:27:43 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward6.mail.yandex.net (unknown [IPv6:2a02:6b8:0:202:22cf:30ff:fe6b:6ebc]) by mx1.freebsd.org (Postfix) with ESMTP id EF7938FC1D; Wed, 27 Jun 2012 19:27:42 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward6.mail.yandex.net (Yandex) with ESMTP id 6BC5B1122011; Wed, 27 Jun 2012 23:27:41 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340825261; bh=OkIspLjKNGyDaXq1y54PSoQ1RwCOJlaxTYj6xdEDex8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=WEM/gdYAgPrvfgtzz2Ut57kWXpxwvT3h575FAUMWCrqRDbUauQXUZ+OHE9I/w6HXt DkXqPjTwurTeBjIDz+L5vsZAAuNArZxOPxrlGjfhAGZTmbmEhOwqYEi39z9YSp6+GW ODlC+gKC61OQhxQHPCx83+6QmBNc0aprTkC5o4qw= Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id E141A1B604F8; Wed, 27 Jun 2012 23:27:40 +0400 (MSK) Received: from dynamic-178-141-5-132.kirov.comstar-r.ru (dynamic-178-141-5-132.kirov.comstar-r.ru [178.141.5.132]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ReOCrCvP-ReOStuZF; Wed, 27 Jun 2012 23:27:40 +0400 X-Yandex-Rcpt-Suid: marcel@xcllnt.net X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: marcel@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340825260; bh=OkIspLjKNGyDaXq1y54PSoQ1RwCOJlaxTYj6xdEDex8=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=eWuqWtCm5wixM4u9+w5Mht+fOE+tsyf0ejOwz+dW8gs9aNGc5piFB1qkicRFRxfcX hc4beO5f0yRROxtjbMaffb1yf33TEnBF7ep3B6vEWHGFydimWesxp4kvEu4qGGskNO VJYI9hHykSYemJzvLzQZh8waNbYVUj0ipqShUClI= Message-ID: <4FEB5EA1.7060903@yandex.ru> Date: Wed, 27 Jun 2012 23:27:29 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120406 Thunderbird/10.0.3 MIME-Version: 1.0 To: Marcel Moolenaar References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> In-Reply-To: <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig83CA4CDA895588EA348A5B70" Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:27:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig83CA4CDA895588EA348A5B70 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 27.06.2012 21:55, Marcel Moolenaar wrote: > You can't just re-interpret standards to match a context you know very = well > isn't applicable and consequently redefine what the word "device" means= =2E > You're on a slippery slope and while you may not see it as a problem, y= ou > do make it a problem for FreeBSD users. It's our users we should be kee= ping > in mind when we solve problems. >=20 >> If a user wants modify GPT in the disk editor from the another OS, >> he can do it, and it should work. The result depends only from the par= tition editor, >> it might overwrite the last sector and might don't. >=20 > Right. Another happy user that sees his/her FreeBSD installation destro= yed > or degraded (no mirroring, warning messages about corrupted GPT, etc) f= or > no apparent reason and without any kind of warning that what he/she is = doing > is potentially harmful... That's the spirit! Ok. Let's return back to my patches. They don't add any new methods to shoot in the foot. We are talking about the *FreeBSD loader*. This is the program that starts FreeBSD kernel. It doesn't start other OS. We already have many users who uses FreeBSD as a single system on the machine. Many of them use GPT inside of some GEOM provider. You can just read the lists, articles about installing FreeBSD, forums, etc. We already have these users and i hope they will use FreeBSD as before. So, why can't add a simple quirk to make theirs system a bit more reliable? As i understand there two parts where we haven't a consensus: 1. You are against from: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is "GEOM::" signature. It tries to read one previous sector and there is *valid* GPT header. It is valid, because it's CRC is valid, it's self_LBA is valid. For the *FreeBSD* users it is better to don't use this GPT and just complain "i'm sorry, can't boot". The other OSes can't, and we shouldn't. 2. You are against from having one fake PMBR entry by default in the /boot/pmbr image. Ok, I can propose several ways to resolve this: * remove from the loader's GPT probing code restriction to necessarily have PMBR partition record in the MBR; * teach the boot0cfg command properly write the PMBR; * add new condition to mark GPT as corrupt when it has invalid PMBR. Thus, when you write PMBR with empty partition table with dd(1), the kernel will complain and you will be forced to run `gpart recover`. --=20 WBR, Andrey V. Elsukov --------------enig83CA4CDA895588EA348A5B70 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJP616pAAoJEAHF6gQQyKF6+e4H/iJa1VBeTVo2y5XMs0n4jwSZ ESorJVjkq+erib5v25ww5YHD4B2302wYaSJUu4dSHtWvAv9WRbMz917GPnYegc8T PNGPOuVFUqBYcdlBbJFoPg+yZG+OdkLzjLrcQk3GCOpapBxTD5FNhGaWzwtZUhJ2 yD0wnmS1qwJKObiJxWQOgC9NoJJT06b033ss+aj8qERbE0Sh7jijDycG4rNDYI71 b5LbBXqU+YrmJRrWz4x9i1kKBe/O6XVgeNEW/wmhz7XuWQiCnJ7jiUknrsxYofP/ 7ybGIgZaQn+ZhC0AFkdiqxF5RW/sYsB+CIeOoGtZnG8zclgkdUJNsgv9L+BCdBs= =r5NN -----END PGP SIGNATURE----- --------------enig83CA4CDA895588EA348A5B70-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 20:03:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA3241065672 for ; Wed, 27 Jun 2012 20:03:49 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 71E058FC12 for ; Wed, 27 Jun 2012 20:03:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=65WMy77W9X92VcWKzPzlhdwkeXq8VSSYNtkvreUPwZ0=; b=e6sCKEGzVJMNxyvfNl6pDTYDhH4lBNDhkU67243N4I+jdze/NRwNaz7NUM1Fd7fHHgS/yUJgQs0Ou2gLHr/bNCAQohWUQ6cOrK1AvM6FNGx8Ax90CFtMfMBlwqQhB6ma; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjySq-000I5a-5i for freebsd-hackers@freebsd.org; Wed, 27 Jun 2012 15:03:48 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1340827422-94480-94479/5/69; Wed, 27 Jun 2012 20:03:42 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> Date: Wed, 27 Jun 2012 15:03:41 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <201206261337.11741.jhb@freebsd.org> User-Agent: Opera Mail/12.00 (FreeBSD) X-SA-Score: -1.5 Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:03:49 -0000 On Tue, 26 Jun 2012 12:37:11 -0500, John Baldwin wrote: > I'm > hesitant to encourage the use of this as I do think putting GPT inside > of a > gmirror violates the GPT spec. I personally think this use case is a bit ... odd, anyway. I have only request to those that manage GPT/GEOM/etc -- as I'm used to doing multiple mdadm RAID components on Linux for maximum flexibility, using gmirror upon multiple GPT partitions upon the same physical device is OK with me. My only complaint is that recovery is very, very stupid. We should by default detect and only rebuild ONE gmirror device at a time on the same physical provider. You get nothing but a smokin' angry head if you allow multiple to rebuild at the same time because it's fighting over sequential writes all the way across the platters. It would also be nice if gmirror rebuild could also be detected by fsck and fsck could either hold off or gmirror could be paused until a consistent filesystem state exists. It's probably best for the background fsck to go first so you can get the system up and running, but then when it's finished gmirror should continue. Otherwise I have no issues with gmirror -- it does exactly the job I need it to. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 20:14:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC3DB1065673; Wed, 27 Jun 2012 20:14:24 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 990018FC0A; Wed, 27 Jun 2012 20:14:24 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RKEDrR012391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 13:14:20 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=koi8-r From: Marcel Moolenaar In-Reply-To: <4FEB5EA1.7060903@yandex.ru> Date: Wed, 27 Jun 2012 13:14:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:14:24 -0000 On Jun 27, 2012, at 12:27 PM, Andrey V. Elsukov wrote: > On 27.06.2012 21:55, Marcel Moolenaar wrote: >> You can't just re-interpret standards to match a context you know = very well >> isn't applicable and consequently redefine what the word "device" = means. >> You're on a slippery slope and while you may not see it as a problem, = you >> do make it a problem for FreeBSD users. It's our users we should be = keeping >> in mind when we solve problems. >>=20 >>> If a user wants modify GPT in the disk editor from the another OS, >>> he can do it, and it should work. The result depends only from the = partition editor, >>> it might overwrite the last sector and might don't. >>=20 >> Right. Another happy user that sees his/her FreeBSD installation = destroyed >> or degraded (no mirroring, warning messages about corrupted GPT, etc) = for >> no apparent reason and without any kind of warning that what he/she = is doing >> is potentially harmful... That's the spirit! >=20 > Ok. Let's return back to my patches. They don't add any new methods to > shoot in the foot. We are talking about the *FreeBSD loader*. > This is the program that starts FreeBSD kernel. It doesn't start other > OS. We already have many users who uses FreeBSD as a single system on > the machine. Many of them use GPT inside of some GEOM provider. Your patches are a continuation on a path that we're discussing isn't necessarily the path we should be on. While you don't make things worse from a compliance perspective, you make it worse by adding the non-compliant behaviour to more components. > As i understand there two parts where we haven't a consensus: >=20 > 1. You are against from: > Our loader detects that primary GPT header is damaged. It tries to = read > backup GPT header from the last LBA and it detects that there is > "GEOM::" signature. It tries to read one previous sector and there is > *valid* GPT header. How do you know it's valid? It's in a location that is not valid to begin with. Validity is based on rules and you're violating the the rules without defining exactly what we call valid given the new rules. This may seem nitpicking, but having went through the hassle of dealing with the broken way we created the dangerously dedicated disk, I appreciate the importance of being anal when it comes to something that lives on non-volatile storage and gets to be exposed to a world much larger than FreeBSD. > 2. You are against from having one fake PMBR entry by default in the > /boot/pmbr image. I don't understand what you're saying or what I'm being accused to be against. --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 20:48:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4854E1065674; Wed, 27 Jun 2012 20:48:08 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward19.mail.yandex.net (forward19.mail.yandex.net [IPv6:2a02:6b8:0:1402::4]) by mx1.freebsd.org (Postfix) with ESMTP id A02588FC0A; Wed, 27 Jun 2012 20:48:07 +0000 (UTC) Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward19.mail.yandex.net (Yandex) with ESMTP id D87DC11215B9; Thu, 28 Jun 2012 00:48:05 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340830086; bh=fpN5xy35M4eeleaFZ3TpM92u3EFVrXqcUDZiQR1AXz4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WLNhS25Kcw1+BJgM1x0EAYojavokukfK/wSGYeBCX38POdmElVRKJi69ZVz6+Sowh u4rB2zW9ScCq2J14+Wc4AsPSct/D0khNTqXnlLAldIl/oKdHHFIlkx4bGUI5XZxw/V 8uLAqjzR+xZsvdzZSqvEZs0PNgXSS93GHVhinKTo= Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id 5AD0918A019A; Thu, 28 Jun 2012 00:48:05 +0400 (MSK) Received: from dynamic-178-141-5-132.kirov.comstar-r.ru (dynamic-178-141-5-132.kirov.comstar-r.ru [178.141.5.132]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTP id m4V0IY66-m4Vab2EW; Thu, 28 Jun 2012 00:48:05 +0400 X-Yandex-Rcpt-Suid: marcel@xcllnt.net X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: marcel@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340830085; bh=fpN5xy35M4eeleaFZ3TpM92u3EFVrXqcUDZiQR1AXz4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=XxoeMQsw7zjOrNVK3xpMoLXmojQOK64dz55HMu4ynyurBFZ6+3oMv/DOPP4DnpvNK IDu7/5IHEQkAXvkmg87GfK/hjc4UX6n+4MLfws+XQMQTMu76CpnT/zoVsWXJ/ZyVQb fT9XcnMKFzfKhvLFKMrPqF9Dlzz3TiXb2ZiMjjlc= Message-ID: <4FEB7181.9000508@yandex.ru> Date: Thu, 28 Jun 2012 00:48:01 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120406 Thunderbird/10.0.3 MIME-Version: 1.0 To: Marcel Moolenaar References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:48:08 -0000 On 28.06.2012 00:14, Marcel Moolenaar wrote: >> Our loader detects that primary GPT header is damaged. It tries to read >> backup GPT header from the last LBA and it detects that there is >> "GEOM::" signature. It tries to read one previous sector and there is >> *valid* GPT header. > > How do you know it's valid? It's in a location that is not valid > to begin with. Validity is based on rules and you're violating the > the rules without defining exactly what we call valid given the > new rules. This may seem nitpicking, but having went through the > hassle of dealing with the broken way we created the dangerously > dedicated disk, I appreciate the importance of being anal when it > comes to something that lives on non-volatile storage and gets to > be exposed to a world much larger than FreeBSD. So why do you not prevent to attach GEOM_PART_GPT to any providers that are not the disk drive? This will be the right solution to all our problems. Just don't create invalid GPT. -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 21:12:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 396291065672; Wed, 27 Jun 2012 21:12:02 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 06BE38FC0C; Wed, 27 Jun 2012 21:12:02 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RLBqNW012645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 14:11:58 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=koi8-r From: Marcel Moolenaar In-Reply-To: <4FEB7181.9000508@yandex.ru> Date: Wed, 27 Jun 2012 14:11:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: <658E457B-3107-4BE8-A8EE-4F97D021843E@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> <4FEB7181.9000508@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 21:12:02 -0000 On Jun 27, 2012, at 1:48 PM, Andrey V. Elsukov wrote: > On 28.06.2012 00:14, Marcel Moolenaar wrote: >>> Our loader detects that primary GPT header is damaged. It tries to read >>> backup GPT header from the last LBA and it detects that there is >>> "GEOM::" signature. It tries to read one previous sector and there is >>> *valid* GPT header. >> >> How do you know it's valid? It's in a location that is not valid >> to begin with. Validity is based on rules and you're violating the >> the rules without defining exactly what we call valid given the >> new rules. This may seem nitpicking, but having went through the >> hassle of dealing with the broken way we created the dangerously >> dedicated disk, I appreciate the importance of being anal when it >> comes to something that lives on non-volatile storage and gets to >> be exposed to a world much larger than FreeBSD. > > So why do you not prevent to attach GEOM_PART_GPT to any providers that > are not the disk drive? This will be the right solution to all our > problems. Just don't create invalid GPT. It's not even the right solution, as it prevents legit nesting of gpart GEOMs *and* is fundamentally based on a flawed assumption that any non-disk GEOM underneath gpart yields an invalid GPT. Think gnop. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 21:55:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2C3C1065688 for ; Wed, 27 Jun 2012 21:55:32 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 1690A8FC1C for ; Wed, 27 Jun 2012 21:55:31 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5RLtLhJ003818 for ; Wed, 27 Jun 2012 23:55:21 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5RLtLAS003815 for ; Wed, 27 Jun 2012 23:55:21 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 27 Jun 2012 23:55:20 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 27 Jun 2012 23:55:21 +0200 (CEST) Subject: "magic" crashes - mostly solved but X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 21:55:33 -0000 the reason was most probably of of date vbox and fuse kernel modules. after making everything in sync system boots successfully with WITNESS, INVARIANT etc. options enabled. STILL - mostly at booting i'm getting few messages. first comes when executing /etc/rc.d/named (at mounting devfs IMHO): Jun 27 18:32:23 foo kernel: lock order reversal: Jun 27 18:32:23 foo kernel: 1st 0xffffff80f5859800 bufwait (bufwait) @/usr/src/sys/kern/vfs_bio.c:2636 Jun 27 18:32:24 foo kernel: Jun 27 18:32:24 foo kernel: 2nd 0xffffff0005c82200 dirhash (dirhash) @/usr/src/sys/ufs/ufs/ufs_dirhash.c:285 Jun 27 18:32:24 foo kernel: KDB: stack backtrace: Jun 27 18:32:24 foo kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x27 Jun 27 18:32:24 foo kernel: em0: link state changed to UP Jun 27 18:32:24 foo kernel: kdb_backtrace() at kdb_backtrace+0x3e Jun 27 18:32:24 foo kernel: _witness_debugger() at _witness_debugger+0x24 Jun 27 18:32:24 foo kernel: witness_checkorder() at witness_checkorder+0xae7 Jun 27 18:32:24 foo kernel: _sx_xlock() at _sx_xlock+0xbf Jun 27 18:32:24 foo kernel: ufsdirhash_acquire() at ufsdirhash_acquire+0x4f Jun 27 18:32:24 foo kernel: ufsdirhash_remove() at ufsdirhash_remove+0x1c Jun 27 18:32:24 foo kernel: ufs_dirremove() at ufs_dirremove+0x12c Jun 27 18:32:24 foo kernel: ufs_remove() at ufs_remove+0x8f Jun 27 18:32:24 foo kernel: VOP_REMOVE_APV() at VOP_REMOVE_APV+0xf4 Jun 27 18:32:24 foo kernel: VOP_REMOVE() at VOP_REMOVE+0x45 Jun 27 18:32:24 foo kernel: kern_unlinkat() at kern_unlinkat+0x1ce Jun 27 18:32:24 foo kernel: kern_unlink() at kern_unlink+0x28 Jun 27 18:32:24 foo kernel: unlink() at unlink+0x25 Jun 27 18:32:24 foo kernel: syscallenter() at syscallenter+0x2e3 Jun 27 18:32:24 foo kernel: amd64_syscall() at amd64_syscall+0x58 Jun 27 18:32:24 foo kernel: Jun 27 18:32:24 foo kernel: Xfast_syscall() at Xfast_syscall+0xfc Jun 27 18:32:24 foo kernel: --- syscall (10, FreeBSD ELF64, unlink), rip = 0xeede070c, rsp = 0x7fffffffdb08, rbp = 0x7fffffffef58 --- Jun 27 18:32:24 foo kernel: lock order reversal: Jun 27 18:32:24 foo kernel: 1st 0xffffff00080a8270 ufs (ufs) @/usr/src/sys/kern/vfs_mount.c:1081 Jun 27 18:32:24 foo kernel: 2nd 0xffffff00085397f8 devfs (devfs) @/ /usr/src/sys/kern/vfs_subr.c:2169 Jun 27 18:32:24 foo kernel: KDB: stack backtrace: Jun 27 18:32:24 foo kernel: db_trace_self_wrapper() atdb_trace_self_wrapper+0x27 Jun 27 18:32:24 foo kernel: kdb_backtrace() at kdb_backtrace+0x3e Jun 27 18:32:24 foo kernel: _witness_debugger() at _witness_debugger+0x24 Jun 27 18:32:24 foo kernel: witness_checkorder() atwitness_checkorder+0xae7 Jun 27 18:32:24 foo kernel: __lockmgr_args() at __lockmgr_args+0x68d Jun 27 18:32:24 foo kernel: _lockmgr_args() at _lockmgr_args+0x6f Jun 27 18:32:24 foo kernel: vop_stdlock() at vop_stdlock+0x67 Jun 27 18:32:24 foo kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfd Jun 27 18:32:24 foo kernel: VOP_LOCK1() at VOP_LOCK1+0x4b Jun 27 18:32:24 foo kernel: _vn_lock() at _vn_lock+0x64 Jun 27 18:32:24 foo kernel: vget() at vget+0xe9 Jun 27 18:32:24 foo kernel: devfs_allocv() at devfs_allocv+0x125 Jun 27 18:32:24 foo kernel: devfs_root() at devfs_root+0x5a Jun 27 18:32:24 foo kernel: vfs_domount() at vfs_domount+0xcdb Jun 27 18:32:24 foo kernel: vfs_donmount() at vfs_donmount+0x78e Jun 27 18:32:24 foo kernel: nmount() at nmount+0x7e Jun 27 18:32:24 foo kernel: syscallenter() at syscallenter+0x2e3 Jun 27 18:32:24 foo kernel: amd64_syscall() at amd64_syscall+0x58 Jun 27 18:32:24 foo kernel: Xfast_syscall() at Xfast_syscall+0xfc Jun 27 18:32:24 foo kernel: --- syscall (378, FreeBSD ELF64, nmount), rip= 0xeee6535c, rsp = 0x7fffffffdd18, rbp = 0xef206048 --- Jun 27 18:32:24 foo named[1071]: starting BIND 9.6.-ESV-R7-P1 -t/var/named -u bind Jun 27 18:32:24 foo kernel: Starting named. few more when mounting or unmounting (i'm not sure) pendrive. Jun 27 18:57:09 foo kernel: lock order reversal: Jun 27 18:57:09 foo kernel: 1st 0xffffff011ec78098 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:504 Jun 27 18:57:09 foo kernel: 2nd 0xffffff80f5e1bb80 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6193 Jun 27 18:57:09 foo kernel: 3rd 0xffffff011ead3d80 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2169 Jun 27 18:57:09 foo kernel: KDB: stack backtrace: Jun 27 18:57:09 foo kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x27 Jun 27 18:57:09 foo kernel: kdb_backtrace() at kdb_backtrace+0x3e Jun 27 18:57:09 foo kernel: _witness_debugger() at _witness_debugger+0x24 Jun 27 18:57:09 foo kernel: witness_checkorder() at witness_checkorder+0xae7 Jun 27 18:57:09 foo kernel: __lockmgr_args() at __lockmgr_args+0x68d Jun 27 18:57:09 foo kernel: _lockmgr_args() at _lockmgr_args+0x6f Jun 27 18:57:09 foo kernel: ffs_lock() at ffs_lock+0xaa Jun 27 18:57:09 foo kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfd Jun 27 18:57:09 foo kernel: VOP_LOCK1() at VOP_LOCK1+0x4b Jun 27 18:57:09 foo kernel: _vn_lock() at _vn_lock+0x64 Jun 27 18:57:09 foo kernel: vget() at vget+0xe9 Jun 27 18:57:09 foo kernel: vfs_hash_get() at vfs_hash_get+0xe6 Jun 27 18:57:09 foo kernel: ffs_vgetf() at ffs_vgetf+0x4a Jun 27 18:57:09 foo kernel: flush_pagedep_deps() at flush_pagedep_deps+0x12a Jun 27 18:57:09 foo kernel: softdep_sync_metadata() at softdep_sync_metadata+0x474 Jun 27 18:57:09 foo kernel: ffs_syncvnode() at ffs_syncvnode+0x447 Jun 27 18:57:09 foo kernel: ffs_truncate() at ffs_truncate+0x786 Jun 27 18:57:09 foo kernel: ufs_direnter() at ufs_direnter+0xb1f Jun 27 18:57:09 foo kernel: ufs_mkdir() at ufs_mkdir+0x8d8 Jun 27 18:57:09 foo kernel: VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf4 Jun 27 18:57:09 foo kernel: VOP_MKDIR() at VOP_MKDIR+0x51 Jun 27 18:57:09 foo kernel: kern_mkdirat() at kern_mkdirat+0x232 Jun 27 18:57:09 foo kernel: kern_mkdir() at kern_mkdir+0x31 Jun 27 18:57:09 foo kernel: mkdir() at mkdir+0x20 Jun 27 18:57:09 foo kernel: syscallenter() at syscallenter+0x2e3 Jun 27 18:57:09 foo kernel: amd64_syscall() at amd64_syscall+0x58 Jun 27 18:57:09 foo kernel: Xfast_syscall() at Xfast_syscall+0xfc Jun 27 18:57:09 foo kernel: --- syscall (136, FreeBSD ELF64, mkdir), rip = 0xeede1dfc, rsp = 0x7fffffffe998, rbp = 0x7fffffffed16 --- any idea what is it? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 21:39:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3FFC106564A; Wed, 27 Jun 2012 21:39:08 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 96E688FC0C; Wed, 27 Jun 2012 21:39:08 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id CF3503B080; Wed, 27 Jun 2012 21:39:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q5RLd0tL060048; Wed, 27 Jun 2012 21:39:01 GMT (envelope-from phk@phk.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 27 Jun 2012 14:11:46 MST." <658E457B-3107-4BE8-A8EE-4F97D021843E@xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 27 Jun 2012 21:39:00 +0000 Message-ID: <60047.1340833140@critter.freebsd.dk> X-Mailman-Approved-At: Wed, 27 Jun 2012 22:20:15 +0000 Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-current , freebsd-hackers , Andriy Gapon , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 21:39:09 -0000 I would like to point out that all other operating system which has had this precise problem, have solved it by adding a bootfs partition to hold the kernel+modules required to truly understand the disk-layout ? -- 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-hackers@FreeBSD.ORG Wed Jun 27 22:20:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1316C1065786 for ; Wed, 27 Jun 2012 22:20:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id E79468FC0C for ; Wed, 27 Jun 2012 22:20:24 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta02.emeryville.ca.mail.comcast.net with comcast id TaCX1j00A1eYJf8A2aKJT7; Wed, 27 Jun 2012 22:19:18 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta19.emeryville.ca.mail.comcast.net with comcast id TaKH1j00U4NgCEG01aKJUi; Wed, 27 Jun 2012 22:19:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q5RMJFVt047644; Wed, 27 Jun 2012 16:19:15 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Varuna In-Reply-To: <4FE1853C.2090002@eudaemonicsystems.net> References: <4FDB25E0.2070705@eudaemonicsystems.net> <4FDB3BAA.6090906@fluffy.khv.ru> <4FDB71B9.9070804@eudaemonicsystems.net> <1339784344.73426.40.camel@revolution.hippie.lan> <4FE1853C.2090002@eudaemonicsystems.net> Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Jun 2012 16:19:15 -0600 Message-ID: <1340835555.1110.33.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: /etc/resolv.conf getting over written with dhcp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 22:20:25 -0000 On Wed, 2012-06-20 at 13:39 +0530, Varuna wrote: > Ian Lepore wrote: > > > > Using the 'prepend' or 'supercede' keywords in /etc/dhclient.conf is > > pretty much the standard way of handling a mix of static and dhcp > > interfaces where the static config needs to take precedence. I'm not > > sure why you dismiss it as essentially good, but somehow not good > > enough. It's been working for me for years. > > > > -- Ian > > > The issue that I had indicated that the issue with the /etc/resolv.conf is being > caused by an error in /sbin/dhclient-script; hence, I am definitely not looking > at solving the issue either with /etc/dhclient.conf or /etc/dhclient-exit-hooks > configuration file. > > BTW, resolver(5) / resolv.conf(5) does not mention the usage of > /etc/dhclient-exit-hooks file to protect the earlier contents of > /etc/resolv.conf file. Will put this issue in the freebsd-doc mailing list. > > With regards, > Varuna > Eudaemonic Systems > Simple, Specific & Insightful I have re-read your original message and I think the confusion is here: > 2*** # When resolv.conf is not changed actually, we don't > # need to update it. > # If /usr is not mounted yet, we cannot use cmp, then > # the following test fails. In such case, we simply > # ignore an error and do update resolv.conf. > 3*** if cmp -s $tmpres /etc/resolv.conf; then > rm -f $tmpres > return 0 > fi 2>/dev/null > [...] > I guess, the 1***, 3*** and 4*** is causing the recreation of /etc/resolv.conf. > Is this correct? I did a small modification to 3*** which is: > if !(cmp -s $tmpres /etc/resolv.conf); then > rm -f $tmpres > return 0 > fi 2>/dev/null > This seems to have solved the issue of /etc/resolv.conf getting overwritten with > just: nameserver 192.168.98.4. This ensures that: If there is a difference > between $tmpres and /etc/resolv.conf, then it exits post removal of $tmpres. If > the execution of 3*** returns a 0, a new file gets created. I guess the > modification get the intent of 3*** working. > > Have I barked up the wrong tree? I think yes, you have barked up the wrong tree. The intent of the code at 3*** is not to exit if there is a difference, it is to exit if there is NO difference. In other words, if the old and new files are identical then there is no need to re-write the file, just cleanup and exit. If the files are different then replace the existing file with the new one. This is just the (sometimes annoying) way dhcp works. If the dhcp server provides new resolver info it completely replaces any existing resolver info unless you've configured your dhclient.conf to prevent it. It only does so if the interface being configured is the current default-route interface, or there is no current default-route interface. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 01:35:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D93D2106566B for ; Thu, 28 Jun 2012 01:35:31 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 94D9A8FC0C for ; Thu, 28 Jun 2012 01:35:31 +0000 (UTC) Received: (qmail 3285 invoked by uid 0); 28 Jun 2012 01:35:24 -0000 Received: from 67.206.183.61 by rms-us006.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Wed, 27 Jun 2012 21:35:20 -0400 From: "Dieter BSD" Message-ID: <20120628013522.298400@gmx.com> MIME-Version: 1.0 To: To: freebsd-hackers@freebsd.org,freebsd-geom@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: jdGZb/QV3zOlNR3dAHAhI35+IGRvb4DV Cc: Subject: Re: Freeze when running freebsd-update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 01:35:32 -0000 >>>> Robert writes: >>>>> 3) the box is responsive to hitting enter at the console (it produces >>>>> another login: prompt) >>>> >>>> Getty is in memory and can run. >>>> >>>>> 5) if I try to login to the console, it lets me enter a username then >>>>> locks up totally, it does not present me with a password: prompt. >>>> >>>> Login(1) is not in memory, and the kernel cannot read it from disk >>>> for some reason. >>>> >>>> I can get this symptom by writing a large file to a disk on a >>>> controller that FreeBSD doesn't support NCQ on. I assume there >>>> is a logjam in the buffer cache. Something trivial like reading >>>> login in from disk that would normally happen in well under a >>>> second can take many minutes. >>>> >>>> Perhaps geli is causing a similar logjam? Does it hang forever or >>>> is it just obscenely slow? If it truely hangs forever it is >>>> probably something else. Is there disk activity after it hangs? >>>> Can you try it without geli? systat -vmstat might provide a clue. >>> >>> Well, it is geli. I'm unable to reproduce the freeze on the same >>> exact system with everything else the same except for no geli. I'm >>> going to move this thread over to geom, and continue it there. Thanks >>> for your help! >> >> It occurs to me that it will need twice as much memory for disk i/o. >> 1 buffer for encrypted and 1 for unencrypted. I know nothing about geli, >> so I don't know if it uses the buffer cache for both, or what. >> Could it be that the kernel isn't keeping enough memory free and >> manages to paint itself into a corner and not have space to store >> the unencrypted version of disk reads, and can't page/swap anything >> out to make space because it doesn't have space to store the encrypted >> version to write? > > I think that's probably about what is happening. I'm still waiting > for an answer on the geom mailing list, but I will do some testing > with increasing memory sizes and see where the problem stops > occurring. Some of the vfs.*buf sysctls might be useful? From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 03:04:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 714251065672 for ; Thu, 28 Jun 2012 03:04:23 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3588FC08 for ; Thu, 28 Jun 2012 03:04:22 +0000 (UTC) X-AuditID: 1209190e-b7fb56d0000008b2-c3-4febc9b46970 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 9F.C2.02226.4B9CBEF4; Wed, 27 Jun 2012 23:04:20 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q5S34JX2029827; Wed, 27 Jun 2012 23:04:20 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q5S34H6w020425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jun 2012 23:04:19 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id q5S34HMH029497; Wed, 27 Jun 2012 23:04:17 -0400 (EDT) Date: Wed, 27 Jun 2012 23:04:17 -0400 (EDT) From: Benjamin Kaduk To: Wojciech Puchar In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrLvl5Gt/g5k3VSy2b/7HaDFp13s2 ByaPGZ/ms3g8uBkWwBTFZZOSmpNZllqkb5fAlXHv+z/Wgp2cFb3zNjI2ML5l72Lk5JAQMJFY uW07I4QtJnHh3nq2LkYuDiGBfYwS85bsYIJwNjBKnOt+BJU5wCTR+e0ZO4TTwCjx4N18sFks AtoSN3bfAZvFJqAiMfPNRqAODg4RoB09B6NBwswC8hIXNh8CKxEWMJC4sXk7E4jNKeApsf3T dLAxvAKOEvum97GC2EICHhLLtr5iAbFFBXQkVu+fwgJRIyhxcuYTFoiZlhLn/lxnm8AoOAtJ ahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6xnq5mSV6qSmlmxjBgSrJt4Px60GlQ4wC HIxKPLyn3F/7C7EmlhVX5h5ilORgUhLlZT0GFOJLyk+pzEgszogvKs1JLT7EKMHBrCTC+z0O KMebklhZlVqUD5OS5mBREue9knLTX0ggPbEkNTs1tSC1CCYrw8GhJMErAoxIIcGi1PTUirTM nBKENBMHJ8hwHqDhK06ADC8uSMwtzkyHyJ9iVJQS530HkhAASWSU5sH1whLJK0ZxoFeEeb+A VPEAkxBc9yugwUxAg50CwAaXJCKkpBoYl/UcEj7xIPzJy92WX/xOt/6qf2/r8LT/UK7DR/eC bjmnyozlok+tU4Kl3aP9Km7Yfgr9KdC+MWJvet/DGba+l18tsq9dub4n4O5dPuZj2zt1j1eu evfto1hP9oePBSaBPg2X1G1Cny90XhBpkrimNGfhrb63PWtSFfTnOMvFzFJ6ynxGNtNEiaU4 I9FQi7moOBEAKrZKDv8CAAA= Cc: freebsd-hackers@freebsd.org Subject: Re: "magic" crashes - mostly solved but X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 03:04:23 -0000 On Wed, 27 Jun 2012, Wojciech Puchar wrote: > the reason was most probably of of date vbox and fuse kernel modules. > > after making everything in sync system boots successfully with WITNESS, > INVARIANT etc. options enabled. > > STILL - mostly at booting i'm getting few messages. > > first comes when executing /etc/rc.d/named (at mounting devfs IMHO): > > Jun 27 18:32:23 foo kernel: lock order reversal: > Jun 27 18:32:23 foo kernel: 1st 0xffffff80f5859800 bufwait (bufwait) > @/usr/src/sys/kern/vfs_bio.c:2636 > Jun 27 18:32:24 foo kernel: Jun 27 18:32:24 foo kernel: 2nd > 0xffffff0005c82200 dirhash (dirhash) @/usr/src/sys/ufs/ufs/ufs_dirhash.c:285 http://ipv4.sources.zabbadoz.net/freebsd/lor/261.html > > > few more when mounting or unmounting (i'm not sure) pendrive. > > Jun 27 18:57:09 foo kernel: lock order reversal: > Jun 27 18:57:09 foo kernel: 1st 0xffffff011ec78098 ufs (ufs) @ > /usr/src/sys/kern/vfs_lookup.c:504 > Jun 27 18:57:09 foo kernel: 2nd 0xffffff80f5e1bb80 bufwait (bufwait) @ > /usr/src/sys/ufs/ffs/ffs_softdep.c:6193 > Jun 27 18:57:09 foo kernel: 3rd 0xffffff011ead3d80 ufs (ufs) @ http://ipv4.sources.zabbadoz.net/freebsd/lor/285.html From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 08:36:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05B87106566C for ; Thu, 28 Jun 2012 08:36:09 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 526128FC0C for ; Thu, 28 Jun 2012 08:36:07 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5S8a2hC001987; Thu, 28 Jun 2012 10:36:02 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5S8a1KL001984; Thu, 28 Jun 2012 10:36:01 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 28 Jun 2012 10:36:01 +0200 (CEST) From: Wojciech Puchar To: Benjamin Kaduk In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 28 Jun 2012 10:36:02 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: "magic" crashes - mostly solved but X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 08:36:09 -0000 >> 0xffffff0005c82200 dirhash (dirhash) >> @/usr/src/sys/ufs/ufs/ufs_dirhash.c:285 > > > http://ipv4.sources.zabbadoz.net/freebsd/lor/261.html so - it's "fine". > >> >> >> few more when mounting or unmounting (i'm not sure) pendrive. >> >> Jun 27 18:57:09 foo kernel: lock order reversal: >> Jun 27 18:57:09 foo kernel: 1st 0xffffff011ec78098 ufs (ufs) @ >> /usr/src/sys/kern/vfs_lookup.c:504 >> Jun 27 18:57:09 foo kernel: 2nd 0xffffff80f5e1bb80 bufwait (bufwait) @ >> /usr/src/sys/ufs/ffs/ffs_softdep.c:6193 >> Jun 27 18:57:09 foo kernel: 3rd 0xffffff011ead3d80 ufs (ufs) @ > > http://ipv4.sources.zabbadoz.net/freebsd/lor/285.html > less "fine", yet as it only happens at mounting it is less risky. anyway i do 2 fuse mounts per day on that server (cron job). From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 09:23:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7EE401065678 for ; Thu, 28 Jun 2012 09:23:57 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm2-vm0.bullet.mail.ukl.yahoo.com (nm2-vm0.bullet.mail.ukl.yahoo.com [217.146.183.226]) by mx1.freebsd.org (Postfix) with SMTP id E95408FC14 for ; Thu, 28 Jun 2012 09:23:56 +0000 (UTC) Received: from [217.146.183.211] by nm2.bullet.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 09:23:49 -0000 Received: from [77.238.184.61] by tm4.bullet.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 09:23:49 -0000 Received: from [127.0.0.1] by smtp130.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 09:23:49 -0000 X-Yahoo-Newman-Id: 477533.38404.bm@smtp130.mail.ukl.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aj1_ABcVM1m_bKiy7nT6Mb_DPxf6oducw7_286ALLjHzzwu qweB9qDvd8URveHB3u028SpgZY8BTFwjnP2Q_2SAmgIeN9Rv3TSaRwpzYcKu jBqc2487vOvgQ3Shk0w_P2BjMbjDYbydycicWTv1Y4XZ3ZnFbFZUs9XfJKhd KX1etpFsfCU4fF1S0ygy8amqbhL62zEHVEQJg6GTGLXXhH5kXJRXtv4jD3qS uIFsntB68FpA8DCj_okZedZjBNuVr3cJyri0uiCplRuhdBRX8whgmWUp_6EC .Wi_xnmM90h8QS_.lkPnEzTDIcIhJ7K._62M.0.ud5h668qjXpK4ORxLA0FO gyN5mhCa06v3K_7Gml_MJ8zm7ZAH4CzHLc6V_PbMu8639GnSI0.pKehW74TY LgxozpK42wrkMmLX58Msm X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.17] (se@81.173.156.36 with plain) by smtp130.mail.ukl.yahoo.com with SMTP; 28 Jun 2012 09:23:44 +0000 GMT Message-ID: <4FEC22A0.9000109@freebsd.org> Date: Thu, 28 Jun 2012 11:23:44 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Marcel Moolenaar References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> In-Reply-To: <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 09:23:57 -0000 Am 27.06.2012 21:14, schrieb Marcel Moolenaar: > > On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote: > >> On 06/27/12 16:28, John Baldwin wrote: >>> On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: >>> >>>> When we are in the FreeBSD, our loader can detect that device size >>>> is lower than it see and it will work. When primary header is OK, then >>>> other OSes should work with this GPT. When it isn't OK, you just can't >>>> load other OS :) >>> >>> Ah, yes. The solution to violating standards is to make sure you never >>> use standards-compliant software. That's a great argument. :) >>> >>> (Although not entirely uncommon. Standards aren't always perfect, but if >>> we had a way to not gratuitously violate them it would be nice to avoid >>> doing so.) >> >> To be standards compliant and allow whole-disk based mirroring to work at the same time wouldn't nested GPT work like this? > > GPTs don't nest. It is not strictly necessary to use nested GPT to have GMIRROR et.al. and GPT co-exist. And I think this is possible without violation of any standard. Just modify GEOM classes that keep state at the end of a partition to leave some spare area *behind* the GEOM data. I.e.: MBR or Primary GTP header <> GMIRROR Configuration and State <> (Spare area for Sec. GPT header) If creating a GMIRROR (or other GEOM that keeps state at the end of the provider) left at least the last 32KByte untouched (33 GPT sectors rounded up to a power of 2), GPT could use this spare space to store its Secondary Header. These sectors could be treated as part of the User Data area, i.e. logical addresses would be translated by GMIRROR to skip the GMIRROR configuration sector (which I'd enlarge to at least 4KB for alignment of "User Data 2"). This implies that the GMIRROR specification covers the whole provider (including the spare space but without the sectors holding the GMIRROR config, which are "mapped out"), since updates to the Secondary GPT must be performed on all mirrored devices. This is a complication of the current GMIRROR code, but could be added without impact on existing disk layouts. (I have not checked, whether backwards compatibility mandates introduction of a new GMIRROR class that supports such spare space after the GMIRROR config data, but I assume that there is enough spare space pre-initialized to 0 that can be used to add a flag that declares the 32 KByte beyond the end of the config data to be part of the mirror.) The only modifications required are: - If a GMIRROR is created, place the configuration sector 32 KByte before the end of the provider and mark it as "GPT compatible". (It is unknown at this point, whether GPT is to be used on the mirror at a later time.) - Tasting a provider should support looking for a valid GMIRROR (or GRAID) config sector not only at the end of the provider, but if that fails then also 32 KByte before the end of the provider. The GMIRROR is considered to be the provider for the GPT (i.e. the GMIRROR extends to 32 KByte beyond its config sector). - Creating partitions with MBR or GPT within a GMIRROR is possible without modification. The only difference is that the protected GMIRROR configuration sector is physically within the range of sectors used for the partition, but logically mapped out. The space available for partitioning is the provider size minus the size of the GMIRROR configuration, just as it used to be. - Readind and writing the mirror is allowed for all sectors in the User Data area, as in a "normal" GMIRROR. The only difference is the test for logical sectors in the last 32 KByte, for which the request is modified to be offset by a few sectors to skip the GMIRROR configuration sector. Requests that cover physical sectors before and behind these GMIRROR config sectors must be split. If instead of splitting off the final 32 KByte as "User Data 2", just the 33 sectors (of 512 Byte) required for GPT were assigned to that area, then there would never be requests that extend beyond the GMIRROR config sectors on GPT partitioned disks. But since such request were still possible if MBR partitions were used, code to treat such requests was still required in GMIRROR. There is one caveat, though: Creating a GMIRROR and then using an OS that does not know about FreeBSD to partition the disk would result in the GMIRROR configuration space being ignored. Another problem could be, that the available space in the GPT is the size of the disk minus the GMIRROR configuration sectors, i.e. there is a difference between the number of physical sectors on the disk and the number of sectors to be assigned to partitions by GPT. >> Nothing but FreeBSD would understand the freebsd-geom partition >> type, so the inner GPT device should be valid and standards >> compliant. > > If it were standards compliant, it would be discoverable by non-FreeBSD. > That clearly isn't the case -- hence it's not standards compliant. What > for example if someone wanted to share the swap partition between Linux > and FreeBSD? My suggested modification to GMIRROR would be compatible with other operating systems use of partitions on such devices. They'd just see individual GPT partitioned disks. Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 10:10:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E97D1065688 for ; Thu, 28 Jun 2012 10:10:16 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm4.bullet.mail.ird.yahoo.com (nm4.bullet.mail.ird.yahoo.com [77.238.189.61]) by mx1.freebsd.org (Postfix) with SMTP id B74518FC17 for ; Thu, 28 Jun 2012 10:10:15 +0000 (UTC) Received: from [77.238.189.234] by nm4.bullet.mail.ird.yahoo.com with NNFMP; 28 Jun 2012 10:10:13 -0000 Received: from [217.146.188.173] by tm15.bullet.mail.ird.yahoo.com with NNFMP; 28 Jun 2012 10:10:13 -0000 Received: from [127.0.0.1] by smtp141.mail.ird.yahoo.com with NNFMP; 28 Jun 2012 10:10:13 -0000 X-Yahoo-Newman-Id: 327864.28753.bm@smtp141.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4VkEvKYVM1kOK6KImTgspsbRlNNbHUI2PaO5OfXrk9CgX8S ZJaazTcRTQIBdQI3qrFpiQfr.nPWAVz80EfdgTvW_dRRyyXpmFJ7_ErmNn84 SoJvut9yOOt.qHHZqcWKs4tEtCyj5.d_BDyJVjtHIC4iGVio1t.UmpHNKeMo 6bAu5JYW0BgFXdunqD7wAnrwGtAJGLdEUqKgSQl834YBjsOpRJLEE9744yfD ascRayIHSgFabgmGrqjfflWiuZUSPFHAO.Z6ry.7w._GP4O9vk8OLgdkuJgV zxH6kLmG8rGnjQRQYvM7DjHuyQWvQXocLCpJoJ3QffoLZyVE5Yc4Na03bXGJ eyU_A8lHw81sqUzzvHOJBNkIS5svfR3VCwJfkr8hn83PUmosPOp6V7LV6YQP 3_5fvFtUqtuCDhV0.3g5Ux6MUFzdR4Edk2k4koFE- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.17] (se@81.173.156.36 with plain) by smtp141.mail.ird.yahoo.com with SMTP; 28 Jun 2012 03:10:13 -0700 PDT Message-ID: <4FEC2D86.2040505@freebsd.org> Date: Thu, 28 Jun 2012 12:10:14 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Marcel Moolenaar References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> In-Reply-To: <4FEC22A0.9000109@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:10:16 -0000 Sorry for following up to self, but ... I just noticed somebody else suggesting the same method (put GMIRROR configuration below Secondary GPT header), but I think there is a problem: If GMIRROR is used to mirror whole GPT partitioned drives, then you want the GPT sectors to be considered part of the mirror (to keep them identical when GPT partitions are created/modified on the mirrored disks). But the GMIRROR configuration must not be assigned to any GPT partition. Therefore it must be protected, either by hiding it (e.g. create a special partition to hold GEOM config data, just to reserve the space within GPT, since the configuration data will still be located by looking at specific sectors of the provider), or by skipping the sectors assigned to GEOM config data in the GEOM provider that interprets them (e.g. GMIRROR). The former only works if a GMIRROR (or GELI or whatever) is created on a disk that already has GPT headers (since these lead to the GEOM config data put before the Secondary GPT header and allow the GEOM config to be marked as a special partition in that header). The latter only works on disks without GPT headers, since the size of the provider will be smaller then the physical disk. Even with the last physical disks available for GPT, the GPT headers will probably not conform to the standard, since remapping of the sectors to hide the GMIRROR config will lead to different logical sector numbers for the secondary GPT header when looked at with or without GMIRROR loaded. I still think it is possible to find a layout, that does not violate the GPT standard (use last LBAs on disk, have self-referential information like own LBA address consistent with physical block numbers and block numbers presented to users of GMIRROR et.al.). Perhaps, GMIRROR could treat its configuration sector (that is placed at the sector just below the secondary GPT header) as read only. Requests may go to all sectors below and also to the area above the GMIRROR config sector used for the GPT header, to write it to all mirrored devices). But this is also ugly, since GPT must know to not assign the GMIRROR config sector to any partition (it is read- only for user requests, but writable on each individual drive in case of GMIRROR configuration or state changes, just as it is now). The reservation was best achieved by use of a specific GPT partition for the configuration data, for which GPT headers must exist, before the GMIRROR is created (or bith must be created at the same time, but that would mix GPT knowledge into GMIRROR). All of the above is ugly, U'm afraid :( Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 04:28:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0F51106566C; Thu, 28 Jun 2012 04:28:16 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A7E818FC0A; Thu, 28 Jun 2012 04:28:15 +0000 (UTC) Received: by werg1 with SMTP id g1so1498791wer.13 for ; Wed, 27 Jun 2012 21:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nZkVvSNOCPSopeZn75d6Zb67MbFJL06UZolsShBu+Hs=; b=jWNJD7+ieMRhdS+0RyqS7b5B0V8JXth8Dnx7p1gmKzhiPY4YK5fI5Y6YU1sZYjasTT rgon7sQjX1efuifyAo7SO+ez5IJl8XJV7vQOB8rSLGz0+4aB4MtBcB4t8Jc/+fCBCzCz ZecuUikXddzksetCik42V/L3KQ9u4Y4kqXW1sC62adhvDaHIz8lcyc++rjA+OW9ddK5w GPe9OIdqvYzTbU18LH6jBdy8vRfYjt+c5DFz9vcqSJ2JbpgOjBhlDrJTISK5aVBI94rY 0RBpWEsK08aQ6ZhTW8nB3r9XdMu9WcC1drVCARFzeoZXBfdeYMBpJWuHruGYvfLDpzmW xL2g== MIME-Version: 1.0 Received: by 10.216.215.194 with SMTP id e44mr275286wep.61.1340857688567; Wed, 27 Jun 2012 21:28:08 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Wed, 27 Jun 2012 21:28:08 -0700 (PDT) In-Reply-To: <60047.1340833140@critter.freebsd.dk> References: <658E457B-3107-4BE8-A8EE-4F97D021843E@xcllnt.net> <60047.1340833140@critter.freebsd.dk> Date: Wed, 27 Jun 2012 21:28:08 -0700 Message-ID: From: Kevin Oberman To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 28 Jun 2012 11:45:25 +0000 Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , Marcel Moolenaar , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 04:28:17 -0000 On Wed, Jun 27, 2012 at 2:39 PM, Poul-Henning Kamp wrote: > > I would like to point out that all other operating system which has > had this precise problem, have solved it by adding a bootfs partition > to hold the kernel+modules required to truly understand the disk-layout ? I have seen some form of this solution suggested three times (once by me) and now by someone who I think I can safely states is pretty familiar with geom. So far I have seen no direct response and only a passing comment by jhb that it might be difficult. Sometimes standards need to be broken. Sometimes they such so badly that te entire industry ignores them. But, unless there i a good reason to ignore them, one should fully justify doing so, all the more so when there are obvious ways that non-compliance can lead to disaster. (Think of geli disk there some other software steps on the last block.) Moreover, I think I can see a legitimate case, though I have not tried it. Say I have a FreeBSD system with a large, unused space on the disk and it uses gmirror. I decide that I need to have the ability to occasionally boot Linux on this system (or, even Windows 8). For some reason, and I can think of several, I can't use a virtual system. I create a new partition for the second OS and install it. It knows nothing about the gmirror, so it just uses the disk it is installed on and never touches the metadata. Is this possible? Looks reasonable to me. I really, really feel uncomfortable about all of this. And when people start claiming that, by a very strained interpretation of what appears on the surface to be a clear specification, they are not violating the standard. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 10:35:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67DA5106566C; Thu, 28 Jun 2012 10:35:55 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id B27208FC0A; Thu, 28 Jun 2012 10:35:54 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q5SAZdvo002422; Thu, 28 Jun 2012 12:35:39 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q5SAZcEi002419; Thu, 28 Jun 2012 12:35:38 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 28 Jun 2012 12:35:38 +0200 (CEST) From: Wojciech Puchar To: Stefan Esser In-Reply-To: <4FEC22A0.9000109@freebsd.org> Message-ID: References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 28 Jun 2012 12:35:46 +0200 (CEST) X-Mailman-Approved-At: Thu, 28 Jun 2012 11:47:01 +0000 Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , Marcel Moolenaar , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:35:55 -0000 > Just modify GEOM classes that keep state at the end of a partition to > leave some spare area *behind* the GEOM data. I.e.: > what is really a problem aat all? just leave as is. If someone want's use gpart and mirror then mirroring every partition is simpler. usually not every partition needs to be mirrored. or mirror a whole and make gpart in it, it should still boot fine. even better - update bsdlabel to work with >2TB devices. MUCH better. From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 10:55:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 122BC106566B; Thu, 28 Jun 2012 10:55:39 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [IPv6:2a02:6b8:0:602::4]) by mx1.freebsd.org (Postfix) with ESMTP id 679658FC0A; Thu, 28 Jun 2012 10:55:38 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward4.mail.yandex.net (Yandex) with ESMTP id 75F1C1BC14FD; Thu, 28 Jun 2012 14:55:36 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340880936; bh=kNMheJHUaEMTzvKPHev31tS7pLgT9l4B50lgjJkYYnE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CkA5JnuoI3UChLdemJ2QhpBMTB0TZZpNhYCfe9qlcP3b8OTBe8VCKVzIPt6fw3ye0 kX6aZByAvhBV939J6Q96VaviZLLXsH5hvwe/oFwnaXhxaMB9oCbuXuJmqNewHRqDF0 0MA441yjQCq87jEENuzKA9KC2vND7yPpbkjizw4I= Received: from smtp2.mail.yandex.net (localhost [127.0.0.1]) by smtp2.mail.yandex.net (Yandex) with ESMTP id C7AEDE20363; Thu, 28 Jun 2012 14:55:35 +0400 (MSK) Received: from ns.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by smtp2.mail.yandex.net (nwsmtp/Yandex) with ESMTP id tZY43MQ9-tZYqhT8T; Thu, 28 Jun 2012 14:55:35 +0400 X-Yandex-Rcpt-Suid: wojtek@wojtek.tensor.gdynia.pl X-Yandex-Rcpt-Suid: se@freebsd.org X-Yandex-Rcpt-Suid: marcel@xcllnt.net X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: marcel@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: xi@borderworlds.dk X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340880935; bh=kNMheJHUaEMTzvKPHev31tS7pLgT9l4B50lgjJkYYnE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=Ex7NQ9z6k+E/bxRb3YkY7Ckx34LytIPQDsUocXq7d+JNUQZj2zE57wnwDgO7Rk2x0 nfEpLUnzSPtu9aECvySHRm7JXa3pCUtPn4W3hS03yiX1lW6L2/7n+8MxDPMYUB/wBF VaJygmE1O/t9KGhbe6+aEmEixiN/WDZDWneUQTs8= Message-ID: <4FEC3826.1090601@yandex.ru> Date: Thu, 28 Jun 2012 14:55:34 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Wojciech Puchar References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Jun 2012 11:47:13 +0000 Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-current , freebsd-hackers , Andriy Gapon , Marcel Moolenaar Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:55:39 -0000 On 28.06.2012 14:35, Wojciech Puchar wrote: >> Just modify GEOM classes that keep state at the end of a partition to >> leave some spare area *behind* the GEOM data. I.e.: >> > > what is really a problem aat all? > > just leave as is. If someone want's use gpart and mirror then mirroring every partition is simpler. > usually not every partition needs to be mirrored. > > or mirror a whole and make gpart in it, it should still boot fine. I already reverted changes related to the GPT and GEOM metadata detection. > even better - update bsdlabel to work with >2TB devices. > MUCH better. DragonFlyBSD has disklabel64 partitioning scheme. Make a port is simple task. -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 13:19:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD5971065670 for ; Thu, 28 Jun 2012 13:19:35 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 547538FC14 for ; Thu, 28 Jun 2012 13:19:35 +0000 (UTC) Received: (qmail 691 invoked from network); 28 Jun 2012 09:19:29 -0400 Received: from c-71-192-38-198.hsd1.ma.comcast.net (HELO Macintosh-21.local) (71.192.38.198) by mail.atlantawebhost.com with SMTP; 28 Jun 2012 09:19:28 -0400 Message-ID: <4FEC59E0.5080706@shadowsun.net> Date: Thu, 28 Jun 2012 09:19:28 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20120627211720.0df2a145@pyramind.ukuu.org.uk> In-Reply-To: <20120627211720.0df2a145@pyramind.ukuu.org.uk> X-Forwarded-Message-Id: <20120627211720.0df2a145@pyramind.ukuu.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Fwd: UEFI, Qemu and emulating the secure boot interfaces X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 13:19:35 -0000 Received this yesterday, about Linux's plans for supporting secure booting with EFI. I've looked into it as a possibility for FreeBSD, but I won't be in a position to do anything about it for some time. But the possibilities are enticing to say the least. -------- Original Message -------- Subject: UEFI, Qemu and emulating the secure boot interfaces Date: Wed, 27 Jun 2012 21:17:20 +0100 From: Alan Cox To: emc2@FreeBSD.org I'm guessing this will be of some use to you and to the FreeBSD guys http://marc.info/?l=linux-kernel&m=134081867819972 It's a qemu Tianocore environment with the recent stuff including keysigning and "secure" boot. Not sure who else might want pointing at it but hopefully you can bounce it on wherever is useful in the project Alan From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 14:09:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4381A1065670 for ; Thu, 28 Jun 2012 14:09:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 18F998FC0C for ; Thu, 28 Jun 2012 14:09:14 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6709EB943; Thu, 28 Jun 2012 10:09:13 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 28 Jun 2012 09:58:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206280958.13859.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 28 Jun 2012 10:09:13 -0400 (EDT) Cc: Ping Chen Subject: Re: distinguish between Maxmem, realmem, physmem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 14:09:14 -0000 On Tuesday, June 26, 2012 3:41:10 pm Ping Chen wrote: > Hi, > I am a bit confused with all these variables defined in freebsd(especially in freebsd 6.1): Which one of this represents the real memory of a system? Say we bought a system with 4G ram, which one tells me the RAM is 4G? > > Accordign to source code: > > Maxmem ==> the highest page of phisycal address page : if I understand correctly, this is the highest page number of physical memory that is usable? > > realMem --> somehow get assigned by realmem = Maxmem: this is confuing, if they are the same, why bother a realmem variables I think realMem is legacy. > physmem --> the number of usage pages : this seems the right one extract the memory info, however, it seems system allocate portion of memory to messge buffer which makes this physmem < 4G (assume RAM is 4G) Correct. Note that the firmware can also take up part of RAM as well (e.g. to hold ACPI tables). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 15:08:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFCCE1065674 for ; Thu, 28 Jun 2012 15:08:43 +0000 (UTC) (envelope-from sr@genyosha.net) Received: from ns1.genyosha.net (ns1.genyosha.net [108.86.149.91]) by mx1.freebsd.org (Postfix) with ESMTP id 640698FC12 for ; Thu, 28 Jun 2012 15:08:43 +0000 (UTC) Received: from dragon.genyosha.net (dragon.genyosha.net [108.86.149.92]) by ns1.genyosha.net (8.14.5/8.14.4) with ESMTP id q5SEkVU4041753 for ; Thu, 28 Jun 2012 07:46:31 -0700 (PDT) (envelope-from sr@genyosha.net) Received: from dragon.genyosha.net (localhost [127.0.0.1]) by dragon.genyosha.net (8.14.5/8.14.5) with ESMTP id q5SEkUZ2050402 for ; Thu, 28 Jun 2012 07:46:30 -0700 (PDT) (envelope-from sr@dragon.genyosha.net) Received: (from sr@localhost) by dragon.genyosha.net (8.14.5/8.14.5/Submit) id q5SEkUNH050401 for freebsd-hackers@freebsd.org; Thu, 28 Jun 2012 07:46:30 -0700 (PDT) (envelope-from sr) Date: Thu, 28 Jun 2012 07:46:30 -0700 From: Steve Rikli To: freebsd-hackers@freebsd.org Message-ID: <20120628144630.GA50099@dragon.genyosha.net> References: <201206280958.13859.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201206280958.13859.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (ns1.genyosha.net [108.86.149.91]); Thu, 28 Jun 2012 07:46:31 -0700 (PDT) Subject: Re: distinguish between Maxmem, realmem, physmem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:08:44 -0000 On Thu, Jun 28, 2012 at 09:58:13AM -0400, John Baldwin wrote: > On Tuesday, June 26, 2012 3:41:10 pm Ping Chen wrote: > > > > I am a bit confused with all these variables defined in > > freebsd(especially in freebsd 6.1): Which one of this represents the > > real memory of a system? Say we bought a system with 4G ram, which one > > tells me the RAM is 4G? > > > > Accordign to source code: > > Maxmem ==> the highest page of phisycal address page : if I understand > > correctly, this is the highest page number of physical memory that is > > usable? > > > > realMem --> somehow get assigned by realmem = Maxmem: this is confuing, if > > they are the same, why bother a realmem variables > > I think realMem is legacy. > > > physmem --> the number of usage pages : this seems the right one extract > > the memory info, however, it seems system allocate portion of memory to > > messge buffer which makes this physmem < 4G (assume RAM is 4G) > > Correct. Note that the firmware can also take up part of RAM as well (e.g. > to hold ACPI tables). Given that, are the values for real & avail memory from 'dmesg' presented anywhere like sysctl? E.g. one of my small servers has these from dmesg: real memory = 1073741824 (1024 MB) avail memory = 1023852544 (976 MB) but the presumably equivalent sysctl values are different: hw.realmem: 1065287680 hw.physmem: 1047953408 For system hardware inventory purposes (I assume OP is asking for reasons along those lines, as am I) I'd want the value which reflects 1024MB of RAM in this case, understanding that it may not be precisely the amount available for system/user/etc. usage. Is dmesg the (only?) place to get that number? Cheers, sr. From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 15:18:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 793591065670 for ; Thu, 28 Jun 2012 15:18:52 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from mail.averesystems.com (50-73-27-109-cpennsylvania.hfc.comcastbusiness.net [50.73.27.109]) by mx1.freebsd.org (Postfix) with ESMTP id 4341E8FC0A for ; Thu, 28 Jun 2012 15:18:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.averesystems.com (Postfix) with ESMTP id BACB94805A1; Thu, 28 Jun 2012 11:18:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.averesystems.com Received: from mail.averesystems.com ([127.0.0.1]) by localhost (mail.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywd-RofrVNoV; Thu, 28 Jun 2012 11:18:48 -0400 (EDT) Received: from riven.arriad.com (206.193.225.214.nauticom.net [206.193.225.214]) by mail.averesystems.com (Postfix) with ESMTPSA id 16DA148024E; Thu, 28 Jun 2012 11:18:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <20120628144630.GA50099@dragon.genyosha.net> Date: Thu, 28 Jun 2012 11:18:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0262B234-1618-4072-92A9-7EC1D3AE596D@averesystems.com> References: <201206280958.13859.jhb@freebsd.org> <20120628144630.GA50099@dragon.genyosha.net> To: Steve Rikli X-Mailer: Apple Mail (2.1278) Cc: freebsd-hackers@freebsd.org Subject: Re: distinguish between Maxmem, realmem, physmem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:18:52 -0000 On Jun 28, 2012, at 10:46 AM, Steve Rikli wrote: > On Thu, Jun 28, 2012 at 09:58:13AM -0400, John Baldwin wrote: >> On Tuesday, June 26, 2012 3:41:10 pm Ping Chen wrote: >>>=20 >>> I am a bit confused with all these variables defined in >>> freebsd(especially in freebsd 6.1): Which one of this represents the >>> real memory of a system? Say we bought a system with 4G ram, which = one >>> tells me the RAM is 4G? >>>=20 >>> Accordign to source code: >>> Maxmem =3D=3D> the highest page of phisycal address page : if I = understand >>> correctly, this is the highest page number of physical memory that = is >>> usable? >>>=20 >>> realMem --> somehow get assigned by realmem =3D Maxmem: this is = confuing, if >>> they are the same, why bother a realmem variables >>=20 >> I think realMem is legacy. >>=20 >>> physmem --> the number of usage pages : this seems the right one = extract >>> the memory info, however, it seems system allocate portion of memory = to >>> messge buffer which makes this physmem < 4G (assume RAM is 4G) >>=20 >> Correct. Note that the firmware can also take up part of RAM as well = (e.g. >> to hold ACPI tables). >=20 > Given that, are the values for real & avail memory from 'dmesg' = presented > anywhere like sysctl? E.g. one of my small servers has these from = dmesg: >=20 > real memory =3D 1073741824 (1024 MB) > avail memory =3D 1023852544 (976 MB) >=20 > but the presumably equivalent sysctl values are different: >=20 > hw.realmem: 1065287680 > hw.physmem: 1047953408 >=20 > For system hardware inventory purposes (I assume OP is asking for = reasons > along those lines, as am I) I'd want the value which reflects 1024MB = of > RAM in this case, understanding that it may not be precisely the = amount > available for system/user/etc. usage. >=20 > Is dmesg the (only?) place to get that number? >=20 > Cheers, > sr. Here I use hw.physmem and round up to the nearest 1GB. You can also check the output of 'dmidecode -t 17' and total up the = listed size of each DIMM. It gets its info from the BIOS, which probed = the SPD on each EEPROM at boot time. dmidecode is in = ports/sysutils/dmidecode. Sometimes a flaky motherboard won't find all of the memory, so it's = useful to make sure they match. -Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 15:24:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB3A51065674 for ; Thu, 28 Jun 2012 15:24:51 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from mail.averesystems.com (50-73-27-109-cpennsylvania.hfc.comcastbusiness.net [50.73.27.109]) by mx1.freebsd.org (Postfix) with ESMTP id 948778FC14 for ; Thu, 28 Jun 2012 15:24:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.averesystems.com (Postfix) with ESMTP id 7375E4806C3; Thu, 28 Jun 2012 11:24:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.averesystems.com Received: from mail.averesystems.com ([127.0.0.1]) by localhost (mail.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYfBJSu911Td; Thu, 28 Jun 2012 11:24:52 -0400 (EDT) Received: from riven.arriad.com (206.193.225.214.nauticom.net [206.193.225.214]) by mail.averesystems.com (Postfix) with ESMTPSA id 59F4A4806CB; Thu, 28 Jun 2012 11:24:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <0262B234-1618-4072-92A9-7EC1D3AE596D@averesystems.com> Date: Thu, 28 Jun 2012 11:24:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0788A673-5CC8-4F64-9CE1-DD16C71C255C@averesystems.com> References: <201206280958.13859.jhb@freebsd.org> <20120628144630.GA50099@dragon.genyosha.net> <0262B234-1618-4072-92A9-7EC1D3AE596D@averesystems.com> To: Steve Rikli X-Mailer: Apple Mail (2.1278) Cc: freebsd-hackers@freebsd.org Subject: Re: distinguish between Maxmem, realmem, physmem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:24:51 -0000 On Jun 28, 2012, at 11:18 AM, Andrew Boyer wrote: > It gets its info from the BIOS, which probed the SPD on each EEPROM at = boot time.=20 Meant to say "SPD EEPROM on each DIMM." -A -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 15:33:33 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D19CE106564A; Thu, 28 Jun 2012 15:33:33 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2408FC14; Thu, 28 Jun 2012 15:33:33 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5SFXMPR036709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 08:33:28 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Marcel Moolenaar In-Reply-To: <4FEC2D86.2040505@freebsd.org> Date: Thu, 28 Jun 2012 08:33:17 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:33:33 -0000 On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: > > All of the above is ugly, U'm afraid :( Indeed. The only sane way is to put the metadata in a partition of its own. Every compliant OS will respect that and consequently will not scribble over the data unintentionally. Any other scheme that puts valuable data in some undocumented or unregistered location is violating the GPT spec right away and is susceptible to being clobbered unintentionally. If the metadata is in its own partition, one can document the metadata layout and providing a reference implementation. That way one increases the chance that someone, somewhere may port support for it to some other OS. Lacking widespread support for the mirroring scheme, I think that the notion that one can safely and reliably mirror entire disks (read: mirror data not owned or controlled by FreeBSD) is a very questionable one -- all one has to do is boot some other OS and start modifying one of its partitions and you've failed to achieve the objective. My advise is to leave disk mirroring to H/W or firmware solutions and use FreeBSD mirroring for FreeBSD partitions only. If you want to mirror the whole disk, don't partition the disk with non-FreeBSD partitioning schemes and partition only with FreeBSD-specific schemes or put a FreeBSD file system on the whole disk. In other words: make the whole disk private to FreeBSD. Whether or not people agree with this is besides the point. All I'm saying is that unique disk identifiers such as the "UniqueMBRSignature" (a 4 byte ID written at offset 440 in the MBR) or the "DiskGUID" (an UUID written to offset 56 in the GPT header) cannot, in general, be mirrored across disks if OSes can see the mirrored disks as independent entities. One violates the spec on grounds of making the *unique* disk identifier non-unique by presenting OSes with multiple disks that have identical IDs. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 16:17:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C421E1065670 for ; Thu, 28 Jun 2012 16:17:26 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 69CD98FC19 for ; Thu, 28 Jun 2012 16:17:26 +0000 (UTC) Received: (qmail 3051 invoked by uid 0); 28 Jun 2012 16:04:58 -0000 Received: from 67.206.186.153 by rms-us006.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Thu, 28 Jun 2012 12:04:55 -0400 From: "Dieter BSD" Message-ID: <20120628160456.287270@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: /+Web1MR3zOlNR3dAHAhN9B+IGRvb8A5 Subject: geom metadata (Re: [CFC/CFT] large changes in the loader(8) code) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:17:26 -0000 These schemes to just put the metadata in some special location and have all the tools know about it create a lot of problems. There is always some tool that doesn't know. There is always some human that doesn't know. Telling the difference between real metadata and some other data that happens to look similar. Convoluted logic that is prone to bugs. I have seen complaints from people that have lost data when some tool wrote metadata on top of it. Losing data is absolutely unacceptable. There is a time to be clever and a time to just keep it simple. Define a "FreeBSD geom metadata" GPT partition type. Create a 6 sector (3 KiB) "FreeBSD geom metadata" GPT partition just after the GPT header. PMBR pri GPT header pri GPT table FreeBSD geom metadata data partition(s) sec GPT table sec GPT header Advantages: 1) All OSes will know that this space is taken. 2) Humans looking at the GPT partition table will know that this space is taken, and what it is being used for. 3) The 1st data partition becomes 4 KiB aligned, which is important for many recent disks (yes the metadata partition is not 4K aligned, but is presumably accessed only rarely, so it is not a performance problem) Disadvantages 1) uses up a partition type 2) uses up a partition With GPT neither of these disadvantages is significant. Alternately one could make the geom metadata partition smaller and add a spaceholder partition to get 4K alignment. Yes you can just leave a hole, but putting a partition there labled "4K_alignment" makes it obvious why it is there. So, what have I missed? From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 16:27:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0218F106573C for ; Thu, 28 Jun 2012 16:27:32 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 86D338FC0C; Thu, 28 Jun 2012 16:27:32 +0000 (UTC) Message-ID: <4FEC85F4.8010005@FreeBSD.org> Date: Thu, 28 Jun 2012 12:27:32 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120626 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andrew Boyer References: <201206280958.13859.jhb@freebsd.org> <20120628144630.GA50099@dragon.genyosha.net> <0262B234-1618-4072-92A9-7EC1D3AE596D@averesystems.com> In-Reply-To: <0262B234-1618-4072-92A9-7EC1D3AE596D@averesystems.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Steve Rikli Subject: Re: distinguish between Maxmem, realmem, physmem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:27:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-06-28 11:18:45 -0400, Andrew Boyer wrote: > On Jun 28, 2012, at 10:46 AM, Steve Rikli wrote: > >> On Thu, Jun 28, 2012 at 09:58:13AM -0400, John Baldwin wrote: >>> On Tuesday, June 26, 2012 3:41:10 pm Ping Chen wrote: >>>> >>>> I am a bit confused with all these variables defined in >>>> freebsd(especially in freebsd 6.1): Which one of this >>>> represents the real memory of a system? Say we bought a >>>> system with 4G ram, which one tells me the RAM is 4G? >>>> >>>> Accordign to source code: Maxmem ==> the highest page of >>>> phisycal address page : if I understand correctly, this is >>>> the highest page number of physical memory that is usable? >>>> >>>> realMem --> somehow get assigned by realmem = Maxmem: this >>>> is confuing, if they are the same, why bother a realmem >>>> variables >>> >>> I think realMem is legacy. >>> >>>> physmem --> the number of usage pages : this seems the right >>>> one extract the memory info, however, it seems system >>>> allocate portion of memory to messge buffer which makes this >>>> physmem < 4G (assume RAM is 4G) >>> >>> Correct. Note that the firmware can also take up part of RAM >>> as well (e.g. to hold ACPI tables). >> >> Given that, are the values for real & avail memory from 'dmesg' >> presented anywhere like sysctl? E.g. one of my small servers has >> these from dmesg: >> >> real memory = 1073741824 (1024 MB) avail memory = 1023852544 >> (976 MB) >> >> but the presumably equivalent sysctl values are different: >> >> hw.realmem: 1065287680 hw.physmem: 1047953408 >> >> For system hardware inventory purposes (I assume OP is asking for >> reasons along those lines, as am I) I'd want the value which >> reflects 1024MB of RAM in this case, understanding that it may >> not be precisely the amount available for system/user/etc. >> usage. >> >> Is dmesg the (only?) place to get that number? >> >> Cheers, sr. > > Here I use hw.physmem and round up to the nearest 1GB. > > You can also check the output of 'dmidecode -t 17' and total up the > listed size of each DIMM. It gets its info from the BIOS, which > probed the SPD on each EEPROM at boot time. dmidecode is in > ports/sysutils/dmidecode. You don't have to use dmidecode for that. The same information is already available from loader(8) for very long time: % kenv smbios.memory.enabled 4194304 % dmesg | grep 'real memory' real memory = 4294967296 (4096 MB) http://svnweb.freebsd.org/base?view=revision&revision=190599 > Sometimes a flaky motherboard won't find all of the memory, so it's > useful to make sure they match. Correct. In fact, the "real memory" from dmesg is derived from the same SMBIOS data unless it is less than "avail memory". http://svnweb.freebsd.org/base?view=revision&revision=196412 Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/shfMACgkQmlay1b9qnVMb1gCgtaJbMoBycsDKMLki3ttlp7xz NfwAoMNbHVs+l5EluxFGDbL1zpBsrRXh =rbey -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 17:27:40 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CDAB1065672; Thu, 28 Jun 2012 17:27:40 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 70EB08FC08; Thu, 28 Jun 2012 17:27:39 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id CB4E049A; Thu, 28 Jun 2012 19:27:31 +0200 (CEST) Date: Thu, 28 Jun 2012 19:25:27 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20120628172526.GA1438@garage.freebsd.pl> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Doug Rabson , Marcel Moolenaar , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 17:27:40 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: >=20 > On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: > >=20 > > All of the above is ugly, U'm afraid :( >=20 > Indeed. The only sane way is to put the metadata in a partition of its ow= n. > Every compliant OS will respect that and consequently will not scribble o= ver > the data unintentionally. Any other scheme that puts valuable data in some > undocumented or unregistered location is violating the GPT spec right away > and is susceptible to being clobbered unintentionally. If the user runs: # gpart create -s GPT /dev/mirror/foo for me it is obvious that he wants to partition the mirror device and not individual disks. Because the mirror was configured earlier, do you expect gmirror to somehow detect that someone is writting GPT metadata later and magically place GPT metadata on the raw disk and move mirror's metadata to some magic partition? Not to mention that the mirror itself doesn't have to be configured on top of raw disks. And not to mention that the mirror may never be partitioned. If GPT in your opinion is limited only to raw disks then I guess the best way to fix that is to refuse to configure GPT on anything except raw disks (which was already proposed by Andrey?). In my opinion this is unacceptable, but I think this is what you are suggesting. One of the GEOM design goals was to be flexible. Let the user decide in what order he wants to configure various layers. How do you know that in every possible scenerio software mirroring should come after partitioning and encryption after mirroring? Why can't we provide flexible tools to the user and let him decide? Maybe GPT nesting violates standards, but why can't we support it as an extention, really? I recognize the need to warn users if they use FreeBSD-specific features. We do that with non-standard APIs. So how about this. Let's modify gpart(8) to print a warning if GPT is configured on something else than raw disk. Let's the warning say that such configuration is non-standard and problems are expected if the disk is shared between other OSes. In my opinion that's fair. With such a warning in place, I think we can allow users to decide on their own if they really want that or not. Then, we can also improve FreeBSD boot loader to play nice with FreeBSD-specific extensions. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --AqsLC8rIMeq19msA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/sk4UACgkQForvXbEpPzRESwCgwGF+RxCLlootXW4lu+j8Owmt YEcAnA7XjZwxeS2poA25AtIptQHTPZco =CaJC -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 20:17:11 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 938721065674 for ; Thu, 28 Jun 2012 20:17:11 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm9.bullet.mail.ukl.yahoo.com (nm9.bullet.mail.ukl.yahoo.com [217.146.182.250]) by mx1.freebsd.org (Postfix) with SMTP id A34F58FC1A for ; Thu, 28 Jun 2012 20:17:10 +0000 (UTC) Received: from [217.146.183.183] by nm9.bullet.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 20:17:04 -0000 Received: from [77.238.184.71] by tm14.bullet.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 20:17:04 -0000 Received: from [127.0.0.1] by smtp140.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 20:17:04 -0000 X-Yahoo-Newman-Id: 600360.4893.bm@smtp140.mail.ukl.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8f6UlLwVM1n5ttpSZw9NlubZgRSUf7BKNsuxXBI_v5NdV.s srvb_2gSPiC8Bek7UI612_w3lJ8fj95Y7CPiLkhkADG7bFesY3PwkhETfOCk rC1jA.xa5lXBSbnmnx2PjzweLG5vo009IS2_krClPc7Mq_WYTC10cJfV9whq C03ON613fnns3XlPjhaPD1p_3Eo1BDys.sDkR_g.xuFtx1KC2rZPIPCoRdCF oLSpfaSo1XIhLB7PZOZWuWiG68KgGAq7O2Qc986eXXYIzdvK8sV3rKhZSGl. IevowY6PKLGJvV_JdB9U4XdH83KU9IvfWiBS3SdYyvfQ0FcXUnQgfxgufbKC gtC_wSg65oD.rv8yREScN4draZhA40Js9H36tP_ExKbllVliZp_2wO9wUC78 HUA-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.11] (se@81.173.146.169 with plain) by smtp140.mail.ukl.yahoo.com with SMTP; 28 Jun 2012 20:17:04 +0000 GMT Message-ID: <4FECBBC1.3000800@freebsd.org> Date: Thu, 28 Jun 2012 22:17:05 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: FreeBSD developers References: <4FEAA3C1.2040807@freebsd.org> In-Reply-To: <4FEAA3C1.2040807@freebsd.org> Content-Type: multipart/mixed; boundary="------------040406000400060803010701" Cc: Subject: [PATCH] Fix for negative cacheing problem in NSCD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:17:11 -0000 This is a multi-part message in MIME format. --------------040406000400060803010701 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit The Name Service Cache Daemon (NSCD) is useful, but may get in your way if you modify data that is cached and have the cache return stale data until expiry. One common scenario is an installation script that creates the required user account, but first checks whether the account name is currently unused. The query result (user does not exist) will be cached by NSCD and will be returned even after the user has been created in the password database (or in LDAP or whatever). One solution is to signal changes of the database to NSCD, but that requires an interfaces between the programs that modify possibly cached data and NSCD. A short timeout for negative query results is possible, but limits the effectiveness of the cache. I propose a different solution, which completely fixes the behavior in the scenario given above: I have prepared a patch to NSCD that allows to specify a threshold for negative queries. Requests for negative entries are only answered from the cache after the specified number of attempts has been made to get the result from the underlying files/databases. A high number does effectively disable negative caching, but I doubt that more than 3 is useful under normal conditions (this allows for 2 failures before the negative entry is trusted). Rate limiting of queries with negative results continues to work with this patch, since at most the specified number of retries is made within the TTL of the cache entry. A patch against -CURRENT is attached. It does not change the default behavior in any way, so I think it would be save to commit to HEAD, with possible MFC (since nothing changes unless you use the new parameters). This patch has been tested with the hosts database and verified to work as expected in my test cases. To activate a negative query threshold you have to add lines like the following to ncsd.conf:: negative-confidence-threshold hosts 3 negative-confidence-threshold passwd 2 negative-confidence-threshold group 2 A value of 2 will generally be sufficient. In the scenario where you query the user DB to check that an account is free to use, there is exactly one pro query with negative reply, before the user is added and the query succeeds. A second probe would cache the negative reply. Please let me know, whether it helps in situations with wrong negative cacheing. I'm also interested in any problems you observe with the patch. It would be great, if a native speaker had a look at the patch for the man-page since I'm not convinced it is correct and easy to understand. And finally: Please suggest a better name for the parameter ... I do not like "negative-confidence-threshold", but did not find any better phrase. Regards, STefan PS: The patch contains an undocumented option to also set the positive confidence threshold. Entries are put into the cache but the original data sources are still queried, if the results do not match for at least the number of successive queries specified. Not sure whether this is useful, it was fall-out of the negative threshold change ... One possible use case is DNS based load-balancing. If NSCD is configured with "positive-confidence-threshold hosts 3" then it will require 3 identical replies for a host name before it is willing to cache that reply. Any host with fixed IP will soon be resolved from the cache, but hosts with changing IP will continue to be queried via DNS (until the specified number of identical results is received). Hmmm, I'm not sure whether this works as advertised, since any change in the returned data (including TTL) would cause the counter to start over ... PPS: I have not tested multipart queries; they should continue to work as before (with a fixed threshold of 1). I have not verified that this is the correct behavior, and have run out of time for today ... --------------040406000400060803010701 Content-Type: text/plain; charset=windows-1252; name="nscd-Negative-Threshold.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="nscd-Negative-Threshold.patch" Index: cachelib.h =================================================================== --- cachelib.h (revision 237713) +++ cachelib.h (working copy) @@ -92,6 +92,7 @@ size_t satisf_elemsize; /* if entry size is exceeded, * this number of elements will be left, * others will be deleted */ + int confidence_threshold; /* number matching replies required */ struct timeval max_lifetime; /* if 0 then no check is made */ enum cache_policy_t policy; /* policy used for transformations */ }; @@ -116,6 +117,7 @@ size_t value_size; struct cache_policy_item_ *fifo_policy_item; + int confidence; /* incremented for each verification */ }; struct cache_ht_item_ { Index: config.c =================================================================== --- config.c (revision 237713) +++ config.c (working copy) @@ -209,6 +209,7 @@ positive_params.max_elemsize = DEFAULT_POSITIVE_ELEMENTS_SIZE; positive_params.satisf_elemsize = DEFAULT_POSITIVE_ELEMENTS_SIZE / 2; positive_params.max_lifetime.tv_sec = DEFAULT_POSITIVE_LIFETIME; + positive_params.confidence_threshold = DEFAULT_POSITIVE_CONF_THRESH; positive_params.policy = CPT_LRU; memcpy(&negative_params, &positive_params, @@ -216,6 +217,7 @@ negative_params.max_elemsize = DEFAULT_NEGATIVE_ELEMENTS_SIZE; negative_params.satisf_elemsize = DEFAULT_NEGATIVE_ELEMENTS_SIZE / 2; negative_params.max_lifetime.tv_sec = DEFAULT_NEGATIVE_LIFETIME; + negative_params.confidence_threshold = DEFAULT_NEGATIVE_CONF_THRESH; negative_params.policy = CPT_FIFO; memset(&default_common_timeout, 0, sizeof(struct timeval)); Index: config.h =================================================================== --- config.h (revision 237713) +++ config.h (working copy) @@ -44,9 +44,11 @@ #define DEFAULT_POSITIVE_ELEMENTS_SIZE (2048) #define DEFAULT_POSITIVE_LIFETIME (3600) +#define DEFAULT_POSITIVE_CONF_THRESH (1) #define DEFAULT_NEGATIVE_ELEMENTS_SIZE (2048) #define DEFAULT_NEGATIVE_LIFETIME (60) +#define DEFAULT_NEGATIVE_CONF_THRESH (1) /* (2) ??? */ #define DEFAULT_MULTIPART_ELEMENTS_SIZE (1024 * 8) #define DEFAULT_MULITPART_SESSIONS_SIZE (1024) Index: nscd.conf.5 =================================================================== --- nscd.conf.5 (revision 237713) +++ nscd.conf.5 (working copy) @@ -107,6 +107,16 @@ The value should be a prime number for optimum performance. You should only change this value when the number of cached elements is significantly (5-10 times) greater than the default hash table size (257). +.It Va negative-confidence-threshold Oo Ar cachename Oc Op Ar value +The number of times a query must have failed before the cache accepts +that the element can not be found. This makes it possible to check for +the existence of an element, before this element is created in one of +the data sources queried by +.Xr nscd 8 . +If this parameter is at its default value of 1, then the negative +result of the first request will be considered valid for the duration +of the TTL. A value of 2 will require two failed queries for the same +element, before this information is returned by the cache. .It Va keep-hot-count Oo Ar cachename Oc Op Ar value The size limit of the cache with the given .Ar cachename . Index: parser.c =================================================================== --- parser.c (revision 237713) +++ parser.c (working copy) @@ -167,6 +167,41 @@ TRACE_OUT(set_negative_time_to_live); } +static void +set_positive_confidence_threshold(struct configuration *config, + const char *entry_name, int conf_thresh) +{ + struct configuration_entry *entry; + + TRACE_IN(set_positive_conf_thresh); + assert(conf_thresh > 0); + assert(entry_name != NULL); + + entry = find_create_entry(config, entry_name); + assert(entry != NULL); + memcpy(&entry->positive_cache_params.confidence_threshold, + &conf_thresh, sizeof(conf_thresh)); + + TRACE_OUT(set_positive_conf_thresh); +} + +static void +set_negative_confidence_threshold(struct configuration *config, + const char *entry_name, int conf_thresh) +{ + struct configuration_entry *entry; + + TRACE_IN(set_negative_conf_thresh); + assert(conf_thresh > 0); + assert(entry_name != NULL); + entry = find_create_entry(config, entry_name); + assert(entry != NULL); + memcpy(&entry->negative_cache_params.confidence_threshold, + &conf_thresh, sizeof(conf_thresh)); + + TRACE_OUT(set_negative_conf_thresh); +} + /* * Hot count is actually the elements size limit. */ @@ -393,6 +428,12 @@ fields[1], value); continue; } else if ((field_count == 3) && + (strcmp(fields[0], "positive-confidence-threshold") == 0) && + ((value = get_number(fields[2], 1, -1)) != -1)) { + set_positive_confidence_threshold(config, + fields[1], value); + continue; + } else if ((field_count == 3) && (strcmp(fields[0], "positive-policy") == 0) && (check_cachename(fields[1]) == 0) && ((value = get_policy(fields[2])) != -1)) { @@ -416,6 +457,12 @@ fields[1], value); continue; } else if ((field_count == 3) && + (strcmp(fields[0], "negative-confidence-threshold") == 0) && + ((value = get_number(fields[2], 1, -1)) != -1)) { + set_negative_confidence_threshold(config, + fields[1], value); + continue; + } else if ((field_count == 3) && (strcmp(fields[0], "negative-policy") == 0) && (check_cachename(fields[1]) == 0) && ((value = get_policy(fields[2])) != -1)) { Index: cachelib.c =================================================================== --- cachelib.c (revision 237713) +++ cachelib.c (working copy) @@ -726,6 +726,12 @@ TRACE_OUT(cache_read); return (-1); } + /* pretend that entry was not found if confidence is below threshold*/ + if (find_res->confidence < + common_entry->common_params.confidence_threshold) { + TRACE_OUT(cache_read); + return (-1); + } if ((common_entry->common_params.max_lifetime.tv_sec != 0) || (common_entry->common_params.max_lifetime.tv_usec != 0)) { @@ -826,6 +832,24 @@ item = HASHTABLE_GET_ENTRY(&(common_entry->items), hash); find_res = HASHTABLE_ENTRY_FIND(cache_ht_, item, &item_data); if (find_res != NULL) { + if (find_res->confidence < common_entry->common_params.confidence_threshold) { + /* duplicate entry is no error, if confidence is low */ + if ((find_res->value_size == value_size) && + (memcmp(find_res->value, value, value_size) == 0)) { + /* increase confidence on exact match (key and values) */ + find_res->confidence++; + } else { + /* create new entry with low confidence, if value changed */ + free(item_data.value); + item_data.value = malloc(value_size); + assert(item_data.value != NULL); + memcpy(item_data.value, value, value_size); + item_data.value_size = value_size; + find_res->confidence = 1; + } + TRACE_OUT(cache_write); + return (0); + } TRACE_OUT(cache_write); return (-1); } @@ -839,6 +863,8 @@ memcpy(item_data.value, value, value_size); item_data.value_size = value_size; + item_data.confidence = 1; + policy_item = common_entry->policies[0]->create_item_func(); policy_item->key = item_data.key; policy_item->key_size = item_data.key_size; --------------040406000400060803010701-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 19:49:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34A15106564A; Thu, 28 Jun 2012 19:49:31 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id B525B8FC17; Thu, 28 Jun 2012 19:49:30 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C40B.dip.t-dialin.net [87.150.196.11]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 97E3C8443FE; Thu, 28 Jun 2012 21:49:09 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTPS id F07C010A1; Thu, 28 Jun 2012 21:49:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1340912947; bh=Ry6lmCgOb82JHvW7IUERwucQLMP+5OvljheL+CMD+xk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=fj7QcjBN38Xsu9MSMCP9wdPO5oBC0j9IBNq48PdVJusuzBjoM0vAfBdC//8rNT/Qf WpPtANKsxp1lX9Mn42v5QZApCiLEM47xO4XGMQ/e904h9I4bfg5FEACEmfoh2XZO68 0Xu04NpC6lqkVRcm4YXrypXji7Z0t2d1o6mog1TMoMKPv06rtZ+Os4vKziOmL55C78 wwl6a6FDwzgNZHk8fUjK4u32YpN1K9J0sdEnie5LQndjoVAeBTq+Twc17CgLHzoh9v XABEujhFb5b1KyAfgvqWMRGILHTAKv0DPQKb2GU2w9snXG1Dan6MYp2jhW6J0bC5Ob WvKqURoJ7dGVA== Date: Thu, 28 Jun 2012 21:49:02 +0200 From: Alexander Leidinger To: Marcel Moolenaar Message-ID: <20120628214902.00004e34@unknown> In-Reply-To: <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> X-Mailer: Claws Mail 3.7.10cvs42 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 97E3C8443FE.A49C0 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.921, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL 0.19, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1341517751.24885@iNvizbqaG+q1nHn8i0eSQw X-EBL-Spam-Status: No X-Mailman-Approved-At: Thu, 28 Jun 2012 20:42:24 +0000 Cc: Doug Rabson , Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Marcel, Stefan Esser , Andriy Gapon , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 19:49:31 -0000 On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar wrote: > My advise is to leave disk mirroring to H/W or firmware solutions and > use FreeBSD mirroring for FreeBSD partitions only. If you want to > mirror the whole disk, don't partition the disk with non-FreeBSD > partitioning schemes and partition only with FreeBSD-specific schemes > or put a FreeBSD file system on the whole disk. In other words: make > the whole disk private to FreeBSD. If I gmirror the entire disk, I already expressed my interest to make the whole disk private to FreeBSD, haven't I? Or are you suggesting to convince all BIOS vendors to include the ability to boot from some kind of FreeBSD private partitioning scheme (not MBR as it is not suitable, not GPT as you are not OK to use it on a gmirror)? > Whether or not people agree with this is besides the point. All I'm > saying is that unique disk identifiers such as the > "UniqueMBRSignature" (a 4 byte ID written at offset 440 in the MBR) > or the "DiskGUID" (an UUID written to offset 56 in the GPT header) > cannot, in general, be mirrored across disks if OSes can see the > mirrored disks as independent entities. One violates the spec on > grounds of making the *unique* disk identifier non-unique by > presenting OSes with multiple disks that have identical IDs. What about multipathing? In case the disk is attached via two paths but multipath is not enabled, the OS sees the same disk (and the same identical unique disk identifier) multiple times. Is this a violation of the spec too? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 21:41:22 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84682106566C; Thu, 28 Jun 2012 21:41:22 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 381D58FC0C; Thu, 28 Jun 2012 21:41:22 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5SLf3oI037908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 14:41:10 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120628172526.GA1438@garage.freebsd.pl> Date: Thu, 28 Jun 2012 14:40:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <279E75A8-0D3C-4492-B470-BCF4A8973748@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628172526.GA1438@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 21:41:22 -0000 On Jun 28, 2012, at 10:25 AM, Pawel Jakub Dawidek wrote: > On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: >>=20 >> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: >>>=20 >>> All of the above is ugly, U'm afraid :( >>=20 >> Indeed. The only sane way is to put the metadata in a partition of = its own. >> Every compliant OS will respect that and consequently will not = scribble over >> the data unintentionally. Any other scheme that puts valuable data in = some >> undocumented or unregistered location is violating the GPT spec right = away >> and is susceptible to being clobbered unintentionally. >=20 > If the user runs: >=20 > # gpart create -s GPT /dev/mirror/foo >=20 > for me it is obvious that he wants to partition the mirror device and > not individual disks. It could definitely be interpreted as the user knowing what he/she wants and as such design an infrastructure around this assumption. If users were at least as knowledgable as developers, my concerns wouldn't be as big. But we all know how knoweldgable users can be and kike it or not, even developers aren't gurus in everything. We may think to know stuff, but in practice we're just as clueless in cases as users -- more clueless even sometimes. So you may think the intend is obvious, but you should know better. > Let's modify gpart(8) to print a warning if GPT is configured on > something else than raw disk. Let's the warning say that such > configuration is non-standard and problems are expected if the disk is > shared between other OSes. Yes. I think we finally reached the point we should have reached years ago. With the proper tooling, our flexible infrastructure can be used in a safe and complaint way while still giving the freedom to those who unwisely think they know better. Build it and I'll concur. --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 21:55:04 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 385E91065675; Thu, 28 Jun 2012 21:55:04 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id D48328FC19; Thu, 28 Jun 2012 21:55:03 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5SLsnfc037954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 14:54:58 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120628214902.00004e34@unknown> Date: Thu, 28 Jun 2012 14:54:43 -0700 Content-Transfer-Encoding: 7bit Message-Id: <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628214902.00004e34@unknown> To: Alexander Leidinger X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Thu, 28 Jun 2012 22:50:38 +0000 Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 21:55:04 -0000 On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote: > On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar > wrote: > >> My advise is to leave disk mirroring to H/W or firmware solutions and >> use FreeBSD mirroring for FreeBSD partitions only. If you want to >> mirror the whole disk, don't partition the disk with non-FreeBSD >> partitioning schemes and partition only with FreeBSD-specific schemes >> or put a FreeBSD file system on the whole disk. In other words: make >> the whole disk private to FreeBSD. > > If I gmirror the entire disk, I already expressed my interest to make > the whole disk private to FreeBSD, haven't I? No. All you've done is type some commands. There's no inherent value in it that relays that you know what you're doing. I have no problem accepting that you do in fact know what you're doing, but that doesn't mean that anyone who types the same sequence of commands is as skilled as you are -- that would be a silly inference. What you need to do is not have it be about you, but about some random user. > Or are you suggesting to > convince all BIOS vendors to include the ability to boot from some kind > of FreeBSD private partitioning scheme (not MBR as it is not > suitable, not GPT as you are not OK to use it on a gmirror)? I would be having less problems if the mirroring didn't force the backup GPT header in anything but the last sector. If the metadata was somewhere else, then we wouldn't need to kluge various places to deal with the ambiguity and visible interoperability problems of the various tools and OSes. Thus, it's not that I object to the mirroring per se, just to the mirroring as it is currently implemented with gmirror. > What about multipathing? In case the disk is attached via two paths but > multipath is not enabled, the OS sees the same disk (and the same > identical unique disk identifier) multiple times. Is this a violation > of the spec too? It's the same disk, isn't it? The OS can actually use the property of the ID to infer that it has already seen this disk and not create multiple device nodes. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 22:04:27 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 172801065672; Thu, 28 Jun 2012 22:04:27 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 65B248FC15; Thu, 28 Jun 2012 22:04:26 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 184412842A; Fri, 29 Jun 2012 00:04:19 +0200 (CEST) Received: from [192.168.1.2] (static-84-242-120-26.net.upcbroadband.cz [84.242.120.26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id CBA2B28427; Fri, 29 Jun 2012 00:04:17 +0200 (CEST) Message-ID: <4FECD4E1.1070505@quip.cz> Date: Fri, 29 Jun 2012 00:04:17 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628172526.GA1438@garage.freebsd.pl> In-Reply-To: <20120628172526.GA1438@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Jun 2012 22:50:50 +0000 Cc: Doug Rabson , Marcel Moolenaar , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 22:04:27 -0000 Pawel Jakub Dawidek wrote: > On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: >> >> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: >>> >>> All of the above is ugly, U'm afraid :( >> >> Indeed. The only sane way is to put the metadata in a partition of its own. >> Every compliant OS will respect that and consequently will not scribble over >> the data unintentionally. Any other scheme that puts valuable data in some >> undocumented or unregistered location is violating the GPT spec right away >> and is susceptible to being clobbered unintentionally. > > If the user runs: > > # gpart create -s GPT /dev/mirror/foo > > for me it is obvious that he wants to partition the mirror device and > not individual disks. Because the mirror was configured earlier, do you > expect gmirror to somehow detect that someone is writting GPT metadata > later and magically place GPT metadata on the raw disk and move mirror's > metadata to some magic partition? Not to mention that the mirror itself > doesn't have to be configured on top of raw disks. And not to mention > that the mirror may never be partitioned. > > If GPT in your opinion is limited only to raw disks then I guess the > best way to fix that is to refuse to configure GPT on anything except > raw disks (which was already proposed by Andrey?). In my opinion this is > unacceptable, but I think this is what you are suggesting. > > One of the GEOM design goals was to be flexible. Let the user decide in > what order he wants to configure various layers. How do you know that in > every possible scenerio software mirroring should come after > partitioning and encryption after mirroring? Why can't we provide > flexible tools to the user and let him decide? Maybe GPT nesting > violates standards, but why can't we support it as an extention, really? > > I recognize the need to warn users if they use FreeBSD-specific > features. We do that with non-standard APIs. So how about this. > > Let's modify gpart(8) to print a warning if GPT is configured on > something else than raw disk. Let's the warning say that such > configuration is non-standard and problems are expected if the disk is > shared between other OSes. > > In my opinion that's fair. > > With such a warning in place, I think we can allow users to decide on > their own if they really want that or not. Then, we can also improve > FreeBSD boot loader to play nice with FreeBSD-specific extensions. I think this is valid point of view. FreeBSD already does things not supported by other OSes and I am completely fine with it - I am running FreeBSD on servers, not sharing anything with other OSes so I prefer extended FreeBSD specific features over 100% standard compliant behaviour crippling SW mirroring etc. I think that our tools should support / provide all standard compliant (compatible) features, but let user to choose any other extended non-compatible features if user wants it. Even if it can be seen as foot shooting by somebody else. And maybe one day our solution will be widespread and taken as a standard. Miroslav Lachman From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 23:09:33 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9836106564A; Thu, 28 Jun 2012 23:09:33 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF2E8FC0C; Thu, 28 Jun 2012 23:09:33 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 616735BF; Fri, 29 Jun 2012 01:09:31 +0200 (CEST) Date: Fri, 29 Jun 2012 01:07:26 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20120628230725.GB1438@garage.freebsd.pl> References: <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628214902.00004e34@unknown> <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 29 Jun 2012 01:44:20 +0000 Cc: Doug Rabson , Marcel Moolenaar , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , Alexander Leidinger , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 23:09:33 -0000 --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2012 at 02:54:43PM -0700, Marcel Moolenaar wrote: > On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote: > > Or are you suggesting to > > convince all BIOS vendors to include the ability to boot from some kind > > of FreeBSD private partitioning scheme (not MBR as it is not > > suitable, not GPT as you are not OK to use it on a gmirror)? >=20 > I would be having less problems if the mirroring didn't force the backup > GPT header in anything but the last sector. [...] GPT backup header is placed in the last sector of the mirror device, just like the user asked. Gmirror doesn't force anything. User decides to put GPT partitioning on the mirror device instead of raw disk. Gmirror doesn't even know and doesn't have to know how the user uses data area on the mirror device. > [...] If the metadata was somewhere > else, then we wouldn't need to kluge various places to deal with the > ambiguity and visible interoperability problems of the various tools and > OSes. [...] Where is "somewhere else", exactly? If somewhere else on this disk, then where? At the begining of the disk? Then you would complain that it keeps metadata where the primary header should be located and also MBR metadata, BSDlabel metadata, etc. Somewhere in the middle of the disk? Some future GPTng may want to use the same spot, but also gmirror-unaware boot loader will see corrupted data (shifted by one sector). Come on... If somewhere else is not on this disk, then I'm sorry, but this is totally impractical. Disks are the place you store stuff. In 99% of the cases there is no other place to store it, but the disk itself. Should we ask users to use additional disk to keep mirror's metadata? > [...] Thus, it's not that I object to the mirroring per se, just to the > mirroring as it is currently implemented with gmirror. Do you know software RAID (>=3D1) or volume manager that doesn't keep metadata on component disks? PS. We are discussing two totally different things here: 1. Is placing GPT on anything but raw disk violates the spec? I can agree that it does and I'm happy with gpart(8) growing a warning. 2. How to do software mirroring. Besides trying really hard I'm not sure what alternative are you proposing. Could you be more specific and describe how gmirror should be implemented in your opinion? > > What about multipathing? In case the disk is attached via two paths but > > multipath is not enabled, the OS sees the same disk (and the same > > identical unique disk identifier) multiple times. Is this a violation > > of the spec too? >=20 > It's the same disk, isn't it? The OS can actually use the property > of the ID to infer that it has already seen this disk and not create > multiple device nodes. You cannot trust some id that is found on disk to be unique, as all your assumptions break when the user decides to dd(1)-copy content of this disk to another disk, for example. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/s460ACgkQForvXbEpPzRTGwCfTL2ATAwe2abfVXK56cmuJocw R10An0aub6mww15UVaL2CrI3ao8Ohu9k =7Mep -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 29 00:42:44 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50083106566B; Fri, 29 Jun 2012 00:42:44 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6148FC0A; Fri, 29 Jun 2012 00:42:44 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5T0gXcs038953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 17:42:39 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120628230725.GB1438@garage.freebsd.pl> Date: Thu, 28 Jun 2012 17:42:28 -0700 Content-Transfer-Encoding: 7bit Message-Id: <03CF2422-2A8F-4055-B5CF-F6F110D146F4@xcllnt.net> References: <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628214902.00004e34@unknown> <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> <20120628230725.GB1438@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Fri, 29 Jun 2012 03:26:28 +0000 Cc: Doug Rabson , Marcel Moolenaar , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , Alexander Leidinger , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 00:42:44 -0000 On Jun 28, 2012, at 4:07 PM, Pawel Jakub Dawidek wrote: >> >> I would be having less problems if the mirroring didn't force the backup >> GPT header in anything but the last sector. [...] > > GPT backup header is placed in the last sector of the mirror device, > just like the user asked. Gmirror doesn't force anything. User decides > to put GPT partitioning on the mirror device instead of raw disk. > Gmirror doesn't even know and doesn't have to know how the user uses > data area on the mirror device. This really is a cop-out paragraph. >> [...] If the metadata was somewhere >> else, then we wouldn't need to kluge various places to deal with the >> ambiguity and visible interoperability problems of the various tools and >> OSes. [...] > > Where is "somewhere else", exactly? I already suggested a few things in this thread. Go read it. I'm bored now, so I'll just wait for UEFI booting to be forced upon those who mirror the whole disk with gmirror. I think that's when we will have a more substantial and meaningful continuation of this thread. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 29 03:06:00 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9658106566B; Fri, 29 Jun 2012 03:05:59 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 0149C8FC12; Fri, 29 Jun 2012 03:05:58 +0000 (UTC) Received: from alph.allbsd.org (p4242-ipbf1504funabasi.chiba.ocn.ne.jp [118.7.211.242]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q5T35WTi080211; Fri, 29 Jun 2012 12:05:43 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q5T35SaH061314; Fri, 29 Jun 2012 12:05:29 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 29 Jun 2012 11:47:34 +0900 (JST) Message-Id: <20120629.114734.957117006298853448.hrs@allbsd.org> To: pjd@FreeBSD.org From: Hiroki Sato In-Reply-To: <20120628230725.GB1438@garage.freebsd.pl> References: <20120628214902.00004e34@unknown> <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> <20120628230725.GB1438@garage.freebsd.pl> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jun_29_11_47_34_2012_987)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 29 Jun 2012 12:05:44 +0900 (JST) X-Spam-Status: No, score=-96.8 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT, RCVD_IN_RP_RNBL, SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org X-Mailman-Approved-At: Fri, 29 Jun 2012 03:36:15 +0000 Cc: dfr@FreeBSD.org, marcel@FreeBSD.org, xi@borderworlds.dk, freebsd-hackers@FreeBSD.org, avg@FreeBSD.org, marcel@xcllnt.net, se@FreeBSD.org, bu7cher@yandex.ru, Alexander@Leidinger.net, freebsd-current@FreeBSD.org Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 03:06:00 -0000 ----Security_Multipart(Fri_Jun_29_11_47_34_2012_987)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pawel Jakub Dawidek wrote in <20120628230725.GB1438@garage.freebsd.pl>: pj> PS. We are discussing two totally different things here: pj> 1. Is placing GPT on anything but raw disk violates the spec? I can pj> agree that it does and I'm happy with gpart(8) growing a warning. I agree that there is a sort of violation, but in practice most of implementations which use GPT can recognize the backup header as long as the primary one is not corrupted by using the alternative LBA field. One thing we have to consider is what happens when the primary header becomes broken. In that case and if a GEOM metadata is placed at the end of the raw disk, GPT will be lost and it cannot recover by non-GEOM-aware software including BIOS and other OS. Also, even for FreeBSD it causes a boot failure. The modification which ae@ proposes mitigates this case. Of course, maybe BIOS or EFI will not recognize the corrupted header because the backup header is not located at the end. In that case all of the partitions are not recognized and the FreeBSD does not boot. This is the trade-off when we use GPT in a logical volume provided by GEOM. In short, the risk is that backup header does not work as a backup when the primary is broken. I agree that putting a warning about that is good and enough. Whether this risk is acceptable or not depends on the sysadmin. Also, we can describe the pros and cons in detail in a section of the handbook because I and wblock@ are working on updating it. pj> 2. How to do software mirroring. Besides trying really hard I'm not sure pj> what alternative are you proposing. Could you be more specific and pj> describe how gmirror should be implemented in your opinion? I do not think this topic is related to ae@'s change and this should be discussed in a separate thread. His change aims to support a non-standard GPT header location in a quite limited situation, not actively promote such a configuration. The issue of GPT+GEOM is not limited to gmirror. Just putting GEOM::LABEL metadata causes the same issue. -- Hiroki ----Security_Multipart(Fri_Jun_29_11_47_34_2012_987)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk/tF0YACgkQTyzT2CeTzy1kOgCfVfIyJA3wP4V+tAeNSOb/fD9D jx4An3Buxn6SA3rVPDkMuYTZNgVU7QZj =R0+R -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jun_29_11_47_34_2012_987)---- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 29 20:16:59 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB8091065695 for ; Fri, 29 Jun 2012 20:16:58 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id CDCD28FC19 for ; Fri, 29 Jun 2012 20:16:58 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q5TKGndl001896 for ; Fri, 29 Jun 2012 13:16:51 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4FEE0D2F.4010808@rawbw.com> Date: Fri, 29 Jun 2012 13:16:47 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120625 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: System is flooded with failed read(2) calls: Resource temporarily unavailable (errno=35) coming from xorg unix socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:16:59 -0000 When I run dtrace script (attached) on 9.0 amd64 with kde4 I see a lot of failed read(2) calls from the xorg socket /tmp/.X11-unix/X0 . This can't be right in my opinion. This means that code keeps reading from this socket and failing, instead of using select(2) or kquere(2). Requests mostly come from kdeinit4 but some also from kwin, chrome and even Xorg itself. Rate of failure for read(2) calls is ~2500/sec systemwide. This is of course not a deadly problem. But is this situation considered to be normal? Yuri --- dtrace script--- !/usr/bin/perl use Getopt::Std; # # Defaults # $FILTER = ""; $COUNT = 0; # # Command line arguments # &Usage() if $ARGV[0] eq "--help"; getopts('ch:n:p:') || &Usage(); &Usage() if $opt_h; $COUNT = 1 if $opt_c; $FILTER = "&& execname == \"$opt_n\"" if defined $opt_n; $FILTER = "&& pid == $opt_p" if defined $opt_p; # # Load errno descriptions # open(ERRNO,"/usr/include/sys/errno.h") || die "ERROR1: reading errno.h: $!\n"; while (chomp($line = )) { next unless $line =~ /^#define/; ($errno,$desc) = $line =~ /^#define\s+\S+\s+(\d+)\s+\/\*(.*)\*\//; $Errno{$errno} = $desc; } close ERRNO; # # Declare DTrace script # if ($COUNT) { # aggregate style $dtrace = <fd = arg0; } syscall::read:return /errno != 0 && pid != \$pid $FILTER/ { printf("%d %s %s %d\\n", pid, execname, probefunc, errno); printf("fd=%d\\n",self->fd); }' END } # # Cleanup on signals # $SIG{INT} = \&Cleanup_Signal; # Ctrl-C $SIG{QUIT} = \&Cleanup_Signal; # Ctrl-\ $SIG{TERM} = \&Cleanup_Signal; # TERM # # Run DTrace, process output # if ($COUNT) { print STDERR "Sampling... Hit Ctrl-C to end.\n"; $header = 1; } else { printf("%16s %16s %4s %s\n","EXEC","SYSCALL","ERR","DESC"); } ### Open DTrace open(DTRACE,"$dtrace |") || die "ERROR2: Can't start dtrace (perms?): $!\n"; ### Process DTrace output while (chomp($line = )) { ### Print count header if ($COUNT && $header) { printf("\n%16s %16s %16s %4s %6s %s\n", "PID", "EXEC","SYSCALL","ERR","COUNT","DESC"); $header = 0; } ### Split data ($pid,$execname,$syscall,$errno,$counts) = split(' ',$line); if ($errno eq "") {printf("DESCR %s\n", $line);} next if $errno eq ""; ### Fetch errno description $desc = $Errno{$errno}; ### Print output line if ($COUNT) { printf("%16s %16s %16s %4d %6d %s\n", $pid, $execname,$syscall,$errno,$counts,$desc); } else { printf("%16s %16s %16s %4d %s\n",$pid,$execname,$syscall,$errno,$desc); } } close(DTRACE); # # Triggered by signals # sub Cleanup_Signal { } # # Usage message # sub Usage { print STDERR "USAGE: errinfo [-ch] [-p PID] [-n name]\n"; print STDERR <