Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp63935ybg; Thu, 11 Jun 2020 17:17:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyaeHReWaCHac2jENE9iXsYdzYcfZebbERXKmkUL0GBi4IF9srUqWGTsaw4nEt0u8BxS5oj X-Received: by 2002:aa7:ce13:: with SMTP id d19mr9588889edv.355.1591921070821; Thu, 11 Jun 2020 17:17:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591921070; cv=none; d=google.com; s=arc-20160816; b=Q2tsr2k7Uo+KIuoK609jdj7nv55LeAx4vlJZmRZjDQMbCsv7HMiaofsw9mCVCZKrQd 5Gqj3cM9/OiBPf6ZaLn1akmuYDBLbzEkB3tR1vUiyoTUidAosD6g/wZdRbg/+D+IbVgP 9Sq5dCrsEBAMTKHtkHCjpNlU4xbV4PKlcL3xqAaLSOvFw9B/X+zdoVJfYliVpeS46k24 gHaC6w5eHKDfgAs7S2c81n2kh7AiNlz4oEAf6/t5+oPG/BjVdx6BkmR9Vqy4k/9aKoek lICRjyaA9ntRKJL17Lrfhk5fsRfHoDaHUr5nibyIaJoAH575oaxOGGpFlVaeG4snLguc jlRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=Bo6aOWlg0XGStpr/5Q3GmSr0D+5zqxlBZ+pEFMhCgN0=; b=G7KOX7SPdZlu3atcifqtKYzyN4+nrVWsnSyK5jWtmg+6uwOjmNZWPaS4wy2RdUL0md Tx8iZo7B3Z+B1KCR93zJJO3RLaPOnzfOrR7VU/A1fxElqAmp745OgxTlg5u5m5R2nN/J YL/B1J42Y1FeOC9fO9KQQRISd7EmJ9ojZhupA8t896PZINfG+VtWsT6W6mEx2AzO4l7S L1hnE/cku5Wg9YxBgwMrHPOFaQVABx1xdzm58RDuV67GBw+Z8qWOsC1xJDBYMj2nl3Wk cXwL0/KHCsmdKzWPRpdotQIK0WBf5BfrlAo/sv88j3Zq2DtzKVisKigWwPAhSfVNY+cj MJCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="VLL7M/7R"; 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 u4si3047430ejx.88.2020.06.11.17.17.28; Thu, 11 Jun 2020 17:17:50 -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; dkim=pass header.i=@kernel.org header.s=default header.b="VLL7M/7R"; 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 S1726369AbgFLANh (ORCPT + 99 others); Thu, 11 Jun 2020 20:13:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:33048 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726285AbgFLANg (ORCPT ); Thu, 11 Jun 2020 20:13:36 -0400 Received: from gmail.com (unknown [104.132.1.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3174D2078C; Fri, 12 Jun 2020 00:13:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591920816; bh=BHDLwQ4NKVsGm3dtY7FyF5hFRMR2IEXbr0Acsm+JZbM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VLL7M/7RBgmclrzLSuEbOGMCOjmaXjUqh/wGQArH/Ct8UwxROcyuO6GQTsLcPKCo0 86zWe5PlYIr0N9tA5P6U9WiAGQ2XO2N9v2ZlkCtP1cZlfVeS5QWLE46HZzfhHdw0Mf aBn5STit0Q6DQjRdofkX5CsHU8R3paLletU8uTkE= Date: Thu, 11 Jun 2020 17:13:34 -0700 From: Eric Biggers To: Daeho Jeong Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com, Daeho Jeong Subject: Re: [f2fs-dev] [PATCH v2] f2fs: add F2FS_IOC_SEC_TRIM_FILE ioctl Message-ID: <20200612001334.GB18185@gmail.com> References: <20200611031652.200401-1-daeho43@gmail.com> <20200611162721.GB1152@sol.localdomain> <20200611230043.GA18185@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 12, 2020 at 09:00:58AM +0900, Daeho Jeong wrote: > For the incremental way of erasing, we might as well support the > (offset, length) option in a unit of 4KiB. > > So, you might use this ioctl like the below. Does it work for you? > struct f2fs_sec_trim { > u64 startblk; > u64 blklen; > u32 flags; > }; > > sectrim.startblk = 0; > sectrim.blklen = 256; // 1MiB > sectrim.flags = F2FS_TRIM_FILE_DISCARD | F2FS_TRIM_FILE_ZEROOUT; > ret = ioctl(fd, F2FS_SEC_TRIM_FILE, §rim); Most filesystem ioctls and syscalls take offsets and lengths in bytes, especially newer ones. This way implementations of these APIs can support other alignments later. The implementation can still require alignment for now, i.e. return -EINVAL if !IS_ALIGNED(arg.pos | arg.len, sb->s_blocksize). Also, flags should be a u64, especially since it wouldn't actually increase the size of the struct (due to padding). - Eric