Krijg LTO-5 tape niet "verzadigd" met data

[bucovaina89]

Hoi,

Ik ben in mijn thuis workstation aan het proberen om mijn HPe LTO-5 internal SAS tape drive op full speed te laten draaien maar het lukt maar niet. Je moet theoretisch gezien aan 140MB/s kunnen geraken en best case scenario haal ik 80MB/s

Mijn Setup:
Hardware:
ASUS HB1M Plus
LSI-3442 SAS HBA PCIe 8x in mijn PCIe 16x slot.
8GB RAM
i3-4160
HPe LTO-5 HH SAS internal tape drive
SAS kabel heb ik niet gecheckt wat het is maar ik vermoed dat als je hem aansluit en het werkt daar de bottleneck niet kan zitten (correct me if I'm wrong)
2x 3TB WD green

Software
OS: Debian 8 Jessie
tape softare: LTFS en tar (beide traag)

Verdere setup:
Ik wil dus de data op mijn Synology NAS naar LTO-5 tape trekken die in mijn workstation zit. Maar over 1 NIC gaat dat wat traag dus ik rsync alles naar een staging directory wat eigenlijk de 2 lokale WD greens in mijn workstation zijn in BTRFS RAID 0 mode (stripe dus, geen redundancy wel hoge throughput). Als ik een rsync van zo'n 25GB aan bestanden naar /dev/null doe, kom ik aan een doorvoer van ongeveer 280MB/s wat ruim voldoende moet zijn om de tape drive te verzadigen.

Toch blijft de tape drive aan zo'n 60MB/s schrijven en dat lijkt me veel lager dan hij in principe kan. Alleen, waar zit de bottleneck? Ik dacht eerst in de software, maar ik heb mijn OS van nul terug geinstalleerd. Dan dacht ik dat het misschien in LTFS kon zitten, dus gewoon de ouderwetse tar-methode, maar ook daar gaat de tape verre van full speed. De bottleneck zit hem zeker niet in de schijven, tijdens het schrijven naar tape zijn die zo'n 20% belast.

Heeft iemand een idee waar ik verder kan zoeken? Zit ik misschien met een incompatible SAS HBA of SAS kabel? Of iets anders wat ik nog niet vernoemd heb?

Wat heb ik ondertussen geprobeerd
* 3x WD green: ook trage performance
* Samsung 860 EVO SSD: shoe shinen (dus nog tragere performance)
* HPe documentatie: Mijn HBA is compatibel met de drive volgens de documentatie.
* De originele kernel 3.16 geprobeerd ipv 4.18.10 (zelf gecompileerd voor LTFS). Geen verschil.
* Andere cartridge (alle origineel HPe)
* Cleaning tape

[Voor 9% gewijzigd door bucovaina89 op 27-09-2018 14:23]

[Hero of Time]

WD Green schijven zijn geen snelheidsmonsters. Je zal daar dus nooit je 140 MB/s mee kunnen halen als je er maar 2 hebt, zelfs in RAID0.

Dat je rsync zo'n hoge snelheid haalt zegt eigenlijk al iets dat er ergens wordt vals gespeeld. Een enkele WD Green haalt met wat geluk 60 MB/s, met 2 ervan kan je dus nooit 280 MB/s halen.

[bucovaina89]

De WD greens komen hier toch beter uit de test dan 60MB/s. https://www.storagereview...green_2tb_review_wd20ears.

En dan nog klopt het niet dat ik over een netwerk ook maar ~50~60MB/s haal, dat zou toch om en bij of boven de 100MB/s moeten zijn met een (onbelast) gigabit ethernetnetwerk.

[Merethil]

bucovaina89 schreef op donderdag 27 september 2018 @ 11:03:
De WD greens komen hier toch beter uit de test dan 60MB/s. https://www.storagereview...green_2tb_review_wd20ears.

En dan nog klopt het niet dat ik over een netwerk ook maar ~50~60MB/s haal, dat zou toch om en bij of boven de 100MB/s moeten zijn met een (onbelast) gigabit ethernetnetwerk.

Daar gaan ze er wel vanuit dat álles wat gelezen dient te worden ook op een rijtje staat (sequential reads), zodra je naar random reads gaat zie je dat hij al een stuk trager wordt.
Ik begrijp ook niet helemaal waarom je denkt dat alles op 100% zonder overhead dient te draaien, alles (inclusief een, zelfs onbelast, netwerk) heeft overhead en zaken die gewoon niet zo schalen als jij nu verwacht volgens mij.

[bucovaina89]

Klopt, de array is van deze ochtend geformatteerd en er staan een paar grote bestanden op die ik in 1x met rsync erop heb gezet. Ik vermoed niet dat er sprake is van veel defragmentatie.

Ondertussen heb ik de test nog uitgebreid en 3 andere disks ook in een RAID 0 array. Geen merkbaar verschil in performance. Dus ik vermoed nog altijd niet dat de bottleneck in de disks gaat zitten.

- zelfde probleem met 2xWD green
- als met 3x WD green
- zelfde als ik over het netwerk trek wat theoretisch 125MB/s praktisch hou je daar zo'n 100 à 110 aan over, 60MB seconde zou meer dan 50% overhead betekenen. Dat lijkt me haast ondenkbaar
- verschillende performance monitors zeggen me dat de disks maar voor ~20% belast zijn.

[Merethil]

Maar had je niet, in de tijd dat je nu al die dingen hebt geprobeerd, gewoon de data kunnen overzetten? Om hoeveel data gaat het, wat voor files zijn het (en hoeveel), en welk specifiek tape heb je?
Het zou zomaar kunnen dat je SAS-controller borkt, of dat het kabeltje niet helemaal lekker werkt. 60 MB/s is volgens mij niet eens zo slecht, dat je theoretisch 140 zou kunnen halen is ook al zoiets wat gewoon waarschijnlijk niemand gaat lukken.

Ben benieuwd waar het aan ligt, maar ik gok dat het gewoon een samenkomst van factoren is.

[bucovaina89]

4TB aan data wil ik overzetten. Ondertussen heb ik een Samsung 860 EVO SSD erin geknald op een SATA 6G aansluiting en nu valt de drive zelfs stil (shoe shinen). Dat betekent dat hij minder dan 40MB/s seconde binnen krijgt. Dus nog minder doorvoer dan 2x of 3x WD greens in RAID0

[bucovaina89]

Ondertussen wat verder getest. Ik heb de LTO drive in een Dell Precision T7500 gestoken. Dual Xeon X5650 CPU 24 threads 96GB RAM. Ik heb het uiterste scenario geprobeerd om een RAM disk te maken van 48GB. Eerst kopieer ik zo'n 15GB aan data van mijn RAID 0 array aan ~178MB/s naar de RAM disk. Dan van de RAM disk naar de LTO-5 tape en plots gaat het maar aan 45MB/s 🤨.

Nog iemand ervaring met die dingen? Ik begin stilaan de SAS controllers te verdenken. Hoewel de LSI-3442 HBA op de compatibility list van HP staat. Kan ik de kaart ook in het verkeerde PCI-x slot steken?

[Rainmaker]

Ik heb ervaring met tapedrives, maar normaal zie ik die dingen aan fibrechannel switches hangen

Vanuit een RAM disk zou ik in ieder geval Kan het zijn dat je data niet correct gechuncked is? Als jij 1000 files naar tape zet, schrijft de tape ook 1000 EOF descriptors.

Om die reden hebben ze tar uitgevonden (Tape ARchiver).

Probeer dus eens 1 groot bestand te schrijven.

Verder; hoe kopieer je de data naar de tape? Welke blocksize gebruik je?

[heuveltje]

Is die 140MB/s niet met compressie ?
Voor opslag capaciteit geven ze ook altijd 2 waardes aan. en die 2e is alleen te halen als je niks anders wegschrijft dan text files of andere zeer makkelijk te comprimeren data.

[Gomez12]

bucovaina89 schreef op donderdag 27 september 2018 @ 12:34:
Klopt, de array is van deze ochtend geformatteerd en er staan een paar grote bestanden op die ik in 1x met rsync erop heb gezet. Ik vermoed niet dat er sprake is van veel defragmentatie.

Hoeveel bestanden probeer je erop te zetten? 140MB/Sec is uitgaande van 1 bestand. En heb je verder nog opties als verify aanstaan oid.

En beschrijf je backup-software / procedure eens wat nauwkeuriger. Want ltfs / tar zijn ook helemaal fout toe te passen en dan mag je blij zijn dat je alsnog 60MB/s haalt.

[bucovaina89]

Gomez12 schreef op maandag 8 oktober 2018 @ 11:09:
[...]

Hoeveel bestanden probeer je erop te zetten? 140MB/Sec is uitgaande van 1 bestand. En heb je verder nog opties als verify aanstaan oid.

En beschrijf je backup-software / procedure eens wat nauwkeuriger. Want ltfs / tar zijn ook helemaal fout toe te passen en dan mag je blij zijn dat je alsnog 60MB/s haalt.

Ik heb geprobeerd met een directory vol met video-opnames. Ik vermoed dat bestanden vanaf 700MB t.e.m zo'n 10GB onder de grotere bestanden kan worden gerekend. Er zijn hier en daar wel wat kleinere bestandjes (<1MB) maar die zijn eerder schaars.

(los daarvan heb ik ook eens geprobeerd met mijn RAW directory van zo'n halve TeraByte aan RAW photos met hier en daar een sidecar file van een paar 100kb erbij. Een redelijk cleane directory met 80% bestanden van rond de 25MB en 20% 100KB zeg maar)

Verify heb ik niet aan staan (als je softwarematig met tar bedoelt).

Hier heb ik een test gedaan met telkens verschillende block size. de 17GB zijn 3 grote videobestanden die ik naar tape schrijf. Ze komen van mijn "staging directory" (btrfs RAID0) die aan ~178MB/s diezelfde 17GB naar een RAM disk kan schrijven.

code:

user@host:/home/user$ time tar --totals -b 512 -cvf /dev/nst0 /mnt/stage/
...
...
...
Total bytes written: 18162384896 (17GiB, 50MiB/s)
real    5m53.684s
user    0m0.318s
sys 0m14.225s

code:

user@host:/home/user$ time tar --totals -b 1024 -cvf /dev/st0 /mnt/stage/
...
...
...
Total bytes written: 18162384896 (17GiB, 57MiB/s)
real    5m57.396s
user    0m0.167s
sys 0m15.720s

code:

user@host:/home/user$ time tar --totals -b 1024 -cvf /dev/st0 /mnt/stage/
...
...
...
Total bytes written: 18162384896 (17GiB, 48MiB/s)
real    6m57.161s
user    0m0.116s
sys 0m17.017s

Vorige voorbeeld was met tar, dus niet met LTFS. Als ik wel werk met LTFS dan formatteer ik de tape als LTFS, mount ik hem onder /mnt/ltfs, open ik midnight commander en kopieer ik weer diezelfde 17GB aan (3) bestanden naar de geformatteerde tape. Geprobeerd vanaf RAM disk of vanaf mijn staging directory (goed voor 178MB sustained throughput).

Maar dus, telkens is trage performance mijn deel . Ik ben nog nooit boven de 100MB/s uitgekomen terwijl ik er vanuit ga dat je met LTO drives de marketing voor 1x echt wel mag geloven. Die drive "vreet" echt 140MB/s, no problem.

Ik ben wel benieuwd naar wat je bedoelt met "helemaal fout toepassen". Als dat slaat op vergeten dat tape een lineair medium is of dat LTO-5 een minimale sustained streaming speed nodig heeft van ~40MB/s (shoe shinen), of dat je niet 2 "concurrent copy's" moet gaan doen met LTFS, ben ik het helemaal met je eens.

Anders hoor ik het graag wat ik nog over het hoofd zie

edit:
markup errors

[Gomez12]

Sowieso alles naar nst0 toegooien als het je om kleinere testjes gaat, anders wordt de rewind tijd meegeteld.

Ik zou het zo eens als testset proberen (zodat ze altijd teruggespoeld zijn en je over dezelfde tape-stukjes praat) :

code:

mt -f /dev/st1 rewind
time tar --totals -b 512 -cvf /dev/nst0 /mnt/stage/

En ik zou even heel goed kijken wat in jouw versie van tar die -b doet, want ik zie dat voor LTO-5 512Kb blocks geadviseerd zijn, maar ik meen dat jouw notatie leidt tot 512 bytes blocks.

Persoonlijk zou ik het volgende eens uittesten :

code:

mt -f /dev/st1 rewind
time tar --totals -cvf /dev/nst0 /mnt/stage/
mt -f /dev/st1 rewind
time tar --totals -b 2048kb -cvf /dev/nst0 /mnt/stage/

En dan eens kijken wat het verschil is.

[bucovaina89]

Nog geen 50MB/s.

code:

time tar --totals -cvf /dev/nst0 *.mkv
...
...
...
Total bytes written: 18160762880 (17GiB, 41MiB/s)

real    7m8.437s
user    0m7.724s
sys     1m26.248s

code:

time tar --totals -b 2048 -cvf /dev/nst0 *.mkv                                                        
...
...
...
Total bytes written: 18161336320 (17GiB, 48MiB/s)

real    6m8.629s
user    0m0.035s
sys     0m7.221s

[Gomez12]

Is dat met een rewind van te voren? Dus de tape staat ook echt klaar aan het begin van de tape om te recorden en hij zit niet eerst te spoelen etc?

Want als ik het hele topic teruglees dan valt me op dat het steeds trager en trager en trager gaat.
Je begint met 80 MB/s
Dan gaat het naar 60
Dan een beetje heen en weer zweven tussen 40 en 50
Alsof je steeds verder op tape gaat schrijven en steeds meer moet spoelen.

Doe anders eens een check hoeveel erop staat, is dat 17Gb die je de hele tijd zit te schrijven, of is dat een veelvoud van die 17Gb omdat je steeds zit toe te voegen?

[Rainmaker]

Pin je niet teveel vast op die 140 MB/s. Die is voor full-height drives.

HPe LTO-5 HH SAS internal tape drive

Jij hebt een Half Height drive.

Ik kan zo geen echte benchmark vinden, maar het zou kunnen dat je simpelweg aan het maximum van de drive zit. Als ik dit bijvoorbeeld zie, wordt er aangegeven dat het zo'n 30% langzamer is met half height drives. Maar, in hetzelfde topic wordt ook aangegeven dat het met LTO-5 en 6 hetzelfde zou moeten zijn...

HPE quickspecs geven allebei 140MB/s native aan. Als je het inderdaad snel genoeg aanlevert (ramdisk lijkt me goed), zit ik te denken aan:
- Firmware
- Drivers
- Kabels

Voor de 1e lijkt me simpel; check op de HP site, download en install. Laatste is van 24 april. Moeite waard lijkt me. Zelfde natuurlijk voor je SAS kaart.

De 2e; volgens mij heeft HP geen losse driver voor Linux. Maar, er zijn wat tuning dingen die je kan doen met de "st" driver zelf. Probeer ook eens met

code:

mt setblk $[256*1024]

de blocksize naar 256k te zetten.

De 3e is lastiger. Je zou iets van een extern disk cabinet achter de SAS controller moeten hangen. Kijken of je daar wel fatsoenlijke performance haalt.

[_JGC_]

Waar je ook nog naar kunt kijken is de firmware van je SAS controller. Heb je die controller in IR of in IT mode draaien op dit moment? Beste voor tapes is in IT mode. RAID heb je niks aan met tapes.

[bucovaina89]

Gomez12 schreef op maandag 8 oktober 2018 @ 22:12:
Dus de tape staat ook echt klaar aan het begin van de tape om te recorden en hij zit niet eerst te spoelen etc?

Ik had een mt -f /dev/nst0 asf 0 gedaan om hem op de eerste file block klaar te zetten. Vlak na het "rewind" commando kreeg ik meteen terug een prompt zonder dat de drive iets moest doen dus ik vermoed dat het meteen juist was.

Ik heb lig wel elke keer dezelfde data over hetzelfde stukje tape geschreven (steeds rewind gedaan)

[bucovaina89]

Rainmaker schreef op dinsdag 9 oktober 2018 @ 00:34:
Pin je niet teveel vast op die 140 MB/s. Die is voor full-height drives.


[...]

- Firmware
- Drivers
- Kabels

Aha, daar zeg je al wat van die 30%. Ik neem dan maar aan dat als de drive tegen de 100MB/s aanschurkt dat het vet wel van de soep zal zijn. Ooit koop ik me dan wel een FH-FC-drive, daar heb ik nog wel een HBA voor liggen :-)

De firmware van beide de kaart en drive heb ik geen idee maar ik vermoed dat ze vrij oud gaan zijn. Iig wel de moeite van eens achter te gaan. Library & Tape tools heb ik nu niet geïnstalleerd maar lijkt me wel de moeite om te doen.

De kabels heb ik ook al aan gedacht maar wat kan er mis zijn met een SAS-kabel? 't Is een rooie (zegt mijn bewust naïeve ik )

[bucovaina89]

_JGC_ schreef op dinsdag 9 oktober 2018 @ 00:40:
Waar je ook nog naar kunt kijken is de firmware van je SAS controller. Heb je die controller in IR of in IT mode draaien op dit moment? Beste voor tapes is in IT mode. RAID heb je niks aan met tapes.

Dat moet ik ook eens nakijken, nog nooit van IR/IT mode gehoord. Ik zoek het op. Hardware RAID hoeft voor mij idd niet op die controller.

[bucovaina89]

Hmmm, nieuwe observatie. Ik denk dat ik iets te snel een conclusie heb getrokken door niet genoeg data te schrijven. Blijkt dat als er 1 wrap beschreven is en de tape de andere kant op gaat, de snelheid plots wel 140MB/s is (pretty damn close).

Hoe langer ik wacht lijkt het erop dat: als even wrap nummers (richting 1) hoe langer hoe trager gaan, en oneven wrap nummers (richting 2, tegenovergesteld) hoe langer hoe sneller gaan. Ik zeg maar wat:

code:

WRAP #0: 50MB/s (tape verandert hierna van richting)
WRAP #1: 140MB/s IDEM
WRAP #2: 70MB/s IDEM
WRAP #3: 135MB/s IDEM
WRAP #4: 75MB/s IDEM
WRAP #5: 130MB/s IDEM
WRAP #6: 78MB/s IDEM
...

[Alfa Novanta]

heuveltje schreef op maandag 8 oktober 2018 @ 10:49:
Is die 140MB/s niet met compressie ?
Voor opslag capaciteit geven ze ook altijd 2 waardes aan. en die 2e is alleen te halen als je niks anders wegschrijft dan text files of andere zeer makkelijk te comprimeren data.

^ Met hierboven

Maar bel anders eens met de fabrikant voor je er zoveel tijd in steekt

[bucovaina89]

heuveltje schreef op maandag 8 oktober 2018 @ 10:49:
Is die 140MB/s niet met compressie ?
Voor opslag capaciteit geven ze ook altijd 2 waardes aan. en die 2e is alleen te halen als je niks anders wegschrijft dan text files of andere zeer makkelijk te comprimeren data.

Ik denk dat 280MB/s met compressie wordt opgegeven, 140MB/s zonder.

[bucovaina89]

Alfa90_Buttje schreef op dinsdag 9 oktober 2018 @ 20:19:
[...]

Maar bel anders eens met de fabrikant voor je er zoveel tijd in steekt

Heb de drive tweedehnads gekocht en het is voor de hobby dus daar mag al eens wat tijd in steken ;-)

