All of lore.kernel.org
 help / color / mirror / Atom feed
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 11:53:01 +0300	[thread overview]
Message-ID: <20170912085301.rfsiwojqn2nr6md5@linux.intel.com> (raw)
In-Reply-To: <lyzia1fi13.fsf@ensc-virt.intern.sigma-chemnitz.de>

On Mon, Sep 11, 2017 at 04:04:40PM +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?

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


> 
> >> +    def __extend_rootfs_image(self, rootfs):
> >
> > Do we really need to mangle name of this method?
> 
> ok; I will make it _extend_rootfs_image
> 
> 
> > As this function is not going to be used anywhere I'd just use this
> > code in prepare_rootfs_squashfs. It would be less generic, but much
> > more readable and understandable.
> 
> 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:
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -338,6 +338,14 @@ class Partition():
                        (rootfs_dir, rootfs, extraopts)
         exec_native_cmd(squashfs_cmd, native_sysroot, pseudo=pseudo)
 
+        # Enlarges the image to make bigger partition
+        sz = (os.stat(rootfs).st_size + 1023) // 1024
+        pad_sz = self.get_rootfs_size(sz)
+
+        if pad_sz > sz:
+            with open(rootfs, 'a') as fimage:
+                  fimage.truncate(pad_sz * 1024)
+
     def prepare_empty_partition_ext(self, rootfs, oe_builddir,
                                     native_sysroot):

Then introducing a method that will be called for all supported
filesystems except squashfs without any effect.

> partition.py is full of redundant code (look for all the "du" calls or
> generally at the beginning of the prepare_rootfs_*() methods) where
> probably somebody thought that it is not going to be used anywhere else
> ;)
Feel free to send a patch then.
I'd not consider it a good excuse for the above new method though :)

--
Regards,
Ed


  reply	other threads:[~2017-09-12  8:53 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 [this message]
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
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=20170912085301.rfsiwojqn2nr6md5@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 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.