Re: thoughts about adding tmpfs support to live-helper
On 05/21/2010 04:25 PM, Jiří Paleček wrote:
> there are various other
> opportunities for speed up - for one thing, the chroot/chroot device
> does not help, etc.
chroot/chroot is required in order to ensure to not taint the target
system with the host systems tools (especially when building a diffrent
distribution than the computer is running, e.g. unstable on stable).
if you know any other way that doesn't have special requirements on the
host machine (like having aufs installed), i really like to know it. in
all those years, everyone came up with 'we can make it much faster by
dropping chroot/chroot', and yet nobody did come up with a mechanism
that ensures untainted images.
besides.. for those that know what they are doing (e.g. they are sure
that their host dist is the same as the target distribution), they can
disable chrooted build. this is present since about two eterneties.
> I disagree. First, the tmpfs could only be useful for binary and chroot
> (and probably .stage).
having cache not on the tmpfs means, that we can't use hardlinking, and
all the speed benefits are gone anyway.
> I'm not sure you actually mean storing cache on
> tmpfs - I always thought that was something that should survive the
> whole build.
s/whole build/several builds with a possible shutdown in between/
so we're copying out one we unmount. that's still faster than not using
hardlinking and copying arround multiple times.
> Second, "moving things around in a hackish way" actually
> means some 5 commands - a mount, and two bind mounts, or, if you mind,
> symlinks.
hackish way i was refering to is this:
mkdir foo
cd foo
lh config
mv ../foo ../bar
mkdir ../foo
mount -t tmpfs live-tmpfs ../foo
mv ../bar/* ../foo
rmdir ../bar
lh build
to avoid that, i said i think it's better to setup the tmpfs within the
directory we're building in (apart from the fact, also the binary images
would end up in the tmpfs, which is exactely what we don't want).
> Are you serious that changing locations almost everywhere is
> more appropriate than this?
yes. unless you have a better idea (please show pseudo-code to discuss it).
>> ..what do you think about such a layout change?
>
> I think it is unneeded, and will do nothing good, apart from introducing
> bugs. There are enough of them
which one? please fill bug reports for those that are not yet filled.
> plus functionality defects (eg. grub+usb
> is impossible) that would be worth fixing first.
appears to be non-trivial, any help welcome.
--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baumann@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/
Reply to: