I have been investigating the storage usage of the share that is holding all of the data from the rock-on service. For one it seems that it is running far more snapshots that I would like it to. Additionally, I do not see anywhere in the scheduled tasks a command to be running all of these snapshots. Finally, I did not realize that it was going to take up as much space as it is. Does anyone know how to migrate a share from the OS pool to my primary storage pool? Thank you for any assistance.
uuuuuu …
So, Rock-on is not really any of rockstor service, it’s a docker in disguise:) Rockstor is using their own name because they automated the whole process and made it fool proof ( it’s me proof = more than adequate 
)
Docker is a peculiar beast. Snapshots that you see are actually a “thin provisioning” trick that docker uses. If you will delete one snapshot (which is physically a thin provision subvolume that is made to look for you as a snapshot) your docker will explode with nice green after glow from nuke you dropped on it (;
Few details about naming and physical reality.
pool = a singular file system (of btrfs), it can span on multiple discs, but it’s still a singular FS - it’s non divedable, inseparable, non joinable. just a file system.
share = a subvolume, but not like LVM suvol where you allocate space physically on the disk, and you get X sectors for it … think of it more as of a “special & magical & mountable folder” - it is part of your FS, it does not occupy a specific sectors pre allocated on disk (in future you can limit it in size, but that’s about it), you can monted just like a disk, you can set a specyfic subvol to be a default, so if you mount FS without any subol option it will use this subvol as a root of FS.
snapshot = snapshot (on laiman tearms) = subvol that represented a mirror image of other subvol in specific point in time without producing any additinal space usage - snapshot works like a subvol, can be mounted, you can create a snaphot of a snapshot etc.
Still, subvolume and snapshots are not movable between FileSystems - BUT - if you have some knowledge of *nix console you can theoretically clone subvolumes to other FS your self. *nix is not windows world, you don’t have to use a magical (and expensive) cloning tools to make stuff work.
So process to follow:
- Stop rockon
- perform a full backup of everything rock-on related and you operating system related
- on your other pool (FS) create subvolumes with exactly identical names as ones used in you rock-on (might be needed to do it by hand)
- mount source and destination subvolume by hand to separate locations and execute command
- cp -xar /path_to_source_mount_poin/* /path_to_destination_mount_point/
- rinse & repeat for all subvolumes in question.
- destroy source subvolumes and reinstall rock-on and chose a destination subvolumes.
Ofcourse you can ignore this long winded process and just drop the nuke on your rock-on install and just delete rock-on storage subvolume and start fresh with subvolume on your non operating system pool. All important data should already be in shares that you should have already created outside of your operating system FS
1 Like
Maybe I should mention that it would be a jolly good feature to have a simple share migrating tool that you just “click” but that’s life for time being.