Tape drives

SGI hardware problems, solutions, tips, hacks, etc.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.

Best tape archiver tool?

tar
9
56%
cpio
1
6%
xfsdump
6
38%
 
Total votes: 16

User avatar
hhoffman
Posts: 77
Joined: Fri Apr 01, 2011 7:45 am
Location: Germany

Re: Tape drives

Unread postby hhoffman » Thu Nov 08, 2012 9:21 am

there where several things I noticed:
i.e. with mt, the setblksz command did not work. Also with tar I got:
tar: /dev/rmt/tps4d3: Cannot write: Invalid argument

... but not with gnu tar. So I mainly used gnu tar.

One funny thing is in the moment, I changed the first line in the scsi file from your

Code: Select all

 { TPUNKNOWN, TPUNKNOWN, 2, 9, "HP", "Ultrium 4", 0, 0, {0},

to

Code: Select all

{ TPLTO, TPLTO, 2, 9, "HP", "Ultrium 4", 0, 0, {0},

and have now

Code: Select all

tezro 1# mt -f /dev/tape status
        Controller: SCSI
        Device: HP: Ultrium 4-SCSI  W54D
        Status: 0x20262
        Drive type: Linear Tape-Open
        Media : READY, writable, at BOT


:D

My HP 1760 unit is connected to the IO9 external port.
Last edited by hhoffman on Thu Nov 08, 2012 11:27 pm, edited 1 time in total.

User avatar
recondas
Moderator
Moderator
Posts: 5441
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: Tape drives

Unread postby recondas » Thu Nov 08, 2012 9:40 am

hhoffman wrote:One funny thing is in the moment, I changed the first line in the scsi file from your

Code: Select all

 { TPUNKNOWN, TPUNKNOWN, 2, 9, "HP", "Ultrium 4", 0, 0, {0},

to

Code: Select all

{ TPLTO, TPLTO, 2, 9, "HP", "Ultrium 4", 0, 0, {0},

and have now

Code: Select all

tezro 1# mt -f /dev/tape status
        Controller: SCSI
        Device: HP: Ultrium 4-SCSI  W54D
        Status: 0x20262
        Drive type: Linear Tape-Open
        Media : READY, writable, at BOT
Interesting! A few questions if I might.

Do you have APD installed, and what IRIX revision are you running?

Could you post the the list of tape device definitions from inside /var/sysgen/master.d/scsi? It will be a fairly short list, probably 20 or 25 entries, and would start like and look similar to this:

Code: Select all

#define TPUNKNOWN       0       /* type not known */
#define CIPHER540       1       /* cipher QIC24 */
#define TANDBERG3660    2       /* TANDBERG 3660 QIC150 */
#define VIPER150        3       /* VIPER 150 QIC150 */
#define KENNEDY96X2     4       /* Kennedy 96[16]2 1/2" 9 track */
#define EXABYTE8200     5       /* Exabyte EXB-8200 8mm cartridge tape */
...............followed by another 15 or 20 #define statements.......


Thanks!
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

User avatar
hhoffman
Posts: 77
Joined: Fri Apr 01, 2011 7:45 am
Location: Germany

Re: Tape drives

Unread postby hhoffman » Thu Nov 08, 2012 9:59 am

Of course, you are perfectly welcome!
I do not have APD installed and I use 6.5.28f.

in my scsi file is actually not much ...

Code: Select all

#define   TS_ENABLE_DLT7000      0
#define   TS_ENABLE_STK9840      0
#define   TS_ENABLE_STK9490      0
#define   TS_ENABLE_STKSD3      0
#define   TS_ENABLE_IBM3590      0

/*
 * DLT8000 is only supported in TS.
 */
#define ts_dennum_dlt8000       4
char   *ts_denhwg_dlt8000[]   = {"98250", "85937", "62500", "81633" };
char   *ts_densuf_dlt8000[] = {".98250", ".85937", ".62500", ".81633" };

#if   TS_ENABLE_DLT7000
#define ts_dennum_dlt7000       2
char   *ts_denhwg_dlt7000[]   = { "7000", "4000" };
char   *ts_densuf_dlt7000[] = { ".7000", ".4000" };
#endif

ts_types_t ts_types[] = {
   /*
    * Always define DLT8000 because it is only supported in TS.
    */
   { TPDLT, "", "DLT8000", 1, 0, 1,
     ts_dennum_dlt8000, ts_denhwg_dlt8000, ts_densuf_dlt8000,
     {0x41, 0x1B, 0x19, 0x1a}},

   { TPSTK9940, "STK", "T9940A", 1, 0, 1, 0, 0, 0, {0} },

#if   TS_ENABLE_DLT7000
   { TPDLT, "", "DLT7000", 1, 0, 1,
     ts_dennum_dlt7000, ts_denhwg_dlt7000, ts_densuf_dlt7000,
     {0x1B, 0x1A, {0}, {0}, {0}, {0}, {0}, {0} } },
#endif

#if   TS_ENABLE_STK9490
   { TPSTK9490, "STK", "9490", 1, 0, 1, 0, 0, 0, {0} },
#endif

#if   TS_ENABLE_STK9840
   { TPSTK9840, "STK", "9840", 1, 0, 1, 0, 0, 0, {0} },
#endif

#if   TS_ENABLE_STKSD3
   { TPSTKSD3, "STK", "SD-3", 1, 0, 1, 0, 0, 0, {0} },
#endif

#if   TS_ENABLE_IBM3590
   { TPNTP, "IBM", "03590B1A", 1, 0, 1, 0, 0, 0, {0} },
   { TPNTPSTACKER, "IBM", "03590B11", 1, 0, 1, 0, 0, 0, {0} },
   { TPNTP, "IBM", "03590E1A", 1, 0, 1, 0, 0, 0, {0} },
   { TPNTPSTACKER, "IBM", "03590E11", 1, 0, 1, 0, 0, 0, {0} },
#endif
};

int       ts_numtypes = sizeof(ts_types)/sizeof(ts_types_t);


/*
 * tpsc_types table
 *
 * When adding a new device of a known type, which will be accessed
 * through tpsc, an entry can be added to tpsc_types without
 * recompiling tpsc, with the assumption that the SCSI commands,
 * capabilities, and request sense info are constant within a type. 
 * This is rarely completely true, but is often close enough to allow
 * a drive to work.  Note that when no additional info (id_ailen field)
 * is returned on the inquiry, the driver sets the vendor id (id_vid) to
 * "CIPHER" and id_pid to "540S" before checking this table.
 *
 * See also sys/mtio.h for definitions of the MTCAN_* bits.
 *
 * Note that this does not quite allow arbitrary drives to be
 * connected, since interpretation of the request sense results,
 * and the modeselect that is done is based on the tp_type field.
 * That field must be set to match one of the known types, or a
 * drive must not appear in this table at all, in which case it is
 * treated as an unknown type, and the tpsc_generic structure (below)
 * is used.  However, if a drive is of an unknown type, but the inquiry
 * command indicates SCSI 2 compliance, the error codes and additional
 * sense info are decoded according to SCSI 2.
 *
 * Also note that a similar list is built into the PROMs and standalone
 * drivers, so changes to this are only effective for use under unix.
 * Furthermore, miniroot kernels will not have any local changes made
 * to this file, which may be important to people attempting system
 * recover with "unknown" tape drives.  If such drives are your only
 * tape device, it is best to make a backup using the fixed block
 * device with 512 byte blocks, of at least enough files to allow you
 * to boot a customized kernel.
 *
 * This structure is defined in sys/tpsc.h - read the comments there for
 * the meanings of fields, and their units, where applicable (search for
 * the tpsc_types structure definition).
 *
*/   
#define tpsc_exa8500_dens_count    2
#define tpsc_exa8500c_dens_count    4
#define tpsc_exa8505_dens_count    4
char   *tpsc_exabyte_hwg_dens_names[]   = { "8500",  "8200",  "8500_compress", "8200_compress" };
char   *tpsc_exabyte_alias_dens_names[] = { ".8500", ".8200", ".8500c",        ".8200c"        };

#define tpsc_kennedy_dens_count    4
char   *tpsc_kennedy_hwg_dens_names[]   = { "6250bpi", "3200bpi", "1600bpi", "800bpi" };
char   *tpsc_kennedy_alias_dens_names[] = { ".6250",   ".3200",   ".1600",   ".800"   };

#define tpsc_dlt7000_dens_count    4
char   *tpsc_dlt7000_hwg_dens_names[]   = { "7000",  "7000_compress", "4000",  "4000_compress" };
char   *tpsc_dlt7000_alias_dens_names[] = { ".7000", ".7000c",        ".4000", ".4000c"        };

#define tpsc_default_dens_count    2
char   *tpsc_default_hwg_dens_names[]   = { "uncompress", "compress" };
char   *tpsc_default_alias_dens_names[] = { "",           "c"        };


mia, I'm still trying to find out, how you have tested the data rate of your HP LTO unit.

User avatar
mia
Posts: 1055
Joined: Wed Feb 19, 2003 1:54 pm

Re: Tape drives

Unread postby mia » Thu Nov 08, 2012 11:40 am

I've experimented several tar blocking factors, I've repeated the same exact tests on the same 45GB directory, tarring to an uncompressed tape drive (HP 1760 scsi), the results are as such:

blocking factor: 1
time to tar: 5h53m02s
throughput: 2.1MB/s

blocking factor: 2
time to tar: 3h03m54s
throughput: 4MB/s

blocking factor: 4
time to tar: 1h33m33s
throughput: 8MB/s

blocking factor: 8
time to tar: 50m07s
throughput: 14.9MB/s

blocking factor: 16
time to tar: 29m44s
throughput: 25.2MB/s

blocking factor: 32
time to tar: 18m57s
throughput: 39.5MB/s

blocking factor: 64
time to tar: 16m25s
throughput: 45.6MB/s

blocking factor: 128
time to tar: 18m42s
throughput: 40.1MB/s

blocking factor: 256
time to tar: 15m58s
throughput: 46.9MB/s

blocking factor: 512
time to tar: 15m58s
throughput: 46.9MB/s

blocking factor: 1024
time to tar: 15m31s
throughput: 48.3MB/s <--- sweet spot?

blocking factor: 2048
time to tar: 16m36s
throughput: 45.1MB/s

blocking factor: 4096
time to tar: 15m51s
throughput: 47.3MB/s

blocking factor: 8192
time to tar: 16m43s
throughput: 44.8MB/s

I do however believe that the higher the blocking factor is, the more space is wasted after each and every file, meaning if you use a blocking factor of 1024, and tar a file of 10 bytes, the resulting "tape length" used would be 1024*512=524288 bytes. Please don't hesitate to correct me on this, I'm speculating.
:Onyx2:

User avatar
recondas
Moderator
Moderator
Posts: 5441
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: Tape drives

Unread postby recondas » Thu Nov 08, 2012 12:11 pm

mia wrote:I do however believe that the higher the blocking factor is, the more space is wasted after each and every file, meaning if you use a blocking factor of 1024, and tar a file of 10 bytes, the resulting "tape length" used would be 1024*512=524288 bytes. Please don't hesitate to correct me on this, I'm speculating.

Are you using the same command mentioned earlier to call the tape device?
mia wrote:I've repeated the tests, this time with a different tar blocking factor, as such:
timex tar cvb 4096 -f /dev/rmt/tps4d3 /path/to/files
Tezro: 15m53s (47MB/s)
"Very fast" Intel*: 19m04s (39MB/s)
*If* it's compatible with your explicit 4096 tar block size, and *if* the additional devices exist, calling tps4d3v would specify a tape device with a variable block size, and tps4d3vc would be the tape device with a variable block size and compression enabled.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

User avatar
mia
Posts: 1055
Joined: Wed Feb 19, 2003 1:54 pm

Re: Tape drives

Unread postby mia » Thu Nov 08, 2012 1:17 pm

Thank you Recondas,

Those are my available devices:

Code: Select all

tps4d3    tps4d3nrc    tps4d3nrnsv   tps4d3nrsc   tps4d3nrv   tps4d3nsc   tps4d3s     tps4d3sv   tps4d3vc
tps4d3c   tps4d3nrns   tps4d3nrnsvc  tps4d3nrsv   tps4d3nrvc  tps4d3nsv   tps4d3sc    tps4d3svc  tsdaem
tps4d3nr  tps4d3nrnsc  tps4d3nrs     tps4d3nrsvc  tps4d3ns    tps4d3nsvc  tps4d3stat  tps4d3v    tsreq


Yes, I am using the same command, I will start experimenting with the variable sized blocks, although I believe those are different from the tar blocking factor, those would ultimately be the tape "blocks" (LTO being "packets" on a block device), as opposed to the tar "blocks". Please let me know if I am mistaken.

Experimenting with the block size was less fruitful than expected, as such:

Tar blocking factor: 1024
Tape block size: 512
Time to tar: 15m28s
Throughput: 48.5MB/s

Tar blocking factor: 1024
Tape block size: 262144
Time to tar: 15m16s
Throughput: 49.1MB/s

Tar blocking factor: 1024
Tape block size: 524288
Time to tar: 15m19s
Throughput: 49MB/s

Tar blocking factor: 1024
Tape block size: variable
Time to tar: 15m11s
Throughput: 49.3MB/s

Tar blocking factor: 1024
Tape block size: variable, with compression
Time to tar: 15m11s
Throughput: 49.3MB/s

No big win there, worth a try.

Hhoffman: I estimate the throughput by dividing the archive size by the number of seconds reported by "timex". I always use the same "source" to tarball, and this directory is mostly composed of large files, for a total amount of 45GB, or, more precisely, 46936088 bytes; without counting the metadata of course.
:Onyx2:

User avatar
mia
Posts: 1055
Joined: Wed Feb 19, 2003 1:54 pm

Re: Tape drives

Unread postby mia » Thu Nov 08, 2012 10:01 pm

For the sake of it, I've tested the same procedure with another scsi card, a LSI21320-R (I've lsflash'd it to 1.3.39.16). Results are as follows, always the same repeatable process:

Tar blocking factor: 1024
Tape block size: 262144
Time to tar: 15m41s
Throughput: 47.8MB/s

Tomorrow I will experiment with different /var/sysgen/master.d/scsi parameters and APD.
:Onyx2:

User avatar
hhoffman
Posts: 77
Joined: Fri Apr 01, 2011 7:45 am
Location: Germany

Re: Tape drives

Unread postby hhoffman » Fri Nov 09, 2012 1:26 am

Meanwhile I did a test with a HP DL180 server (8x 2ghz, 8gb ram), the HP LTO 1760 connected to a adaptec AIC-7892A U160 controller. The test was done with hp ltt software under RHEL5 64bit. My 1760 unit was updated to firmware W62D before the test.

Code: Select all

- Device Performance Test Started on Drive (Ultrium 4-SCSI) (40.5.0[4-/dev/sg0])
  - Opening Tape Drive 40.5.0[4-/dev/sg0]
  - Successfully opened the Tape Drive /dev/nst0
  - Spinning Up
  - 2.1 GB written in 26.5 seconds at 81.2 MB/s (Min 80.6 MB/s, Max 81.3 MB/s)


And here from my tezro:

Code: Select all

tezro 1# mt -f /dev/tape status
        Controller: SCSI
        Device: HP: Ultrium 4-SCSI  W62D
        Status: 0x20262
        Drive type: Linear Tape-Open
        Media : READY, writable, at BOT

and ..

Code: Select all

tezro 2# mt -f /dev/tape blksize

 Recommended tape I/O size: 262144 bytes (512 512-byte blocks)
 Minimum block size: 1 byte(s)
 Maximum block size: 16777215 bytes
 Current block size: 512 byte(s)


Now mia's testfile

Code: Select all

tezro 3# mkfile -nv 46936088 testfile.deleteme
testfile.deleteme 46936088 bytes


and the test

Code: Select all

tezro 4# timex tar cvb 4096 /dev/rmt/tps1d5 testfile.deleteme
a /dev/rmt/tps1d5 char special (0/620)
a testfile.deleteme 91673 blocks

real        7.20
user        0.01
sys         0.19


Code: Select all

tezro 5# tar -tvf /dev/tape
rw-rw-rw-   0/0  c:0/620       Nov  9 12:16 2012 /dev/rmt/tps1d5
rw-------   0/0       46936088 Nov  9 12:11 2012 testfile.deleteme


hm, it seems that the 1760 did it in 7.20.
7.20 secs or minutes?

:D

Where you do read the datarate and how you did get your time printouts?

User avatar
mia
Posts: 1055
Joined: Wed Feb 19, 2003 1:54 pm

Re: Tape drives

Unread postby mia » Fri Nov 09, 2012 7:38 am

Sorry, my files are 46936088 kb, not 46936088 bytes; sorry for the typo.
Be careful with mktemp, it creates zero-filled files, meaning, highly compressable; but those are okay for non-compress tests.

Thank you for setting this new record, now I have a target.
:Onyx2:

User avatar
hhoffman
Posts: 77
Joined: Fri Apr 01, 2011 7:45 am
Location: Germany

Re: Tape drives

Unread postby hhoffman » Fri Nov 09, 2012 8:54 am

You are perfectly welcome! Could you tell us a little bit about the APD software? There is not much to find on techpubs etc. about it ...

Sorry, my files are 46936088 kb, not 46936088 bytes; sorry for the typo.

that is explaining something in my test.
;)

alright let's do it again ...

Code: Select all

tezro 1# mkfile -v 46936088000 testfile.deleteme
testfile.deleteme 46936088000 bytes
tezro 2# ls -l
-rw-------    1 root     sys       46936088000 Nov  9 18:21 testfile.deleteme
tezro 3# mt -f /dev/tape setblksz 4096
tezro 4# mt -f /dev/tape blksize
 Recommended tape I/O size: 262144 bytes (512 512-byte blocks)
 Minimum block size: 1 byte(s)
 Maximum block size: 16777215 bytes
 Current block size: 4096 byte(s)
tezro 5# mt -f /dev/tape status
        Controller: SCSI
        Device: HP: Ultrium 4-SCSI  W62D
        Status: 0x20262
        Drive type: Linear Tape-Open
        Media : READY, writable, at BOT
tezro 6# timex tar cvK /dev/rmt/tps1d5 testfile.deleteme
a /dev/rmt/tps1d5 char special (0/620)
Warning: Inclusion of file -> testfile.deleteme will create a non-portable archive
a testfile.deleteme 91672047 blocks

real    11:42.06
user        0.59
sys      3:23.12

I am not much into tar, but does someone know what it means, a 'non-portable archive'?

User avatar
mia
Posts: 1055
Joined: Wed Feb 19, 2003 1:54 pm

Re: Tape drives

Unread postby mia » Fri Nov 09, 2012 9:37 am

hhoffman wrote:I am not much into tar, but does someone know what it means, a 'non-portable archive'?


If those results are correct, they are very impressive.

A non-portable archive probably means that tar uses a different structure to store files larger than 2GB, which would exceed the size of unsigned interger on 32 bits platforms.
:Onyx2:

User avatar
mia
Posts: 1055
Joined: Wed Feb 19, 2003 1:54 pm

Re: Tape drives

Unread postby mia » Fri Nov 09, 2012 9:41 am

hhoffman wrote:tezro 6# timex tar cvK /dev/rmt/tps1d5 testfile.deleteme


This doesn't look right, it should probably be:

timex /usr/bin/tar cvKbf 4096 dev/rmt/tps1d5 testfile.deleteme
:Onyx2:

User avatar
mia
Posts: 1055
Joined: Wed Feb 19, 2003 1:54 pm

Re: Tape drives

Unread postby mia » Sat Nov 10, 2012 9:27 am

I'm afraid I might have found my bottleneck, as such, this is my diskperf:

Code: Select all

root@plum:~# diskperf -W -D -r 4k -m 4m testfile
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : Unspecified
# Test date     : Sat Nov 10 09:15:21 2012
# Test machine  : IRIX64 plum 6.5 07202013 IP35
# Test type     : XFS data subvolume
# Test path     : testfile
# Request sizes : min=4096 max=4194304
# Parameters    : direct=1 time=10 scale=1.000 delay=0.000
# XFS file size : 3221225472 bytes
#---------------------------------------------------------
# req_size  fwd_wt  fwd_rd  bwd_wt  bwd_rd  rnd_wt  rnd_rd
#  (bytes)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)
#---------------------------------------------------------
       4096   14.98   15.44    3.64    1.24    1.12    0.55
       8192   25.73   27.57    7.57    2.34    2.29    1.10
      16384   38.88   47.41   12.73    4.22    4.41    2.14
      32768   47.96   48.15   19.63    9.26    7.92    4.18
      65536   48.35   48.16   27.77   12.86   13.70    8.00
     131072   48.31   47.91   36.07   20.11   22.00   13.37
     262144   48.28   48.31   39.86   28.43   30.54   21.21
     524288   47.80   36.04   41.78   36.19   34.86   30.85
    1048576   48.29   39.20   47.19   40.89   37.82   37.67
    2097152   48.30   41.66   47.88   43.71   45.16   43.28
    4194304   48.43   45.10   48.12   48.42   49.25   49.37


If the disk can't forward read faster than 48MB/s, I'd be surprised if we could write to the tape faster, I'll attach a fiber channel array to the Tezro and repeat the tests.
:Onyx2:

User avatar
mia
Posts: 1055
Joined: Wed Feb 19, 2003 1:54 pm

Re: Tape drives

Unread postby mia » Sat Nov 10, 2012 2:58 pm

I've repeated a small portion of the tests as such, using a OCZ Virtex SSD (next I'll try from a FC array):

Tar blocking factor: 16
Tape block size: variable
Time to tar: 29m13s
Throughput: 26.77MB/s

Tar blocking factor: 32
Tape block size: variable
Time to tar: 18m30s
Throughput: 42.28MB/s

Tar blocking factor: 64
Tape block size: variable
Time to tar: 15m31s
Throughput: 50.41MB/s

Tar blocking factor: 128
Tape block size: variable
Time to tar: 18m01s
Throughput: 43.41MB/s

Tar blocking factor: 256
Tape block size: variable
Time to tar: 14m33s
Throughput: 53.76MB/s

Tar blocking factor: 512
Tape block size: variable
Time to tar: 14m32s
Throughput: 53.82MB/s

Tar blocking factor: 1024
Tape block size: variable
Time to tar: 14m33s
Throughput: 53.76MB/s

Tar blocking factor: 2048
Tape block size: variable
Time to tar: 14m32s
Throughput: 53.82MB/s

Tar blocking factor: 4096
Tape block size: variable
Time to tar: 14m33s
Throughput: 53.76MB/s

Tar blocking factor: 8192
Tape block size: variable
Time to tar: 14m34s
Throughput: 53.70MB/s

Scsi entry used:

Code: Select all

         /* HP LTO4 / Ultrium 4 */
         { TPLTO, TPLTO, 2, 14, "HP", "Ultrium 4-SCSI", 0, 0,
           { 0 },               /* values for 4 possible densities; used
                                   only when MTCAN_SETDEN is true; indexed by DENSITY_DEV() */
             MTCAN_BSF|MTCAN_BSR|MTCAN_APPEND|MTCAN_SETMK|MTCAN_PART|MTCAN_PREV|
             MTCAN_SYNC|MTCAN_SPEOD|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|
             MTCAN_SILI|MTCAN_AUDIO|MTCAN_SEEK|MTCAN_CHTYPEANY|MTCAN_COMPRESS,
           40,                  /* transfer timeout; see XFER_TIMEO
                                   (units are inverse ticks) */
           5*60,                /* minimum timeout for any cmd; see XFER_TIMEO and
                                   SHORT_TIMEO (units are seconds) */
           20*60,               /* space cmd timeout; (units are in seconds), see
                                   SPACE_TIMEO() */
           20*60,               /* timeout for very long operations, like rewind,
                                   retension, erase; (units are in seconds); time is
                                   doubled for retension. */
           3*3600,              /* maximum possible timeout for those commands
                                   potentially taking a very Very VERY long time,
                                   e.g. ERASE, SETPOS, etc. */
           1024,                /* default (and often only) block size in fixed block
                                   mode */
           512*512,             /* recommended blocking factor, used only for
                                   MTIOCGETBLKINFO ioctl; note that it is given in
                                   bytes, not as a multipier for the blocksize. */
           tpsc_default_dens_count,
           tpsc_default_hwg_dens_names,
           tpsc_default_alias_dens_names,
           {0}, 0, 0, 0,
           0, (u_char *)0 },
:Onyx2:

User avatar
mia
Posts: 1055
Joined: Wed Feb 19, 2003 1:54 pm

Re: Tape drives

Unread postby mia » Sat Nov 10, 2012 4:31 pm

Here's a quick test with xfsdump from the ssd, with relatively optimal parameters:

Dump size: 48062600640 bytes, 48171581440 bytes with metadata.
media block size: 2097152 bytes
Tape block size: 4194304 bytes
Time to xfsdump to tape: 14m42s
Throughput: 54.61MB/s

Dump size: 48062600640 bytes, 48171581440 bytes with metadata.
media block size: 2097152 bytes
Tape block size: variable
Time to xfsdump to tape: 14m39s
Throughput: 54.80MB/s
:Onyx2:


Return to “SGI: Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests