Re: issues affecting kfreebsd d-i

[Robert Millan <rmh@debian.org>]

On 04/02/2014 12:50, Steven Chamberlain wrote:
> On 04/02/14 09:47, Robert Millan wrote:
>> On 04/02/2014 00:40, Steven Chamberlain wrote:
>>> On 04/02/14 00:34, Robert Millan wrote:
>>>>> Where are all these being downloaded to? The root ramdisk is constrained, but
>>>>> tmpfs isn't. We can mount that anywhere we'd like.
>>> I'm guessing /var/cache/anna in the ramdisk initially, but udpkg
>>> installs their contents one at a time all over the root filesystem.
>>
>> So we can get rid of almost half the problem by adding a single line to /sbin/init?
> 
> What do you mean?  A tmpfs for /var/cache/anna?
> 
> I imagined udebs are fetched to there, installed elsewhere and
> immeditaely cleaned, one at a time, so it probably won't help very much
> (only by as much as the size of the largest udeb).

Oh, I see.

> The stuff extracted throughout the filesystem will be more than half of
> the problem.  And I suspect there are other places where a tmpfs would
> be more helpful, perhaps where debconf templates are written for
> processing - I'll try to find a way to measure where most space is being
> used up.
> 
>> Sounds like a good start... and it doesn't preclude reducing the size in other
>> ways. What do you think?
> 
> In the case of a low-memory install it could actually need more memory
> than before.  If there's a fixed-size allocation already for the ramdisk
> (with free space inside it) and now a new allocation for anything
> written to the tmpfs.  If we did this we should try to shrink the
> ramdisk to compensate.

Or maybe use unionfs+tmpfs to create a new root hierarchy, then start
a jail on it (since we don't have pivot_root)? But that's probably a lot
more work...

-- 
Robert Millan