From owner-freebsd-arch@FreeBSD.ORG Mon Oct 18 15:12:20 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 24DAE16A4CE for ; Mon, 18 Oct 2004 15:12:20 +0000 (GMT) Received: from saturn.criticalmagic.com (saturn.criticalmagic.com [64.74.124.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1FEA43D55 for ; Mon, 18 Oct 2004 15:12:19 +0000 (GMT) (envelope-from rcoleman@criticalmagic.com) Received: from [10.40.30.144] (borg.ciphertrust.com [64.238.118.66]) by saturn.criticalmagic.com (Postfix) with ESMTP id 04D533BD5E; Mon, 18 Oct 2004 11:12:18 -0400 (EDT) Message-ID: <4173DD4F.1030501@criticalmagic.com> Date: Mon, 18 Oct 2004 11:12:15 -0400 From: Richard Coleman Organization: Critical Magic, Inc. User-Agent: Mozilla Thunderbird 0.7.3 (X11/20041008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Sommers References: <4171F702.9020405@gamersimpact.com> In-Reply-To: <4171F702.9020405@gamersimpact.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Removal of /stand Directory 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, 18 Oct 2004 15:12:20 -0000 Ryan Sommers wrote: > After a thread on current@ and private discussion following, myself and > the other party were in agreement that /stand serves no purpose after > the initial install. Most of /stand is duplicated in /rescue with the > exception of a few members. This makes the approx. 3mb of space consumed > by /stand wasted space. > > The only post-install dependency on /stand I can find is the diskless rc > script. This script uses /stand/cpio and /stand/gzip for unpacking > template archives to populate memory disks. I have come up with two > solutions that would solve this problem. The first involves /bin/pax and > moving gzip to /bin/gzip. This would be enough to unpack archives for > diskless systems. The other is to use /rescue/tar and /rescue/gzip. > > Currently /rescue uses gtar, however, this will likely be switched to > bsdtar after 5.3-RELEASE (see PR bin/72549). This will add cpio and pax > support to /rescue/tar (in addition to saving approx. 40k). I don't > believe using /rescue is the correct solution for diskless systems. > > Which is why I propose moving gzip to /bin. This would increase /bin by > about 46k. However, upon removing /stand the net would be a savings in > the root partition. /bin/pax and gzip are capable of handling the > diskless template archives and will also be updated as part of world to > receive any bugfixes. > > If people agree with this, after providing patches for moving gzip to > /bin I plan on addressing sysinstall to have /stand removed as part of > the post-install cleanup/configuration. And then after I'd like to work > on bringing our support and instructions for diskless environments up to > date with 5.X. > > Anyone have any thoughts, objections, feelings on this? If anyone has > already started work on this but doesn't have the time let me know and > I'd be happy to pick up where they left off. Otherwise I'm willing to > put in the grunt work if anyone is willing to help commit it once > 5.3-release is out of the way. Bsdtar has internal support for gzip/bzip2 compression. So, if the move was made to use bsdtar would this allow the diskless setup to no longer depend on gzip? Of course, the dependency on /lib/libz.so and /usr/lib/libz2.so would need to be dealt with. I'm not sure what that does to your diskspace calculations. Of course, I still find it odd that tar and cpio are in /usr/bin, but pax is in /bin. But that's a bikeshed for another day when we are really bored. Richard Coleman rcoleman@criticalmagic.com