[dds4] drive werkt niet goed

[PrinsEdje80]

Probleem is als volgt:

Het schrijven van tapes is waardeloos, op 2 punten:
1) tar geeft foutmelding:

code:

tar: /dev/st0: Wrote only 0 of 10240 bytes
tar: Error is not recoverable: exiting now

zomaar midden in een backup-sessie
2) snelheid is erg traag; de tape wordt een stukje geschreven, dan weer stukje teruggespoeld, vooruitgespoeld en weer verder geschreven

Vraagjes:
1) Hebben meer van jullie dit probleem (gehad)?
2) Wat zou een oplossing kunnen zijn? Switches, firmware, kernel, etc...

Over de switches: deze staan als het juist is goed!!
Over de kernel: is dit een juiste versie hiervoor?
Is firmware idd erg belangrijk?
Andere zaken ook welkom!

systeem:
RedHat 7.2 kernel 2.4.9-13
scsitapedrive: dds4 sony sdt-11000

[cjdijk]

Er kunnen twee zaken aan de hand zijn.

1. De koppen zijn vuil geworden,
gebruik hiervoor een cleaning tape.

2. De koppen kunnen versleten zijn.
Bij elke dag een backup draaien,
kan hij na een half jaar al op zijn.
Dit weet ik uit ervaring,
hangt ook af van de hoeveelheid data
die gebackupd wordt per keer.

Die firmware en jumpers zijn alleen relevant
als de drive ergens anders in heeft gezeten.
Kortom als er veranderingen zijn geweesd.

[PrinsEdje80]

Op donderdag 28 maart 2002 13:06 schreef cjdijk het volgende:
Er kunnen twee zaken aan de hand zijn.
1. De koppen zijn vuil geworden,
gebruik hiervoor een cleaning tape.

Zijn ze niet. Drive is redelijk nieuw.

2. De koppen kunnen versleten zijn.
Bij elke dag een backup draaien,
kan hij na een half jaar al op zijn.
Dit weet ik uit ervaring,
hangt ook af van de hoeveelheid data
die gebackupd wordt per keer.

Zie reactie bij 1.

Die firmware en jumpers zijn alleen relevant
als de drive ergens anders in heeft gezeten.
Kortom als er veranderingen zijn geweesd.

Heeft ie op zich wel. In een solaris, maar daar waren ook al problemen

[cjdijk]

Gebruik je trouwens wel de correcte tapes,
die de juiste capaciteit/dichtheid hebben?
Anders de drive omruilen (garantie?)

[PrinsEdje80]

Op vrijdag 29 maart 2002 12:12 schreef cjdijk het volgende:
Gebruik je trouwens wel de correcte tapes,
die de juiste capaciteit/dichtheid hebben?

Zeker weten van wel!!!!

Anders de drive omruilen (garantie?)

Is een optie, maar lijkt me niet logisch. Het probleem doet zich ook bij een 2e drive (ook dds4) voor.

Het gebruik van dds3 in de dds4 is ook waardeloos!!

[wizzzzzz]

terminatie - scsi

[DeBolle]

Wat voor aanlsuiting heeft die drive? Het kan zijn dat je namelijk te weinig data naar de drive zit te sturen, waardoor 'ie niet gaat streamen maar schoenpoetsen.
Een DDS-4 met hardware compressie enabled kan naar mijn ervaringen ongeveer 700MB/minuut verwerken en wil dus graag veel en snel data. Jouw scsi bus moet dus in staat zijn die hoeveelheid continue te leveren. Zit 'ie op dezelfde bus als de HD's?

Overigens is tar echt niet een optimaal programma voor moderne tapedrives - de blocksize gaat uit van QIC tape, niet van DAT.
Probeer eens met dd, bijvoorbeeld:
tar cf - /whatever | dd of=/dev/st0 bs=16k
of
cpio -ocC 16k
of
schakel de hardware compressie uit en doe iets als:
find . -print | cpio -o | compress | dd
enz. enz.

