I have two filesystems in the same zfs pool, /mnt/fs_a and /mnt/fs_b. I want to move about 1TB of data from fs_a to fs_b. But when I:

mv /mnt/fs_a/mythtv_recordings /mnt/fs_b/

to my surprise it starts copying the files block-by-block. Given the time it took to move a 2GB file, it looks like this operation would take days of massive thrashing to finish.

There has to be a much smarter and faster way to do this, right?

1 Answer 1


Unfortunately, the answer is "No". There isn't a faster, or smarter way to do this.

ZFS filesystems (even though they are on the same pool) are separate filesystems. Neither mv nor any other tool can just move the block pointers or whatever so that files that were on fs_a are now on fs_b.

(BTW, multiple formatted partitions or LVM volumes on the same disk or raid array are also separate filesystems and mv devolves to copy-and-delete for them too)

This issue has come up several times over the years (with some talk of creating a tool to do what you want) and as I understand it, the major difficulty that puts it in the too-hard basket is the question of how to handle snapshots - if there are snapshots of fs_a, the blocks would be in both fileystems at the same time. The same is true of files that have hard-links.

I've run into it myself numerous times (e.g. when moving files between datasets as you did, or when I need to convert a subdirectory to a fs), and have just learnt to put up with the inconvenience. It can be a major PITA.

if fs_b is empty or doesn't yet exist and you want to move the entire contents of fs_a to fs_b (and not just some or even most files & directories) you can use zfs rename to rename fs_a to fs_b. I suspect that this is not relevant to your situation, though.

There's an open issue on this for ZFSOnLinux at https://github.com/zfsonlinux/zfs/issues/2991

I haven't searched but I would expect that upstream OpenZFS and even Sun/Oracle ZFS probably have similar bug-reports/feature-requests.

BTW, see also https://serverfault.com/questions/584693/freenas-why-isnt-mv-command-instant-within-a-raidz1-volume

  • 4
    Thanks for the thorough response. I appreciate the rename suggestion, but as you suspect I have even more data on that I don't want on b. At least I can move on now, and copy the files via a buffer disk to at least eliminate the thrashing. Apr 15, 2016 at 1:30
  • Hello, I just realized, this is relevant, i was trying to accomplish near the same thing. unix.stackexchange.com/questions/219786/… May 29, 2021 at 22:17
  • Wouldn't dedup be able to alleviate this to some extent?
    – sean
    Feb 15, 2023 at 3:23
  • 1
    @sean ZFS's dedupe is a great way of substituting very expensive RAM for dirt-cheap disk. There are a few use cases where it's a good idea (like a VM or container host with dozens or hundreds of near-identical VMs/containers) but in most cases, it's worse than useless. Even in cases like the VM host, the main benefit is the reduced I/O demand & improved performance from reading the same blocks from cache, not from storage savings - disk storage is cheap and plentiful. RAM is expensive and a far more limited resource. Even SSDs are cheap compared to RAM.
    – cas
    Feb 15, 2023 at 4:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .