lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAO1O6seVp0wBVE6AKmu+EYhoghxbErNuK1F=Y5ewzD=CRro24g@mail.gmail.com>
Date:   Sat, 8 Jun 2019 01:40:38 +0200
From:   Emil Lenngren <emil.lenngren@...il.com>
To:     Richard Weinberger <richard@....at>
Cc:     linux-mtd <linux-mtd@...ts.infradead.org>,
        Sebastian Andrzej Siewior <sebastian@...akpoint.cc>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Michele Dionisio <michele.dionisio@...il.com>
Subject: Re: [PATCH] ubifs: Add support for zstd compression.

Hi,

Den fre 7 juni 2019 kl 22:49 skrev Richard Weinberger <richard@....at>:
>
> ----- Ursprüngliche Mail -----
> > Von: "Emil Lenngren" <emil.lenngren@...il.com>
> > An: "richard" <richard@....at>
> > CC: "linux-mtd" <linux-mtd@...ts.infradead.org>, "Sebastian Andrzej Siewior" <sebastian@...akpoint.cc>, "linux-kernel"
> > <linux-kernel@...r.kernel.org>, "Michele Dionisio" <michele.dionisio@...il.com>
> > Gesendet: Freitag, 7. Juni 2019 22:27:09
> > Betreff: Re: [PATCH] ubifs: Add support for zstd compression.
> >> So I'm not sure what is the best choice for the default filesystem.
> >
> > My idea was at the end, i.e. it will only be used when LZO and ZLIB
> > are not selected to be included for UBIFS, for example when someone
> > compiles a minimal kernel who knows exactly which compression
> > algorithms will be used on that system.
>
> BTW: you can always select the compressor using the compr= mount option.
> Also for the default filesystem.

Yep that's what I'm using while I'm testing.

> Putting it at the end does not harm but IMHO the use is little.
> But for the sake of completes, I agree with you. Can you send a follow-up
> patch?

Ok

>
> > I did a single test today and compared lzo and zstd and on that test
> > lzo had faster decompression speed but resulted in larger space. I'll
> > do more tests later.
>
> Can you please share more details? I'm interested what CPU this was.

ARM Cortex-A7. The kernel is compiled with gcc 7.3.1. Next week I'll
test some more.
I have a question about how the decompression is done while reading.
When a large file is read from the filesystem (assuming not in any
cache), is it the case that first a chunk is read from flash, that
chunk is then decompressed, later next chunk is read from flash, that
one is then decompressed and so on, or can the decompression be done
in parallel while reading the next chunk from flash?

/Emil

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