Doubt about cloning

Support
1

hello, i’m exploring this feature and have kind of a doubt. i want to reorganize shares in rs so decided to clone one share. once done, i can see in the file explorer all folders and files, but from the shares panel i can see

rst-music 200.00 GB 128.71 GB 0 bytes (clone)

rst-media 200.00 GB 128.71 GB 129.02 GB (original share)

the clone on the btrfs says 0 bytes, while on the original share it reads 129.02gb

is this normal? also, can’t see the new cloned share on the dashboard top shares by usage.

my question. is this a real clone with own files or they are some kind of linked to the files on the original share?

just want to do some clean up and reorganizing, but don’t want to end up deleting permanently files.

thank you.

2

@satello Hello again. I’ll have a go at this one:

The answer is, funnily enough, both: at least initially anyway.

A ‘Clone’ in Rockstor parlance is just a ‘special case’ writable (rw) btrfs snapshot. The special case is just it’s path: ie top level. That is why initially it takes no additional space as if no files are changed, in relation to it’s parent, then no additional space is required to represent the same files. However as the parent or the clone (child snapshot) change from one another (ie differ), additional space is required to represent the differing information they then reference.

You can see the relationship via the command line in the following example:
we create a rock-share (in rock-pool) and then clone it:

btrfs subvolume show /mnt2/rock-pool/rock-share
rock-share
	Name: 			rock-share
	UUID: 			59132e14-d486-dc42-bbe1-7ca5d266194a
	Parent UUID: 		-
	Received UUID: 		-
	Creation time: 		2018-06-05 11:17:35 +0100
	Subvolume ID: 		340
	Generation: 		241
	Gen at creation: 	240
	Parent ID: 		5
	Top level ID: 		5
	Flags: 			-
	Snapshot(s):
				rock-share-clone

and the same command for the clone:

btrfs subvolume show /mnt2/rock-pool/rock-share-clone/
rock-share-clone
	Name: 			rock-share-clone
	UUID: 			9defbc90-7931-294c-84c2-af7d762306fd
	Parent UUID: 		59132e14-d486-dc42-bbe1-7ca5d266194a
	Received UUID: 		-
	Creation time: 		2018-06-05 11:17:50 +0100
	Subvolume ID: 		341
	Generation: 		241
	Gen at creation: 	241
	Parent ID: 		5
	Top level ID: 		5
	Flags: 			-
	Snapshot(s):

which doesn’t yet have any snapshots of it’s own, but could have.
Note the “Parent UUID” entries in both of the above.

But given their unique subvolume ID’s they are independent file systems, within the scope of the Pool, or Volume in btrfs speak.

Hope that helps.

1 Like