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
next prev parent 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