Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
To: Ed Bartosh <ed.bartosh@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 3/3] wic: apply --extra-space + --overhead to squashfs
Date: Tue, 12 Sep 2017 11:44:02 +0200	[thread overview]
Message-ID: <lymv60fdzx.fsf@ensc-virt.intern.sigma-chemnitz.de> (raw)
In-Reply-To: <20170912085301.rfsiwojqn2nr6md5@linux.intel.com> (Ed Bartosh's message of "Tue, 12 Sep 2017 11:53:01 +0300")

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.


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

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


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


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


Enrico
-- 
SIGMA Chemnitz GmbH       Registergericht:   Amtsgericht Chemnitz HRB 1750
Am Erlenwald 13           Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
09128 Chemnitz


  reply	other threads:[~2017-09-12  9:44 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 [this message]
2017-09-12 11:48           ` Ed Bartosh
2017-09-12 12:18             ` Enrico Scholz
2017-09-12 12:57               ` Ed Bartosh
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=lymv60fdzx.fsf@ensc-virt.intern.sigma-chemnitz.de \
    --to=enrico.scholz@sigma-chemnitz.de \
    --cc=ed.bartosh@linux.intel.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