DLoop comments

Matt Zimmerman mdz at ubuntu.com
Wed Sep 28 15:53:02 CDT 2005


On Wed, Sep 28, 2005 at 02:51:14PM -0400, Phillip Susi wrote:
> I wasn't sure if I should comment on this by adding to the wiki or here, 
> but I decided to go with here.
> 
> I have read over this Wiki proposing changes for ubuntu express, and it 
> seems overly complex to me.  I have some comments and a much simpler 
> proposal.

Which wiki page(s) are you referring to here?

> One issue this Wiki discusses is freeing unused cloop blocks.  As it 
> says, this is easily done when initially building the cloop image by 
> running a utility to zero out all unused blocks.  Once the livecd is up 
> and running, the solution to this problem seems that it should be as 
> simple as having the filesystem zero out freed blocks, and have the 
> snapshot device mapper notice when it gets an all zero block written to 
> a page that has been COW'd it can discard the memory.  That should be a 
> rather simple thing for the mapper device to do.

A block containing all zeroes is perfectly valid data, and the system can't
treat it as a signal to revert to the old, pre-COW data (which itself isn't
necessarily all zeroes).  Indeed, having the filesystem zero out unused
blocks would actually increase the number of COW actions, in the natural
course of modifying and deleting files which are included in the base cloop
image.

Addressing this issue is not as simple as it sounds.  Fortunately, there are
some alternative technologies available which we are experimenting with to
increase performance here (including unionfs and squashfs).

> The rest of the Wiki seems to be about the debs.  It seems to me that a 
> simple solution would be to modify dpkg so that it can remove the 
> binaries from the .deb once installed.  Then when you go to install the 
> package on another filesystem, it can simply pull the binaries back from 
> where they were installed to the first time.  That would avoid the 
> duplication of binaries in both the .deb and the livecd filesystem, and 
> shouldn't be very difficult to implement.

I'm not sure that I understand your suggestion correctly, but it does not
sound at all straightforward to implement.  Certainly the current planned
solution (installing by copying the preinstalled filesystem) is much simpler
and more robust.

-- 
 - mdz



More information about the ubuntu-devel mailing list