linux-kernel - Re: [PATCH v3 00/13] fiemap extension for more physical information

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 3 Apr 2024 16:29:14 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Sweet Tea Dorminy <sweettea-kernel@...miny.me>,
 Jonathan Corbet <corbet@....net>, Kent Overstreet
 <kent.overstreet@...ux.dev>, Brian Foster <bfoster@...hat.com>,
 Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
 David Sterba <dsterba@...e.com>, Jaegeuk Kim <jaegeuk@...nel.org>,
 Chao Yu <chao@...nel.org>, Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
 Mickaël Salaün <mic@...ikod.net>,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-bcachefs@...r.kernel.org, linux-btrfs@...r.kernel.org,
 linux-f2fs-devel@...ts.sourceforge.net, linux-fsdevel@...r.kernel.org,
 kernel-team@...a.com
Subject: Re: [PATCH v3 00/13] fiemap extension for more physical information

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