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 for Android: free password hash cracker in your pocket

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

Message-Id: <BF24ACE8-3644-4378-8E7A-AFAF82C0CDD3@dilger.ca>
Date: Fri, 5 Apr 2024 12:20:21 -0600
From: Andreas Dilger <adilger@...ger.ca>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Sweet Tea Dorminy <sweettea-kernel@...miny.me>,
 Jonathan Corbet <corbet@....net>,
 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 Mailing List <linux-kernel@...r.kernel.org>,
 linux-bcachefs@...r.kernel.org,
 linux-btrfs <linux-btrfs@...r.kernel.org>,
 linux-f2fs-devel@...ts.sourceforge.net,
 linux-fsdevel <linux-fsdevel@...r.kernel.org>,
 kernel-team@...a.com,
 djwong@...nel.org
Subject: Re: [PATCH v3 00/13] fiemap extension for more physical information

On Apr 3, 2024, at 12:17 PM, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> 
> On Wed, Apr 03, 2024 at 03:22:41AM -0400, 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.
>> 
>> 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.
> 
> I believe there was some talk of using the padding for a device ID, so
> that fiemap could properly support multi device filesystems. Are we sure
> this is the best use of those bytes?

The current (pre-patch) fiemap_extent struct is:

struct fiemap_extent {
        __u64 fe_logical;  /* logical offset in bytes for the start of
                            * the extent from the beginning of the file */
        __u64 fe_physical; /* physical offset in bytes for the start
                            * of the extent from the beginning of the disk */
        __u64 fe_length;   /* length in bytes for this extent */
        __u64 fe_reserved64[2];
        __u32 fe_flags;    /* FIEMAP_EXTENT_* flags for this extent */
        __u32 fe_reserved[3];
};

and this series is only changing fe_reserved64[0] to fe_phys_length.
There was discussion in the past of using "fe_reserved[0]" for the device
ID, which is still OK.

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)