[Alfa Novanta]

dat hoeven hun toch niet te weten? en het is een simpele vraag.

bucovaina89 schreef op dinsdag 9 oktober 2018 @ 19:57:

code:

(tape verandert hierna van richting)

whut .. ?! hoe kom je daar bij?

ik dacht dat die gewoon van begin tot eind beschreven werd, hooguit 2-zijdig.

[Voor 69% gewijzigd door Alfa Novanta op 10-10-2018 09:35]

[bucovaina89]

Alfa90_Buttje schreef op woensdag 10 oktober 2018 @ 09:32:
dat hoeven hun toch niet te weten? en het is een simpele vraag.


[...]

whut .. ?! hoe kom je daar bij?

ik dacht dat die gewoon van begin tot eind beschreven werd, hooguit 2-zijdig.

Euh nu doe je me twijfelen, maar dit heb ik gekopieerd van wikipedia:

LTO Ultrium tape is laid out with four wide data bands sandwiched between five narrow servo bands. The tape head assembly, that reads from and writes to the tape, straddles a single data band and the two adjacent servo bands. The tape head has 8, 16, or 32 data read/write head elements and 2 servo read elements. The set of 8, 16, or 32 tracks are read or written in a single, one-way, end-to-end pass that is called a "wrap". The tape head shifts laterally to access the different wraps within each band and also to access the other bands.

