On 10 Nov 2020, at 13:39, Christoph Hellwig wrote:
On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
You do consistently ask for a shim layer, but you haven???t explained
what
we gain by diverging from the documented and tested API of the
upstream zstd
project. It???s an important
On 6 Nov 2020, at 13:38, Christoph Hellwig wrote:
You just keep resedning this crap, don't you? Haven't you been told
multiple times to provide a proper kernel API by now?
You do consistently ask for a shim layer, but you haven’t explained
what we gain by diverging from the documented and
On 2 Oct 2020, at 2:54, Christoph Hellwig wrote:
On Wed, Sep 30, 2020 at 08:05:45PM +, Nick Terrell wrote:
On Sep 29, 2020, at 11:53 PM, Christoph Hellwig
wrote:
As you keep resend this I keep retelling you that should not do it.
Please provide a proper Linux API, and switch to that.
On 17 Sep 2020, at 6:04, Christoph Hellwig wrote:
On Wed, Sep 16, 2020 at 09:35:51PM -0400, Rik van Riel wrote:
One possibility is to have a kernel wrapper on top of the zstd API
to
make it
more ergonomic. I personally don???t really see the value in it,
since
it adds
another layer of indire
On 16 Sep 2020, at 4:49, Christoph Hellwig wrote:
On Tue, Sep 15, 2020 at 08:42:59PM -0700, Nick Terrell wrote:
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Again, please use sensible names And no one gives a fuck
On 16 Sep 2020, at 10:30, Christoph Hellwig wrote:
On Wed, Sep 16, 2020 at 10:20:52AM -0400, Chris Mason wrote:
It???s not completely clear what you???re asking for here. If the
API
matches what???s in zstd-1.4.6, that seems like a reasonable way to
label
it. That???s what the upstream is
On 16 Sep 2020, at 10:46, Christoph Hellwig wrote:
On Wed, Sep 16, 2020 at 10:43:04AM -0400, Chris Mason wrote:
Otherwise we just end up with drift and kernel-specific bugs that are
harder
to debug. To the extent those APIs make us contort the kernel code,
I???m
sure Nick is interested in
On 08/10/2017 03:25 PM, Hugo Mills wrote:
On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote:
On 08/10/2017 04:30 AM, Eric Biggers wrote:
Theses benchmarks are misleading because they compress the whole file as a
single stream without resetting the dictionary, which isn't how
On 08/10/2017 03:00 PM, Eric Biggers wrote:
On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote:
On 08/10/2017 04:30 AM, Eric Biggers wrote:
On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote:
The memory reported is the amount of memory the compressor requests.
| Method
On 08/10/2017 04:30 AM, Eric Biggers wrote:
On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote:
The memory reported is the amount of memory the compressor requests.
| Method | Size (B) | Time (s) | Ratio | MB/s| Adj MB/s | Mem (MB) |
|--|--|--|---|-
Reviewed-by: Jan-Simon Möller
> Reviewed-by: Mark Charlebois
> Signed-off-by: Behan Webster
> Cc: "David S. Miller"
> Cc: Herbert Xu
Acked-by: Chris Mason
On the btrfs bits. Thanks for the v3.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linu
On Mon, 2008-08-04 at 23:42 +0800, Herbert Xu wrote:
> Chris Mason <[EMAIL PROTECTED]> wrote:
> >
> >>From a performance point of view I'm probably reading the crypto API
> > code wrong, but it looks like my choices are to either have a long
> > standing
On Mon, 2008-08-04 at 11:45 +0100, David Woodhouse wrote:
> On Mon, 2008-08-04 at 06:35 -0400, Austin Zhang wrote:
> > On Mon, 2008-08-04 at 11:12 +0100, David Woodhouse wrote:
> > > You could perhaps just use 'unsigned long' here, to avoid the ifdef.
> > Thanks.
> > > And it would be nice if we c
13 matches
Mail list logo
