Date: Tue, 21 Feb 2017 23:11:47 +0900 From: Tomoya Tabuchi <t@tomoyat1.com> To: freebsd-hackers@freebsd.org Subject: Re: GSoC Project Involving the reimplementation of beadm(1) Message-ID: <20170221141147.GB11545@tomoyat1.com> In-Reply-To: <485A34F5-C747-498A-A0D1-04533603A54D@icloud.com> References: <20170220131509.GA31623@tomoyat1.com> <485A34F5-C747-498A-A0D1-04533603A54D@icloud.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 20, 2017 at 12:52:03PM -0800, Jordan Hubbard wrote: > > > On Feb 20, 2017, at 5:15 AM, Tomoya Tabuchi <t@tomoyat1.com <mailto:t@tomoyat1.com>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170221141147.GB11545>