FreeBSD version ( uname -a ):
FreeBSD lab01.local 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #0: Thu Sep 27 08:16:24 UTC 2018 firstname.lastname@example.org:/usr/obj/usr/src/sys/GENERIC amd64
CBSD version ( cbsd version ):
Description: 'bclone-local' feature to have the exact same effect as 'bclone', but operating only on local files. Use native file operations instead of rsync so that in the case of a remotely hosted filesystem a) copying NFS based files can be faster, b) processor usage is less, c) file copying operations may be offloaded to the remote fileserver where supported.
----following is from the telecom chat at 3:06 pm US Central Time / 9:06 pm UCT ---
I think the solution would be a light one. It would be a subset of some functionality you already have so that it is not too much of a burden to maintain. My ideal solution would be something like the following, but I do not know what impact this would have on your distributed architecture since I have only one node:
Assumptions: the local database is consistent. The database and the files on the local node are representative of the state of cbsd on the local system. The files and DB are authoritative .
Preconditions: the "old=" machine is powered off, and the configuration files, VHD and database are all consistent.
Command: cbsd bclone-local old= new=
Behavior: cbsd creates an exact duplicate of the old machine as the new machine. The only difference is the name. All files, all other attributes in teh database and/or configuration on /usr/jails is duplicated as well. The behavior is just like bclone, except the mechanism is to only copy the files.
the user is responsible for making edits to the properties of the "new' machine. For example the IP address and any unique attributes are to be done separately.
Benefits: - less processing is consumed by the 2 rsyncs. - (I think?) some efficiences can be had on the NFS fileserver side if I turn on an option for cloning or scavenging files that already exist. In other words, the NFS server may be able to copy files on the filesserver side without consuming NFS traffic. I have to check this part.
The text was updated successfully, but these errors were encountered:
We can use additional hook in the appropriate directories for remote action on data:
remove.d for [jbx]remove
rename.d for [jbx]rename
clone.d for [jbx]clone
commands and so on.
This allows you to use any other native implementations to manipulate data.
Issue #373, suggested by: haynesjustin