Om de zoveel minuten hoor ik dat de tape stopt met draaien. Ik vermode dat dan de tape 1 zijde heeft bereikt en dan terug draait.

Of ook hier: http://www.manualsdir.com...uantum-lto-2.html?page=42

A wrap is a track group recorded in the physical forward or physical reverse direction.

Edit en hier p32:

Blijkbaar heeft een LTO-5 tape 80 wraps, wat dus zou betekenen dat hij 80 keren (79) moet omkeren om de hele tape te beschrijven.

https://docs.oracle.com/c..._Vol4_E4/LTO5_Vol4_E4.pdf

[Voor 8% gewijzigd door bucovaina89 op 10-10-2018 11:23]

[Alfa Novanta]

Nooit geweten. Vraag me het nut af t.o.v. gewoon vanaf voren beginnen alle tracks simultaan pakken en dan door schrijven. Lijkt mij dat je anders fragmentatie krijgen gaat .. het spoor naar rechts is 6 lang, dan gaat ie 4 terug .. hou je 2 over .. daar kun je wat anders zetten, maar als dat 8 lang is, schrijf je dus eerst die 2 en dan die resterende 6 weer elders ... wat een gedoe .. maar ze zullen er ongetwijfeld over nagedacht hebben

[Gomez12]

bucovaina89 schreef op woensdag 10 oktober 2018 @ 08:59:
[...]


