I stand corrected... It seems the data rate matching in LTO-3 drives
isn't as flexible as I'd have thought... One interesting thing to note
in the doc you mentioned is that if you think you may be shoe-shining,
try backing up onto an LTO-2 tape as this will run the drive at native
LTO-2 speeds rather than at the much higher data throughput of LTO-3.
Bob
[EMAIL PROTECTED] wrote:
>
> In the message dated: Thu, 28 Feb 2008 11:21:31 EST,
> The pithy ruminations from Bob Hetzel on
> <Re: [Bacula-users] Volumes marked with Error> were:
> =>
> => First a quick note... drives LTO 2nd generation and newer should not
> => shoeshine unless you're really running way to slow a cpu for what else
> => is going on with the computer.
>
> Huh? That's exactly the opposite of everything I've heard from drive
> manufacturers, from Curtis Preston, etc.
>
> The faster the drive, the more difficult it is to supply it with enough data
> to
> prevent shoe-shining. In general, the limiting factor isn't the CPU of the
> backup server, but the disk drives that are supplying data and the network
> connection[s] end-to-end between the data source and the tape drive.
>
> For example, an LTO-3 drive supports a native (uncompressed) throughput of
> 80MB/
> sec. This means that, for "average" data that the drive will be compressing,
> the
> server must supply data at the rate of 120~160MB/sec to keep the drive running
> at full speed. This is not trivial. Many tape drives are capable of variable
> write speeds, deliberately slowing down when the incoming data rate is
> insufficient, in an attempt to avoid shoe-shining. AFAIK, the minimum data
> rate
> that LTO3 drives must receive in order to avoid shoe-shining is ~35MB/s. This
> can be difficult to achieve in a real-world environment, such as reading data
> from a server in active use, sending that data over a network (even GigE)
> that's
> used for other tasks, and competing with other streams of client data being
> sent
> the same backup media server (ie., storage director).
>
> My simple rule of thumb:
> If the data source is a single spindle (ie. not a RAID device), then
> you will not be able to feed an LTO3 drive fast enough to prevent
> shoe-shining. With a single disk, even an LTO2 drive may shoe shine,
> depending on the overall system and the compressibility of the data.
>
>
> http://www.open-mag.com/features/Vol_117/LTO3/LTO3.htm
>
> http://www.datastor.co.nz/Datastor/Promotions.nsf/4a91ca5e06d20e15cc256ebe0002290e/d954d1c5e5e6df09cc25723b00740956/$FILE/When%20to%20Choose%20LTO3%20Tape%20Drives.pdf
>
> =>
> => If the room air temp is less than 85 degrees or so it's unlikely in a
> => tape autoloader cabinet (i.e. good airflow by design) that you've got a
>
> Yep.
>
> [SNIP!]
> =>
> => Also, have you considered spooling everything? I know this may slow
> => down your backups on fast servers but the increase gained in doing more
> => than one thing at a time may balance this, especially on incrementals.
>
> Absolutely. You may be able to avoid shoe-shining by spooling data from
> individual servers onto a fast RAID device on the storage director. This will
> probably produce a small decrease in the backup time for individual servers,
> and a significant decrease in the aggregate backup duration for multiple
> concurrent clients.
>
> =>
> => > Date: Wed, 27 Feb 2008 09:31:40 +0000
> => > From: Bob Cregan <[EMAIL PROTECTED]>
> => > Subject: Re: [Bacula-users] Volumes marked with Error
> => > To: bacula-users@lists.sourceforge.net
> => > Message-ID: <[EMAIL PROTECTED]>
> => > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> => >
> => > Hi,
> => > I am running the following
> => >
> => > Director, Storage deamon 2.2.6. The library is an Overland Arcvault 24
> => > (LTO3)
> => > Most clients (about 30 ~ 8TB in total) are 2.2.4
> => >
>
> [SNIP!]
>
> => >
> => > There is one thing that I thought may have a bearing. I am using a
> => > mixture of spooled and non spooled backups. Some of the backups are on
> => > old hardware, consist of lots of very small files (several million ~1Kb
> => > html files ) and the resulting very poor throughput can result in a big
> => > shoeshining problem - I generally spool these. Other ones are large
> => > database files with good throughput so I run these direct to tape. The
> => > spool files can be as big as 80Gb.
> => >
>
> I have a very similar arrangement. I spool data from ~25 clients (some on
> GigE
> and some on 100Mb) to 3 spool files on my storage director. The spool files
> are
> located on separate LUNs on a fast RAID array. Each spool file is limited to
> 60~90GB.
>
> In my case, the only client which writes to tape directly (without spooling)
> is
> the storage director (which is also a file server with about 3TB). I haven't
> checked backup performance for "collisions" between unspooling data and a
> direct backup of the sd.
>
>
> => > The director allows four concurrent jobs, I have two tape drives one of
> => > which is generally Incrementals only the other Full backups only.
> => >
> => > Can there be a problem if a spool file is despooling and a "direct to
> => > tape" job also need to write to the tape? Should I spool all my jobs?
> => >
>
> Hmmm.... I'm not ready to suggest that, but I am very interested in hearing
> about your findings if you do try it.
>
> => > Any advice would be very welcome.
> => >
> => > Thanks
> => >
> => > Bob
> => >
> =>
>
> ----
> Mark Bergman [EMAIL PROTECTED] 215-662-7310
> System Administrator Section of Biomedical Image Analysis
> Department of Radiology University of Pennsylvania
> PGP Key at: https://www.rad.upenn.edu/sbia/bergman
>
>
>
> The information contained in this e-mail message is intended only for the
> personal and confidential use of the recipient(s) named above. If the reader
> of this message is not the intended recipient or an agent responsible for
> delivering it to the intended recipient, you are hereby notified that you
> have received this document in error and that any review, dissemination,
> distribution, or copying of this message is strictly prohibited. If you have
> received this communication in error, please notify us immediately by e-mail,
> and delete the original message.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
