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

[Ed Bartosh]

On Tue, Sep 12, 2017 at 11:44:02AM +0200, Enrico Scholz wrote:
> 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.
>

I'd propose to fix this instead of applying extra space and overhead
factor to the filesystems that don't support this by design.

The idea is to make size and fixed-size parameters to set partition size
and use extra-space and overhead-factor to extend filesystem size as
they're currently used.

> 
> > --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.
>

Yep, I understood what you want. I think it's better achieved by setting
partition size with --size option than artificially apply extra-space and
overhead factor to the filesystem that doesn't support this.

> 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").
> 

So far extra-space and overhead factor were used to allocate additional
space on the file system. This is different from the way you want to use
them. You're not allocating space on squashfs, you're allocating
unformatted space on the partition. It's better to use --size for this.

> >> 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.
> 

When somebody implements something that would require this functionality
he/she can create this method instead of copy&pasting the code. Let's
not try to solve problems before they arise as they may never arise :)

> > 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).
> 

I mean that method is called for all possible filesystems, but makes
sense only for squashfs. It makes code less understandable for no
reason. When code is used in the only place it's much more easy to
understand from my point of view.

--
Regards,
Ed