Heb de drive tweedehnads gekocht en het is voor de hobby dus daar mag al eens wat tijd in steken ;-)

Tja, ik ging uit van nieuw spul. Maar als het 2e hands spul is, dan zou ik in eerste instantie HP er eens naar laten kijken, zoals in die link van jou al stond dan leest hij dus echt links en rechts, oftewel als de linker lezer kapot is / kuren heeft dan kan je exact dit krijgen.

Bij een nieuw apparaat zou je dit niet verachten maar bij gewone 2e hands is er niemand die er iets van kan zeggen.

[bucovaina89]

Weet iemand toevallig hoe je als particulier contact kan opnemen met HP voor Enterprise hardware? Ik heb een account aangemaakt maar als ik een support request wil ingeven, vraagt die eerst een support contract id...

edit:

Ik heb een prijsvraag gedaan bij een bedrijf dat gespecialiseerd is in herstellen van tape drives en ze geven zelfs nog een jaar garantie. Ik vermoed dat HP - als ze al geinteresseerd zijn om er naar te kijken - in het bedte geval een omruiling gaat doen ter waarde van ... een nieuwe.

[Voor 41% gewijzigd door bucovaina89 op 02-10-2019 16:52]

[Alfa Novanta]

bucovaina89 schreef op woensdag 2 oktober 2019 @ 16:29:
Weet iemand toevallig hoe je als particulier contact kan opnemen met HP voor Enterprise hardware? Ik heb een account aangemaakt maar als ik een support request wil ingeven, vraagt die eerst een support contract id...

