[OE-core] [PATCH 3/3] wic: apply --extra-space + --overhead to squashfs

Enrico Scholz enrico.scholz at sigma-chemnitz.de
Tue Sep 12 09:44:02 UTC 2017


Ed Bartosh <ed.bartosh at linux.intel.com> writes:

>> >> The --extra-space and --overhead option did not had an effect to squashfs
>> >> partitions.  Although squashfs is read-only, it can be useful to allocate
>> >> more space for the on-disk partition to avoid repartitioning of the whole
>> >> disk when a new (and larger) squashfs image is written on later updates.
>> >
>> > Is it possible to just use --size or --fixed-size in .wks to allocate
>> > partition of certain size?
>> 
>> --fixed-size works with this patch (tested); --size should work.
>
> Sorry for not being clear. Why do we need this if we can use --size to
> explicity specify partition size?

--size and --fixed-size did not had an effect for squashfs with the old
code.


> --extra-space and --overhead have the same meaning as
> IMAGE_ROOTFS_EXTRA_SPACE and IMAGE_OVERHEAD_SIZE variables. From my
> point of view their purpose is to allocate additional space on the
> file system. This doesn't make sense for squashfs. That's the reason
> those options are not used for squashfs. Using them to implicitly make
> bigger partition is a questionable and possible confusing approach.

I want/need it to allow updates of the running system without complete
repartitioning.  E.g. at wic creation time, the squashfs has a certain
size.  Sometime in the future, there are needed e.g. 5 MiB more because
a new package was added or so.

I need to reserve space in the partition so that I can 'dd' the new
image without a complete repartitioning.

--extra-space/--overhead has the meaning which I want (e.g. to say
"reserve +20% for changes in the future").


>> I would keep it as is.  It is a non trivial function which is reusable.
>> Perhaps, somebody adds CRAMFS or another file system which does not
>> support extending its size.
>> 
>
> I personally find this much more understandable and logical:

me not ;) As I said, functionality is perfect for putting into an extra
method and it makes code much more readable.  When somebody implements
CRAMFS he can use this method instead of copy&pasting the code.


> Then introducing a method that will be called for all supported
> filesystems except squashfs without any effect.

You mean, function should be called at the end of prepare_rootfs()
(after "method(...)")?  Yes, it would reduce code duplication but other
methods needs to be touch too (to give information whether rootfs size
has been adjusted already).


Enrico
-- 
SIGMA Chemnitz GmbH       Registergericht:   Amtsgericht Chemnitz HRB 1750
Am Erlenwald 13           Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
09128 Chemnitz



More information about the Openembedded-core mailing list