All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
To: Emil Lenngren <emil.lenngren@gmail.com>
Cc: Richard Weinberger <richard@sigma-star.at>,
	linux-mtd@lists.infradead.org,
	David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Subject: Re: [PATCH v2] mkfs.ubifs: Add ZSTD compression
Date: Tue, 11 Jun 2019 19:21:18 +0200	[thread overview]
Message-ID: <20190611172117.awht3kogioilxnia@flow> (raw)
In-Reply-To: <CAO1O6sc4RfdrDGiJgXYZaDeZ2e46Rr=PFhqFYYWB9Gqd8XH8NQ@mail.gmail.com>

On 2019-06-10 19:34:53 [+0200], Emil Lenngren wrote:
> Hi all,
Hi,

> After some more investigations, although increasing compression level
> certainly increases compression time, decompression time does not seem
> to be increased by increasing compression level. See
> http://www.open-zfs.org/w/images/b/b3/03-OpenZFS_2017_-_ZStandard_in_ZFS.pdf
> page 9 for a benchmark. The benchmark even shows this seems to apply
> to gz as well...
> 
> SquashFS has also added support for zstd and squashfs-tools uses level
> 15 as the default level (see
> https://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git/commit/?id=e38956b92f738518c29734399629e7cdb33072d3
> at the bottom).
> 
> While the kernel compression level should maybe stay at 3, for
> mkfs.ubifs where speed doesn't matter that much, a higher level such
> as 15 might not be bad after all. So I have two different proposals:
> either just set level 15 OR set level 15 and also provide an option
> for mkfs.ubifs to override it if one for some reason wants to generate
> the image faster.
> 
> What do you think?

So the original problem was that ZSTD_CLEVEL_DEFAULT is not defined in
earlier releases of zstd and I would suggest to use `0' as stated here
in this thread.
Larger levels take more time to compress and I don't see the benefit in
doing compared to the size of the compressed image. I included my
numbers in the initial commit.
Also, if you use a larger compression level in mkfs compared to the
kernel then your image will grow if you rewrite existing files.

I've been told that for RO images (where higher compression levels
matter and compression is done once at creation time) the best thing to
do is to use squashfs on top of ubi.

> /Emil

Sebastian

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

      reply	other threads:[~2019-06-11 17:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-01 10:43 [PATCH v2] mkfs.ubifs: Add ZSTD compression Sebastian Andrzej Siewior
2019-06-02 21:37 ` David Oberhollenzer
2019-06-07 14:20 ` Emil Lenngren
2019-06-07 20:24   ` Richard Weinberger
2019-06-10 17:34     ` Emil Lenngren
2019-06-11 17:21       ` Sebastian Andrzej Siewior [this message]

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=20190611172117.awht3kogioilxnia@flow \
    --to=sebastian@breakpoint.cc \
    --cc=david.oberhollenzer@sigma-star.at \
    --cc=emil.lenngren@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@sigma-star.at \
    /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.