Re: [Bacula-users] Bacula 2.2.5 source + Win32 binaries released to Source Forge
On Sat, 13 Oct 2007, Ralf Gross wrote: FYI: the HP Ultrium 1840 LTO-4 drives have a buffer size of 128MB. Are these FC or LVD interface? AB - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula 2.2.5 source + Win32 binaries released to Source Forge
Alan Brown schrieb: On Sat, 13 Oct 2007, Ralf Gross wrote: FYI: the HP Ultrium 1840 LTO-4 drives have a buffer size of 128MB. Are these FC or LVD interface? We have two drives with LVD interface. http://h18006.www1.hp.com/products/storageworks/ultrium1840/specs.html Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula 2.2.5 source + Win32 binaries released to Source Forge
On Mon, 15 Oct 2007, Ralf Gross wrote: Are these FC or LVD interface? We have two drives with LVD interface. http://h18006.www1.hp.com/products/storageworks/ultrium1840/specs.html Ah, standalone drives. I was doubtful that the FC-LVD routers in MSL-series changers could keep up with LTO4 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula 2.2.5 source + Win32 binaries released to Source Forge
Alan Brown schrieb: On Mon, 15 Oct 2007, Ralf Gross wrote: Are these FC or LVD interface? We have two drives with LVD interface. http://h18006.www1.hp.com/products/storageworks/ultrium1840/specs.html Ah, standalone drives. Well, the two drive are in a Overland Neo 4100 changer. I was doubtful that the FC-LVD routers in MSL-series changers could keep up with LTO4 I've only limited experience with FC and haven't used it with tape drive. Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula 2.2.5 source + Win32 binaries released to Source Forge
Alan Brown schrieb: Also, as I said, I remain very skeptical about sizes greater than 500K, and there is even a certain amount of evidence from my own tests and from several other users that increasing the size above 128K makes no significant difference. FWIW the tape drives I'm using (HP LTO2 drives in a 60 slot robot) appear to have 2Mb internal buffering. You may well be correct as long as the SD can feed data to the drives fast enough to keep up, but even a SAN fabric can become congested at times. FYI: the HP Ultrium 1840 LTO-4 drives have a buffer size of 128MB. Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula 2.2.5 source + Win32 binaries released to Source Forge
On Fri, 12 Oct 2007, Kern Sibbald wrote: And I did as I said I will increase this limit,. OK, I missed that bit/ Also, as I said, I remain very skeptical about sizes greater than 500K, and there is even a certain amount of evidence from my own tests and from several other users that increasing the size above 128K makes no significant difference. FWIW the tape drives I'm using (HP LTO2 drives in a 60 slot robot) appear to have 2Mb internal buffering. You may well be correct as long as the SD can feed data to the drives fast enough to keep up, but even a SAN fabric can become congested at times. AB - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula 2.2.5 source + Win32 binaries released to Source Forge
On Friday 12 October 2007 15:18, Alan Brown wrote: On Fri, 12 Oct 2007, Kern Sibbald wrote: And I did as I said I will increase this limit,. OK, I missed that bit/ Also, as I said, I remain very skeptical about sizes greater than 500K, and there is even a certain amount of evidence from my own tests and from several other users that increasing the size above 128K makes no significant difference. FWIW the tape drives I'm using (HP LTO2 drives in a 60 slot robot) appear to have 2Mb internal buffering. You may well be correct as long as the SD can feed data to the drives fast enough to keep up, but even a SAN fabric can become congested at times. I suspect that tape drive chop up blocks to suit their needs so that they can index for doing quick forward spacing. From what I understand, older drives wrote in 512 byte chunks no matter what you did. This is unlikely to be true for modern drives, but then modern drives probably buffer up a meg or so of data before writing it, so I suspect that the block size is pretty irrelevant after a certain point. It all comes down to how fast Bacula can feed the data, and that is restricted either by the disk speed if you are spooling, or the comm line speed if you are writing directly. I'm starting to get contacts in hardware manufacturing companies, so will bring up this issue with them at some appropriate point, so we can get the point of view of a manufacturer. Regards, Kern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula 2.2.5 source + Win32 binaries released to Source Forge
On Thu, 11 Oct 2007, Kern Sibbald wrote: Version 2.2.5 is a major bug fix release to version 2.2.4 - It fixes the following bugs: #961, 962, 963, 969, 968, 960, 964, (possibly 935 and 903), 953, 953, 967, 966, 965, 954, 957, 908, 958, and 955. Looking at this, it appears you simply closed 957 Given the _wide_ range of tape speeds now available, perhaps some way of dynamically changing the buffer sizes might be in order? Failing that, the ability to test varying buffer sizes in btape and then allow user-selectable buffer size in SD? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Bacula 2.2.5 source + Win32 binaries released to Source Forge
On Friday 12 October 2007 12:15, Alan Brown wrote: On Thu, 11 Oct 2007, Kern Sibbald wrote: Version 2.2.5 is a major bug fix release to version 2.2.4 - It fixes the following bugs: #961, 962, 963, 969, 968, 960, 964, (possibly 935 and 903), 953, 953, 967, 966, 965, 954, 957, 908, 958, and 955. Looking at this, it appears you simply closed 957 I closed bug 957 with the following comment: == I think you are complaining about a problem that does not exist so I am closing this bug report. The current default is quite appropriate, anything larger would be inappropriate for a large class of drives that exist today. If you have a particularly fast drive, you *can* increase the Maximum Block Size. It is currently limited to 1MB, but you can modify the code if you want. I will increase this limit, but remain *very* skeptical about block sizes greater than 500K, and even that is quite large. For most tape drives (I don't know about LTO-4) 250K is probably more reasonable. === And I did as I said I will increase this limit,. Previously it was at 100, in 2.2.5, it is set to 4096000. Also the submitter was confused about how setting buffers in Bacula and tried to change the maximum buffer size by setting the minimum buffer size, and at some point (if I remember right) Bacula crashed or did something nasty. I've added code in 2.2.5 to test for this inconsistent setting in the conf file and to immediately terminate with and appropriate error message. As a consequence, I don't think it is correct to say that I simply closed the bug report. Also, as I said, I remain very skeptical about sizes greater than 500K, and there is even a certain amount of evidence from my own tests and from several other users that increasing the size above 128K makes no significant difference. Given the _wide_ range of tape speeds now available, perhaps some way of dynamically changing the buffer sizes might be in order? From day one you have had the ability to dynamically change buffer sizes and it works as long as you change the Maximum Buffer Size and not the Minimum Buffer size. This maximum was previously restricted to 1MB, and now it is restricted to 4MB. As I wrote to the submitter -- I think you are complaining about a problem that does not exist. Failing that, the ability to test varying buffer sizes in btape and then allow user-selectable buffer size in SD? From the beginning of Bacula you have had the ability to dynamically change buffer sizes both in btape for testing and in Bacula. I recommend against changing the buffer size, and have documented the consequences and how to work around them long ago in the manual. You are free to change it, but you do so having been warned (i.e. at your own risk). Regards, Kern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
