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-doc@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