You could clone the root dataset, but promote won't do any good as you won't be able to destroy the root dataset once it is the clone since it will always have children. Thus, the original snapshot would become permanent. If this is acceptable, then clone to a new dataset then delete the files that are not needed in root.
Thank you Philip. I also found this possibility, which would work for the time being but feels downright ugly. I probably could not sleep at night anymore, knowing I've this, somewhere, waiting for me ;) what I was hoping for is that there be a way to promote a sub dataset to root dataset (while everything is unmounted) and re mount everything after that. But this is not a feature of ZFS, I'm afraid (not sure it's a feature of any modern filesystem, tbh).
Incremental rsync of each folder. Write a script that walks the dataset root and copies over the content to the new dataset and then removes the source folder. You will have to turn off snapshots and remove all of them to gain the space needed if utilization is above 40%. If it’s below you can just zfs send
.
Thank you Garm. This seems to be the hard way I'll have to follow.
Something else popped in my mind, though:
1) De-share the projects folder in the root dataset
Create a subfolder "old_projects", move everything to it and reshare (all this takes roughly 30 seconds)
At this point, users do not see a difference except that jails folder and other datasets cannot be seen anymore (I'm not sure how intelligently snapshots handle this, but I'll find out)
2) Create a sub dataset "projects" which, thanks to the preceding actions, won't appear to users (who would be quick to wonder and test >_<)
Create the project folders in the new sub-dataset and mount_nullfs the real projects folders to them
Again, deshare/reshare to the new dataset
At this point, system is running everything seems to work, nothing really changed.
3) Each time I can organize downtime, I demount a project, rsync it to the subdataset, and delete it from the root dataset.
Or I just let the project leader inform every coworker/freelancer not to touch the project until further notice while I'm moving the files and count on the fact that people are responsible, can be trusted and just kidding
Does it sounds like evil and catastrophic sorcery ? yes.
Is there an elegant solution to my problem, not involving one week downtime ? (considering %used > 60% and rsync taking ages to transfer lots of huge folders ~20k files ?) does not seem like it :/