From owner-freebsd-ports@FreeBSD.ORG Wed Feb 19 20:13:57 2014 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90805243; Wed, 19 Feb 2014 20:13:57 +0000 (UTC) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.234]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3E81FE0; Wed, 19 Feb 2014 20:13:57 +0000 (UTC) Date: Wed, 19 Feb 2014 21:13:54 +0100 From: vermaden Subject: RE: [patch] sysutils/beadm To: Andrew Hotlab X-Mailer: interia.pl/pf09 In-Reply-To: References: X-Originating-IP: 95.41.211.153 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1392840835; bh=iuknLm/oCYrpwiE5GT5xnHaCs7S5xkXLf8VP5KXOAvU=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=SDaxRja/dnSrc+JAHfdSnEv3/yX66op7Qy+A0qq0WXXCjCHBbSvXlP8vYytlcjEzA mVT1PuDh8sW1A8ybOimhIct2U5sQNrZ4Nwf2yU3DU/9YYi9chKUyYlpW4Hz/3673IF rqadr2L/1Vu0XvetKtxMlTPtoBd3vUrpKkZDYO+8= Cc: "ports@freebsd.org" , Bryan Drewery X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:13:57 -0000 Hi, I will try to test that patch then, I will reply when I'm done with info ab= out issues or info about commit ;) Regards, vermaden Od: "Andrew Hotlab" Do: "Bryan Drewery" ;=20 Wys=C5=82ane: 17:18 =C5=9Aroda 2014-02-19 Temat: RE: [patch] sysutils/beadm > ---------------------------------------- > > Date: Wed, 19 Feb 2014 07:27:45 -0600 > > From: bdrewery@FreeBSD.org > > To: andrew.hotlab@hotmail.com > > CC: ports@freebsd.org; vermaden@interia.pl > > Subject: Re: [patch] sysutils/beadm > > > > On 2/13/2014 4:19 PM, Andrew Hotlab wrote: > >> First of all, thank you very much for the good work with this port. I'= m sure it's changing the life of a lot FreeBSD system administrators! > >> > >> In my setup I have the following layout (several datasets for /usr, /v= ar, etc.): > >> > >> NAME USED AVAIL REFER MOUNTPOINT > >> sys 1.55G 18.0G 31K none > >> sys/ROOT 532M 18.0G 31K none > >> sys/ROOT/default 114K 18.0G 250M / > >> sys/ROOT/default/tmp 22K 18.0G 38K /tmp > >> sys/ROOT/default/usr 1K 18.0G 245M /usr > >> sys/ROOT/default/var 48.5K 18.0G 36.4M /var > >> sys/swap 1.03G 19.0G 16K - > >> > >> At this moment the utility does not seems to be able to manage this sc= heme, since it sets the mountpoint property as "legacy" for all datasets un= der the root, thus preventing to automatically mount any subdirectory at bo= ot. > >> I've tested this simple solution (to let do the job to the canmount pr= operty), and it seems to solve the problem without affecting the behavior w= hen all system folders are located under a single root dataset (please see = the patch below). I'd be glad if you'll include it in the next port revisio= n. > >> > > > > ACK on this. CC'ing upstream maintainer too. > > > > I run the same setup but I specifically set /usr /var and /tmp mntpoint= s > > to /usr,/var/,/tmp to avoid this issue. I am not sure if mntpoint=3D/ i= s > > proper. I recall there being an issue with it. I would much prefer your > > patch though if it is safe. > > > > Does beadm mount still work with this to mount a new BE into /tmp? > > > > Ie, > > > > beadm create newbe > > beadm mount newbe > > > > Does it go and remount / or only touch /tmp? > > >=20 > It seems to behave correctly, as you can see in the attached transcript. >=20 > > How about activating? Does it blow away / right away or wait until rebo= ot? >=20 > Since beadm changes only the "canmount" ZFS property to set the active en= vironment for the next reboot, there is no implications for the running env= ironment. >=20 > Regards >=20 > Andrew =20 =