I "inherited" management of a system, whose "/opt" (and some other large directory trees) are stored in the root file system.

My wish now is to create a new filesystem in the rpool (easy enough) for /opt, BUT I'd hope for some zfs magic, to have the /opt directory tree of /-filesystem efficiently moved to the new filesystem - that means: without having to copy it and then remove the original.

My naive understanding of zfs is that it is awesome and can already share stored information between snapshots, and I'd expect it could also just rearrange for a directory to show up in a different filesystem without moving any of the bulk data.

Is there a direct way? If really not, I can still do the "cp & rm".

PS: In case anyone wonders about the "why"? To get it out of the boot-environmemnt on solaris.

  • Your version of "mv" may be capable of moving files across filesystems. Commented Nov 12, 2020 at 16:24
  • @ThorbjørnRavnAndersen Thanks, I'll try it with a small dir... I only remember that some versions of "mv" just do the cp&rm automatically. For large data I want to avoid cp&rm altogether, not just my need to type it.
    – avl42
    Commented Nov 12, 2020 at 16:30
  • I understand that what you want to, is avoiding physically moving the bits on the harddisk. That may require actually carving chunks out of the existing filesystem that /opt exists in for zfs to take over, and is quite likely not supported. Commented Nov 12, 2020 at 16:33
  • maybe I should just clone the filesystem and then remove /opt from first, and everything else from the new one... Edit: nope, at least not that directly... - only snapshots can be cloned... maybe still worth a deeper investigation.
    – avl42
    Commented Nov 12, 2020 at 16:35
  • zfs datasets are completely separate even though they're on the same pool, so mv-ing files between them requires copy-and-delete, same as different partitions on a drive. You don't need to cp & then rm, just mv will do. mv will automatically copy and delete when moving files from one filesystem to another (AFAIK, all version of mv will do this. if you have some horribly archaic version that doesn't then install GNU coreutils or some other decent mv). See unix.stackexchange.com/questions/276600/…
    – cas
    Commented Mar 17, 2021 at 5:04

1 Answer 1


In the meantime I can answer my own question:

Assume it is the /opt ("very large") that needs to move away from root filesystem.

Important!!! Shut down all services that might have files open on /opt, e.g. oracle database server - if that happens to be installed under /opt)

Essentially, what I did was that:

  • zfs snapshot -r rpool@opt-out (created a snapshot - one for the current boot environment would have been enough, but a snapshot probably doesn't hurt, anyway)
  • zfs clone rpool/ROOT/ rpool/opt (cloned a new filesystem off the snapshot of current boot-environment, which initially gets mounted to /rpool/opt -- was my current boot-environment, likely a different one for later readers)
  • mv /opt /OPT; mkdir /opt (move away and recreate mountpoint /opt on root filesystem - /OPT can be deleted, later)
  • cd /rpool/opt; mkdir rest; mv * rest; mv rest/opt/* . ("rest" to be deleted later. Make sure to also check for ".dot-entries" and move them manually at each step)
  • zfs set mountpoint=/opt rpool/opt (remounts the new filesystem on /opt)


Finally restart those services that you shut down before.

  • 3
    Using a clone for this is a bad idea - you can never delete the snapshot that the clone was cloned from unless you also destroy rpool/opt (and zfs promote is not a solution to this, that will only create more problems). If you were using Linux, I'd say "see the zfsconcepts, zfs-clone, and zfs-promote man pages". On solaris, these are probably all combined into a single zfs man page.
    – cas
    Commented Apr 8, 2021 at 8:23
  • 1
    I very strongly recommend creating a VM with a zfs pool to experiment with and practice potentially dangerous operations before trying them on a real system - this is a good idea for any task you're not completely familiar with, not just zfs operations.
    – cas
    Commented Apr 8, 2021 at 8:35
  • I appreciate your pointing out of the downsides. Yet, this solution is currently at work, and you're right about that common snapshot that I cannot get rid of. My expectation is, that if this eventually gets to hurt me (in terms of wasted disk space in the snapshot), then I can create newer snapshots, and then get rid of the old ones, or I can still create a new filesystem lateron and just copy the data over there, then purge the waste.
    – avl42
    Commented Apr 9, 2021 at 17:04
  • This of course uses 'mv' to move the files over, which is a copy+delete operation across two different file systems (worse, on the same volume, likely) -- say you had to move 8TB around on a 10TB fs this way, that's 8TB of copying. Quite a lot. Your question is my question, but you've solved it in a way that doesnt answer it -- how to create an actual dataset out of a subdir, which would obviate the expensive 'copy' portion. This solution does not do that.
    – math
    Commented Dec 7, 2022 at 1:10
  • The solution DID work in the end, and it didn't involve reading&writing of lots of data. -- I created a snapshot - no copying of data -- I cloned the "partition" - n.c.o.d -- I removed contents of /opt on one of the clones - n.c.o.d -- I removed everything but /opt on the other clone - n.c.o.d -- I moved the contents of /opt to / on second clone - as this was an "intra-partition-move", it went fast: n.c.o.d ! -- I mounted (actually just setup the mountpoint of) the second clone on now empty /opt directory of first clone - n.c.o.d.
    – avl42
    Commented Dec 10, 2022 at 18:37

You must log in to answer this question.

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