From: Ed Bartosh <ed.bartosh@linux.intel.com>
To: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 3/3] wic: apply --extra-space + --overhead to squashfs
Date: Tue, 12 Sep 2017 15:57:20 +0300 [thread overview]
Message-ID: <20170912125720.lj6rwuclmbrd6fx2@linux.intel.com> (raw)
In-Reply-To: <lya820f6u6.fsf@ensc-virt.intern.sigma-chemnitz.de>
On Tue, Sep 12, 2017 at 02:18:41PM +0200, Enrico Scholz wrote:
> Ed Bartosh <ed.bartosh@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.
>
> For what is this overhead to be used? In most cases, to allow future
> updates. And this is required for squashfs too.
>
It depends on the usage scenario. Additional space may be required
for other purposes too. It may me needed for the system to be able to
boot and perform what it was built for.
> Only difference is, that updates for squashfs are to be applied on
> partition level and these for other file systems on file system level.
> But the need for extra space exists in both cases.
>
>
> >> 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.
>
> It really does not matter for me whether the filesystem itself can be
> extended or whether I need a larger partition to apply future updates.
>
It matters for me. I think I explained why.
> I just need a partition which provides an absolute or relative amount of
> additional space.
>
>
> >> 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.
>
> No; --size is not what I want. --size (or --fixed-size) assume that I
> know the absolute size.
>
> Of course, I can get this size empirically. But it is highly inflexible
> and requires different wks files for different image types.
>
> I want to reserve an extra percentage for future updates. And these
> percentages can be in the range of 1 - 5 MB (for small images with
> only test tools) or several hundred MB (for large image types with
> e.g. desktop environments).
>
> --size or --fixed-size for these image types would be in completely
> different ranges while --extra-space/--overhead fits to all.
>
I agree. --size is less suitable for your needs than extra space and
overhead factor. I still don't like the idea of using them to reserve
non-formatted space. Any other ideas how to do it?
--
Regards,
Ed
next prev parent reply other threads:[~2017-09-12 12:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 17:33 [PATCH 0/3] wic: enhanced bootimage + squashfs support Enrico Scholz
2017-09-08 17:33 ` [PATCH 1/3] wic: accept '-' in bitbake variables Enrico Scholz
2017-09-08 17:33 ` [PATCH 2/3] wic: allow multiple /boot partitions with different content Enrico Scholz
2017-09-08 17:33 ` [PATCH 3/3] wic: apply --extra-space + --overhead to squashfs Enrico Scholz
2017-09-11 13:41 ` Ed Bartosh
2017-09-11 14:04 ` Enrico Scholz
2017-09-12 8:53 ` Ed Bartosh
2017-09-12 9:44 ` Enrico Scholz
2017-09-12 11:48 ` Ed Bartosh
2017-09-12 12:18 ` Enrico Scholz
2017-09-12 12:57 ` Ed Bartosh [this message]
2017-09-12 13:23 ` Enrico Scholz
2017-09-13 12:10 ` Ed Bartosh
2017-09-11 20:00 ` [PATCH v2 " Enrico Scholz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170912125720.lj6rwuclmbrd6fx2@linux.intel.com \
--to=ed.bartosh@linux.intel.com \
--cc=enrico.scholz@sigma-chemnitz.de \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox