From: Kern S. <ke...@si...> - 2005-02-27 20:34:57
|
On Sunday 27 February 2005 12:51, Arno Lehmann wrote: > Hello. > > Kern Sibbald wrote: > >>So now, the director can get the information it needs from the SDs, > >>which is new, I understand. An important improvement, I'd say. > > > > Yes, the Director now has a list of all the Devices for each SD with the > > following info: > > > > class DEVICE { > > public: > > RES hdr; > > > > bool found; /* found with SD */ > > int num_writers; > > int num_waiting; > > int use_count; > > bool open; > > bool append; /* in append mode */ > > bool read; > > bool labeled; > > bool autochanger; > > bool offline; > > char VolumeName[MAX_NAME_LENGTH]; > > char MediaType[MAX_NAME_LENGTH]; > > Why not make this an array or a list? Or even something like > LIST_TYPE MediaTypeReadable > LIST_TYPE MediaTypeWriteable > > I do think that multiple supported media types will be introduced in the > (relatively) near future, and why not prepare things now that you > already introduce new structures? You know, there are two large classes of programmers ("large classes" means "this is a bit of a simplification") those like you and David who like to design everything up front, and those like me that like to design/implement things in little chunks. The advantage of your way is that it is programmed once. The disadvantage is that it often takes forever to debug. The advantage of my way, is that debugging is incremental, thus easy, and the product is stable. The disadvantage of my way is that it requires re-programming several times, which I don't mind, and has the advantage that when I get to where I want to know, I am sure it is the right way. So, you see, we both arrive at the same point, just the path of getting there is different. > > Or does that class describe the current device usage only? Yes, and it has changed since I first programmed it, and it will surely change over time, hopefully not again in 1.37. :-) > > (I'll leave these lines in, but before I start discussing this I > *should* perhaps have a look into the source as it is now. Although I > would need quite a time to understand it...) > > > }; > > > > So, as you see, the Director now knows what Volume is in what drive, and > > it knows what MediaType is associated with a device, so there is no need > > for the user to put it in the bacula-dir.conf (I still need to change the > > code). The director also knows whether or not the device is part of an > > autochanger, ... > > That's as it should be - this stuff should be setup only once. > > >>The configuration allows to bind jobs to distinct devices or media > >>types, or it allows the director to make these decisions. > > > > Well, this was my original idea some time ago, my current thinking is > > that the configuration will still specify which devices can be used, but > > there is no need to specify the Media Type -- possibly I'll add that in a > > later version. > > I'd keep it possible for the user to bin a job to a media type. Unfortunately, it is probably another project. I am not ruling it out as a future addition, but unless things go much smoother than I expect it is probably ruled out this cut. > > Imagine the following: > An autochanger with many slots. LTO, as an example. > In some of them is an LTO-1 cartridge, in others an LTO-2 one. > For full backups you want to use the LTO2 tapes, for incrementals the LTO1. > Sure, you can put them in different pools, but wouldn't have to. > > > Ok, thanks for the further clarification. I hope that it's not only me > who understands things better now. > > >>Still, I miss a clean and documented interface between the director > >>(rather, the job management functions) and the SD management (device > >>management, tape management). :-) > > I'ts not that I want to keep nagging you, but I really tink that this is > an area where many changes might be necessary in the future. Not > necessarily more than elsewhere, it's just that I try to think how to > improve that part. What is important to me is not that I implement everything now but that I do not go in a direction that will require a major upheaval either for the code or the users in the future -- so far, I have avoided major upheavals ... > > Of course I do understand that you can do only so much and that you have > your personal priorities. > > > If there were three or four of me this would be possible. Unfortunately, > > it is unlikely I will do much documentation along those lines. I have a > > lot of programming to do, and it is *extremely* difficult programming to > > get right. If I had more time and energy, I would do pretty much a > > re-write of the SD because it has been patched too many times now. Then > > there is all the user documentation where I have barely scratched the > > surface in the ReleaseNotes. > > There were some offers of money recently - we could have you cloned ;-) Yes, I would love to be cloned. I have an interesting idea how to generate money for the project, but it is a whole separate project. I will be working with O'Reilly to publish the idea in the near future -- I'm waiting for an interview with me about the Bacula project to be published before beginning in earnest on this article. > > Or perhaps somebody will be able to help there. We'll see. Something always seems to drop out of the sky at the right time ... :-) > > Have a nice Sunday, It was -- thanks. Aside from having a really nice outing with my wife, I found and fixed a long standing Verify bug and have 1.36.2 ready for imminent release. :-) -- Best regards, Kern |