Date: Fri, 8 Aug 2014 08:09:41 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: dteske@FreeBSD.org Cc: freebsd-current@freebsd.org, avg@freebsd.org Subject: Re: loader lszfs command Message-ID: <alpine.BSF.2.11.1408080805570.64214@mail.fig.ol.no> In-Reply-To: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org> References: <091101cfb284$f616cbb0$e2446310$@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <owner-freebsd-current@FreeBSD.ORG> 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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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" <ivan@ivan-labs.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Konstantin Belousov <kostikbel@gmail.com> 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 <freebsd-current.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>; List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=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. --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.11.1408080805570.64214>