From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CF6903E48E; Wed, 3 Apr 2024 08:29:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.113 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712132969; cv=none; b=ho6+ijI8R78pxaONgStjw4TUFIkPxn6vGz4Yxltvkzw8nbwGdLlI0EBE3QGakhnH9RZfdxRD1tZr3UKMQumBzzHSsCEl5parC41U1k6dEBkF3Q2PGxPY8YfjH/z1xC6td8SFhudA383whBZjNMWEoKpCEAyerTif96X5kTxmwYA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712132969; c=relaxed/simple; bh=Ldfjw0TveG1bC27L02CGJ1El9aX9iApZ9fZGyu1A5wg=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=HQuM189R0MWqJgf153p1wXmA2Lq/2s5TiMbkAmh8H2O3SfOOqiNt3cR2wuWoHaKnvd6S2BgsjlWLR69JtPANyo+Jc1WZVg3oinOXY1M1ic3Z2ZywYbIQs6qACB2V+ZBYG55azUMvi0O1+ey+n7VT5WOWKDgAp93LUu6t1xWIvX4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=R9aXz0Ht; arc=none smtp.client-ip=115.124.30.113 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="R9aXz0Ht" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1712132958; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=6ARyxKsG7GVlym8JkJymXRlceZpVJP0pu/mDsnbzovQ=; b=R9aXz0HtchVxIj0OkVENOP7cn2AfFizRkz0mdt8mvI73FcWSx0ysGaFPOaN+ZaHguEqXNlsr/eeR24y4bKKSzrI8BZ373JQxfl/fwJPrV4hYPSVbj6wg7FluO1tL1kw8ugKsABUjFoL8ZiB7LZ0EV3h0tQaP03EESXs0Njme5JM= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045192;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=20;SR=0;TI=SMTPD_---0W3r6Fd3_1712132955; Received: from 30.97.48.165(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0W3r6Fd3_1712132955) by smtp.aliyun-inc.com; Wed, 03 Apr 2024 16:29:16 +0800 Message-ID: Date: Wed, 3 Apr 2024 16:29:14 +0800 Precedence: bulk X-Mailing-List: linux-bcachefs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 00/13] fiemap extension for more physical information To: Sweet Tea Dorminy , Jonathan Corbet , Kent Overstreet , Brian Foster , Chris Mason , Josef Bacik , David Sterba , Jaegeuk Kim , Chao Yu , Alexander Viro , Christian Brauner , Jan Kara , =?UTF-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-bcachefs@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, kernel-team@meta.com References: From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 2024/4/3 15:22, Sweet Tea Dorminy wrote: > For many years, various btrfs users have written programs to discover > the actual disk space used by files, using root-only interfaces. > However, this information is a great fit for fiemap: it is inherently > tied to extent information, all filesystems can use it, and the > capabilities required for FIEMAP make sense for this additional > information also. > > Hence, this patchset adds various additional information to fiemap, > and extends filesystems (but not iomap) to return it. This uses some of > the reserved padding in the fiemap extent structure, so programs unaware > of the changes will be unaffected. I'm not sure why here iomap was excluded technically or I'm missing some previous comments? > > This is based on next-20240403. I've tested the btrfs part of this with > the standard btrfs testing matrix locally and manually, and done minimal > testing of the non-btrfs parts. > > I'm unsure whether btrfs should be returning the entire physical extent > referenced by a particular logical range, or just the part of the > physical extent referenced by that range. The v2 thread has a discussion > of this. Could you also make iomap support new FIEMAP physical extent information? since compressed EROFS uses iomap FIEMAP interface to report compressed extents ("z_erofs_iomap_report_ops") but there is no way to return correct compressed lengths, that is unexpected. Thanks, Gao Xiang From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4DFF6C6FD1F for ; Wed, 3 Apr 2024 08:45:22 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1rrwFC-00039C-Qk; Wed, 03 Apr 2024 08:45:19 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1rrwF8-00038h-S4 for linux-f2fs-devel@lists.sourceforge.net; Wed, 03 Apr 2024 08:45:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6ARyxKsG7GVlym8JkJymXRlceZpVJP0pu/mDsnbzovQ=; b=jegZhsvRN7zyk6tattZ/oObaRk KojgbdH1UFGBXV94Qn/ONiKZ5BPXF9FkZrWNkkGDD16sgBQj8PCNj2cr6vRk4Mj2yOxtbSOIAi+BR wDmUO7Ac2HejQyO49XT6PwDkUMdH6xNQmHAxYrsBLawaQdznnH+3Pf5Tzw7nHIkZ6J54=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:To: Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6ARyxKsG7GVlym8JkJymXRlceZpVJP0pu/mDsnbzovQ=; b=nN8rLGpCofr2Nb1lqTmce7N//z E7wUeJFMtEvO+sbz+jW25lqTN2MKSjrCxvXM443SdxgbXHZ5XtlKG5WgORA6FuE3zud+8PlfXSMRa 0Q2TBBBfBVr/8Wfrc4EeoZo+OK0ZDfXabAPCFv11ACfgWuLQEkz7os00cfnIFVjYccnI=; Received: from out30-99.freemail.mail.aliyun.com ([115.124.30.99]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1rrwF7-0006d8-An for linux-f2fs-devel@lists.sourceforge.net; Wed, 03 Apr 2024 08:45:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1712133906; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=6ARyxKsG7GVlym8JkJymXRlceZpVJP0pu/mDsnbzovQ=; b=we/YrAAMhp/Dm/WrdDb/kEsoJf8oKIL7AgylvZdjOh39+O4w/6dgNverFNKD0lerYWp3a75P2nBKWK4TKQPRBjt2VNUz3KxN46xT9aMRRskoAlEWg4/5MYkUXj4jzyXTpS4hUFrH3m0DundJxvKMhcfyrEafjh9QqKakSkpjgpk= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R191e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018045192; MF=hsiangkao@linux.alibaba.com; NM=1; PH=DS; RN=20; SR=0; TI=SMTPD_---0W3r6Fd3_1712132955; Received: from 30.97.48.165(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0W3r6Fd3_1712132955) by smtp.aliyun-inc.com; Wed, 03 Apr 2024 16:29:16 +0800 Message-ID: Date: Wed, 3 Apr 2024 16:29:14 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Sweet Tea Dorminy , Jonathan Corbet , Kent Overstreet , Brian Foster , Chris Mason , Josef Bacik , David Sterba , Jaegeuk Kim , Chao Yu , Alexander Viro , Christian Brauner , Jan Kara , =?UTF-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-bcachefs@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, kernel-team@meta.com References: From: Gao Xiang In-Reply-To: X-Headers-End: 1rrwF7-0006d8-An Subject: Re: [f2fs-dev] [PATCH v3 00/13] fiemap extension for more physical information X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net Hi, On 2024/4/3 15:22, Sweet Tea Dorminy wrote: > For many years, various btrfs users have written programs to discover > the actual disk space used by files, using root-only interfaces. > However, this information is a great fit for fiemap: it is inherently > tied to extent information, all filesystems can use it, and the > capabilities required for FIEMAP make sense for this additional > information also. > > Hence, this patchset adds various additional information to fiemap, > and extends filesystems (but not iomap) to return it. This uses some of > the reserved padding in the fiemap extent structure, so programs unaware > of the changes will be unaffected. I'm not sure why here iomap was excluded technically or I'm missing some previous comments? > > This is based on next-20240403. I've tested the btrfs part of this with > the standard btrfs testing matrix locally and manually, and done minimal > testing of the non-btrfs parts. > > I'm unsure whether btrfs should be returning the entire physical extent > referenced by a particular logical range, or just the part of the > physical extent referenced by that range. The v2 thread has a discussion > of this. Could you also make iomap support new FIEMAP physical extent information? since compressed EROFS uses iomap FIEMAP interface to report compressed extents ("z_erofs_iomap_report_ops") but there is no way to return correct compressed lengths, that is unexpected. Thanks, Gao Xiang _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel