 |
we put it into a feature request. This will induce significant code redesign. Have you tried to run 2 separate FDs on the windows machine? I am not sure, if it works but it might be a workaround. |
|
|
Note to self. VSS implementation uses a global variable for keeping track of the VSS its performing. There is a mutex lock that locks any two threads for ever entering the critical section of the VSS session e.g. from start backup till end backup and from start restore till end restore when there is some meta data to restore. When there is no meta data to restore the restore will restore without VSS enabled. Its seems that this is not easy to solve, we do initialize the COM subsystem for multithread support (as we needed that for the MSSQL plugin.) so it might be possible to have now two or more handles to the VSS subsystem and as the the fileset determines what gets snapshotted (for now only drives but soon also VMPs) I cannot imagine you can only have one set of VSS data. Some ideas: - If we cannot get ride of the global VSS client we might look at stuffing it into thread specific storage. - First figure out if you can even have multiple sets of VSS data in one process (e.g. how multithreaded VSS really is.) All in all it means yet an other serious redesign of the windows subsytem which have to wait until we stabilize the other pending windows patches. |
|
|
No, we have not tried running two FDs on the same machine. If time permits i will test it. From what i can see here http://msdn.microsoft.com/en-us/library/windows/desktop/aa384629%28v=vs.85%29.aspx there should be no limit regarding thread safety, but i'm not a developer at all. As said would be nice to have, at least to be conform with documentation and Unix behaviour. Thanks Andreas |
|
|
Given that the whole windows code uses a slack of global variables this means getting at least rid of those before even being able to try instantiating multiple VSS instances. Over the holiday season dissected the whole problem and its one big mine field of global variables and caches. So that needs to be cleaned to be able to not get worse performance as one job destroys the cache of an other. Some small progress made but needs lots of testing and a lot more work. For now not really worth the effort. |
|
|
Fix committed to bareos bareos-15.2 branch with changesetid 6018. |
- Anonymous
