From: Ed Bartosh <ed.bartosh@linux.intel.com>
To: "Maciej Borzęcki" <maciej.borzecki@rndity.com>
Cc: Maciej Borzecki <maciek.borzecki@gmail.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] wic: add --reserved-size wks option
Date: Tue, 18 Oct 2016 12:27:48 +0300 [thread overview]
Message-ID: <20161018092748.GA18050@linux.intel.com> (raw)
In-Reply-To: <CAD4b0_LVGC5mJ72MXytQ+4Kovve1=ca8HVohfju8CPe+BzpjfA@mail.gmail.com>
On Tue, Oct 18, 2016 at 11:24:14AM +0200, Maciej Borzęcki wrote:
> On Tue, Oct 18, 2016 at 10:38 AM, Ed Bartosh <ed.bartosh@linux.intel.com> wrote:
> > On Tue, Oct 18, 2016 at 10:37:22AM +0200, Maciej Borzęcki wrote:
> >> On Tue, Oct 18, 2016 at 9:31 AM, Ed Bartosh <ed.bartosh@linux.intel.com> wrote:
> >> > On Mon, Oct 17, 2016 at 04:46:00PM +0200, Maciej Borzęcki wrote:
> >> >> On Mon, Oct 17, 2016 at 3:22 PM, Ed Bartosh <ed.bartosh@linux.intel.com> wrote:
> >> >> > Hi Maciej,
> >> >> >
> >> >> > There is already --size and --extra-space options.
> >> >> > Can we get the same or similar result by just using them? Do we really
> >> >> > need new option for similar purpose?
> >> >>
> >> >> --reserved-size serves a different purpose, it establishes an upper
> >> >> bound on the size of a partition during layout. Unlike
> >> >> --size/--extra-space does not depend on the size of the filesystem
> >> >> image.
> >> >>
> >> >> For instance, assume I'm creating an image for SD card/eMMC with a
> >> >> fixed partition layout (something simple: boot partition, primary &
> >> >> secondary rootfs partitions, some data partition). Because future
> >> >> system updates are delivered as filesystem image, I want to make sure
> >> >> that there is exactly xxx MBs for my current and future rootfs images
> >> >> (regardless of current image size). Neither --size nor --extra-space
> >> >> can do that. I could use, say `--size 200 --overhead-factor 1`, but
> >> >> this will needlessly create a 200MB rootfs image and if I happen to
> >> >> cross the 200MB boundary I will not get an error.
> >> >>
> >> >> I had a private patch that added --fixed-size to enforce --size, but
> >> >> that would still end up creating filesystem image to fill the whole
> >> >> space.
> >> > I didn't get the difference between enforcing partition size and below
> >> > implementation. Can you elaborate a bit?
> >>
> >> `--fixed-size` was something that I had added to my fork back in 2014,
> >> even before `--overhead-factor` came in. The problem is that depending
> >> on a project you might want to have more control over how partitions
> >> are laid out, or even need to have a fixed layout. Adding
> >> `--fixed-size` would had a similar effect to what `--overhead-factor
> >> 1` does right now. Combined with `--size` would ensure that rootfs is
> >> say, 200MB large. The downside was that wic would actually create a
> >> 200MB rootfs, something that is not really necessary. In fact, I only
> >> wanted to have 200MB gap so that I have some spare space for future
> >> updates (where update is just a rootfs image you dd to the partition).
> >>
> > Thanks for the explanations. Now I got it - reserved size is not a part
> > of partition, it's a gap between partitions.
>
> I might have not been clear enough when explaining. It's not a gap,
> it's just a container of size --reserved-size listed in MBR/GPT.
> There's probably a filesystem inside but not necessarily.
> Graphically it looks as like this:
>
> --reserved-size
> |----------------------|
> v v
> +-----------------+----------------------+---------------------+
> |..... stuff .....|xxxxxxxxxx |..... stuff .........|
> +-----------------+----------------------+---------------------+
> ^ ^ ^
> |---------|------------|
> --size --extra-space
>
>
Ah, I'm wrong again. It's a partition size limit, but it's not necessary
formatted, right? It's only formatted if size == reserved_size.
> >
> > 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.
--
Regards,
Ed
next prev parent reply other threads:[~2016-10-18 9:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-17 13:06 [PATCH] wic: add --reserved-size wks option Maciej Borzecki
2016-10-17 13:22 ` Ed Bartosh
2016-10-17 14:46 ` Maciej Borzęcki
2016-10-18 7:31 ` Ed Bartosh
2016-10-18 8:37 ` Maciej Borzęcki
2016-10-18 8:38 ` Ed Bartosh
2016-10-18 9:24 ` Maciej Borzęcki
2016-10-18 9:27 ` Ed Bartosh [this message]
2016-10-18 10:24 ` Maciej Borzęcki
2016-10-18 10:17 ` Ed Bartosh
2016-10-18 11:07 ` Maciej Borzęcki
2016-10-18 11:05 ` Ed Bartosh
2016-10-18 13:59 ` Maciej Borzęcki
2016-10-18 14:24 ` Ed Bartosh
2016-10-18 14:54 ` Maciej Borzęcki
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=20161018092748.GA18050@linux.intel.com \
--to=ed.bartosh@linux.intel.com \
--cc=maciej.borzecki@rndity.com \
--cc=maciek.borzecki@gmail.com \
--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