Tape troubles. Trage tape geen idee waarom

[bucovaina89]

Hoi,

Ik zit met een ever lasting probleem. Ik heb verschillende HPe LTO interne tape drives gaande van LTO-3 tot LTO-5. Alle drives behalve de LTO-5's zijn half height en intern. De LTO-5's zijn full height en ook intern. Allemaal op SAS aangesloten in een ML350p Gen8 die voor de rest niets te doen heeft (TrueNAS Core 12 backup/archiving server thuis).

Ik heb behalve met de LTO-3 drives altijd last van shoe shinen. Maar echt altijd en ik snap echt niet waarom. De throughput van het netwerk is 1Gbit wat niet recommended is voor LTO 4-5 maar shoe shinen zou die niet mogen doen. De snelheid is ~20MB/s . Als ik dan een grote file naar de lokale SAS array kopieer en dan naar tape schrijf gaat het ook miserabel traag. Kopieer ik die naar de RAM disk net hetzelfde. Van alle bronnen kan ik veel sneller data halen dan 20MB/s.

Deze ochtend "breekt m'n klomp" helemaal. Ik doe een tar -uvvf /dev/st0 /somedir/ Als ik de throughput zie, gebeurt er eignelijk op het netwerk nagenoeg niets maar toch is de tape aan het shoe-shinen terwijl hij door het eerste gedeelte van de tape loopt (zien of hij iets moet updateten of niet).

Alleen LTO-3 shoe shinet zelden. Ik vermoed omdat de laagst mogelijke snelheid bij LTO-3 lager gaat liggen dan LTO-4/5. LTO-3 gaat ook trager dan je zou verwachten van een LTO tape drive.

Ik had lang gedacht dat het aan de desktop waar vroeger mijn tapes in zaten (Dell T7500) mogelijk omdat het geen HP is of niet 100% de juiste bus heeft of zo, maar nu met een ML350p lukt het ook niet.

Wie heeft nog een idee?

EDIT:
Cleaning cartridge heb ik al meerdere keren gedaan, ik heb net ook de tape drive uit elkaar gehaald en met een penseel de tape head gecleaned. Die zat effectief stampvol met stof. Maar na de "thourough cleaning" nog altijd hetzelfde probleem.

EDIT2:
Ook met een tar -tvf heeft de drive het probleem. Het heeft dus puur met lezen/schrijven te maken als je't mij vraagt, niet met de bron/doel van de data bij lezen/schrijven.

[ Voor 9% gewijzigd door bucovaina89 op 01-12-2020 11:57 ]

[Q]

Heeft dit ooit goed gewerkt?

Heb je ooit snelheden naar/van tape gehad boven de 20 MB/s?

Heb je wel eens een SAS schijf of SATA schijf op de SAS HBA aangesloten en de performance getest?

[bucovaina89]

Ik denk dat ik het uiteindelijk gevonden heb na zo zo lang mij druk te liggen maken over die shoe-shinende tape (je vindt nog wel topics van mij daarover vrees ik )

code:

mt-st -f /dev/st0 setblk 262144 # setblk is in bytes, 254kb block size is 262144 bytes
tar -b 262144 -cvvf /dev/st0 ./ > /mnt/ruimteschip/Documents/tape-archive/ecw006l4.txt

Ik denk dat ik vroeger wel eens mt-st -f /dev/st0 setblk 256 heb geprobeerd. Dat zal misschien iets geholpen hebben maar niet genoeg.

Ik ga hier nog wat verder testen maar de drive gaat in ieder geval als de brandweer nu, net zoals je van een LTO drive zou verwachten: data schrokken

EDIT:
Ik kan het probleem reproduceren als ik geschreven tapes er terug in steek en dan :
<code>
mt-st -f /dev/st0 setblk 0
tar xvf /dev/st0
</code>
Dan begint hij weer traag te gaan. Het lag dus gewoon aan een niet wenselijke block size.

[ Voor 16% gewijzigd door bucovaina89 op 01-12-2020 17:01 . Reden: foute code tags ]

[bucovaina89]

Goed en als aanvulling lijkt het nu effectief in orde te zijn. Ik gebruik nu mbuffer om de RAM als buffer te gebruiken voor de net iets te trage NFS mount. Die geeft "maar" 50MB/s op de moment. Met mbuffer ertussen kan ik de drive net op 80MB/s houden en heeft hij ook een stabiele snelheid wat minder frustrerend is op de achtergrond

code:

mt-st -f /dev/st0 setblk 131072
tar -b 131072 -c - ../path-to-backup | mbuffer -t -m 5G -P 99 -f -o /dev/st0

to-do:

• standaard de block size juist krijgen als ik een LTO-3/4/5 erin steek
• de snelheid nog hoger krijgen, nu heb ik maar 80MB/s met LTO-4, dat moet theoretisch tot 120MB/s gaan, zeker met mbuffer ertussen moet ik toch in die buurt komen, misschien nog een grotere block size?
• documenteren

edit:

ik krijg nog iets betere resultaten met een 131072byte block size dan 262144bytes (128KB)

[ Voor 7% gewijzigd door bucovaina89 op 02-12-2020 05:59 ]

[bucovaina89]

Goed, ondertussen heb ik nog wat extra tests gedaan met LTO-4 tapes in een LTO-5 FH tape drive. Het resultaat zoals hierboven beschreven kon nog verder aangescherpt worden van 80MB/s zonder mbuffer naar 96MB/s zonder mbuffer te gebruiken. De drive bij 80MB/s wisselde ook heel vaak van snelheid. Nu draait die redelijk constant.

Het onderstaande bash script heb ik gedraaid als "benchmark". De "dataset" die ik backup zijn CR2 RAW bestanden van ~25MB per stuk en ook nog wat thumbnails en zo die de Synology Photos app zelf genereert. De compressie had ik niet aangezet op de drive. De foto's kwamen in de eerste pass vanop het netwerk, maar door caching alle achtereenvolgende keren van het geheugen. Dus geen bottleneck van de bron gezien die veel sneller dan 120MB/s (theoretische maximumsnelheid van LTO-4 uncompressed), data kan aanleveren (vanuit RAM).

code:

#!/bin/bash
for i in 32 64 128 256 512 1024 2048 4094 8192 16384 32768 65536 131072 262144 524288 1048576 2097152; do                                     
        echo "Trying block size $i"
        mt -f /dev/st0 rewind
        mt -f /dev/st0 setblk $i
        time tar -b $i -cf /dev/st0 /mnt/nas/photo/2020/05/22/
done

block size	snelheid MB/s
32
64	82.18
128	88.25
256	93.48
512	95.54
1024	96.34
2048	92.24
4096	89.85
8096	91.51
16384	92.73
32768	89.85
65536	95.02
131072	91.27
262144	81.41

Mijn conclusie hieruit is dat een block size van 1024bytes het beste werkt voor een LTO-4 tape en tar. Met de block size zowel op de drive te specificeren (mt-st -f /dev/st0 setblk 1024) en meteen ook met tar (tar -b 1024 -cvf /dev/st0 /files/to/backup) zodat beide dezelfde block size gebruiken.