Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4926181pxu; Thu, 10 Dec 2020 08:39:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJzj6jWTBlqpsUl/0aPknMjTcRKxgGM/dPdywasN30YqpNowbYvFJn4iaOQXaFRFPU5U3HL0 X-Received: by 2002:a17:906:60d2:: with SMTP id f18mr6925167ejk.528.1607618347205; Thu, 10 Dec 2020 08:39:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607618347; cv=none; d=google.com; s=arc-20160816; b=kBZ6yyWKfzw3keX/hgsVJQFNfUpYagRUTFJ8xUoVDt3DwVjlB+RWIIfvrsxAm6T6se FO9K7Wn5WKRdltRYCEs9HMPaUo+UoDRpI2zVfR1iHmztcFb7bHV1hHNuCJPmQmf6cUkp q9CD/C0PayCN5kPU9J3In7vqsdPUuZ5A5u0TMWReKVoiArP9aA8NK5pzmb9IVZIifC9R U2maSonmXB50VZbNfOCC3Qq8PCcSQ9FASGPUL9Tr3XhszrjVFIowwRPs/kyUXNymFdyL 2jQ3bf9Dg2kMVqd0IbJY1q8YOIqKW/JH4IVoNmBi13kzHg9X6MRo/nd2dmP1LEGDv+bQ N4ZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:dkim-signature:date; bh=9j9IGwUqdwc8vK2GCjcAzf4gEPZCZv2JGAoOq1jdgew=; b=MIzHdVH+hV4oUyCbfkRwD4u/eF0PSvufAnPwBoC4f+ZTy34OwRJUMb7yDdF8dhHzva cqW28ZEnsCI8mTiJW0IbISqnX74v7mwviaRXJXOUgK4IRomvr8SUdK8sTMcqmPWMnaw6 51LzK8G/74Lrug6NZsS+2Mkn1/Z1wWmpekR057LGO0QOHM6fUt8VHT3CEQeO/qRbSjmz RQ1XZkXglRX6ok0JttwepDrfVMFklrux9u8suUYTi1Q+RZB5KWD7nPBErwhL0xMFZplz YEguM4Q82BJ1wGMhhmNyzNIzup6ix9BPgamvApO4xlEvKTp/K3nYANvtYgfxnqIq4P3b lvKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="GzMO/8Sg"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k2si3098211edf.160.2020.12.10.08.38.44; Thu, 10 Dec 2020 08:39:07 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="GzMO/8Sg"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391872AbgLJQhJ (ORCPT + 99 others); Thu, 10 Dec 2020 11:37:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:58116 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391184AbgLJQgy (ORCPT ); Thu, 10 Dec 2020 11:36:54 -0500 Date: Thu, 10 Dec 2020 08:36:11 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1607618173; bh=fbQ4nuVsVzui/yLCe8bXeRIRjFWB90VPKZTYzTxSMsU=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=GzMO/8Sg2LxApIIozXGkp2kgxVaFJ1k8OEWW7WQ6vCJPb//80dlWjFqcTWjXH4dns ViCNL5ubiNQnJBtKE5Nsgh1+W2C2JhRMO+SgKG8pkk+6GzEHJzK6S/sfxTGurmeDG0 JSIDkOlpGvd/vNW9kC3YCi97QD/kDZkrkcHejfyLCbLVpNYX2kT9ootfZ3ieOEQ/9o bONisRZRZ12z20XKbP/wAFinLmN3nyEyOjwfgS9+jzeUOwjeHMwBSSawWflOOsJmwp V6WrYSeulHnXBzixunP4sLIDqLBKNVD0rwuaIIhrVJI7P9lUXMRmfQU8C3Ib5NrweJ Fgc/fHeQyrbRA== From: Jaegeuk Kim To: =?utf-8?B?5b6Q55Ge5paM?= Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [f2fs-dev] [PATCH v3 2/3] f2fs-tools:sload.f2fs compression support Message-ID: References: <20201208081555.652932-1-robinh3123@gmail.com> <20201208081555.652932-3-robinh3123@gmail.com> <785e9f0a-c3d6-9cc5-f17a-a3cc58a43a0f@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Chao and Robin, I refactored the patch to modify the names and structures. Please take a look at this. https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/commit/?h=dev&id=5cd8e5fcc79611c0692f18c7e7e13d6b4742d3c0 On 12/10, Jaegeuk Kim wrote: > On 12/10, 徐瑞斌 wrote: > > Hi, Jaegeuk, > > > > I comment here the patch your provided (3 parts, since the patch contains 3 > > fixes): > > 1. + dn->data_blkaddr = blkaddr; > > ret = reserve_new_block(sbi, &dn->data_blkaddr, &sum, type, 0); > > > > We cannot assign dn->data_blkaddr here. The old one is to be used in > > reserve_new_block() function. Also, reserve_new_block() function actually > > will set dn->data_blkaddr to blkaddr in the end. > > This tries to avoid deleting the block address used in the previous offset. > Otherwise, we'll see wrong i_blocks. > > > > > 2. Added condition "n < (1 << c.sldc_cc.log_cluster_size) * BLOCK_SZ" > > > > The semantic meaning of the whole if statement is to say: > > When the compression fail (ret != 0) or the original read size is > > smaller than the compressed size plus (the minimum block saved (specified > > by the user) x block size), we will not do compression but just write the > > data as is. > > This is missing the last block having < 4Kb. > > > > > The right hand side (RHS) of your added condition is exactly the read size, > > i.e. the cluster size. That means the condition is always false except the > > read of the last part of the file, when the file size is not exactly the > > multiple of the cluster size. That means we will never try to compress the > > last part of the file (when the last part is not a multiple of the cluster > > size) > > > > IMHO, the original implementation should be correct. > > > > 3. node_blk->i.i_blocks += cpu_to_le64(cblocks); > > > > I am not quite sure of the i_blocks count. Did you mean that when the file > > is mutable, meaning that the file reserves some blocks for future write, > > we will add count to i_blocks to mark the block as a used block by the > > file, right? I thought we only need to increment the allocated count... > > Should add it. > > > > > Regards, > > Robin Hsu 徐瑞斌 > > > > > > On Thu, Dec 10, 2020 at 4:42 PM Chao Yu wrote: > > > > > On 2020/12/8 16:15, Robin Hsu wrote: > > > > From: Robin Hsu > > > > > > > > Add F2FS compression support for sload > > > > * Support file extension filter, either default-accept or default-deny > > > > policy > > > > * Support choice of compression algorithm, LZO (version 2) or LZ4 > > > > (default) > > > > * Support custom log of cluster size > > > > * Support minimum number of compressed blocks per cluster (default 1). > > > > A cluster will not be compressed if the number can not be met. > > > > * suuport -r (read-only) option > > > > > > Could you please update manual as well? > > > > > > > + > > > > + /* sldc: sload compression support */ > > > > > > Personally, I don't like the naming method of adding "sldc_" prefix... :( > > > > > > > + bool sldc_en; > > > > + bool sldc_use_allow_list; /* default false to use the deny list */ > > > > + struct compress_ctx sldc_cc; > > > > + u8 sldc_ca; /* compress algorithm: 0 = LZO, 1 = LZ4 */ > > > > + compress_ops *sldc_compr; > > > > + enum filter_policy sldc_policy; > > > > + /* max_cppc can used to specify minimum compression rate */ > > > > + unsigned int sldc_min_cbpc; /* min compressed pages per cluster */ > > > > + bool sldc_got_opt; > > > > + bool sldc_immutable; > > > > + struct ext_tbl_op *sldc_ef; /* extension filter */ > > > > > > The variables name like sldc_en, sldc_ca, min_cbpc, sldc_ef makes > > > developers > > > hard to understand w/o comments, and also there is no comments for several > > > variable like sldc_en, sldc_cc... > > > > > > Could you please improve the naming like f2fs-tools style? > > > > > > Thanks, > > > > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel