[OE-core] [PATCH] wic: add --reserved-size wks option

[Maciej Borzęcki]

On Tue, Oct 18, 2016 at 4:24 PM, Ed Bartosh <ed.bartosh at linux.intel.com> wrote:
> On Tue, Oct 18, 2016 at 03:59:23PM +0200, Maciej Borzęcki wrote:
>> >> >> >> > What's the advantage of creating unusable gap over creating partition of
>> >> >> >> > the same size that can be used?
>> >> >> >>
>> >> >> >> Just convenience.
>> >> >> >>
>> >> >> > What's the convenience of having extra space on partition that can't be
>> >> >> > used for data over having it formatted and used?
>> >> >> >
>> >> >> >> > Even if that space is not needed it doesn't harm to have it, does it?
>> >> >> >>
>> >> >> >> I have not seen any negative side effects.
>> >> >> >>
>> >> >> > I do. If user needs that reserved space it's impossible to get it without
>> >> >> > reformatting partition. The free space exists, but can't be used.
>> >> >>
>> >> >> That's not the point and is not aligned with use case I'm trying to solve.
>> >> >>
>> >> >> My case is rather simple, I'm creating an image for SD card that is
>> >> >> deployed in the field. In that particular case, there's a primary and
>> >> >> a secondary (aka. active and inactive) rootfs partitions that are
>> >> >> switched whenever a system update comes in. The update is a file
>> >> >> system image that is copied over to the inactive partition, followed
>> >> >> by a system reboot.
>> >> >>
>> >> >> What I need is the ability to set a certain size of a partition (say
>> >> >> 100MB), regardless of current rootfs size (which may be, say 70MB).
>> >> >> The remaining unused space sets an upper limit on how much the rootfs
>> >> >> may grow in the future (in this example case, it's 30MB). RIght now
>> >> >> the best I can do is to describe a partition like this: `part /
>> >> >> --source rootfs --size 100MB --overhead-factor 1`, hoping that if
>> >> >> rootfs grows beyond 100MB I will somehow still be able to catch that
>> >> >> and that the future images remain size compatible.
>> >> >>
>> >> >> The resulting filesystem inside the partition is larger than what
>> >> >> IMAGE_CMD (ex. IMAGE_CMD_ext4) would give me, because of explicit
>> >> >> --size in kickstart. I would prefer to have something comparable in
>> >> >> size just to avoid later surprises, what implies using defaults.
>> >> >> However, using defaults, means that I cannot control the layout
>> >> >> because it will likely change each time rootfs size gets changed.
>> >> >> There is no `--fixed-size` or other option to enforce specific size.
>> >> >>
>> >> >> Summing up, a simple use case that cannot be currently solved using wic.
>> >> >>
>> >> >> BTW. actually we're missing an ability to enforce --size (i.e.
>> >> >> --fixed-size?) and a method passing an explicit partition offset
>> >> >> inside the disk image (something useful for `--source rawcopy
>> >> >> --no-table` partitions, currently solved with `--align`).
>> >> >>
>> >> > I undertood the problem and I agree that wic doesn't provide a solution.
>> >> >
>> >> > However, instead of making unformatted space I'd propose to format it,
>> >> > i.e. to have --max-size option that would confict with --size and
>> >> > specify upper size limit for the partition. All partition will be
>> >> > formatted and available for data. This is identical to --fixed-size option
>> >> > you've described. This approach would solve the problem you're
>> >> > addressing and it would also make additional space usable.
>> >> >
>> >> > I'd also suggest to rename --size to --min-size and make --size deprecated.
>> >> >
>> >> > Does this make sense to you?
>> >>
>> >> No strong opinions here, just that deprecating --size might current
>> >> users uneasy.
>> >>
>> > By deprecting --size I didn't mean removing it completely. We can just
>> > print a warning suggesting usage of other options.
>> >
>> >> Perhaps --max-size could be a boolean switch? We could just name it
>> >> --fixed-size (bool, defaults to False), with semantics that if
>> >> --fixed-size is provided, the partition will have size --size,
>> >> occurrence of --overhead-factor or --extra-space will raise an error.
>> >>
>> > That would work too, but it looks a bit confusing to me to have 2 different
>> > types of size-related options.
>>
>> Ok, but now we would have --min-size (previously known as --size) and
>> --size (or --max-size?). That's still 2 size related options plus a
>> deprecation warning.
>>
>
> I agree, it doesn't look good. Moreover --max-size doesn't make it
> clear that partition will be this size. It rather suggests that partition
> can be this size or less.
>
> So, we have --size which is actually minimum partition size, we have
> couple of options to extend partition size (--overhead-factor and
> --extra-space), but we don't have ability to set upper limit for partition
> size.
>
> OK, let's agree on using --fixed-size(int)
> Using --fixed-size with any of --size or --overhead-factor or --extra-space
> options should raise ks parser error. If rootfs size is bigger than
> --fixed-size wic should raise an error too.
>
> Any other opinions?

Sounds good. I'll try to post a patch in the next couple of days.

Cheers,
-- 
Maciej Borzecki
RnDity