Je zegt dat 'ie uit een Sun komt, wat voor resultaten gaf ufsdump? En zat de drive daar ook op een vlotte bus?

[Zwelgje]

de drive kan dan wel redelijk nieuw zijn, maar elke 20 uur gebruik moet je hem schoonmaken met een cleaning tape (zie ook de handleiding van je apparaat)

kheb zelf ook zon ding, er staat expliciet bij dat je om de 20 uur gebruik het ding moet schoonmaken (op het werk heb ik een dds2 drive in gebruik die moet je elke 8GB schoonmaken....)

[PrinsEdje80]

Op vrijdag 29 maart 2002 18:45 schreef DeBolle het volgende:
Wat voor aanlsuiting heeft die drive? Het kan zijn dat je namelijk te weinig data naar de drive zit te sturen, waardoor 'ie niet gaat streamen maar schoenpoetsen.
Een DDS-4 met hardware compressie enabled kan naar mijn ervaringen ongeveer 700MB/minuut verwerken en wil dus graag veel en snel data. Jouw scsi bus moet dus in staat zijn die hoeveelheid continue te leveren. Zit 'ie op dezelfde bus als de HD's?

De data die ik er naar toe stuur is ongeveer 13 a 14 GB, dus daar heeft het weinig mee van doen. Het zijn ook geen kleine bestanden, zo'n 32 a 33 MB per stuk.

Overigens is tar echt niet een optimaal programma voor moderne tapedrives - de blocksize gaat uit van QIC tape, niet van DAT.
Probeer eens met dd, bijvoorbeeld:
tar cf - /whatever | dd of=/dev/st0 bs=16k
of
cpio -ocC 16k
of
schakel de hardware compressie uit en doe iets als:
find . -print | cpio -o | compress | dd
enz. enz.

Zal ik eens proberen!
Ik lees net de man-page van cpio: moet dat een commandline worden zoals:

code:

cpio -ocC 16k < filelist > /dev/st0

En hoe haal ik het af als ik het er hiermee opgezet heb?

Dezelfde vraag geldt voor:

code:

tar cvf - /whatever | dd of=/dev/st0 bs=16k

Is dat dan gewoon:

code:

tar xvf - /whatever | dd of=/dev/st0 bs=16k

<--- Dit is volgens mij nonsens


Heeft het commando mt hier ook nog enige invloed? Zoals bijv. het instellen van de blocksize e.d.?

Je zegt dat 'ie uit een Sun komt, wat voor resultaten gaf ufsdump? En zat de drive daar ook op een vlotte bus?

Ik zal het eens vragen aan ons systeembeheer.

Dit vraag ik namens dat systeembeheer, omdat zij er niet al te veel van weten/radeloos zijn en ik er mee moet werken binnen zeer korte tijd.
Kan in dit (paas)weekeinde dus niet even testen, maar wel ideeen opdoen! Ik zal het a.s. dinsdag meteen testen.

[DeBolle]

De data die ik er naar toe stuur is ongeveer 13 a 14 GB, dus daar heeft het weinig mee van doen. Het zijn ook geen kleine bestanden, zo'n 32 a 33 MB per stuk.

Ik bedoel niet de absolute hoeveelheid maar de hoeveelheid/per seconde - zoals gezegd, een DDS-4 kan met hardware compressie enabled een SCSI bus helemaal leegtrekken. Als jouw host en SCSI bus niet voldoende snelheid kunnen leveren gaat de drive stoppen, wachten op data, starten, stoppen, terugspoelen, wachten op data .. enz. Ga uit van minimaal 15MB/sec.

code:

cpio -ocC 16k < filelist > /dev/st0

En hoe haal ik het af als ik het er hiermee opgezet heb?

Dat klopt, je kunt experimenteren met die blockzise tussen 4K en 64K. DDS/DAT drives hebben een default blocksize van 16K, DLT heeft 64K. Met cpio van een tape halen: cpio -ic en alleen de filenamen: cpio -itv

tar xvf - /whatever | dd of=/dev/st0 bs=16k

