Hello,

Please note that my experience with btrfs is both recent and, above all, very 
small. However, I've been wondering about the same issue for a different 
purpose and your question intrigues me.

However, and I may be off-base here, I think that wouldn't be trivial to 
achieve. 

Even if one would be able to differ the metadata changes between both 
snapshots, the problem would still be present regarding finding the changed 
data. It would be possible to check for changed extents, at least by comparing 
extent checksums, but I don't think it would be trivial to discover where 
(exactly) the extent was modified.

I would recommend using the generation fields, whenever applicable, but I 
believe these are private to each subvolume/snapshot.


Anyway, I wonder if keeping a data structure (I would go with a tree) 
containing metadata regarding the changed files, within the file system, could 
be a plausible solution, but I'm in no condition (btrfs-knowledge-wise) to make 
such statement.


Cheers.

---
João Eduardo Luís
gpg key: 477C26E5 from pool.keyserver.eu 





On Feb 25, 2011, at 9:59 AM, Arvin Schnell wrote:

> Hi,
> 
> for a backup program I have to find all differing files
> (including metadata) in two snapshots taken from the same
> subvolume.
> 
> Having looked at the find-new command I thought about this
> process:
> 
> 1. Get the two transids when the two snapshots were created.
> 
> 2. Query modifications to the original subvolume between the two
>   transids.
> 
> Is the general process corrent or have I overseen something?
> 
> AFAIS the btrfs tool does not provide the required
> information/commands. Would it be possible to add those?
> 
> Thanks in advance,
>  Arvin
> 
> -- 
> Arvin Schnell, <aschn...@suse.de>
> Senior Software Engineer, Research & Development
> SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to