• 2007
  • March
  • 23
  • More disks is the answer (maybe) (One for portage and one for sugar...)

More disks is the answer (maybe) (One for portage and one for sugar...)
Written by on in Young Coders.


I can be a bit dense sometimes. Splitting out the portage directories onto a separate disk allows users to skip downloading them if they don't want them. Splitting off the Sugar directories would allow the developer to update to a new Sugar "release" with just a few tens of megabytes more. That would let developers keep up-to-date without needing to work with sugar-jhbuild build.

I'd been thinking of doing the install as an ebuild for the Gentoo machine, but that won't work when we move to an FC7 image.

[Update] Hitting the "slow down" button on the Developer Image creation stuff for right now. The Tuquito group is apparently producing a LiveCD that uses AUFS to let you run the developer's image from the CD while writing to a USB or filesystem. More information as that develops.

Comments

  1. Tim

    Tim on 03/27/2007 4:36 a.m. #


    For testing installations of the hotspot software I continue to be plagued with developing, I have evolved a not-too-bad system using Qemu and layered disk images. It's actually extremely simple to do ... once one figures out the command line switches. Basically I create a base disk image and install the O/S and do minor configuration (compressed qcow2 format... somewhat slow, but fairly space efficient). Then I create an application disk image "based" on the o/s image to run the hotspot installer on. The O/S image remains is immutable; so if i need to reinstall the app i just create a new app disk image, and i'm ready to go on top of the still-pristine O/S image.<br />
    <br />
    Most of the time I use nfs to mount my desktop working directory inside the Qemu instance as /cdrom... but use an ISO release image passed to qemu as a physical device for final testing.<br />
    <br />
    It's proved to be much more convenient than the wrangling I used to do with your old box (which sits here gathering dust)... <br />

  2. Mike Fletcher

    Mike Fletcher on 03/27/2007 10:56 a.m. #


    Should it be necessary for me to continue (it doesn't seem likely, given that two other groups are now building developer's images) I'm likely going to use an AUFS for the root filesystem and build on top of that. The biggest issue seems to be Linux's use of the disk. A large virtual vmware disk gets written to the end before old sectors get used up.<br />
    <br />
    Because I'm working in the image (and running lots of build and replace operations) the image grows despite most of the space being used for deleted files. I'm guessing the same will happen even with an aufs system (or a cow under qemu). That said, a simple load using a live CD then cp -a seems to "compress" the image back to just the final file-set for a given file-system.<br />
    <br />
    I think VMWare also has a "base this image on that image" flag that would do the same as the Qemu thing, but again, I'm assuming it would also "fill out" the overlay disk over time.

Comments are closed.

Pingbacks

Pingbacks are closed.