Bijna goed Je moet alles weer terughalen in omgekeerde volgorde als je piped, dus:
dd if=/dev/st0 bs=16k | tar xv

Heeft het commando mt hier ook nog enige invloed? Zoals bijv. het instellen van de blocksize e.d.?

Nee, mt is voor het manipuleren van de tape, zoals spoelen, rewind, on en offline zetten.
Handig om verschillende backups op 1 tape te zetten door de no-rewind device te gebruiken:

code:

mt -f /dev/st0n rew             #tape BOT
find /usr -print | cpio -oc > /dev/st0n  #backup 1
find /var -print | cpio -oc > /dev/st0n  #backup 2
find /home -print | cpio -oc > /dev/st0n #backup 3
mt -f /dev/st0n rew             #tape BOT
mt -f /dev/st0n offl               # *SPIT*

Nu heb je achter elkaar drie backups op die tape. Om nu bijvoorbeeld alleen /home te restoren moet je dan op het no-rewind device twee partities skippen:

code:

mt -f /dev/st0n rew         #tape BOT
mt -f /dev/st0n fsf 2           #2 skippen
cpio -ic < /dev/st0n             #restore
mt -f /dev/st0n rew         #tape BOT

Dan nog in het algemeen voor wat betreft moderne tapedrives, wat ook zal gelden voor de Sun waar die drive aan hangt. DDS-4, DLT7000 en 8000, SDLT en LTO kunnen vergeleken met hun voorgangers erg veel data per seconde verstouwen. Om de tape in 'streaming mode' te houden, moet dus de SCSI bus in staat zijn die hoeveelheid te leveren. Dat betekent dat de host en de harde schijven dat ook moeten kunnen! Zoals gezegd, reken op minimaal 15MB/sec continue.
De drives zijn veelal LVD en moeten bij voorkeur op hun eigen dedicated controller zitten, met de juiste kabel en terminator. Juist bij deze devices is het belangrijk dit goed te doen - LVD heeft bijvoorbeeld een max. kabellengte van 12 meter maar alleen zoalnf de hele chain LVD is.
Zodra een LVD device op een SE bus wordt aangesloten, of als er SE device op dezelfde bus zit, valt alles terug op de beperkingen die voor SE SCSI gelden.
Schrijnend voorbeeld - een tapedrive op een U2W LVD controller, maar geen LVD terminator in huis. Dus een SE terminator gebruikt: resultaat is dat alles terugvalt naar SE -> snelheid is nu UW en max. kabellengte is 1,5 meter.
Hetzelfde gebeurt natuurlijk met een LVD device op een SE controller.

Ehm ...

Ik lul te veel, eh?

[PROnline]

Op zondag 31 maart 2002 14:53 schreef DeBolle het volgende:

[..]
Ik lul te veel, eh?

Je lult wel veel, maar ik vind het allemaal wel interesant om te weten.

[PrinsEdje80]

Op zondag 31 maart 2002 14:53 schreef DeBolle het volgende:
Een heel interessant verhaal dat morgen getest gaat worden
Ehm ...

Ik lul te veel, eh?

Niet dus... Iig bedankt. Ga zsm testen!! thnx!

[PrinsEdje80]

Op dit moment kan ik het mannetje wat over de hardware hier gaat niet vinden, maar hij blijft met

code:

cpio -ocvC 65536 < tape1 > /dev/st0

waarbij tape1 een file met bestandsnamen is, constant spoelen...
Waarmee ik ook wil zeggen dat de snelheid dus werkelijk s*ckt.
Kan dit dus aan die bus-snelheid liggen, maar ook aan evt. smerige koppen?!?

If so, dan moet er maar gauw eens een cleaning tape doorheen

[DeBolle]

Ja, kan aan beiden liggen. Kun je nagaan hoe die drive is aangesloten? (soort controller, terminator, wat zit er verder op de bus) En ook de disks waar de data vandaan moet komen? (welke disks, soort controller, filesystem enz.)

[PrinsEdje80]

