On 15 November 2013 00:12, Stéphane Graber <[email protected]> wrote: > On Fri, Nov 15, 2013 at 12:04:45AM +0000, Dmitrijs Ledkovs wrote: >> On 14 November 2013 17:55, Ricardo Salveti de Araujo >> <[email protected]> wrote: >> > On Wed, Nov 13, 2013 at 7:16 PM, Dmitrijs Ledkovs <[email protected]> wrote: >> >> Dear all, >> >> >> >> I've raised a merge proposal below, to allow initramfs to mount system >> >> partition direct as an ubuntu rootfs. >> >> At the moment this is a fallback, as apart from the emulator, it's not >> >> possible to have a large enough system partition to hold ubuntu >> >> rootfs. >> >> >> >> A matching patch for build/ android project is attached as a file. >> >> >> >> The patch for the emulator package changes the behaviour slightly: >> >> * sdcard.img is dropped >> >> * ubuntu-system.img & ubuntu-userdata.img are generated >> >> * if no options specified: ubuntu-system.img is embedded inside >> >> ubuntu-userdata.img & normal (loop) based mount is performed >> >> >> >> * if "-no-loop" is specified to the build script, ubuntu-system.img is >> >> not embedded. >> >> >> >> ubuntu-system.img is provisioned as the system.img (/dev/mtdblock0) >> >> and ubuntu-userdata.img is provisioned as userdata.img >> >> (/dev/mtdblock1). >> >> >> >> Once booted without loop both / and /userdata are normal partitions >> >> (this is in RW mode) >> >> /dev/mtdblock1 on /userdata type ext4 (rw,relatime,data=ordered) >> >> /dev/mtdblock0 on / type ext4 (rw,relatime,data=ordered) >> > >> > I just don't yet understand why we want to support this path, as we >> > already support cdimage based images ("flipped" model), and >> > system-image (ro and rw). >> > >> >> I don't necessary propose to have this implementation as >> endorsed/supported. It's rather experimentation / exploration at this >> point. >> >> The way system image is organised at the moment (with loop mounts) is >> not because that's how our ideal device would ship, but rather due to >> constraints of the existing partitioning layouts of the Nexus/android >> devices. >> >> Ideally we'd want to mount rootfs in the initramfs and hand-over to >> mountall to mount the rest in-parallel. And similarly loop-mounted >> partitions at the moment, cause shutdown - unmount ordering >> complexities. >> >> > If lack of disk space is the only issue, you could just boot using the >> > "flipped" model instead (but there's also a partition size limit as >> > well, as it's mtd). >> > >> > If you want to just use system-image model, without changing much, you >> > could simply increase the sdcard image size (as it's a "real" mmc >> > device). >> > >> >> For the emulator disk-size is not an issue. Unused partitions on the >> real devices (because they are too small to achieve what we want) or >> wasted space (because a partition is too large) is a problem. Disk >> space will be at premium, and we should come up with optimal >> partitioning schemes going forward. >> >> We do need defined locations for: >> * kernel + initramfs (possibly abootimg format?) >> * RO system image >> * RW customized data >> * image update storage location >> * recovery locations >> * .... >> >> At the moment RO system-image is stored on an always RW-mounted >> partition. Which doesn't feel right. >> >> > Now if you say you want to support the repartition model we discussed >> > before implementing the system-image loop-based format, I'd first like >> > to discuss how our partitioning scheme would look like :-) (e.g. do we >> > want more than one partition?) >> > >> >> At the moment I'm trying to enable something were we can play around >> unconstrained with partitions. Roughly I'm going by at the moment that >> we would want to be able to mount & use partitions direct, have >> ability to use multiple partitions, and have a GPT partition table. >> >> Gathering all partitioning requirements, discussing and settling for a >> strategy is something that still needs to be done. But it shouldn't >> delay a prototype where repartition models can be tried out. >> >> (one partition - formatted as LVM Volume Group?! =) that gets >> mentioned from time to time) >> >> >> Note that android container is still launched from a loop-mounted >> >> .img. I will check if it would be possible to supported unpacked >> >> android container under /var/lib/lxc/android/rootfs >> > >> > Should be, but why would we want that? >> > >> >> Faster boot time >> - no need to loop-mount android-system, and unpack initrd inside that, >> at initramfs time. >> - less time in initramfs, means we can start the container earlier as >> soon as rootfs is available. >> >> Tiny memory usage win - since lxc container is started from disk >> instead of tmpfs. (~0.5MB) >> >> Also in RW mode it will make it easier to change the android container. > > That's a bad idea. > > I agree that it'd be a good thing to avoid the android system.img blob > as that'd make delta images a whole lot more useful for the device > tarball, however, the unpacking of the initrd in a tmpfs remains > important. > > Basically Android expects it's / to be read-write and to be a ramfs, the > closest thing to that we can provide is the current tmpfs onto which we > unpack the initrd and then bind-mount all the partitions. > > > So my recommendation here would be to stick to the initrd + tmpfs > method, possibly moving from a compressed initrd to an uncompressed > tarball if that gives us significant speed benefits (I doubt it, since > the current extraction time is pretty quick). > > But we definitely should be looking into shipping the Android system > partition as a tree on the filesystem and have this bind-mounted instead > of doing the current ext4 image + loop. I don't think we'll see much > speed benefit by doing so, but we will see a drastic reduction in device > tarballs delta size (they're currently around 30MB no matter what > changed, with that change done, they should be around 10MB + whatever > actually changed). >
Ok, agree. Regards, Dmitrijs. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
