Hello,

czw., 7 lut 2019 o 02:34 Adam Nielsen <a.niel...@shikadi.net> napisał(a):

> > Spooling can reduce overall throughput because the data is
> > sequentially written to disk and then read back.
>
> This is what got me.  I thought it was a buffer to ride out variations
> in disk read speed (like the mbuffer program) but it's not.  The
> purpose is to get data off clients as fast as possible for later
> writing to slow tape.
>

It is actually, as pointed by Wolfgang, the opposite. The spooling is to
resolve the problem with fast tape and slow client.


>
> Consequently spooling works best when the spool file is large enough to
> contain one whole tape's worth of data, and you have enough clients
> backing up that there is always a complete spool file ready to write
> out to tape.
>
> Anything less than this and spooling will slow things down.
>

No, absolutely not. The spooling always slow down the backup process as it
has to write data to local disk and then to read this data back to write to
tape instead of direct write to tape.

The only caveat here is the tape shoe-shine problem which can introduce a
larger slow down then a spooling and a higher tape cartridge wear. In this
case the spooling wins.


>
> I think we need a FIFO buffering option in Bacula that will let a few
> GB of data be buffered in memory, so that the tape doesn't shoe shine
> when the disks briefly go slow for some reason.
>
>
Well, this is exactly what a spooling is doing right now. But instead of
saving a stream to memory it saves it to disk.


> I looked at the code for this but it seems like it could be a bit
> tricky, because you need to return success/fail for each written data
> block, but you can't really do this if you're caching them for writing
> later.  This is because if there's a write error, it's difficult to
> handle the error when the block was already written long ago.
>

???

The Bacula backup stream network protocol does not work that way. The FD
(or SD in special case) sends (SD receives) data as fast as possible
without any confirmation (except TCP signaling).

best regards
-- 
Radosław Korzeniewski
rados...@korzeniewski.net
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to