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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
