All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hyunchul Lee <hyc.lee@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: Artem Bityutskiy <dedekind1@gmail.com>,
	linux-mtd@lists.infradead.org, kernel-team@lge.com,
	hyc.lee@gmail.com
Subject: Re: [PATCH 0/3] ubifs: add lz4hc compression
Date: Fri, 03 Mar 2017 20:07:01 +0900	[thread overview]
Message-ID: <58B94E55.3080209@gmail.com> (raw)
In-Reply-To: <5766cc86-d4cc-230c-9d3c-073d9b8d6ec5@nod.at>

Hi, Ricard

On 03/03/2017 05:08 PM, Richard Weinberger wrote:
> Hyunchul Lee,
> 
> Am 28.02.2017 um 06:16 schrieb Hyunchul Lee:
>> From: Hyunchul Lee <cheol.lee@lge.com>
>>
>> This patch set is for adding support for lz4hc compression.  lz4hc's
>> compression ratio is comparable to zlib, but its compression/decompression
>> speed is faster than zlib[1].
> 
> Do you have performance numbers that show the speedup on a common embedded
> system with NAND?

I am trying to build environment for a common embedded system with NAND. 
if I am done, I will report the performance result. 

> 
>> Another compression type cannot be added any more in respect that type of
>> ubifs_inode's compr_type is "unsigned:2" and there are 4 compression
>> types.  There may be overflow in assignment to compr_type, and prevision 
>> version of ubifs is trying to decompress file with wrong compression type.
> 
> As Artem noted this is only an in-memory struct.
> 
> What happens when you compress a file with lz4hc and try to access this
> UBIFS file with an older kernel?
> AFAICT ubifs_iget() will notice and return -EINVAL but please double check.
> 

yes, ubifs detects this. but I mean that if another compression type except lz4hc
is added, ubifs cannot. because ubifs_iget() assigns ubifs_ino_node's compr_type(16-bit) 
to ubifs_inode's compr_type(2-bit).
I guess that the disk format version should be incremented.

> Thanks,
> //richard
> 

Thanks,
Hyunchul

  reply	other threads:[~2017-03-03 11:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28  5:16 [PATCH 0/3] ubifs: add lz4hc compression Hyunchul Lee
2017-02-28  5:16 ` [PATCH 1/3] ubifs: add lz4hc compressor Hyunchul Lee
2017-02-28  5:16 ` [PATCH 2/3] ubifs: change type of ubifs_inode's compr_type to unsigend:16 Hyunchul Lee
2017-02-28 10:17 ` [PATCH 0/3] ubifs: add lz4hc compression Artem Bityutskiy
2017-03-01  1:12   ` Hyunchul Lee
2017-03-01 10:35     ` Artem Bityutskiy
2017-03-03  8:08 ` Richard Weinberger
2017-03-03 11:07   ` Hyunchul Lee [this message]
2017-03-03 12:00     ` Artem Bityutskiy
2017-03-03 12:07       ` Richard Weinberger

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=58B94E55.3080209@gmail.com \
    --to=hyc.lee@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=kernel-team@lge.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.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.