On Mon, Jun 4, 2012 at 5:10 PM, shyam btrfs <shyam.bt...@gmail.com> wrote:
> Hi Alex, Jan,
>
> I was also interested in send/receive semantics & was thinking that if
> we adhere to the semantics as in
> http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg07482.html
> of:
>
> it is impossible to track the "deleted" items (files,dirs, eXtended
> attributes). I can develop a command which compare two subvolumes an
> extract all of this kind of information. But this command would return
> correct information *only if*
> A) a subvolume is a snapshot of the other one
> B.1) the reference snapshot is not touched OR
> B.2) I have the lastgen "when" the snapshot is taken
What I implement is basically the same, but with no transid involved. The
comparison however takes place inside the kernel and not in user space.
>
> then transid/generation number could be made to work to determine the
> differences between two subvolumes including the deletes that were
> involved. I agree that file-clone is tricky as you pointed, but we
> dont use it in our environment.
>
> Do you still see issues with it that I am missing?
>
> Also out of curiosity, would you mind sharing how you avoided looking
> at transid? Would it be that all meta changes are logged in
> tree-modification-log or equivalent?
The btrees in btrfs have a nice feature: If you compare two trees and
encounter a tree block that is shared with the other tree, the whole
subtree below is shared and thus can be regarded as unchanged.
Checking the transids does not guarantee that you skip those
unchanged subtrees, as the transids may also change when none
of the items change. btrfs balance may do this for example. So you
would unnecessarily iterate and compare the whole tree in many
cases, which will give bad performance.
--
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
