Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Jan 2010 20:39:11 +0200
From:      David Naylor <naylor.b.david@gmail.com>
To:        freebsd-current@freebsd.org
Subject:   Re: "tinderbox" using stacked unionfs
Message-ID:  <201001252039.16220.naylor.b.david@gmail.com>
In-Reply-To: <201001231233.18832.naylor.b.david@gmail.com>
References:  <201001231233.18832.naylor.b.david@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1671660.s51KELAnJF
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Saturday 23 January 2010 12:33:14 David Naylor wrote:
> Hi,
>=20
> I have been experimenting with using unionfs to build ports in a
>  "tinderbox" environment.  This avoids having to remove and extract files
>  for the build of each port and it allows the discovery of
>  installed/modified files by the port.
>=20
> Please see attached for a (updated) shell script that handles all the
>  "heavy lifting" of building ports.  Of importance is LOCALBASE and
>  BUILDDIR.  If you want to override LOCALBASE please use `env` as the
>  script needs to know about it.  BUILDDIR (/usr/build by default) is where
>  the script stores everything (including PKG_DBDIR).

Please see attached for an updated script.  This no longer uses `sort -u` b=
ut=20
removed duplicates while maintaining dependency order.  (See below)

> # env LOCALBASE=3D/tmp/local BUILDDIR=3D/tmp/build ./ports-union-builder.=
sh
>=20
> Will install x11/xorg without affecting already installed systems.
>=20
> CURRENT STATUS:
>  - *** Currently kernel stack size is too small and the above will trigger
>  a stack overflow.  Recompiling a kernel with ``options KSTACK_PAGES=3D32=
''
>  will alleviate that problem.

In building xorg there were at least 207 stacked unionfs (206 ro, 1 rw, all=
=20
noatime). =20

>  - Currently there is a build problem that affects eggdbus/polkit (possib=
ly
> others) thus preventing x11/xorg from being built.  I will investigate the
> cause (help welcome).

This is due to not mounting the dependencies in the correct order.  If=20
dependency 'a' modified file from dependency 'b' then mounting in order 'a'=
,=20
'b' will result in those changes being lost as the original files from 'b'=
=20
will supersede 'a'.  The dependencies need to be mounted 'b', 'a'. =20

This has been fixed although may cause a problem if multiple "independent"=
=20
ports modify the same file.  This is a detectable problem. =20

>  - I highly recommend running this in a chroot
>  - NO WARRANTY, SLIPPERY WHEN WET, EATS CHILDREN.

 - I am experiencing process freeze (anything involved in the directories t=
hat=20
are unionfs).  Any way that I can figure out the problem?  I can run a kern=
el=20
will full debug capability. =20
 - mtree does not behave well with unionfs and consumed a fair amount of=20
resources:
# /usr/sbin/mtree -U -f /usr/ports/Templates/BSD.local.dist -d -e -p=20
/usr/local/
took a long time (many minutes) to complete. =20

> Since the script doesn't complete a full build I am unable to compare the
> build speeds (thus the overhead of unionfs) but here are some partial
>  results (with FORCE_MAKE_JOBS and quad core):

The script is now able to complete building but not at once due to process=
=20
freezing.

Please help with debugging the process freezing.  (There is a LOR I have=20
reported for unionfs: kern/141950)

Regards

David

--nextPart1671660.s51KELAnJF
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)

iEYEABECAAYFAktd5VQACgkQUaaFgP9pFrL67wCfdjKnUsfNxGYIgHXQBu7LeEka
SvkAnjc6BOd0Nl9W2agsKjox52t+7Sgr
=Hh/M
-----END PGP SIGNATURE-----

--nextPart1671660.s51KELAnJF--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001252039.16220.naylor.b.david>