4

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.

avl42
  • 61
  • Your version of "mv" may be capable of moving files across filesystems. – Thorbjørn Ravn Andersen Nov 12 '20 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 Nov 12 '20 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. – Thorbjørn Ravn Andersen Nov 12 '20 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 Nov 12 '20 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 https://unix.stackexchange.com/questions/276600/how-to-move-files-from-one-zfs-filesystem-to-a-different-zfs-filesystem-in-the-s – cas Mar 17 '21 at 05:04
  • @cas nice&correct answer - just for a different question. – avl42 Apr 08 '21 at 07:00
  • actually, it's the same question, with very minor variations in the details - a dupe. Just like the linked question, you want to move files from one dataset (rpool) to another (rpool/opt). The question is the same, and the answer is the same: There is no clever way to avoid copying the data between datasets, so just use mv, or cp & rm (or rsync & rm, or tar & rm, etc). – cas Apr 08 '21 at 08:30
  • It certainly is a different question, because it explicitly excluded a copy&rm, even if hidden behind a mv.

    Based on the comments below, it is certainly possible that the answer I then found myself has its downsides, and if they turn out real, then this question would differ from the other one in your previous comment simply in that this one would have "no" answer.

     – avl42 Apr 09 '21 at 16:57
  • deliberately excluding the only actual solution does not make it a different question. the question is the same, even if you don't like the answer. – cas Apr 09 '21 at 23:36
  • if I were asking for a solution to x²=25 and deliberately excluded x=5, then it is a different question than one that has already been answered with "x=5". Ok, enough. You can split hairs as you like, but I'm not likely going to answer again. Thanks anyway, for adding the caveat about my clone-solution wrt the snapshot. Anyone passing by here later is well-advised to consider it. – avl42 Apr 11 '21 at 14:16

1 Answers1

2

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/11.4.23.69.3@opt-out rpool/opt (cloned a new filesystem off the snapshot of current boot-environment, which initially gets mounted to /rpool/opt -- 11.4.23.69.3 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)

done.

Finally restart those services that you shut down before.

avl42
  • 61
  • 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 Apr 08 '21 at 08: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 Apr 08 '21 at 08: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 Apr 09 '21 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 Dec 07 '22 at 01: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 Dec 10 '22 at 18:37
  • Btw., now, 1½ years later I still have the original common snapshot, so I haven't yet tested my plans on replacing the snapshots. – avl42 Dec 10 '22 at 18:37