Re: Can the output of FIEMAP on BTRFS be used to check if a file and its reflink copy might have diverged?

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 1831 bytes --]

On 9/22/25 13:31, Christoph Hellwig wrote:
> On Mon, Sep 22, 2025 at 01:30:36PM -0400, Demi Marie Obenour wrote:
>> On 9/22/25 13:20, Christoph Hellwig wrote:
>>> On Mon, Sep 22, 2025 at 01:18:52PM -0400, Demi Marie Obenour wrote:
>>>> Is it safe on XFS if there is no RT device and both files have been
>>>> fsync'd and are not modified by userspace?  I believe this is the case
>>>> here: reflinks are used to snapshot the files before they are looked at.
>>>
>>> No.  Yo ucan still have defragementation or garbage collection going on
>>> underneath.
>>
>> Can these be prevented by mounting a read-only device-mapper snapshot,
>> replaying the journal, and then doing processing in userspace on the
>> block device?
> 
> Which part of "looking at FIEMAP output except for debugging the file
> system is highly dangerous" did you not understand?  Don't do it, you
> will lose data eventually.
I understand that FIEMAP is not to be used.  This also explains why
BTRFS_IOCTL_TREE_SEARCH_V2 is privileged: there is no need for it to
be used in production.

This leaves the question of whether the needed information is in the
filesystem metadata.  If so, xfsprogs and/or btrfsprogs could obtain
it from a block-layer snapshot offline without needing kernel changes.
Otherwise, kernel changes will be needed.  I don't know if the changes
to the userspace tools will be accepted, though.  Until then, btrfs
send/receive will be the only way to efficiently back up a BTRFS
filesystem, and XFS will only be able to be efficiently backed up
at the block level.

What makes thin_delta awesome is that it allows backing up a block
device *without having to read the entire device*.  This makes
backups O(log N) instead of O(N) in the size of the device.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]