From owner-freebsd-arch@FreeBSD.ORG Sun Aug 22 15:06:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7880716A4CF; Sun, 22 Aug 2004 15:06:59 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA22643D39; Sun, 22 Aug 2004 15:06:57 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-b143.otenet.gr [212.205.244.151]) i7MF6jiJ011978; Sun, 22 Aug 2004 18:06:46 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i7MEtNqL014015; Sun, 22 Aug 2004 17:55:23 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i7MEfUs7000816; Sun, 22 Aug 2004 17:41:30 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 22 Aug 2004 17:41:29 +0300 From: Giorgos Keramidas To: Brian Somers , Tom Rhodes Message-ID: <20040822144129.GA785@gothmog.gr> References: <20040821235048.6244270a@dev.lan.Awfulhak.org> <20040822020609.15d7cb27@localhost.pittgoth.com> <20040822095918.60146e21@dev.lan.Awfulhak.org> <20040821191659.GA94336@gothmog.gr> <20040821202252.GB94336@gothmog.gr> <20040821235048.6244270a@dev.lan.Awfulhak.org> <20040822020609.15d7cb27@localhost.pittgoth.com> <20040821191659.GA94336@gothmog.gr> <20040821202252.GB94336@gothmog.gr> <20040821235048.6244270a@dev.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040822095918.60146e21@dev.lan.Awfulhak.org> <20040822020609.15d7cb27@localhost.pittgoth.com> <20040821235048.6244270a@dev.lan.Awfulhak.org> cc: freebsd-arch@freebsd.org Subject: Re: Introducing a poweroff(8) command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 15:06:59 -0000 On 2004-08-21 23:50, Brian Somers wrote: > > IMHO poweroff should behave like ``shutdown -p now'' rather than > ``halt -p''. This is relatively easy too. See below :-) On 2004-08-22 02:06, Tom Rhodes wrote: > > Otherwise, I'm an src/ and can approve this if Brian is ok and > a 1 week timeout occurres on -arch. If that's an offer for precommit review/approval, thanks :-) On 2004-08-22 09:59, Brian Somers wrote: > > Of course the big question is whether to implement poweroff as a shell > script that runs shutdown or as a link to shutdown... Precidence is on > the side of the link, simplicity is on the side of the script. The good thing about implementing this as part of shutdown is that we don't have to duplicate the option/command-line handling in a shell script. It's easier to rely on the existing code for parsing and validating command line arguments, with something similar to the existing reboot.c trick: p = rindex(*argv, '/')) ? p + 1 : *argv; if (strcmp(p, "some magic name") == 0) { magic_flag = 1; } Anyway. Here's a version of the poweroff command implemented as a hard link to shutdown(8) instead of reboot(8). It's simpler because shutdown doesn't have any hard-links yet, but does this look better? %%% Index: Makefile =================================================================== RCS file: /home/ncvs/src/sbin/shutdown/Makefile,v retrieving revision 1.8 diff -u -r1.8 Makefile --- Makefile 4 Dec 2001 02:19:57 -0000 1.8 +++ Makefile 22 Aug 2004 13:30:43 -0000 @@ -3,6 +3,9 @@ PROG= shutdown MAN= shutdown.8 +MLINKS= shutdown.8 poweroff.8 +LINKS= ${BINDIR}/shutdown ${BINDIR}/poweroff + BINOWN= root BINGRP= operator BINMODE=4550 Index: shutdown.8 =================================================================== RCS file: /home/ncvs/src/sbin/shutdown/shutdown.8,v retrieving revision 1.23 diff -u -r1.23 shutdown.8 --- shutdown.8 2 Jul 2004 21:45:05 -0000 1.23 +++ shutdown.8 22 Aug 2004 13:12:38 -0000 @@ -32,7 +32,8 @@ .Dt SHUTDOWN 8 .Os .Sh NAME -.Nm shutdown +.Nm shutdown , +.Nm poweroff .Nd "close down the system at a given time" .Sh SYNOPSIS .Nm @@ -47,6 +48,14 @@ .Oc .Ar time .Op Ar warning-message ... +.Nm poweroff +.Op Fl +.Oo +.Fl o +.Op Fl n +.Oc +.Ar time +.Op Ar warning-message ... .Sh DESCRIPTION The .Nm @@ -65,6 +74,9 @@ (hardware support required) at the specified .Ar time . +This is the default behavior if +.Nm poweroff +is called. .It Fl r The system is rebooted at the specified .Ar time . @@ -83,6 +95,8 @@ .Fl r is specified, .Nm +or +.Nm poweroff will execute .Xr halt 8 or @@ -103,6 +117,8 @@ .Ar Time is the time at which .Nm +or +.Nm poweroff will bring the system down and may be the word .Ar now @@ -188,3 +204,8 @@ .Nm utility appeared in .Bx 4.0 . +.Pp +The +.Nm poweroff +utility appeared in +.Fx 6.0 . Index: shutdown.c =================================================================== RCS file: /home/ncvs/src/sbin/shutdown/shutdown.c,v retrieving revision 1.26 diff -u -r1.26 shutdown.c --- shutdown.c 9 Apr 2004 19:58:38 -0000 1.26 +++ shutdown.c 22 Aug 2004 13:33:39 -0000 @@ -115,6 +115,8 @@ if (geteuid()) errx(1, "NOT super-user"); #endif + if (strstr((p = rindex(*argv, '/')) ? p + 1 : *argv, "poweroff")) + dopower = 1; nosync = NULL; readstdin = 0; while ((ch = getopt(argc, argv, "-hknopr")) != -1) @@ -517,6 +519,7 @@ warnx("%s", cp); (void)fprintf(stderr, "usage: shutdown [-] [-h | -p | -r | -k] [-o [-n]]" - " time [warning-message ...]\n"); + " time [warning-message ...]\n" + " poweroff [-] [-o [-n]] time [warning-message ...]\n"); exit(1); } %%% From owner-freebsd-arch@FreeBSD.ORG Sun Aug 22 21:52:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8593816A508 for ; Sun, 22 Aug 2004 21:52:35 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BF7C43D3F for ; Sun, 22 Aug 2004 21:52:35 +0000 (GMT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (78-240-118-80.kaptech.net [80.118.240.78]) by huva.hittite.isp.9tel.net (Postfix) with SMTP id 99D0014B6FB; Mon, 23 Aug 2004 00:04:45 +0200 (CEST) Message-ID: <071a01c48892$5483c0e0$7890a8c0@gits.invalid> From: "Cyrille Lefevre" To: "Brian Somers" , "Giorgos Keramidas" References: <20040821191659.GA94336@gothmog.gr><20040821202252.GB94336@gothmog.gr> <20040821235048.6244270a@dev.lan.Awfulhak.org> Date: Sun, 22 Aug 2004 23:52:32 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: freebsd-arch@freebsd.org Subject: Re: Introducing a poweroff(8) command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 21:52:35 -0000 "Brian Somers" wrote: > On Sat, 21 Aug 2004 23:22:52 +0300, Giorgos Keramidas wrote: > > On 2004-08-21 22:16, Giorgos Keramidas wrote: > > > Hi guys, > > > > > > In response to PR misc/70476 about `halt -p' I wrote a simple patch to > > > introduce a "poweroff" command that will default to "halt -p" behavior > > > and inhibit the need for changing the default behavior of halt(8). > > > > > > o Does this look ok to you all? > > > > > > o Should I suggest using it as a workaround of the behavior > > > described in the PR? > > > > It would be nice if I also included the patch :-? > > IMHO poweroff should behave like ``shutdown -p now'' rather than ``halt -p''. no, poweroff usually behaves as "halt -p", not "shutdown -p". see Solaris and NetBSD for details. Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-arch@FreeBSD.ORG Sun Aug 22 22:46:06 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B873216A4CE; Sun, 22 Aug 2004 22:46:06 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id E77DE43D1F; Sun, 22 Aug 2004 22:46:05 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.12.11/8.12.11) with SMTP id i7MMjxEd079226; Sun, 22 Aug 2004 23:45:59 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Sun, 22 Aug 2004 23:45:59 +0100 From: Brian Somers To: Giorgos Keramidas Message-Id: <20040822234559.038727bd@dev.lan.Awfulhak.org> In-Reply-To: <20040822144129.GA785@gothmog.gr> References: <20040821235048.6244270a@dev.lan.Awfulhak.org> <20040822020609.15d7cb27@localhost.pittgoth.com> <20040822095918.60146e21@dev.lan.Awfulhak.org> <20040821191659.GA94336@gothmog.gr> <20040821202252.GB94336@gothmog.gr> <20040821235048.6244270a@dev.lan.Awfulhak.org> <20040822020609.15d7cb27@localhost.pittgoth.com> <20040821191659.GA94336@gothmog.gr> <20040821202252.GB94336@gothmog.gr> <20040821235048.6244270a@dev.lan.Awfulhak.org> <20040822144129.GA785@gothmog.gr> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on gw.lan.Awfulhak.org cc: Tom Rhodes cc: freebsd-arch@freebsd.org Subject: Re: Introducing a poweroff(8) command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 22:46:06 -0000 On Sun, 22 Aug 2004 17:41:29 +0300, Giorgos Keramidas wrote: > On 2004-08-21 23:50, Brian Somers wrote: > > > > IMHO poweroff should behave like ``shutdown -p now'' rather than > > ``halt -p''. > > This is relatively easy too. See below :-) I was going to suggest that one of the other things that might be considered is whether a time argument should be required, or whether it should default to ``now''. I think however that the idea behind shutdown still stands - operators and admins should be encouraged to give their users fair warning before shutting the machine down.... This patch looks good to me (although I haven't actually tried it). -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-arch@FreeBSD.ORG Sun Aug 22 23:07:53 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3914016A4CE for ; Sun, 22 Aug 2004 23:07:53 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8274B43D48 for ; Sun, 22 Aug 2004 23:07:52 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.12.11/8.12.11) with SMTP id i7MN7bk8079368; Mon, 23 Aug 2004 00:07:37 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Mon, 23 Aug 2004 00:07:37 +0100 From: Brian Somers To: "Cyrille Lefevre" Message-Id: <20040823000737.418f814a@dev.lan.Awfulhak.org> In-Reply-To: <071a01c48892$5483c0e0$7890a8c0@gits.invalid> References: <20040821191659.GA94336@gothmog.gr> <20040821202252.GB94336@gothmog.gr> <20040821235048.6244270a@dev.lan.Awfulhak.org> <071a01c48892$5483c0e0$7890a8c0@gits.invalid> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on gw.lan.Awfulhak.org cc: Giorgos Keramidas cc: freebsd-arch@freebsd.org Subject: Re: Introducing a poweroff(8) command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 23:07:53 -0000 On Sun, 22 Aug 2004 23:52:32 +0200, "Cyrille Lefevre" wrote: > "Brian Somers" wrote: > > On Sat, 21 Aug 2004 23:22:52 +0300, Giorgos Keramidas > wrote: > > > On 2004-08-21 22:16, Giorgos Keramidas wrote: > > > > Hi guys, > > > > > > > > In response to PR misc/70476 about `halt -p' I wrote a simple patch to > > > > introduce a "poweroff" command that will default to "halt -p" behavior > > > > and inhibit the need for changing the default behavior of halt(8). > > > > > > > > o Does this look ok to you all? > > > > > > > > o Should I suggest using it as a workaround of the behavior > > > > described in the PR? > > > > > > It would be nice if I also included the patch :-? > > > > IMHO poweroff should behave like ``shutdown -p now'' rather than ``halt -p''. > > > no, poweroff usually behaves as "halt -p", not "shutdown -p". > see Solaris and NetBSD for details. This does seem to be true, and in fact, Linux's poweroff is also ``halt -p''. The unusual thing about linux is that without the -f option, halt/reboot/poweroff will call shutdown (this is where I got the assumption that ``poweroff'' was equivalent to shutdown)! I don't think it's a good idea to encourage users to use shutdown methods that don't run the rc.d scripts, but I also don't think we should deviate from what others do without good reason! So I'll just take my oar back out and apologise for getting it wrong! -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 07:36:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B79E16A4CE for ; Mon, 23 Aug 2004 07:36:01 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 103F243D45 for ; Mon, 23 Aug 2004 07:36:01 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 8A774ACAE6; Mon, 23 Aug 2004 09:35:59 +0200 (CEST) Date: Mon, 23 Aug 2004 09:35:59 +0200 From: Pawel Jakub Dawidek To: freebsd-arch@freebsd.org Message-ID: <20040823073559.GP30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yZuF+CWsFPFxEfM2" Content-Disposition: inline User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 Subject: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 07:36:01 -0000 --yZuF+CWsFPFxEfM2 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. MIRROR GEOM class was introduced recently and it allows to setup root file system on a mirror device, but there is a small problem. If mirror starts without one component, it waits few seconds (kern.geom.mirror.timeout) for missing components before creating provider. Because of this root file system can't be mounted properly. I'm not sure how to fix this. The easiest way is to just put some timeout and check every one second if we already have our provider. I don't know, anyone have some better solution which can be implemented and merged to RELENG_5 before 5.3? --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --yZuF+CWsFPFxEfM2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBKZ5fForvXbEpPzQRAizhAJ9eHEzdwXRgK1atnHnNqq9bxQmmxACfet9K /2tAlxiTf4472pXewyoH1yw= =Y7EA -----END PGP SIGNATURE----- --yZuF+CWsFPFxEfM2-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 15:31:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8C3216A4CE for ; Mon, 23 Aug 2004 15:31:28 +0000 (GMT) Received: from green.homeunix.org (pcp04371970pcs.nrockv01.md.comcast.net [69.140.223.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42D9F43D39 for ; Mon, 23 Aug 2004 15:31:28 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i7NFVRq3058500 for ; Mon, 23 Aug 2004 11:31:27 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i7NFVRb4058499 for arch@FreeBSD.org; Mon, 23 Aug 2004 11:31:27 -0400 (EDT) (envelope-from green) Date: Mon, 23 Aug 2004 11:31:26 -0400 From: Brian Fundakowski Feldman To: arch@FreeBSD.org Message-ID: <20040823153126.GB77326@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: erase/erase2 support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 15:31:28 -0000 After jkh added basic erase/erase2 support a while back, I was wondering why it didn't really seem to matter. It seems that just about nothing takes into account the possibility of erase2 (VERASE2) existing, so I took a look and found the three most noticeable offenders (ncurses, nvi, and less) are all completely orthogonal. I went ahead and added support in all three, but I think we need to decide if the proper course of action right now is to get these changes accepted and finish implementing erase2; if we don't try to support it pervasively, I don't feel it has very good value. It's a no-brainer to add support to nvi, since it's essentially "ours" now to do what we want with. How many other OSen have erase2 support such that the ncurses and less maintainers will see the value in it? See: http://green.homeunix.org/~green/erase2.patch -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 18:09:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA66116A4DB for ; Mon, 23 Aug 2004 18:09:58 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8019943D1D for ; Mon, 23 Aug 2004 18:09:58 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30867 invoked from network); 23 Aug 2004 18:09:58 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 23 Aug 2004 18:09:57 -0000 Received: from [10.50.40.208] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7NI9rEA088096; Mon, 23 Aug 2004 14:09:54 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Mon, 23 Aug 2004 11:41:24 -0400 User-Agent: KMail/1.6.2 References: <20040821191659.GA94336@gothmog.gr> <20040821202252.GB94336@gothmog.gr> In-Reply-To: <20040821202252.GB94336@gothmog.gr> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408231141.25077.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Giorgos Keramidas Subject: Re: Introducing a poweroff(8) command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 18:09:58 -0000 On Saturday 21 August 2004 04:22 pm, Giorgos Keramidas wrote: > On 2004-08-21 22:16, Giorgos Keramidas wrote: > > Hi guys, > > > > In response to PR misc/70476 about `halt -p' I wrote a simple patch to > > introduce a "poweroff" command that will default to "halt -p" behavior > > and inhibit the need for changing the default behavior of halt(8). > > > > o Does this look ok to you all? > > > > o Should I suggest using it as a workaround of the behavior > > described in the PR? > > It would be nice if I also included the patch :-? > > %%% > Add a hard link to reboot(8) called "poweroff" which defaults to the > same behavior as "halt -p". Also fix a related bug while here. When > called as "halt -p" the previous reboot program would not disallow the > use of -d for saving kernel dumps (it would inhibit dumps without the > -p option though). > > Index: Makefile > =================================================================== > RCS file: /home/ncvs/src/sbin/reboot/Makefile,v > retrieving revision 1.13 > diff -u -r1.13 Makefile > --- Makefile 22 Mar 2004 00:52:27 -0000 1.13 > +++ Makefile 21 Aug 2004 18:45:36 -0000 > @@ -14,8 +14,8 @@ > MLINKS+= boot_i386.8 boot.8 > .endif > > -LINKS= ${BINDIR}/reboot ${BINDIR}/halt ${BINDIR}/reboot ${BINDIR}/fastboot > \ - ${BINDIR}/reboot ${BINDIR}/fasthalt > +LINKS= ${BINDIR}/reboot ${BINDIR}/halt ${BINDIR}/reboot ${BINDIR}/poweroff > \ + ${BINDIR}/reboot ${BINDIR}/fastboot ${BINDIR}/reboot ${BINDIR}/fasthalt > > SCRIPTS= nextboot.sh > > Index: reboot.8 > =================================================================== > RCS file: /home/ncvs/src/sbin/reboot/reboot.8,v > retrieving revision 1.22 > diff -u -r1.22 reboot.8 > --- reboot.8 9 Apr 2004 19:58:35 -0000 1.22 > +++ reboot.8 17 Aug 2004 22:04:34 -0000 > @@ -34,6 +34,7 @@ > .Sh NAME > .Nm reboot , > .Nm halt , > +.Nm poweroff , > .Nm fastboot , > .Nm fasthalt > .Nd stopping and restarting the system > @@ -41,6 +42,9 @@ > .Nm halt > .Op Fl lnqp > .Op Fl k Ar kernel > +.Nm poweroff > +.Op Fl lnqp > +.Op Fl k Ar kernel > .Nm > .Op Fl dlnqp > .Op Fl k Ar kernel > @@ -52,7 +56,8 @@ > .Op Fl k Ar kernel > .Sh DESCRIPTION > The > -.Nm halt > +.Nm halt , > +.Nm poweroff > and > .Nm > utilities flush the file system cache to disk, send all running processes > @@ -91,9 +96,10 @@ > This option is intended for applications such as > .Xr shutdown 8 , > that call > -.Nm > -or > +.Nm , > .Nm halt > +or > +.Nm poweroff > and log this themselves. > .It Fl n > The file system cache is not flushed. > @@ -106,6 +112,9 @@ > This option should probably not be used. > .It Fl p > The system will turn off the power if it can. > +This is the default action if > +.Nm poweroff > +is called. > If the power down action fails, the system > will halt or reboot normally, depending on whether > .Nm halt > Index: reboot.c > =================================================================== > RCS file: /home/ncvs/src/sbin/reboot/reboot.c,v > retrieving revision 1.20 > diff -u -r1.20 reboot.c > --- reboot.c 9 Apr 2004 19:58:35 -0000 1.20 > +++ reboot.c 17 Aug 2004 21:55:57 -0000 > @@ -70,9 +70,13 @@ > char *kernel, *p; > const char *user; > > - if (strstr((p = rindex(*argv, '/')) ? p + 1 : *argv, "halt")) { > + p = rindex(*argv, '/') ? p + 1 : *argv; > + if (strcmp(p, "halt") == 0) { I think this is buggy in that p will point to the / character since you don't modify it in the second case. I.e. what you wrote is basically this: p = rindex(*argv, '/'); if (p != NULL) p + 1; /* does nothing */ else *argv; /* also does nothing */ Note that in the old code the expression generates a char * that gets passed to strstr(), but in your version the result of the expression is just discarded. gcc(1) should have warned about this. (Assuming you compiled with warnings on of course. :) It would probably be better to use an explicit if statement rather than the more obfuscated ?: in this case anyways: p = rindex(argv[0], '/'); if (p != NULL) p++; else p = argv[0]; Also, given the behavior of poweroff(8) on other OS's, I think that it would violate POLA to make it a link to shutdown. If a sysadmin wants to be nice and/or wants to run rc.d scripts on shutdown he can already use 'shutdown [-hrp]' as it is. The fact that shutdown does all 3 via command line options but halt/reboot/poweroff each only do one I think it makes more sense for poweroff to link to halt/reboot. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 18:10:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89A8F16A4FD for ; Mon, 23 Aug 2004 18:10:01 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B5AB43D45 for ; Mon, 23 Aug 2004 18:10:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 23252 invoked from network); 23 Aug 2004 18:10:01 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 23 Aug 2004 18:10:00 -0000 Received: from [10.50.40.208] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7NI9rEB088096; Mon, 23 Aug 2004 14:09:56 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Mon, 23 Aug 2004 11:46:12 -0400 User-Agent: KMail/1.6.2 References: <20040823073559.GP30151@darkness.comp.waw.pl> In-Reply-To: <20040823073559.GP30151@darkness.comp.waw.pl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408231146.12972.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Pawel Jakub Dawidek Subject: Re: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 18:10:01 -0000 On Monday 23 August 2004 03:35 am, Pawel Jakub Dawidek wrote: > Hi. > > MIRROR GEOM class was introduced recently and it allows to setup root > file system on a mirror device, but there is a small problem. > > If mirror starts without one component, it waits few seconds > (kern.geom.mirror.timeout) for missing components before creating provider. > Because of this root file system can't be mounted properly. > > I'm not sure how to fix this. > > The easiest way is to just put some timeout and check every one second > if we already have our provider. > > I don't know, anyone have some better solution which can be implemented > and merged to RELENG_5 before 5.3? Why not have mirror create the provider instantly in an degraded state as soon as one disk shows up and then change from degraded back to full when the second disk finally arrives? Isn't this the same case as someone jerking the disk out at run time and then shoving it (or a new one) back in without rebooting? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 19:05:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4211616A51F; Mon, 23 Aug 2004 19:05:44 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1BD543D5E; Mon, 23 Aug 2004 19:05:43 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 271ABAC969; Mon, 23 Aug 2004 21:05:41 +0200 (CEST) Date: Mon, 23 Aug 2004 21:05:41 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20040823190541.GS30151@darkness.comp.waw.pl> References: <20040823073559.GP30151@darkness.comp.waw.pl> <200408231146.12972.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UPvCt0eiAD9X+G9u" Content-Disposition: inline In-Reply-To: <200408231146.12972.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-arch@FreeBSD.org Subject: Re: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 19:05:44 -0000 --UPvCt0eiAD9X+G9u Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2004 at 11:46:12AM -0400, John Baldwin wrote: +> Why not have mirror create the provider instantly in an degraded state a= s soon=20 +> as one disk shows up and then change from degraded back to full when the= =20 +> second disk finally arrives? Isn't this the same case as someone jerkin= g the=20 +> disk out at run time and then shoving it (or a new one) back in without= =20 +> rebooting? If it will be started in degraded mode, it can be mounted and modified before next components arrive, so there will be a need to rebuild them. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --UPvCt0eiAD9X+G9u Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBKkAFForvXbEpPzQRApmPAKDSGHxXTrsjaiWRtWEyK/fc5zucSwCg5sl/ eujZmCER5x70nzo2Ip2p3CI= =Hk5g -----END PGP SIGNATURE----- --UPvCt0eiAD9X+G9u-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 20:01:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0522A16A4CE; Mon, 23 Aug 2004 20:01:59 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACF4D43D1F; Mon, 23 Aug 2004 20:01:58 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i7NK1vuG092880; Mon, 23 Aug 2004 15:01:57 -0500 (CDT) (envelope-from dan) Date: Mon, 23 Aug 2004 15:01:57 -0500 From: Dan Nelson To: Pawel Jakub Dawidek Message-ID: <20040823200157.GA36920@dan.emsphone.com> References: <20040823073559.GP30151@darkness.comp.waw.pl> <200408231146.12972.jhb@FreeBSD.org> <20040823190541.GS30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040823190541.GS30151@darkness.comp.waw.pl> X-OS: FreeBSD 5.3-BETA1 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-arch@freebsd.org Subject: Re: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 20:01:59 -0000 In the last episode (Aug 23), Pawel Jakub Dawidek said: > On Mon, Aug 23, 2004 at 11:46:12AM -0400, John Baldwin wrote: > +> Why not have mirror create the provider instantly in an degraded > +> state as soon as one disk shows up and then change from degraded > +> back to full when the second disk finally arrives? Isn't this the > +> same case as someone jerking the disk out at run time and then > +> shoving it (or a new one) back in without rebooting? > > If it will be started in degraded mode, it can be mounted and > modified before next components arrive, so there will be a need to > rebuild them. There are a couple of cases here: 1. The mirror was cleanly closed on shutdown, in which case you can allow write access and simply sync the changes onto the other disk whenever it decides to show up. 2. The mirror is dirty and the other disk is never going to show up, since it has failed. You need to allow write access for the system to boot and a replacement disk to be added (possibly hot-swapped in). 3. The mirror is dirty, but the other disk is around somewhere (USB disk with its cable kicked out, maybe). In this case you don't know if the half you have is current, but you have to allow at least read access for the system to boot up. If you allow write access before the other half is found you risk corrupting the filesystem if it turns out the other mirror has changes that conflict with yours and you don't resync them correctly. How about maybe blocking on the initial access to a degraded mirror for 5 (just a guess) seconds to see if the other half shows up? If it doesn't, assume it's never showing up and use what you have. When the other disk arrives, sync your changes over to it. If geom_mirror keeps an on-disk bitmap of dirty blocks for fast resyncs, copy your data over the other mirror's dirty blocks. You'll lose whatever changes were made to that disk, but at least the filesystem will be consistent. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 20:38:57 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D73D216A4CE; Mon, 23 Aug 2004 20:38:57 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8113E43D7C; Mon, 23 Aug 2004 20:38:57 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id DDF17ACAE3; Mon, 23 Aug 2004 22:38:55 +0200 (CEST) Date: Mon, 23 Aug 2004 22:38:55 +0200 From: Pawel Jakub Dawidek To: Dan Nelson Message-ID: <20040823203855.GV30151@darkness.comp.waw.pl> References: <20040823073559.GP30151@darkness.comp.waw.pl> <200408231146.12972.jhb@FreeBSD.org> <20040823190541.GS30151@darkness.comp.waw.pl> <20040823200157.GA36920@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KCLoHzx0Ylaw/v4x" Content-Disposition: inline In-Reply-To: <20040823200157.GA36920@dan.emsphone.com> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-arch@freebsd.org Subject: Re: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 20:38:58 -0000 --KCLoHzx0Ylaw/v4x Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2004 at 03:01:57PM -0500, Dan Nelson wrote: +> How about maybe blocking on the initial access to a degraded mirror for +> 5 (just a guess) seconds to see if the other half shows up? If it +> doesn't, assume it's never showing up and use what you have. When the +> other disk arrives, sync your changes over to it. [...] I'm waiting for few seconds for the rest of components now, but mounting root routine doesn't wait for me. And I'm not going to create provider without given a chance to the rest components to show up, because I can end up with mirror started on stale component, because a fresh one showed up with some delay. +> If geom_mirror keeps +> an on-disk bitmap of dirty blocks for fast resyncs, copy your data over +> the other mirror's dirty blocks. You'll lose whatever changes were +> made to that disk, but at least the filesystem will be consistent. Geom_mirror doesn't keep bitmap with dirty blocks in metadata, this will probably slowdown things a lot. Synchronization in geom_mirror is based on 'syncid'. Basically one can set kern.geom.mirror.timeout to 0 and there will be no need to rebuild if there will be no write to the mirror... --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --KCLoHzx0Ylaw/v4x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBKlXfForvXbEpPzQRAqbAAJ0c23rDsKpzaF4nxlXm/0KuCPCxAACg5HGF UlSKd/Z8eeGiExgQ95iNLLI= =FO/p -----END PGP SIGNATURE----- --KCLoHzx0Ylaw/v4x-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 20:43:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32BD716A4CE; Mon, 23 Aug 2004 20:43:44 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ACA543D5D; Mon, 23 Aug 2004 20:43:44 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7NKiw8V019076; Mon, 23 Aug 2004 13:44:58 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7NKiwo7019075; Mon, 23 Aug 2004 13:44:58 -0700 Date: Mon, 23 Aug 2004 13:44:58 -0700 From: Brooks Davis To: Pawel Jakub Dawidek Message-ID: <20040823204458.GA18623@odin.ac.hmc.edu> References: <20040823073559.GP30151@darkness.comp.waw.pl> <200408231146.12972.jhb@FreeBSD.org> <20040823190541.GS30151@darkness.comp.waw.pl> <20040823200157.GA36920@dan.emsphone.com> <20040823203855.GV30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <20040823203855.GV30151@darkness.comp.waw.pl> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Dan Nelson cc: freebsd-arch@freebsd.org Subject: Re: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 20:43:44 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2004 at 10:38:55PM +0200, Pawel Jakub Dawidek wrote: > On Mon, Aug 23, 2004 at 03:01:57PM -0500, Dan Nelson wrote: > +> How about maybe blocking on the initial access to a degraded mirror for > +> 5 (just a guess) seconds to see if the other half shows up? If it > +> doesn't, assume it's never showing up and use what you have. When the > +> other disk arrives, sync your changes over to it. [...] >=20 > I'm waiting for few seconds for the rest of components now, but mounting > root routine doesn't wait for me. > And I'm not going to create provider without given a chance to the rest > components to show up, because I can end up with mirror started on stale > component, because a fresh one showed up with some delay. Would it be feasiable to create the provider immediatly and journal writes up to a certain period of time/data size before degrading the array? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBKldJXY6L6fI4GtQRApyWAJ40c6mRR6PhBrh7pHIlAw5W8eZJEQCfeb9L UEjihyZ7z9lGpDf6yS5GQmw= =PvCr -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 20:52:46 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BEC816A4CE for ; Mon, 23 Aug 2004 20:52:46 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1333A43D3F for ; Mon, 23 Aug 2004 20:52:46 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id BCBC7ACC71; Mon, 23 Aug 2004 22:52:44 +0200 (CEST) Date: Mon, 23 Aug 2004 22:52:44 +0200 From: Pawel Jakub Dawidek To: Brooks Davis Message-ID: <20040823205244.GW30151@darkness.comp.waw.pl> References: <20040823073559.GP30151@darkness.comp.waw.pl> <200408231146.12972.jhb@FreeBSD.org> <20040823190541.GS30151@darkness.comp.waw.pl> <20040823200157.GA36920@dan.emsphone.com> <20040823203855.GV30151@darkness.comp.waw.pl> <20040823204458.GA18623@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="05AYo7Fj2eyhp+k+" Content-Disposition: inline In-Reply-To: <20040823204458.GA18623@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: Dan Nelson cc: freebsd-arch@freebsd.org Subject: Re: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 20:52:46 -0000 --05AYo7Fj2eyhp+k+ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2004 at 01:44:58PM -0700, Brooks Davis wrote: +> On Mon, Aug 23, 2004 at 10:38:55PM +0200, Pawel Jakub Dawidek wrote: +> > On Mon, Aug 23, 2004 at 03:01:57PM -0500, Dan Nelson wrote: +> > +> How about maybe blocking on the initial access to a degraded mirror= for +> > +> 5 (just a guess) seconds to see if the other half shows up? If it +> > +> doesn't, assume it's never showing up and use what you have. When = the +> > +> other disk arrives, sync your changes over to it. [...] +> >=20 +> > I'm waiting for few seconds for the rest of components now, but mounti= ng +> > root routine doesn't wait for me. +> > And I'm not going to create provider without given a chance to the rest +> > components to show up, because I can end up with mirror started on sta= le +> > component, because a fresh one showed up with some delay. +>=20 +> Would it be feasiable to create the provider immediatly and journal +> writes up to a certain period of time/data size before degrading the +> array? Everything is possible, but I just want to suggest, that we have more and more GEOM classes and we should rethink our boot process, because raw disks aren't the only providers used in mount process and not all providers have to show up immediatelly. The best solution will be probably to ask every class if it waits for something or not. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --05AYo7Fj2eyhp+k+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBKlkcForvXbEpPzQRAmqpAKDC26KH4Rc9OG2vS5N3TQqlllg39wCgoKpO Dxr5M0O5wmbX3enOEVI4ofY= =G/lP -----END PGP SIGNATURE----- --05AYo7Fj2eyhp+k+-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 21:10:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE4D716A4CE; Mon, 23 Aug 2004 21:10:25 +0000 (GMT) Received: from bgezal.rise.tuwien.ac.at (bgezal.rise.tuwien.ac.at [128.130.59.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5631E43D1D; Mon, 23 Aug 2004 21:10:25 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (unknown [212.186.3.235]) by bgezal.rise.tuwien.ac.at (Postfix) with ESMTP id A529320AF; Mon, 23 Aug 2004 23:10:23 +0200 (CEST) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id 686FE40B6; Mon, 23 Aug 2004 23:09:52 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id B289DDD; Mon, 23 Aug 2004 23:09:49 +0200 (CEST) Date: Mon, 23 Aug 2004 23:09:49 +0200 From: Stefan Farfeleder To: John Baldwin Message-ID: <20040823210944.GC91753@wombat.fafoe.narf.at> References: <20040821191659.GA94336@gothmog.gr> <20040821202252.GB94336@gothmog.gr> <200408231141.25077.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408231141.25077.jhb@FreeBSD.org> User-Agent: Mutt/1.5.6i cc: Giorgos Keramidas cc: freebsd-arch@FreeBSD.org Subject: Re: Introducing a poweroff(8) command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 21:10:25 -0000 On Mon, Aug 23, 2004 at 11:41:24AM -0400, John Baldwin wrote: > On Saturday 21 August 2004 04:22 pm, Giorgos Keramidas wrote: > > - if (strstr((p = rindex(*argv, '/')) ? p + 1 : *argv, "halt")) { > > + p = rindex(*argv, '/') ? p + 1 : *argv; > > + if (strcmp(p, "halt") == 0) { > > I think this is buggy in that p will point to the / character since you don't > modify it in the second case. I.e. what you wrote is basically this: > > p = rindex(*argv, '/'); > if (p != NULL) > p + 1; /* does nothing */ > else > *argv; /* also does nothing */ No, p = rindex(*argv, '/') ? p + 1 : *argv is parsed as p = (rindex(*argv, '/') ? p + 1 : *argv). Your code is equivalent to (p = rindex(*argv, '/')) ? p + 1 : *argv. Cheers, Stefan From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 21:22:41 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B70C916A4CE; Mon, 23 Aug 2004 21:22:41 +0000 (GMT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F08743D1D; Mon, 23 Aug 2004 21:22:41 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i7NLMbYv044498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2004 14:22:37 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i7NLMbda029464; Mon, 23 Aug 2004 14:22:37 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200408231141.25077.jhb@FreeBSD.org> Date: Mon, 23 Aug 2004 14:22:37 -0700 (PDT) From: John Polstra To: John Baldwin X-Bogosity: No, tests=bogofilter, spamicity=0.078671, version=0.14.5 cc: Giorgos Keramidas cc: freebsd-arch@freebsd.org Subject: Re: Introducing a poweroff(8) command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 21:22:41 -0000 On 23-Aug-2004 John Baldwin wrote: > On Saturday 21 August 2004 04:22 pm, Giorgos Keramidas wrote: >> Add a hard link to reboot(8) called "poweroff" which defaults to the >> same behavior as "halt -p". Also fix a related bug while here. When >> called as "halt -p" the previous reboot program would not disallow the >> use of -d for saving kernel dumps (it would inhibit dumps without the >> -p option though). >> >> Index: Makefile [...] > I think this is buggy in that p will point to the / character since you don't > modify it in the second case. I.e. what you wrote is basically this: > > p = rindex(*argv, '/'); > if (p != NULL) > p + 1; /* does nothing */ > else > *argv; /* also does nothing */ [...] This whole thread seems ridiculous to me. Why can't it be done with a simple shell script? John From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 21:26:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4F4F16A4EB for ; Mon, 23 Aug 2004 21:26:32 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id B39D943D54 for ; Mon, 23 Aug 2004 21:26:32 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 3940 invoked from network); 23 Aug 2004 21:26:32 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 23 Aug 2004 21:26:32 -0000 Received: from [10.50.40.208] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7NLQHeT089422; Mon, 23 Aug 2004 17:26:27 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Mon, 23 Aug 2004 17:16:31 -0400 User-Agent: KMail/1.6.2 References: <20040823073559.GP30151@darkness.comp.waw.pl> <200408231146.12972.jhb@FreeBSD.org> <20040823190541.GS30151@darkness.comp.waw.pl> In-Reply-To: <20040823190541.GS30151@darkness.comp.waw.pl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408231716.31321.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Pawel Jakub Dawidek Subject: Re: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 21:26:33 -0000 On Monday 23 August 2004 03:05 pm, Pawel Jakub Dawidek wrote: > On Mon, Aug 23, 2004 at 11:46:12AM -0400, John Baldwin wrote: > +> Why not have mirror create the provider instantly in an degraded state > as soon +> as one disk shows up and then change from degraded back to full > when the +> second disk finally arrives? Isn't this the same case as > someone jerking the +> disk out at run time and then shoving it (or a new > one) back in without +> rebooting? > > If it will be started in degraded mode, it can be mounted and modified > before next components arrive, so there will be a need to rebuild them. How is this different from jerking the disk out of a running system and then shoving it back in again? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 21:47:31 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF6CA16A4CE; Mon, 23 Aug 2004 21:47:31 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 595D143D1F; Mon, 23 Aug 2004 21:47:31 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id BB07CAC977; Mon, 23 Aug 2004 23:47:29 +0200 (CEST) Date: Mon, 23 Aug 2004 23:47:29 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20040823214729.GX30151@darkness.comp.waw.pl> References: <20040823073559.GP30151@darkness.comp.waw.pl> <200408231146.12972.jhb@FreeBSD.org> <20040823190541.GS30151@darkness.comp.waw.pl> <200408231716.31321.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kRi8yh5Cr14O/OFH" Content-Disposition: inline In-Reply-To: <200408231716.31321.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-arch@FreeBSD.org Subject: Re: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 21:47:31 -0000 --kRi8yh5Cr14O/OFH Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2004 at 05:16:31PM -0400, John Baldwin wrote: +> On Monday 23 August 2004 03:05 pm, Pawel Jakub Dawidek wrote: +> > On Mon, Aug 23, 2004 at 11:46:12AM -0400, John Baldwin wrote: +> > +> Why not have mirror create the provider instantly in an degraded st= ate +> > as soon +> as one disk shows up and then change from degraded back to = full +> > when the +> second disk finally arrives? Isn't this the same case as +> > someone jerking the +> disk out at run time and then shoving it (or a = new +> > one) back in without +> rebooting? +> > +> > If it will be started in degraded mode, it can be mounted and modified +> > before next components arrive, so there will be a need to rebuild them. +>=20 +> How is this different from jerking the disk out of a running system and = then=20 +> shoving it back in again? You don't want to rebuild a mirror on every boot after clean shutdown. In most cases one can set kern.geom.mirror.timeout to 0 and there will be no problem with this, because even after mirror start is degraded mode new components are not rebuilt if there were no writes, but it will be good to have more general solution... --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --kRi8yh5Cr14O/OFH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBKmXxForvXbEpPzQRAu9LAJwJXCslkQCgD8rPwOxhQUe8qnEoIwCgrpFR oNncTZeHYT02DepB9AKVyUw= =5zgE -----END PGP SIGNATURE----- --kRi8yh5Cr14O/OFH-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 22:33:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0BB116A4CF for ; Mon, 23 Aug 2004 22:33:48 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 836BE43D5D for ; Mon, 23 Aug 2004 22:33:48 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 20984 invoked from network); 23 Aug 2004 22:33:48 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 23 Aug 2004 22:33:47 -0000 Received: from [10.50.40.208] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7NMXdTr089863; Mon, 23 Aug 2004 18:33:39 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Mon, 23 Aug 2004 17:35:53 -0400 User-Agent: KMail/1.6.2 References: <20040821191659.GA94336@gothmog.gr> <200408231141.25077.jhb@FreeBSD.org> <20040823210944.GC91753@wombat.fafoe.narf.at> In-Reply-To: <20040823210944.GC91753@wombat.fafoe.narf.at> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408231735.53831.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Giorgos Keramidas cc: Stefan Farfeleder Subject: Re: Introducing a poweroff(8) command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 22:33:48 -0000 On Monday 23 August 2004 05:09 pm, Stefan Farfeleder wrote: > On Mon, Aug 23, 2004 at 11:41:24AM -0400, John Baldwin wrote: > > On Saturday 21 August 2004 04:22 pm, Giorgos Keramidas wrote: > > > - if (strstr((p = rindex(*argv, '/')) ? p + 1 : *argv, "halt")) { > > > + p = rindex(*argv, '/') ? p + 1 : *argv; > > > + if (strcmp(p, "halt") == 0) { > > > > I think this is buggy in that p will point to the / character since you > > don't modify it in the second case. I.e. what you wrote is basically > > this: > > > > p = rindex(*argv, '/'); > > if (p != NULL) > > p + 1; /* does nothing */ > > else > > *argv; /* also does nothing */ > > No, > p = rindex(*argv, '/') ? p + 1 : *argv > is parsed as > p = (rindex(*argv, '/') ? p + 1 : *argv). > Your code is equivalent to > (p = rindex(*argv, '/')) ? p + 1 : *argv. In that case p's value is undefined when you do p + 1 and it's still a very broken piece of code. The deleted if statement from my original e-mail is not broken. :) It is true that = is parsed last though, I just misparsed operator(7). I wonder if the original code worked if you passed the full path since it would need to be your 3rd alternative. Actually, if you look at the original code, it did work as it used your 3rd alternative: - if (strstr((p = rindex(*argv, '/')) ? p + 1 : *argv, "halt")) { So my point about the new code having a but still stands, and to me it shows that the use of ?: instead of if-else only serves to obfuscate the code and lead to bugs. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Aug 24 04:03:34 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D616B16A4CE; Tue, 24 Aug 2004 04:03:34 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 938C043D45; Tue, 24 Aug 2004 04:03:31 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-b136.otenet.gr [212.205.244.144]) i7O43RqZ023351; Tue, 24 Aug 2004 07:03:28 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i7O426XF029849; Tue, 24 Aug 2004 07:02:06 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i7O426uJ029848; Tue, 24 Aug 2004 07:02:06 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 24 Aug 2004 07:02:06 +0300 From: Giorgos Keramidas To: John Baldwin Message-ID: <20040824040206.GA28962@gothmog.gr> References: <20040821191659.GA94336@gothmog.gr> <20040821202252.GB94336@gothmog.gr> <200408231141.25077.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408231141.25077.jhb@FreeBSD.org> Phone: +30-2610-312145 Mobile: +30-6944-116520 cc: freebsd-arch@freebsd.org Subject: Re: Introducing a poweroff(8) command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 04:03:35 -0000 On 2004-08-23 11:41, John Baldwin wrote: > On Saturday 21 August 2004 04:22 pm, Giorgos Keramidas wrote: > > --- reboot.c 9 Apr 2004 19:58:35 -0000 1.20 > > +++ reboot.c 17 Aug 2004 21:55:57 -0000 > > @@ -70,9 +70,13 @@ > > char *kernel, *p; > > const char *user; > > > > - if (strstr((p = rindex(*argv, '/')) ? p + 1 : *argv, "halt")) { > > + p = rindex(*argv, '/') ? p + 1 : *argv; > > + if (strcmp(p, "halt") == 0) { > > I think this is buggy in that p will point to the / character since you don't > modify it in the second case. I.e. what you wrote is basically this: > > p = rindex(*argv, '/'); > if (p != NULL) > p + 1; /* does nothing */ > else > *argv; /* also does nothing */ True. I think I'll have to write this as this: > p = rindex(argv[0], '/'); > if (p != NULL) > p++; > else > p = argv[0]; Thanks for spotting this :-) From owner-freebsd-arch@FreeBSD.ORG Tue Aug 24 04:06:22 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8D2616A4CE for ; Tue, 24 Aug 2004 04:06:22 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1214B43D2D for ; Tue, 24 Aug 2004 04:06:22 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-b136.otenet.gr [212.205.244.144]) i7O46Isb023455; Tue, 24 Aug 2004 07:06:19 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i7O44xwn030051; Tue, 24 Aug 2004 07:04:59 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i7O44xHU030050; Tue, 24 Aug 2004 07:04:59 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 24 Aug 2004 07:04:59 +0300 From: Giorgos Keramidas To: John Polstra Message-ID: <20040824040459.GB28962@gothmog.gr> References: <200408231141.25077.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Phone: +30-2610-312145 Mobile: +30-6944-116520 cc: freebsd-arch@freebsd.org Subject: Re: Introducing a poweroff(8) command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 04:06:22 -0000 On 2004-08-23 14:22, John Polstra wrote: > This whole thread seems ridiculous to me. Why can't it be done with a > simple shell script? To avoid having to reimplement the command line parsing of reboot for the `-k kernel' for example. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 24 20:33:09 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4957E16A4CE for ; Tue, 24 Aug 2004 20:33:09 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20C2A43D31 for ; Tue, 24 Aug 2004 20:33:09 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13238 invoked from network); 24 Aug 2004 20:33:08 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 24 Aug 2004 20:33:08 -0000 Received: from [10.50.40.208] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7OKX3Jm097086; Tue, 24 Aug 2004 16:33:04 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Tue, 24 Aug 2004 09:43:40 -0400 User-Agent: KMail/1.6.2 References: <20040823073559.GP30151@darkness.comp.waw.pl> <200408231716.31321.jhb@FreeBSD.org> <20040823214729.GX30151@darkness.comp.waw.pl> In-Reply-To: <20040823214729.GX30151@darkness.comp.waw.pl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408240943.40529.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Pawel Jakub Dawidek Subject: Re: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 20:33:09 -0000 On Monday 23 August 2004 05:47 pm, Pawel Jakub Dawidek wrote: > On Mon, Aug 23, 2004 at 05:16:31PM -0400, John Baldwin wrote: > +> On Monday 23 August 2004 03:05 pm, Pawel Jakub Dawidek wrote: > +> > On Mon, Aug 23, 2004 at 11:46:12AM -0400, John Baldwin wrote: > +> > +> Why not have mirror create the provider instantly in an degraded > state +> > as soon +> as one disk shows up and then change from degraded > back to full +> > when the +> second disk finally arrives? Isn't this the > same case as +> > someone jerking the +> disk out at run time and then > shoving it (or a new +> > one) back in without +> rebooting? > +> > > +> > If it will be started in degraded mode, it can be mounted and modified > +> > before next components arrive, so there will be a need to rebuild > them. +> > +> How is this different from jerking the disk out of a running system and > then +> shoving it back in again? > > You don't want to rebuild a mirror on every boot after clean shutdown. > In most cases one can set kern.geom.mirror.timeout to 0 and there will be > no problem with this, because even after mirror start is degraded mode > new components are not rebuilt if there were no writes, but it will be > good to have more general solution... The fact that a RAID can recover when a disk goes away and comes back is already the "general solution" it seems. It works all the time, not just at boot, so it seems to me like you are trying to solve a problem that is already solved. I think at most you could maybe have a system wide delay before that the user can tweak via a tunable (rather than a per-GEOM class tunable like your mirror one) in order to optimize the boot code for these rare cases but that is about it. I.e., if a user notices that one of the disks always takes an extra second they can set the tunable to force the kernel to wait 2 seconds before trying to mount root. Any such delay should be centralized, however, and not per-class, since all the per-class delays would end up being cumulative, so if MIRROR waits 2 seconds and STRIPE waits 3 seconds then the entire process actually waits 5 seconds as opposed to letting the user tweak a single centralized timeout. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Aug 25 07:34:04 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CDDD16A4CE; Wed, 25 Aug 2004 07:34:04 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2335843D41; Wed, 25 Aug 2004 07:34:03 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id D97BEAC976; Wed, 25 Aug 2004 09:33:56 +0200 (CEST) Date: Wed, 25 Aug 2004 09:33:56 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20040825073356.GG30151@darkness.comp.waw.pl> References: <20040823073559.GP30151@darkness.comp.waw.pl> <200408231716.31321.jhb@FreeBSD.org> <20040823214729.GX30151@darkness.comp.waw.pl> <200408240943.40529.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ppsIhpb1zLTQE1OE" Content-Disposition: inline In-Reply-To: <200408240943.40529.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-arch@FreeBSD.org Subject: Re: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 07:34:04 -0000 --ppsIhpb1zLTQE1OE Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 24, 2004 at 09:43:40AM -0400, John Baldwin wrote: +> The fact that a RAID can recover when a disk goes away and comes back is= =20 +> already the "general solution" it seems. It works all the time, not jus= t at=20 +> boot, so it seems to me like you are trying to solve a problem that is= =20 +> already solved. I think at most you could maybe have a system wide dela= y=20 +> before that the user can tweak via a tunable (rather than a per-GEOM cla= ss=20 +> tunable like your mirror one) in order to optimize the boot code for the= se=20 +> rare cases but that is about it. I.e., if a user notices that one of th= e=20 +> disks always takes an extra second they can set the tunable to force the= =20 +> kernel to wait 2 seconds before trying to mount root. Any such delay sh= ould=20 +> be centralized, however, and not per-class, since all the per-class dela= ys=20 +> would end up being cumulative, so if MIRROR waits 2 seconds and STRIPE w= aits=20 +> 3 seconds then the entire process actually waits 5 seconds as opposed to= =20 +> letting the user tweak a single centralized timeout. I second this, I'll prepare a patch then. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --ppsIhpb1zLTQE1OE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBLEDkForvXbEpPzQRAqFdAKDgtCjtElPlFBXephoHyAc06/uNfgCeJYwm 1Rla7fjyOi4oBsFbA+a5OEQ= =hUo8 -----END PGP SIGNATURE----- --ppsIhpb1zLTQE1OE-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 25 20:18:29 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E6C116A4CE; Wed, 25 Aug 2004 20:18:29 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 175D343D45; Wed, 25 Aug 2004 20:18:29 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 822D7AC861; Wed, 25 Aug 2004 22:18:27 +0200 (CEST) Date: Wed, 25 Aug 2004 22:18:27 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20040825201827.GJ30151@darkness.comp.waw.pl> References: <20040823073559.GP30151@darkness.comp.waw.pl> <200408231716.31321.jhb@FreeBSD.org> <20040823214729.GX30151@darkness.comp.waw.pl> <200408240943.40529.jhb@FreeBSD.org> <20040825073356.GG30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6DpgemkcHclpK+A" Content-Disposition: inline In-Reply-To: <20040825073356.GG30151@darkness.comp.waw.pl> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-arch@FreeBSD.org Subject: Re: Mounting root... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 20:18:29 -0000 --d6DpgemkcHclpK+A Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 25, 2004 at 09:33:56AM +0200, Pawel Jakub Dawidek wrote: +> On Tue, Aug 24, 2004 at 09:43:40AM -0400, John Baldwin wrote: +> +> The fact that a RAID can recover when a disk goes away and comes back= is=20 +> +> already the "general solution" it seems. It works all the time, not = just at=20 +> +> boot, so it seems to me like you are trying to solve a problem that i= s=20 +> +> already solved. I think at most you could maybe have a system wide d= elay=20 +> +> before that the user can tweak via a tunable (rather than a per-GEOM = class=20 +> +> tunable like your mirror one) in order to optimize the boot code for = these=20 +> +> rare cases but that is about it. I.e., if a user notices that one of= the=20 +> +> disks always takes an extra second they can set the tunable to force = the=20 +> +> kernel to wait 2 seconds before trying to mount root. Any such delay= should=20 +> +> be centralized, however, and not per-class, since all the per-class d= elays=20 +> +> would end up being cumulative, so if MIRROR waits 2 seconds and STRIP= E waits=20 +> +> 3 seconds then the entire process actually waits 5 seconds as opposed= to=20 +> +> letting the user tweak a single centralized timeout. +>=20 +> I second this, I'll prepare a patch then. Ok, here is proposed patch: http://people.freebsd.org/~pjd/patches/root_mount.patch --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --d6DpgemkcHclpK+A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBLPQTForvXbEpPzQRAk9jAKCoV3UKl+az5PX2rNc/odZbEarbiACgw/en nxpeIkqw994VHPYGs+jZfks= =p0oM -----END PGP SIGNATURE----- --d6DpgemkcHclpK+A-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 25 21:46:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48F6816A4CE; Wed, 25 Aug 2004 21:46:28 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0EF443D53; Wed, 25 Aug 2004 21:46:27 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7PLlcTj001814; Wed, 25 Aug 2004 15:47:39 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <412D0868.9060203@freebsd.org> Date: Wed, 25 Aug 2004 15:45:12 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <43041.1093469620@critter.freebsd.dk> In-Reply-To: <43041.1093469620@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Matthew Jacob cc: sos@freebsd.org cc: arch@freebsd.org Subject: Re: potential re change for 5.3? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 21:46:28 -0000 [moving this to a more appropriate list] Poul-Henning Kamp wrote: > In message <412D00BE.5030406@freebsd.org>, Scott Long writes: > > >>>I'm not sure I understand the question in the first place, sorry... >>> >> >>Let me re-interate. You should not sleep in the bio path. >>tsleep/msleep/malloc(WAITOK)/etc should not happen because they >>put the entire g_down thread to sleep and block further I/O. >>Sleep mutexes are kind of a stretch but we seem to be lucky so far. >>Contrast that to pre-GEOM days where I/O was dispatched directly > >>from the process that initiated it, so sleeping wasn't a horrible > >>thing if done with care. > > > There are many things in this casserole, and the one thing I didn't > see in any driver when I started was "sleeping ... done with care". > > If for instance the process was the kernel trying to free memory > resources and you slept, they system wedged solid, nobody checked > for that. > Well, there are certainly many marginal I/O drivers hanging around, but the ones that are written with care make sure that they allocate their resources up front and don't allow sleeping in either direction. > >>If there was one thing I could change >>about GEOM, it would be to allow direct dispatch up and down. >>Don't get me wrong, I'm understand the usefulness of decoupling >>the I/O path, especially when it comes to locking, but it does >>have some down-sides. > > >>Incidentally, the 'no blocking in the i/o path' thing is why busdma >>is the way it is with deferred callbacks. If we didn't have it, >>PHK's mutex on GEOM would be triggering all the time under heavy >>load with bounce buffers. > > > And presumably busdma would want to sleep in memory(-space) in some > shape or form ? Memory which would only become available as other > I/O requests were completed freeing up the resources in question ? > No, the case I'm talking about is the NetBSD behaviour of sleeping in bus_dmamap_load() when the bounce pool is empty. > The issue isn't solved by allowing sleeping, allowing sleeping would > open us to the case where the driver goes to sleep on a large read > which needs to allocate some memory resource which is not available, > and thereby stalling the subsequent write requests in the queue which > upon completion would make that memory resource avaiable. > > The current situation not ideal, what happens is that the requests > faults with ENOMEM in the driver and is retried in GEOM above the > geom_disk class, provided the driver uses disksort(), other requests > on the queue would get a chance first. (there should actually be a > flag which kicked the queue into fifo mode on ENOMEM errors (reset > on empty queue)). > > So while it is not ideal and not optimal, it actually works in the > common and the extreeme case (physmem=48m, make -j 12 buildworld > for instance). > We are still at risk of drivers sleeping on mutexes and blocking g_down from processing further I/O. This isn't very apparent on a single controller/single disk configuration, but toss in multiple controllers and you have the real potential for priority inversions in the I/O path. > There are many unknowns still, the entire "make bio scatter/gather > and map/unmapped" thing for instance throws much of this up in the > air again, so I'm not very keen to apply workarounds at this time. > > The current rules are very restrictive, but they work, once we get > further down the road, we may find ways to relax it that does not > compromise the desirable features of our I/O path. In the meantime > I'd prefer to keep the handcuffs on, until we know for sure what > is a better way. > > I'm not suggesting anything different, just making a note of something that might be desirable in the future. In a way, I see GEOM as having the potential to be like Netgraph where it intercepts operations that it wants to process through it's framework and lets ones that it doesn't pass directly through without a decoupling through extra kernel threads. But that's only one possible strategy. Introducing the concept of a I/O scheduler that spawns KSE's to handle individual I/O requests is another possibility. Scott From owner-freebsd-arch@FreeBSD.ORG Wed Aug 25 22:42:45 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9881916A4CF for ; Wed, 25 Aug 2004 22:42:45 +0000 (GMT) Received: from web21429.mail.yahoo.com (web21429.mail.yahoo.com [216.136.232.122]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A3F543D46 for ; Wed, 25 Aug 2004 22:42:45 +0000 (GMT) (envelope-from mjacob44@yahoo.com) Message-ID: <20040825224245.3056.qmail@web21429.mail.yahoo.com> Received: from [146.174.53.5] by web21429.mail.yahoo.com via HTTP; Wed, 25 Aug 2004 15:42:45 PDT Date: Wed, 25 Aug 2004 15:42:45 -0700 (PDT) From: Matthew Jacob To: Scott Long , Poul-Henning Kamp In-Reply-To: <412D0868.9060203@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Matthew Jacob cc: sos@freebsd.org cc: arch@freebsd.org Subject: Re: potential re change for 5.3? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 22:42:45 -0000 I'm a bit late in catching up on this... I just needed to know what the architecture is- it's now fairly clear that it is "don't sleep in driver top half". That being said, then the change to isp should go into 5.3, yes. One can argue whether this is the 'right' architecture or not. I think the points being made are good- I don't want to really debate the wisdom/unwisdom of it at this point. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-freebsd-arch@FreeBSD.ORG Thu Aug 26 05:33:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C17616A4CE; Thu, 26 Aug 2004 05:33:08 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9641B43D4C; Thu, 26 Aug 2004 05:33:07 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i7Q5X5JK051731; Thu, 26 Aug 2004 07:33:05 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 25 Aug 2004 15:45:12 MDT." <412D0868.9060203@freebsd.org> Date: Thu, 26 Aug 2004 07:33:05 +0200 Message-ID: <51730.1093498385@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Matthew Jacob cc: sos@freebsd.org cc: arch@freebsd.org Subject: Re: potential re change for 5.3? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 05:33:08 -0000 In message <412D0868.9060203@freebsd.org>, Scott Long writes: >I'm not suggesting anything different, just making a note of something >that might be desirable in the future. In a way, I see GEOM as having >the potential to be like Netgraph where it intercepts operations that it >wants to process through it's framework and lets ones that it doesn't >pass directly through without a decoupling through extra kernel threads. >But that's only one possible strategy. Introducing the concept of a >I/O scheduler that spawns KSE's to handle individual I/O requests is >another possibility. Well, the problem here is that requests which cannot be dealt with due to resource shortages should be queued at the level where they require least resources. A request queued inside a driver holds far more resources than a request in the pure bio format at the entrance to the driver for instance. And spawning KSE's in low memory situations is a recipe for suicide. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Aug 26 05:36:33 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7CCF16A4CE; Thu, 26 Aug 2004 05:36:33 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4430D43D54; Thu, 26 Aug 2004 05:36:31 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7Q5bj0J003171; Wed, 25 Aug 2004 23:37:46 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <412D7643.9000700@samsco.org> Date: Wed, 25 Aug 2004 23:33:55 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <51730.1093498385@critter.freebsd.dk> In-Reply-To: <51730.1093498385@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Matthew Jacob cc: sos@freebsd.org cc: Scott Long cc: arch@freebsd.org Subject: Re: potential re change for 5.3? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 05:36:34 -0000 Poul-Henning Kamp wrote: > In message <412D0868.9060203@freebsd.org>, Scott Long writes: > > >>I'm not suggesting anything different, just making a note of something >>that might be desirable in the future. In a way, I see GEOM as having >>the potential to be like Netgraph where it intercepts operations that it >>wants to process through it's framework and lets ones that it doesn't >>pass directly through without a decoupling through extra kernel threads. >>But that's only one possible strategy. Introducing the concept of a >>I/O scheduler that spawns KSE's to handle individual I/O requests is >>another possibility. > > > Well, the problem here is that requests which cannot be dealt with > due to resource shortages should be queued at the level where they > require least resources. A request queued inside a driver holds > far more resources than a request in the pure bio format at the > entrance to the driver for instance. Not necessarily. It's not hard for a driver to keep a request queued on the bioq and not consume and driver resources at all. > > And spawning KSE's in low memory situations is a recipe for suicide. > Probably true. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Aug 26 05:42:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B8B716A4CE; Thu, 26 Aug 2004 05:42:43 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD8A543D53; Thu, 26 Aug 2004 05:42:40 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i7Q5gWaL051891; Thu, 26 Aug 2004 07:42:40 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 25 Aug 2004 23:33:55 MDT." <412D7643.9000700@samsco.org> Date: Thu, 26 Aug 2004 07:42:32 +0200 Message-ID: <51890.1093498952@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Matthew Jacob cc: sos@freebsd.org cc: Scott Long cc: arch@freebsd.org Subject: Re: potential re change for 5.3? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 05:42:43 -0000 In message <412D7643.9000700@samsco.org>, Scott Long writes: >> Well, the problem here is that requests which cannot be dealt with >> due to resource shortages should be queued at the level where they >> require least resources. A request queued inside a driver holds >> far more resources than a request in the pure bio format at the >> entrance to the driver for instance. > >Not necessarily. It's not hard for a driver to keep a request queued on >the bioq and not consume and driver resources at all. Again it comes down to skill level of the driver writer, and no offense to present company, I'd rather just make sure it's very hard to be lazy in that context. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Aug 26 15:05:21 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF8B016A4CE for ; Thu, 26 Aug 2004 15:05:21 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D2A643D54 for ; Thu, 26 Aug 2004 15:05:21 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i7QG4N47007364 for ; Thu, 26 Aug 2004 11:04:23 -0500 Date: Thu, 26 Aug 2004 11:04:23 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: block/char major for 4.x? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 15:05:22 -0000 How does one go about reserving a block/char major number for a new device driver under 4.x? Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Thu Aug 26 15:17:27 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA6EF16A4CF for ; Thu, 26 Aug 2004 15:17:27 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C06A43D1D for ; Thu, 26 Aug 2004 15:17:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7QFIgnc007291; Thu, 26 Aug 2004 09:18:42 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <412DFE69.8090601@samsco.org> Date: Thu, 26 Aug 2004 09:14:49 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-arch@freebsd.org Subject: Re: block/char major for 4.x? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 15:17:27 -0000 Sam wrote: > How does one go about reserving a block/char major number > for a new device driver under 4.x? > > Cheers, > > Sam We don't like to reserve major numbers unless a driver is about to be committed. If you have such a driver that is tested and ready to go, you can post a link to it here or send it to someone like myself. If you need a major for private use or for development, you can use numbers 200-247. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Aug 26 16:35:53 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34E2F16A4CE; Thu, 26 Aug 2004 16:35:53 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF29D43D45; Thu, 26 Aug 2004 16:35:52 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i7QGZpR2009917; Thu, 26 Aug 2004 12:35:52 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040823153126.GB77326@green.homeunix.org> References: <20040823153126.GB77326@green.homeunix.org> Date: Thu, 26 Aug 2004 12:35:50 -0400 To: Brian Fundakowski Feldman , arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: erase/erase2 support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 16:35:53 -0000 At 11:31 AM -0400 8/23/04, Brian Fundakowski Feldman wrote: >... I went ahead and added support in [ncurses, nvi, and less], but >I think we need to decide if the proper course of action right now is >to get these changes accepted and finish implementing erase2; if we >don't try to support it pervasively, I don't feel it has very good >value. Fwiw, I would also like to see more programs support erase2. The one where I notice it the most is actually /usr/bin/mail... >It's a no-brainer to add support to nvi, since it's essentially "ours" >now to do what we want with. How many other OSen have erase2 support >such that the ncurses and less maintainers will see the value in it? I could have sworn that some OS had erase2 when jkh added it, but at the moment I can not find an example. Maybe it was just patterned after eol2, which shows up in at least linux and solaris. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Thu Aug 26 17:09:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F93416A4E8; Thu, 26 Aug 2004 17:09:41 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B48C643D45; Thu, 26 Aug 2004 17:09:41 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7QH9f8U028419; Thu, 26 Aug 2004 10:09:41 -0700 Message-ID: <412E1954.5030908@root.org> Date: Thu, 26 Aug 2004 10:09:40 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: arch@freebsd.org Content-Type: multipart/mixed; boundary="------------000200030206080107010709" Subject: Leave acpi enabled in panic shutdown case? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 17:09:43 -0000 This is a multi-part message in MIME format. --------------000200030206080107010709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It seems some people may get a 2nd panic when acpi is shutdown after a panic. I think it makes sense not to do the normal shutdown path if panicing. Is the correct way to check for this panicstr != NULL? The attached patch avoids calling AcpiTerminate() for the panic case. -Nate --------------000200030206080107010709 Content-Type: text/plain; name="panic.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="panic.diff" Index: acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.189 diff -u -r1.189 acpi.c --- acpi.c 23 Aug 2004 16:28:42 -0000 1.189 +++ acpi.c 26 Aug 2004 01:37:13 -0000 @@ -1365,7 +1365,7 @@ DELAY(1000000); printf("ACPI power-off failed - timeout\n"); } - } else { + } else if (panicstr == NULL) { printf("Shutting down ACPI\n"); AcpiTerminate(); } --------------000200030206080107010709--