On Thursday 02 July 2009 18:49:59 Graham Keeling wrote: > I sent the following email to the bacula-devel list this morning, but > again, it seems not to have turned up. I have now added to this at the > bottom.
It does seem to be working, but is just a bit slow through the list. > > On Thu, Jul 02, 2009 at 11:04:44AM +0200, Kern Sibbald wrote: > > One thing that I don't understand is the need to build the Win64 version, > > unless you have changes that you have not sent to the project. In that > > case, I kindly ask you to tell me where I can find the changes so that I > > can download them as the license requires. We will help you as much as > > we can, and you in turn should help the project :-) > > Hello, > Yes, I have changes to do with making restore from multiple storage daemons > work. I have already emailed the patch file to the list. > You can find it here: http://markmail.org/message/t2te5k45qmbr7ssv > > The last time this was talked about, you gave me a list of six 'rather > trivial but essential modifications' that you wanted me to do (which I am > finally OK, thanks for pointing this out. > > getting round to doing): > > 1. You haven't followed the developers programming style guidelines > > that are described in the developers manual. > > > > 2. In addition to the guidelines documented, we do not use // for > > comments except in column 1 to turn code off. Please use C style > > comments. > > > > 3. We do not in general return -1 to mean true and zero to mean false. > > We use true and false and a bool type. The exception to this is > > sometimes some very low level routines that mimic the Unix OS call > > convention. > > > > 4. There aren't many comments. In particular, you have changed a major > > flow within Bacula, so that merits at least some comments so that > > the overall concept of what you are implementing can be easily > > understood. I think the essential elements are in your email > > message below, and it is just a matter of putting it in an appropriate > > place in the code. > > > > 5. We will also need some user documentation that explains the > > ramifications of this change for users. > > > > 6. Can you specify (email or possibly in the user documentation) what > > happens if there is an error with one of the storage daemons -- i.e. does > > everything shutdown correctly, and is it clear to the user which storage > > daemon had the problem? > > > > I would appreciate it if you would make the above rather trivial but > > essential modifications to your patch and then resend it to me. > > (A day later)... > The attached patch addresses points 1-4 above and applies to the > bacula-3.0.1 source. If you sent another patch a day later, I unfortunately did not get it. To be 100% clear, I do now have your patch-3 and your original patch. On a first quick look, your patch-3 seems to be quite clean. Thanks. We will undoubtedly integrate it in the next week or two. > > > 5. We will also need some user documentation that explains the > > ramifications of this change for users. > > I don't know what you mean by 'some user documentation' - whether it should > be a patch to something, for example. Oh, it is always better to have a patch to the appropriate "doc" file or files, but the text below looks fine to me and we can take it from there. I meant "some" in the context above to mean user documentation without being too involved or voluminous. > But here is my explanation of the ramifications: > > These changes mean that you can restore from volumes held by multiple > storage daemons - for example, SD1 has a Full backup and SD2 has your > incrementals. Previously, in this situation, the file daemon would just try > to use a single storage daemon and would get stuck when it got to a volume > that the storage daemon knew nothing about. > If you want the new functionality, you will need to update your director > and your file daemon (there are no changes to the storage daemon). > If you update the director, you do not need to update your file daemon - > the old file daemon will carry on working as before. > > 6. Can you specify (email or possibly in the user documentation) what > happens if there is an error with one of the storage daemons -- i.e. does > everything shutdown correctly, and is it clear to the user which storage > daemon had the problem? > > It's not very much different from what happened before. > After the director sends a bootstrap file to the file daemon, the director > does a wait_for_storage_daemon_termination(). > Then, once that returns, if jcr->SDJobStatus != JS_Terminated, the director > bails out of its restore loop, then cleans up the FD stuff. > As the process will stop with the last Storage daemon that failed, the job > report that gets sent/printed out at the end will state that Storage > daemon, so it should be pretty obvious to the user which SD had the > problem. OK, that seems pretty clair. Thanks, Kern ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
