Re: LTO 8 Slow write speeds
Gilles Van Vlasselaer <[email protected]>
| Newsgroups | gmane.comp.bacula.user |
|---|---|
| Message-ID | <[email protected]> |
Hi Udo, > That's good news. Please leave out the "Minimum Block Size". "Maximum > Block Size" defines also the default that will be used. ITDT made up > the 29G, you don't need to adhere to them. Even though 1024K Transfer > Size is not listed in the ITDT table you should give it a try. I can't seem to get Maximum block size = 1024K to work, I can't label the tapes either with btape or bconsole; Tape block granularity is 1024 bytes. btape:btape.c:477-0 open device "ultrium" (/dev/nst0): OK *label Enter Volume Name: a-test-label Wrote Volume label for volume "a-test-label". *readlabel 11-Apr 15:29 btape JobId 0: Error: [SE0203] The Volume=a-test-label on device="ultrium" (/dev/nst0) appears to be unlabeled. btape:btape.c:525-0 Volume has no label. Volume Label: Adata : 0 Id : **error**VerNo : 11 VolName : a-test-label PrevVolName : VolFile : 0 LabelType : PRE_LABEL LabelSize : 0 PoolName : Default MediaType : LTO PoolType : Backup *wr btape:block.c:163-0 [SF0205] Attempt to write on read-only Volume. dev="ultrium" (/dev/nst0) btape JobId 0: Fatal error:block.c:163 [SF0205] Attempt to write on read-only Volume. dev="ultrium" (/dev/nst0) btape:btape.c:1913-0 Error writing block to device. When I revert it to 512K, the labeling works as expected, maybe the drive isn't capable of managing 1M block sizes? Tape block granularity is 1024 bytes. btape:btape.c:477-0 open device "ultrium" (/dev/nst0): OK *label Enter Volume Name: b-test-label Wrote Volume label for volume "b-test-label". *readlabel btape:btape.c:528-0 Volume label read correctly. Volume Label: Adata : 0 Id : Bacula 1.0 immortal VerNo : 11 VolName : b-test-label PrevVolName : VolFile : 0 LabelType : PRE_LABEL LabelSize : 184 PoolName : Default MediaType : LTO PoolType : Backup *wr btape:btape.c:1916-0 Wrote one record of 524188 bytes. btape:btape.c:1918-0 Wrote block to device. Whilst being in the btape CLI, I was running test and when Max block size is set to 512K I get the following; Doing Bacula scan of blocks: 1 block of 524224 bytes in file 1 End of File mark. 2 blocks of 524224 bytes in file 2 End of File mark. 3 blocks of 524224 bytes in file 3 End of File mark. 1 block of 524224 bytes in file 4 End of File mark. Total files=4, blocks=7, bytes = 3,669,568 End scanning the tape. We should be in file 4. I am at file 4. This is correct! The above Bacula scan should have output identical to what follows. Please double check it ... === Sample correct output === 1 block of 64448 bytes in file 1 End of File mark. 2 blocks of 64448 bytes in file 2 End of File mark. 3 blocks of 64448 bytes in file 3 End of File mark. 1 block of 64448 bytes in file 4 End of File mark. Total files=4, blocks=7, bytes = 451,136 === End sample correct output === If the above scan output is not identical to the sample output, you MUST correct the problem or Bacula will not be able to write multiple Jobs to the tape. When I removed the Max Block size property the sample and scan output are identical, should I be worried? > Please reevaluate your spool disk. As you can see in the ITDT table > you already need 389MB/sec sustained if data is compressible. All our backups are already compressed, I assume a Copy Job doesn't decompress beforehand? Anyway, thanks once again for your input, have a nice weekend - Gilles On 4/10/25 19:58, Udo Kaune wrote: > Am 10.04.25 um 13:33 schrieb Gilles Van Vlasselaer: >> >> Hi Udo, >> >> Thanks for your input, with the itdt command I got the following; >> >> Compres- Transfer Data Size Elapsed Data Rate >> able Size (KB) (MB) Time (s) (MB/s) >> +------+---------+---------+--------+----------+ >> | No | 512 | 29999 | 104.766| 286.342 | >> | No | 256 | 29999 | 104.386| 287.385 | >> | No | 128 | 29999 | 114.132| 262.844 | >> | No | 64 | 29999 | 155.715| 192.654 | >> | Yes | 512 | 29999 | 76.9336| 389.934 | >> | Yes | 256 | 29999 | 85.9795| 348.909 | >> | Yes | 128 | 29999 | 108.639| 276.135 | >> | Yes | 64 | 29999 | 152.646| 196.526 | >> >> In the Device resource for my LTO drive I've added; >> >> Minimum block size = 256K # Seemed to be optimal >> Maximum blocksize = 512K # Seemed to be optimal >> Maximum File Size = 29G # Less start-stops for EOF marks >> >> The Bacula docs defines a default of 64K which seemed to perform >> 'poorly' for my drive. >> >> Now I'm running a test copy job of 600GB, averaging 210MB/sec and >> peaking 240MB/sec at time, huge improvement, never heard the drive >> zoom so hard during writes. >> >> Thank you once again! >> >> - Gilles >> > > Hi Gilles, > > That's good news. Please leave out the "Minimum Block Size". "Maximum > Block Size" defines also the default that will be used. ITDT made up > the 29G, you don't need to adhere to them. Even though 1024K Transfer > Size is not listed in the ITDT table you should give it a try. > Please reevaluate your spool disk. As you can see in the ITDT table > you already need 389MB/sec sustained if data is compressible. > > br, Udo > -- > Bitte denken Sie an die Umwelt, bevor Sie Mails drucken. > Please consider the environment before printing mails. > -- > iNet Integrative Netzwerke Udo Kaune e.K. > Deichstraße 6 > 25335 Elmshorn > Tel: +49 (4121) 579 69 35 > Fax: +49 (4121) 579 69 99 > Web:http://www.inet-hamburg.de > Handelsregister Pinneberg: HRA 1509 EL > > > _______________________________________________ > Bacula-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-users _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users