From owner-freebsd-hackers@freebsd.org Tue Feb 21 14:11:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41B12CE75D4 for ; Tue, 21 Feb 2017 14:11:51 +0000 (UTC) (envelope-from t@tomoyat1.com) Received: from mail.tomoyat1.com (tomoyat1.com [133.130.119.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1665B132B for ; Tue, 21 Feb 2017 14:11:50 +0000 (UTC) (envelope-from t@tomoyat1.com) Received: from tomoyat1.com (60-56-201-126f1.shg1.eonet.ne.jp [60.56.201.126]) by mail.tomoyat1.com (Postfix) with ESMTPSA id B42D317DA for ; Tue, 21 Feb 2017 14:11:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tomoyat1.com; s=tomoyat1; t=1487686308; bh=gatqZjhiX/2s6jPM81Be9LWuTrV+FHb7JUFb51d+hGo=; h=Date:From:To:Subject:Message-ID:From:Sender:To:CC:Subject: Message-Id:Date; b=TANU5snOEB9uDvIPmsn64CY90VSd1YrJ9SVr14BOhblRN3Qd8SCrXvfYlzz3Wln6J ittQB999iAU9FYajGCHB9lp7rlljRIpHsbeS0SlqLZ+O16hmbcvuf5aUK6EaXQYuLh 5PEa4ZOeMOeBudjxjEOqTBQRqjvOGiYdYgVUitlw= Date: Tue, 21 Feb 2017 23:11:47 +0900 From: Tomoya Tabuchi To: freebsd-hackers@freebsd.org Subject: Re: GSoC Project Involving the reimplementation of beadm(1) Message-ID: <20170221141147.GB11545@tomoyat1.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20170220131509.GA31623@tomoyat1.com> <485A34F5-C747-498A-A0D1-04533603A54D@icloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <485A34F5-C747-498A-A0D1-04533603A54D@icloud.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 14:11:51 -0000 On Mon, Feb 20, 2017 at 12:52:03PM -0800, Jordan Hubbard wrote: > > > On Feb 20, 2017, at 5:15 AM, Tomoya Tabuchi > wrote: > > > > I would like to ask a few questions involving this. > > First, is there a particular reason why this project is listed in the > > ideas list? Aside the fact the current implementation in sh is rather > > complicated, I was unable to come up with a reason to justify the > > reimplementation. > > The current implementation of beadm is very slow and fragile - it writes to all previous boot environments when configuration changes are made which require the regeneration of config data, something which becomes slower as an O(n) property of the number of boot environments, and it does a poor job of handling any number of failure cases which can occur during this process. It provides also no “seat belts” for the pathological cases where the ZFS boot pool fills up or even approaches the 90% “storage cliff” where ZFS begins to exhibit pathological performance characteristics. I did not know about such problems. As for the part regarding the regeneration of config data. I'll look into the current implementation and see if I could come up with a better way to do things. As for the zpool approaching the "storage cliff", or filling up, it seems straightforward that a doing a usage check before each BE creation, and aborting if limits are exceeded, should suffice. I figure it will be worth searching the existing implementation for any other edge cases in need of "seat belts". > > It also provides no API other than the beadm(1) command itself, which makes it harder to control from 3rd party tools like FreeNAS (which uses beadm extensively). In order to provide an API to beadm, splitting the final product into 1. an underlying library that does the heavy lifting 2. an user-facing beadm(1) command that will make use of the library could be a solution. IIRC this is sort of like what is done in libzfs and the zfs commands. > > It’s on our (iXsystems) own long-term list of things to rewrite from scratch, but we haven’t managed to find the time or resources. If someone else wanted to do so, we’d be enthusiastic co-conspirators! Thank you! I'll do some more research, write a project proposal, and post it on this list when the time comes. I would appreciate it very much if I could then have feedback from you. > > - Jordan > > Thank you, Tomoya