User: Password:
|
|
Subscribe / Log in / New account

Atime and btrfs: a bad combination?

Atime and btrfs: a bad combination?

Posted Jun 1, 2012 7:41 UTC (Fri) by bakterie (subscriber, #37541)
Parent article: Atime and btrfs: a bad combination?

Does ZFS suffer from the same problem, and if not, how did they solve it?


(Log in to post comments)

Atime and btrfs: a bad combination?

Posted Jun 2, 2012 13:03 UTC (Sat) by Ringding (subscriber, #34316) [Link]

Yes, it does. It won't allow you to "use" more than 63/64th of the space available in a pool though, and I believe this is one of the reasons for that decision. Surprisingly though, the additional space for the atime updates is only accounted for when I unmount the filesystem.

Atime and btrfs: a bad combination?

Posted Jun 7, 2012 16:18 UTC (Thu) by quanstro (guest, #77996) [Link]

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.

Atime and btrfs: a bad combination?

Posted Jun 7, 2012 23:23 UTC (Thu) by HenrikH (subscriber, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds