Bacula-users

Re: [Bacula-users] Configuring autochanger with SAS LTO-5 drives

2017-06-23 12:16:41
Subject: Re: [Bacula-users] Configuring autochanger with SAS LTO-5 drives
From: Ivan Adzhubey <iadzhubey AT rics.bwh.harvard DOT edu>
To: <bacula-users AT lists.sourceforge DOT net>
Date: Fri, 23 Jun 2017 12:15:41 -0400
Hi,

Thank you, Rudolf. This is very useful information! Thank you for taking effort 
to benchmark this.

Best,
Ivan

On Friday, June 23, 2017 03:53:04 PM Cejka Rudolf wrote:
> Cejka Rudolf wrote (2017/06/05):
> > Cejka Rudolf wrote (2017/06/02):
> > > Ivan Adzhubey wrote (2017/06/01):
> > > > b) What is the effect of MaximumFileSize option and what would be its
> > > > optimal value for my IBM LTO-5 SAS drives? I have used 8GB value
> > > > found in one of the list posts, while the documentation suggests 2GB
> > > > for LTO-4. But even set at 8GB this would create lots of EOF marks on
> > > > a 1.5TB tape, do we really need so many?
> > > 
> > > Hi, I do use 16 GB. Every EOF mark means around 3 seconds delay. So if
> > > you have over 200 files on the tape using 8 GB, it is around 10 minutes
> > > extra per tape.> 
> > Hi, small fix. It seems that it is even around 5-6 seconds delay resulting
> > in extra 20 minutes per tape. And worse, I'm afraid that the tape drive
> > do not stop nor slowdown tape movement, which would mean over 10 % of the
> > tape lost because of filemarks. Hope that I'm wrong.
> 
> Hi, I finally have done and finished real testing with Maximum File Size
> option. Tested on LTO-6 drive with LTO-5 tape, so the results are relevant
> for LTO-5, used btape utility and fill s (simplified) command.
> 
> Fortunately, I has negligible impact on tape capacity, but unfortunately, I
> has really dramatical impact on overall write speed and you have to count
> not just 5-6 seconds, but better 8-10 seconds per file. I also added time
> to read one file at 140 MB/s, which is important for seeking during
> restores.
> 
>   File   Simplified   Simplified           Bytes     Files   Rough time to
>   size    fill time    fill rate         written   written   read one file
> 
>   1 GB      6:44:18    61.8 MB/s   1498688192512      1499       00:00:07
>   2 GB      4:51:30    85.7 MB/s   1498737278976       750       00:00:14
>   4 GB      3:54:57   106.3 MB/s   1498762641408       375       00:00:29
>   8 GB      3:24:22   122.2 MB/s   1499224932352       188       00:00:57
>  16 GB      3:11:09   130.7 MB/s   1499456405504        94       00:01:54
>  32 GB      3:04:35   135.4 MB/s   1499690303488        47       00:03:49
>  64 GB      3:01:17   137.8 MB/s   1499574960128        24       00:07:37
> 128 GB      2:59:37   139.1 MB/s   1499603664896        12       00:15:14
> 
> And it seems that the results are perfectly reproducible. Three successive
> tests with 16 GB file size have had exactly the same fill time 3:11:09!
> Tests were done by mistake, when I wondered how it is possible that the
> time stays exactly the same :o)
> 
> Regards.



The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users


ADSM.ORG Privacy and Data Security by https://kimlaw.us