Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jan 2017 10:33:20 +0100 (CET)
From:      =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no>
To:        "Brandon J. Wandersee" <brandon.wandersee@gmail.com>
Cc:        Arthur Chance <freebsd@qeng-ho.org>, FreeBSD-Questions <freebsd-questions@freebsd.org>
Subject:   Re: Boot environments and /var - what should be shared/unshared?
Message-ID:  <alpine.BSF.2.20.1701181027500.1006@mail.fig.ol.no>
In-Reply-To: <86h94xcf78.fsf@WorkBox.homestead.org>
References:  <c7e9a10b-4794-27af-27da-5a8e8c483aee@qeng-ho.org> <86h94xcf78.fsf@WorkBox.homestead.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 17 Jan 2017 19:46-0600, Brandon J. Wandersee wrote:

> Arthur Chance writes:
> 
> > I've been using beadm boot environments for a while now, but still
> > haven't seen a definitive reference for which parts of /var should be
> > shared across boot environments and which should be per environment. Is
> > there such a document, or is everybody still busking it?
> >
> > Some top level directories in /var seem fairly obviously in need of
> > sharing, others less so, and /var/db seems to be a horrible mix of stuff
> > that could be shared across releases and stuff that might break horribly
> > if shared over major revisions. (That's "might" because I have no idea
> > if it would in practice.)
> >
> > I doubt whether any of this would matter (except for space) if one
> > simply rolled forward monotonically, but a roll back because of
> > problems, or simply switching between development environments, could
> > lose necessary updates if the directory hadn't been shared when it
> > should have been.
> 
> I suppose I can't give you a "definitive reference," but I selected
> things to omit from boot environments based on advice in the book
> /FreeBSD Mastery: Advanced ZFS" by Michael W. Lucas and Alan
> Jude. Here's what I've got, follow by the reasoning behind it:
> 
> |  NAME                     USED  AVAIL  REFER  MOUNTPOINT
> |  workbox/VARIABLE        3.82M  72.5G   144K  none
> |  workbox/VARIABLE/crash   144K  72.5G   144K  /var/crash
> |  workbox/VARIABLE/log    2.86M   497M  1.80M  /var/log
> |  workbox/VARIABLE/mail    340K  72.5G   196K  /var/mail
> |  workbox/VARIABLE/tmp     360K  72.5G   144K  /var/tmp
> 
> 
> 1. /var/crash, /var/tmp: The contents of these directories are supposed
>                          to store non-volatile data, some of which is
>                          relevant to recovery. You don't want it
>                          disappearing after a reboot, or want to have to
>                          find and mount an extra ZFS dataset in order to
>                          access it.
>    
> 2. /var/mail, /var/log: Mail and logs are generated by applications as
>                         well as the base system, and are
>                         time-sensitive. You don't want these skipping
>                         around through time at all, but it's more
>                         egregious if you lose a day's worth of logs for
>                         your web server because something in the base
>                         system got messed up. That's exactly the sort of
>                         thing the BSD filesystem hierarchy was designed
>                         to prevent in the first place.
> 
> 
> I've also got a couple datasets mounted in /var, but as children of
> another tree:
> 
> |  workbox/APPS           6.26G  72.5G  5.42G  /usr/local
> |  workbox/APPS/config    7.17M  72.5G  6.22M  /usr/local/etc
> |  workbox/APPS/pkgCache   238M  2.77G   236M  /var/cache/pkg

> |  workbox/APPS/pkgDB      162M  72.5G  81.5M  /var/db/pkg

If you decide to use base as a set of packages, as proposed for 
11.1-RELEASE, I would reconsider having /var/db/pkg and the /usr/local 
subtree as separate datasets/filesystems. It might be better to treat 
base and 3rd party packages as a whole, due to 
/var/db/pkg/local.sqlite recording everything installed in the system.

> This way I can roll back package upgrades all at once without touching
> anything else on the system. I used to handle packages/ports within boot
> environments, but decided to separate them once I realized that doing so
> could make them grow pretty large with successive upgrades. Having your
> ports/packages tied to boot environments is really only useful when
> tracking -CURRENT or performing a major version upgrade, so I see it as
> a waste to constantly take up space in preparation for something that
> happens once every couple years, for which I'll have ample warning and
> preparation.
> 
> Someone else might come along with better ideas, but I suspect a lot of
> it depends on taste and personal need.

-- 
+-------------------------------+------------------------------------+
| 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-questions@freebsd.org  Wed Jan 18 12:35:23 2017
Return-Path: <owner-freebsd-questions@freebsd.org>
Delivered-To: freebsd-questions@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 A984DCB4CD8;
 Wed, 18 Jan 2017 12:35:23 +0000 (UTC) (envelope-from slw@zxy.spb.ru)
Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98])
 (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 60185197F;
 Wed, 18 Jan 2017 12:35:23 +0000 (UTC) (envelope-from slw@zxy.spb.ru)
Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD))
 (envelope-from <slw@zxy.spb.ru>)
 id 1cTpSN-000Fa9-Ce; Wed, 18 Jan 2017 15:35:15 +0300
Date: Wed, 18 Jan 2017 15:35:15 +0300
From: Slawa Olhovchenkov <slw@zxy.spb.ru>
To: "O. Hartmann" <o.hartmann@walstatt.org>
Cc: Daniel Kalchev <daniel@digsys.bg>, "O. Hartmann" <ohartmann@walstatt.org>,
 freebsd-current <freebsd-current@freebsd.org>,
 freebsd-questions <freebsd-questions@freebsd.org>
Subject: Re: ISO image: where is the CLANG compiler?
Message-ID: <20170118123515.GE58505@zxy.spb.ru>
References: <20170118084502.617bfc94@freyja.zeit4.iv.bundesimmobilien.de>
 <A73ED94A-89CE-41C5-98D2-F1611476797B@digsys.bg>
 <20170118101915.523d7d7b@freyja.zeit4.iv.bundesimmobilien.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170118101915.523d7d7b@freyja.zeit4.iv.bundesimmobilien.de>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: slw@zxy.spb.ru
X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false
X-BeenThere: freebsd-questions@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: User questions <freebsd-questions.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-questions>, 
 <mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions/>;
List-Post: <mailto:freebsd-questions@freebsd.org>
List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-questions>, 
 <mailto:freebsd-questions-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 12:35:23 -0000

On Wed, Jan 18, 2017 at 10:19:15AM +0100, O. Hartmann wrote:

> Hello Daniel,
> 
> thank you very much for responding!
> 
> I just looked into "makeing release". I have a lot of NanoBSD images and build
> environments for our purpose at work, but I always strip off the compiler,
> too :-(
> 
> I was realy badly surprised that on the ISOs the compiler is not present - for
> the sake of space? If so, then best practice would be to melt everything down
> to 1,66 MB size - as an ancient floppy would contain. Or better, Null.
> Sorry ... It is hard these days to purchase 1GB USB flash drives, most of them
> do have 2 GB at least.

ISO images limited by size, for fit to real CD-R blank disks.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1701181027500.1006>