ubuntu-phone team mailing list archive

[Dmitrijs Ledkovs <xnox@xxxxxxxxxx>]

On 15 November 2013 00:12, Stéphane Graber <stgraber@xxxxxxxxxxxx> wrote:
> On Fri, Nov 15, 2013 at 12:04:45AM +0000, Dmitrijs Ledkovs wrote:
>> On 14 November 2013 17:55, Ricardo Salveti de Araujo
>> <ricardo.salveti@xxxxxxxxxxxxx> wrote:
>> > On Wed, Nov 13, 2013 at 7:16 PM, Dmitrijs Ledkovs <xnox@xxxxxxxxxx> 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.