Atime and btrfs: a bad combination? [LWN.net]

Atime and btrfs: a bad combination?

Posted Jun 7, 2012 16:18 UTC (Thu) by quanstro (guest, #77996)
In reply to: Atime and btrfs: a bad combination? by bakterie
Parent article: Atime and btrfs: a bad combination?

not in the same way. zfs does de-dup, so the
10 snapshots in the example would take up just
one extra copy of the metadata, not 10 after
changing the live data.

it would seem to me that this could be fixed
without de-dup by simply making the copy into
the live file system rather than all the snapshots.
that would be O(1) for a block not O(snapshots).

(it must be doing that right, otherwise how would
we generate 10x the original metadata)

one would think that this is a general problem with
btrfs snapshots, and not specific to atime.

(Log in to post comments)

Atime and btrfs: a bad combination?

Posted Jun 7, 2012 23:23 UTC (Thu) by HenrikH (guest, #31152) [Link]

But wouldn't each copy of the 10 snapshots have different atime (since it was grepped at different times) which would prohibit dedup?

Atime and btrfs: a bad combination?

Posted Jun 10, 2012 16:52 UTC (Sun) by quanstro (guest, #77996) [Link]

i don't think so. if the atime differed in all the snapshots
to begin with, then the recursive grep would only
trigger a copy into the last snapshot.

it still makes more sense to me to copy into the
working tree rather than the snap. that way all
snaps can continue to share blocks as best they can.