Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cbsd bclone-local feature request #373

Closed
haynesjustin opened this issue Jan 15, 2019 · 3 comments
Assignees

Comments

@haynesjustin
Copy link

@haynesjustin haynesjustin commented Jan 15, 2019

Mandatory info for bug reports:

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 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64

CBSD version ( cbsd version ):
cbsd@lab01> version
11.2.1

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.

@haynesjustin

This comment has been minimized.

Copy link
Author

@haynesjustin haynesjustin commented Jan 16, 2019

So the issue is that bclone can be slow in my case where an NFS hosted shared filesystem is used to host the guest OS files for the host.

@olevole olevole self-assigned this Jan 16, 2019
olevole added a commit that referenced this issue May 31, 2019
WIP!
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
olevole added a commit that referenced this issue Jun 2, 2019
olevole pushed a commit to cbsd/cbsd-wwwdoc that referenced this issue Jun 2, 2019
@olevole

This comment has been minimized.

Copy link
Collaborator

@olevole olevole commented Jun 2, 2019

@olevole olevole closed this Jun 2, 2019
@haynesjustin

This comment has been minimized.

Copy link
Author

@haynesjustin haynesjustin commented Jun 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.