Le Friday 07 November 2008 14:36:46 Kern Sibbald, vous avez écrit : > On Friday 07 November 2008 13:19:45 Ralf Gross wrote: > > Kern Sibbald schrieb: > > > On Thursday 06 November 2008 22:47:41 Ralf Gross wrote: > > > > Alex Chekholko schrieb: > > > > > On Wed, 5 Nov 2008 16:12:51 +0100 > > > > > > > > > > Kern Sibbald <[EMAIL PROTECTED]> wrote: > > > > > > For writing to tape (providing it is LTO-n) I strongly recommend > > > > > > a block size not to exceed 256K. > > > > > > > > > > Hi Kern, > > > > > > > > > > Why do you say that? Is this thread relevant?: > > > > > http://www.mail-archive.com/[email protected]/msg0 > > > > >12 46.h tml > > > > > > > > > > Also, I would like to corroborate the OP's experiences; I had an > > > > > almost identical thread about small block size and slow write > > > > > speed: http://www.nabble.com/LTO-4-performance--td17407840.html > > > > > > > > > > In fact, I was unable to get higher block sizes working at all with > > > > > btape: > > > > > http://www.adsm.org/lists/html/Bacula-users/2008-05/msg00504.html > > > > > > > > > > So I am still stuck at ~22MB/s writing to LTO-4 with the default > > > > > block size. > > > > > > > > I don't think that the blocksize is the problem. I did some tests but > > > > couldn't get higher results with larger blocksizes. I get 75-85 MB/s > > > > with the default bs and no additional tuning. > > > > > > That is probably correct, but most likely only because you have a > > > bottleneck elsewhere -- probably in one of the points I mentioned. The > > > speed is always capped by the slowest component. Once you remove the > > > other bottlenecks on your system, the blocksize will very likely become > > > the bottleneck and then you can measure the difference. > > > > I didn't want to compain, just show the org. poster that his 22 MB/s > > are likely not a bs issue. > > > > That being said, I started a thread on the user list a while ago where > > I aked what throughput people are getting when writing to tape. Nobody > > involved in this thread got higher numbers than 80-85 MB/s for a > > single job. > > That is probably reasonable for one job, but if you are writing to an > LTO-2,3, or 4, we know that with multiple simultaneous jobs it is possible > to get write speeds of 150 MB/sec. > > Kern
This is with a good hardware compression rate, but it's a very good test, IMHO, more than using random data to get only 80MB/sec. If you able to write at 150MB/s, i'm pretty sure that you will be able to write at 80MB/s... Even if your source file is made with a dd if=/dev/zero, your harddisk, your network, your SCSI/SAS or whatever controler have to handle it like real data. Bye ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
