All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.