Op dinsdag 02 april 2002 22:26 schreef DeBolle het volgende:
Ja, kan aan beiden liggen. Kun je nagaan hoe die drive is aangesloten? (soort controller, terminator, wat zit er verder op de bus) En ook de disks waar de data vandaan moet komen? (welke disks, soort controller, filesystem enz.)

Zal ik vandaag vragen...

[PrinsEdje80]

Ik praat even de systeembeheerder na:

[papagaaimode]
Het is een ultra-scsi systeem. met een scsi-schijf, allemaal ultra white 160. En op de DAT zit een actieve terminator.
[/papagaaimode]

Hijzelf vermoedt dat het aan de terminator kan liggen...

[PrinsEdje80]

We hebben nog weer verder geexpirimenteerd. Nu alleen mbt de snelheid. We hebben een actieve terminatie gebruikt: werkt niet. LVC terminatie: werkt wel, maar nog steeds heen en weer spoelen. Geen terminatie: werkt ook, maar ook spoelen.
Andere kabels: ook weer spoelen... Scsi instellingen: ook spoelen...

Mijn systeembeheerder gaat onderhand deze kant uit:

Help hem!!

[DeBolle]

Met 'actieve terminator' bedoelt de hardware man waarschijnlijk een ALT-2 terminator en dat is een single ended terminator, geen LVD. Als de controller inderdaad een UW160 LVD controller is, dan moeten alle devices ook LVD zijn om op die snelheid te werken.
Als de ook aangesloten disk SE is en geen LVD, dan valt alles terug op lagere bussnelheid ...
Hoe snel is die disk overigens? Als het een UW disk is, hou er dan rekening mee dat 'ie niet onder alle omstandigheden voldoende snel data kan leveren om de DDS-4 aan de praat te houden.
Samengevat:
-de disk(en) moet(en) in staat zijn om continue ongeveer 15MB/s te leveren aan de tapedrive
-optimaal is de tapedrive op een eigen controller
-de max. kabellengte van controller tot en met tapedrive voor U160 is ongeveer 1 meter
-de disk moet ook LVD zijn en geen terminator hebben
-de terminator moet een LVD of een multimode LVD/SE type zijn.

Testen voor optimale snelheid met:
time tar cf - /directory | cat | dd of=/dev/st0 bs=16k
'time' laat zien wat de benodigde tijd was, de 'f -' heeft stdout als output, dit gaat door cat, wat weer naar 'dd' gaat om te experimenteren met de blocksize. Niet de 'v' optie meegeven aan tar, het laten zien van de filename vertraagt alleen maar.
Als de disk en SCSI bus voldoende snelheid kunnen halen, moet je hiermee zonder meer tussen 300MB/minuut en 800MB/minuut kunnen halen, ofwel 5MB/s tot 14MB/s.

Als in die directory veel kleine bestanden staan, is het mogelijk dat de disk toch niet snel genoeg de data kan inlezen door het geneuzel met veel inodes - probeer dan een directory met grote bestanden.
Zijn het juist grote bestanden die goed gecomprimeerd kunnen worden, probeer dan eens wat er gebeurd als de data al gecomprimeerd naar de tape gaat met:
time tar cf - /directory | cat | compress| dd of=/dev/st0 bs=16k

Als de data namelijk sterk gecomprimeerd kan worden door de hardware compressie van de drive, kan het voorkomen dat je bijvoorbeeld 100MB aan data naar de drive stuurt, die door de compressie wordt ingedikt tot 5MB - je moet dan een factor 20 meer data sturen dan wat naar de tape wordt geschreven. In dit geval is dan software compressie voordeliger voor de snelheid, want de cpu load is weliswaar hoger maar er gaat 20 maal minder data over de bus naar de tapedrive.
Mocht dit alles niet tot de gewenste resultaten leiden, dan wil ik zelf wel eens op m'n werk een opstelling maken, gelijkwaardig aan de jouwe, zodat ik kan zien wat de vertaging kan veroorzaken.

Ik lul *echt* veel, eh?