From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 06:09:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B17A8EA1; Fri, 8 Aug 2014 06:09:48 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 25BC82FFA; Fri, 8 Aug 2014 06:09:47 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id s7869fer071624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 08:09:41 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id s7869fCL071621; Fri, 8 Aug 2014 08:09:41 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Fri, 8 Aug 2014 08:09:41 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: dteske@FreeBSD.org Subject: Re: loader lszfs command In-Reply-To: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> Message-ID: References: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-current@freebsd.org, avg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 06:09:48 -0000 On Thu, 7 Aug 2014 14:17-0700, dteske@FreeBSD.org wrote: > Hi, > > People have been pestering me to update the Forth code to present > a menu of ZFS datasets (*cough* boot environments *cough*). > > Would love to, but existing code seems broken. > > Can *anybody* produce meaningful output from the following? > > http://svnweb.freebsd.org/base?view=revision&revision=241284 > > All I get on every system I've tried (multiple versions, including HEAD) > produce the following: > > OK lszfs zroot > ZFS: i/o error - all block copies unavailable > operation not permitted > > It's really hard for me to start with something that's broken. Can > I get confirmation that this doesn't appear to be working as intended? > If so, I'll go ahead and try to fix it, but need to confirm that I'm ( a ) > not > crazy and ( b ) seeing the same thing everybody else is seeing. A bit on the side, but more user friendly: You should change the error message on line 335 to explain how to use lszfs, or add a "help lszfs" command. Instead of merely complaining about "wrong number of arguments", how about stating something like "wrong number of arguments, need at least pool name"? -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 08:33:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20763259 for ; Fri, 8 Aug 2014 08:33:05 +0000 (UTC) Received: from ivan-labs.com (ivan-labs.com [162.243.251.239]) by mx1.freebsd.org (Postfix) with ESMTP id EC433207C for ; Fri, 8 Aug 2014 08:33:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ivan-labs.com (Postfix) with ESMTP id B043F12083C; Fri, 8 Aug 2014 12:33:03 +0400 (MSK) X-Virus-Scanned: Debian amavisd-new at Received: from ivan-labs.com ([127.0.0.1]) by localhost (ivan-labs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dGxtUaYk+Rw; Fri, 8 Aug 2014 12:33:03 +0400 (MSK) Received: from [192.168.43.253] (host-63-159-66-217.spbmts.ru [217.66.159.63]) by ivan-labs.com (Postfix) with ESMTPSA id B185A120056; Fri, 8 Aug 2014 12:33:02 +0400 (MSK) Message-ID: <53E48B38.9010607@ivan-labs.com> Date: Fri, 08 Aug 2014 12:32:56 +0400 From: "Ivan A. Kosarev" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: libthr and main thread stack size References: <53E36E84.4060806@ivan-labs.com> <20140808052807.GB93733@kib.kiev.ua> In-Reply-To: <20140808052807.GB93733@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 08:33:05 -0000 On 08/08/2014 09:28 AM, Konstantin Belousov wrote: > On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote: >> Hello, >> >> According to libthr's thr_init.c (the 9.2 version) init_main_thread() >> allocates s.c. "red zone" below the main stack in order to protect other >> stacks. The size of the main stack is determined by the >> _thr_stack_initial variable that is declared extern though it doesn't >> seem it can be changed. The value of the variable is set to 4M on 64-bit >> platforms which is obviously not sufficient for the most of real programs. >> >> Can anyone please confirm that there is no way to increase the stack >> size for the main thread and thus any program linked against libthr has >> only a few megabytes of stack memory for its main thread--whatever the >> system stack size (ulimit -s) is set to? > Yes, there is no way to change the main thread stack clamping. > Could you provide a reasonable use case for the 4MB stack ? Traversing trees with recursive functions or on-stack grammar parsers? > > Anyway, I somewhat sympathize to the idea to stop clamping the main > thread stack, and to not reuse it for other threads stack carving. > This also means that non-main threads stack allocator should stop > tracking the explicit location for the stacks and rely on vm mmap(2) > base selection instead. Yes, that would solve the problem. > I do not know the motivations why the current scheme of stacks allocation > was chosen. The changes do not look too involved. Thanks a lot. --