edit:

Ik heb een prijsvraag gedaan bij een bedrijf dat gespecialiseerd is in herstellen van tape drives en ze geven zelfs nog een jaar garantie. Ik vermoed dat HP - als ze al geinteresseerd zijn om er naar te kijken - in het bedte geval een omruiling gaat doen ter waarde van ... een nieuwe.

Doorgaans moet je een serienummer S/N en productnummer P/N opgeven en als ze nog een geldige garantie hebben willen ze je wel helpen. Bedrijfsnaam desnoods erbij verzinnen of van een goede relatie opgeven oid.

https://support.hpe.com/hpsc/wc/public/home

[bucovaina89]

@Alfa90_Buttje
Thanks voor de tip :-) Ga ik proberen als ik de serienummer terug heb.

Ondertussen ook een offerte gekregen van rond de 530€ ... Wel met een halfjaar garantie en volledig nagekeken ... . Ondertussen ben ik nog verder aan het kijken wat het kost om de tape head alleen te laten vervangen of apart een tape head te kopen en het zelf te doen.

Los daarvan gisteren voor 275€ een LTO5 Full Height gekocht op eBay. Dan heb ik toch een goedkopen backup voor mijn backup drive

[bucovaina89]

Ondertussen heb ik de FH LTO-5 drive binnen gekregen en met Library and Tape Tools wat tests gedaan. De drive is volgens LTT goed verklaard. Ik start mijn backup en jawel hoor, geen shoe shinen meer zoals met de andere drive. De rest van de setup is gelijk gebleven, van de NAS over 1GBe naar mijn workstation. De bottleneck is nu de ethernetverbinding.

Mijn volgende stap is de oude drive uit elkaar halen en de tape head proberen te cleanen. Mogelijk krijg ik deze drive terug fit for purpose, dan heb ik er 2 :-).

Iedereen alvast dank om mee te denken!