Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1569932ybj; Wed, 6 May 2020 00:47:54 -0700 (PDT) X-Google-Smtp-Source: APiQypKZ3wToXNZqPpIT8fUKdvQSt5s4rlDuhyT24Vp2lWcOPOl36Bn7pjiX1fLc8ipWfg22kDq1 X-Received: by 2002:a17:906:2b43:: with SMTP id b3mr5828167ejg.231.1588751274045; Wed, 06 May 2020 00:47:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588751274; cv=none; d=google.com; s=arc-20160816; b=EwdAwL1zG71uZpVEwfAi48EEnzsrbr+L7PVeUr73ZuREJwxBtXDw4ciz8QgF9rns+y 6BHSQgykXcP7rIQYkRyz9B+P+eQPLGHLMRzsM1Ig1TkIH4w9dZS1DkVf4UVusKu61rZ/ QUpEJ04wYHp4wUh/TvZTbSBo1jCh/6BEse2TQKaOqSKvGKjxeHvrtdHXuEMH9IGy0mUs rgWaYL2cYkHVVeVZRN7TJzvA8Yb1ls8+p/do/D2wJwwlW5ra6Y5cOTFYcdFGwBLmKmkM w9zSe9Sr7Y1NW1f4fgWkbFNY0a1KFMlR/LXOmrPUC1KBBqoqxYGBvcIuy+Si8GNUkv7y 9Mpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=AiF7vz67DMyrLX96EoxAKTtK4KdqCnLrecAoEeB+/FM=; b=KEzpzlWWTWgQ+OjcMQji/kANGYiMKmZWCW5MfEhcfBvo9jvjp1jnCutwI1ku904iGU c67yzI2P11CrsNiGrVf+myIz7ub2pzmEBDXqYgRnFSLy4EEwGPouTA1lsbrlZwCr0od4 s/HM4+kMmHTttl7zPhqAtzb9m6LRuLiXpYyronVpEZvvQPPyTDhbJlsHrIdbj3hy45/I AwW8CEdtsZNkMR8AXoorc1gNvOmLa+eI9g23ZqsOb/CsJGJ0Rbo2SSwPNq1IplNcywA8 Olf+wfjua9w2Hv68zmUFi5h9JG3BJeEgZ6a+PESYuKnu3c//9MFfMQYxXUesUK8fHYll zjtw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x21si642351ejc.141.2020.05.06.00.47.31; Wed, 06 May 2020 00:47:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728335AbgEFHpv (ORCPT + 99 others); Wed, 6 May 2020 03:45:51 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:3813 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728301AbgEFHpv (ORCPT ); Wed, 6 May 2020 03:45:51 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id D4F1DBA18A7654661CE1; Wed, 6 May 2020 15:45:45 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.207) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 6 May 2020 15:45:43 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: change maximum zstd compression buffer size To: Jaegeuk Kim , Chao Yu CC: , , References: <20200504143039.155644-1-jaegeuk@kernel.org> <7177aab9-630e-e077-7005-0023c93134b3@kernel.org> <20200505230559.GA203407@google.com> From: Chao Yu Message-ID: <9aaeac5e-4511-5c81-653c-23a85b3c335a@huawei.com> Date: Wed, 6 May 2020 15:45:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200505230559.GA203407@google.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/5/6 7:05, Jaegeuk Kim wrote: > On 05/05, Chao Yu wrote: >> On 2020-5-4 22:30, Jaegeuk Kim wrote: >>> From: Daeho Jeong >>> >>> Current zstd compression buffer size is one page and header size less >>> than cluster size. By this, zstd compression always succeeds even if >>> the real compression data is failed to fit into the buffer size, and >>> eventually reading the cluster returns I/O error with the corrupted >>> compression data. >> >> What's the root cause of this issue? I didn't get it. >> >>> >>> Signed-off-by: Daeho Jeong >>> --- >>> fs/f2fs/compress.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c >>> index 4c7eaeee52336..a9fa8049b295f 100644 >>> --- a/fs/f2fs/compress.c >>> +++ b/fs/f2fs/compress.c >>> @@ -313,7 +313,7 @@ static int zstd_init_compress_ctx(struct compress_ctx *cc) >>> cc->private = workspace; >>> cc->private2 = stream; >>> >>> - cc->clen = cc->rlen - PAGE_SIZE - COMPRESS_HEADER_SIZE; >>> + cc->clen = ZSTD_compressBound(PAGE_SIZE << cc->log_cluster_size); >> >> In my machine, the value is 66572 which is much larger than size of dst >> buffer, so, in where we can tell the real size of dst buffer to zstd >> compressor? Otherwise, if compressed data size is larger than dst buffer >> size, when we flush compressed data into dst buffer, we may suffer overflow. > > Could you give it a try compress_log_size=2 and check decompression works? I tried some samples before submitting the patch, did you encounter app's data corruption when using zstd algorithm? If so, let me check this issue. Thanks, > >> >>> return 0; >>> } >>> >>> @@ -330,7 +330,7 @@ static int zstd_compress_pages(struct compress_ctx *cc) >>> ZSTD_inBuffer inbuf; >>> ZSTD_outBuffer outbuf; >>> int src_size = cc->rlen; >>> - int dst_size = src_size - PAGE_SIZE - COMPRESS_HEADER_SIZE; >>> + int dst_size = cc->clen; >>> int ret; >>> >>> inbuf.pos = 0; >>> > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > . >