3 ms·

> GNU cp uses ioctl() with the FICLONE flag when you run "cp --reflink" on a COW filesystem like Btrfs. > http://man7.org/linux/man-page/man2/ioctl_ficlonerang

> GNU cp uses ioctl() with the FICLONE flag when you run "cp --reflink" on a COW filesystem like Btrfs. > http://man7.org/linux/man-page/man2/ioctl_ficlonerange.2.htm.. http://man7.org/linux/man-page/man2/ioctl_ficlonerange.2.htm.... This unfortunately doesn't yet work with zfs on Linux. One of my only gripes with it.

rincebrain 10y ago
It's not clear to me that it will ever work outside of special cases on any ZFS implementation - see also ryao's two comments here [1], but briefly, ZoL seems to primarily think this would be feasible to implement in a not backward-compatible or upgradable-on-old-datasets way, using the dedup mechanisms, and ZFS's dedup is...well, it's a four-letter word in a number of ZFS circles. [1] - https://github.com/zfsonlinux/zfs/issues/405#issuecomment-50782850 https://github.com/zfsonlinux/zfs/issues/405#issuecomment-50...
- simcop2387 10y ago
  I'm curious about dedup being a four letter word in a number of ZFS circles. I hadn't seen anything bad about it (other than it being heavy on ram and possibly cpu)
  - rincebrain 10y ago
    So, dedup has a nontrivial memory overhead, can't really be turned off short of recreating the datasets in the pool after it's turned on (ZFS doesn't have any operations that allow you to change data blocks retroactively, so setting a new compression type, or checksum...or dedup entry for a block can't be changed back without you copying the data after changing the setting), and can have a significant write performance impact depending on your setup. See [1] for an example of how bad this can be. A number of people run dedup in production workloads. You just need to understand that it's a big and weirdly-shaped hammer, and can hit you in the head if you swing it without being ready for it. [1] - https://forums.freebsd.org/threads/31184/ https://forums.freebsd.org/threads/31184/

rincebrain 10y ago

It's not clear to me that it will ever work outside of special cases on any ZFS implementation - see also ryao's two comments here [1], but briefly, ZoL seems to primarily think this would be feasible to implement in a not backward-compatible or upgradable-on-old-datasets way, using the dedup mechanisms, and ZFS's dedup is...well, it's a four-letter word in a number of ZFS circles. [1] - https://github.com/zfsonlinux/zfs/issues/405#issuecomment-50782850 https://github.com/zfsonlinux/zfs/issues/405#issuecomment-50...

simcop2387 10y ago
I'm curious about dedup being a four letter word in a number of ZFS circles. I hadn't seen anything bad about it (other than it being heavy on ram and possibly cpu)
- rincebrain 10y ago
  So, dedup has a nontrivial memory overhead, can't really be turned off short of recreating the datasets in the pool after it's turned on (ZFS doesn't have any operations that allow you to change data blocks retroactively, so setting a new compression type, or checksum...or dedup entry for a block can't be changed back without you copying the data after changing the setting), and can have a significant write performance impact depending on your setup. See [1] for an example of how bad this can be. A number of people run dedup in production workloads. You just need to understand that it's a big and weirdly-shaped hammer, and can hit you in the head if you swing it without being ready for it. [1] - https://forums.freebsd.org/threads/31184/ https://forums.freebsd.org/threads/31184/