On 4/12/2012 5:55 PM, Steve Costaras wrote:
>
> In continuing testing here I am still unable to get full speed even when
> using the 96-drive array (16x 6-drive raidz2 vdevs). Which is just insane.
> Also tried a raid-0 of 16 drives as a spool array.
>
> Now the last volume I just tried ended with this:
>
> 2012-04-12 19SD-loki JobId 2: End of Volume "FA0064" at 66:91229 on device
> "LTO4" (/dev/nst0). Write of 64512 bytes got -1.
>
> Which I find interesting as the 64512 there would (in my mind) assume that
> bacula is trying to write 65K blocks? This is the exact same number of the
> last block written on each volume. If bacula WAS writing this small of a
> block size I could see where the problem is.
>
> My bacula-sd.conf is:
>
> ---
> Device {
> Name = LTO4
> Changer Device = /dev/sg87
> Alert Command = "sh -c 'smartctl -H -l error %c'"
> AlwaysOpen = yes;
> Archive Device = /dev/nst0
> AutomaticMount = yes;
> Maximum Block Size = 4194304
> Maximum File Size = 10G
> Maximum Job Spool Size = 800G
> Maximum Network Buffer Size = 262144
> Maximum Spool Size = 12800G
> LabelMedia = No
> Media Type = LTO4
> RandomAccess = no;
> RemovableMedia = yes;
> Spool Directory = /scratchdir/spool0
> }
> -------
>
> So I'm trying to set it to 4MiB here. (Again running 5.2.6 and seeing in
> teh release notes that this was uppped to 20MB max). I also tried 2097152.
>
> Drive itself is set to variable block sizes and when loading the module it
> shows it can handle up to 16MiB-1:
>
> Apr 4 13:08:52 loki kernel: [ 72.194766] st 8:0:17:0: Attached scsi tape
> st0
> Apr 4 13:08:52 loki kernel: [ 72.194767] st 8:0:17:0: st0: try direct i/o:
> yes (alignment 4 B)
> Apr 4 13:08:52 loki kernel: [ 72.350579] st0: Block limits 1 - 16777215
> bytes.
>
>
> So question, in the End of Volume message, is that a correct assessment that
> the SD is trying to write in blocks of 64512bytes?
>
> If so, why is it not taking the larger block size as specified in the
> bacula-sd.conf file?
>
>
>
That does seem to be what it indicates to me (but I'm still running
5.0.3, so YRMV), however, I found that my end-of-media messages
typically look like this:
2012-03-04 11:30:20 sweety-sd End of Volume "MO0038L3" at 92:1171 on
device "LTO3" (/dev/nst0). Write of 262144 bytes got -1.
2012-03-04 11:30:24 sweety-sd Re-read of last block succeeded.
And my block size is set to 262144 (aka 256K), whereas the default block
size is 64512, (aka 63K)--since you are seeing a (presumably full, but
maybe not) block that fills the media being only 63K long, it at least
seems that somehow your configured block size is not being observed.
Another point towards that end, even assuming that the current file on
the tape was nearly complete (i.e. 10GByte), then it isn't possible that
you were at block 91229 (which the log message indicates you were) with
a block size anywhere near 4MB (in fact, 10GiB/91229 = ~115KiB). It
looks like the largest possible average block size you saw in the last
file was about 115Kbytes (and if the last file was a bit less than half
complete, this would be consistent with an average block size of ~63K).
I don't fully understand bacula's blocking mechanism, but this seems
unusual to me (given your configured file size of 10G and maximum block
size of 4M).
-se
-se
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
