[gentoo en Powervault] tar -cvvf /dev/tapes/tape0/mt...

[Zwerver]

hallo ik heb een dell poweredge 500sc met een powervault 100T (seagate) tape drive erin. Als ik nu tar -cvvf /dev/tapes/tape0/mt /etc invoer (hiermee zou die de /etc map naar de tape moeten zetten) dan crashed het systeem. Ik heb 2 ide controllers volledig bezet en wel zo:

ide 1: /dev/hda en /dev/hdb (20 gb hdd beide)
ide 2: /dev/hdc en /dev/hdd (cdrom en tape)

dit moet volgens dell, want dell zegt geen hdd en tape op een controller....

Foutmeldingen worden niet teruggevonden in /var/log/messages dus langzaam aan ben ik een beetje wanhopig. Iemand een idee waar dit aan kan liggen? Oja, de tapedrive werkt wel gewoon goed als het gaat om gewone mt commando's zoals retention en rewind.

[Verwijderd]

Hoe crashed je systeem? Krijg je een panic, krijg je een oops of "hangt" ie gewoon? Welke distro gebruik je. Welke kernel gebruik je?

[Zwerver]

system hangt gewoon volledig.... ik gebruik gentoo 1.4_rc2 op die bak met een 2.4.19 kernel aangepast door gentoo. Bij dell dachten ze (heb er vandaag contact mee gehad) dat de driver die in de kernel zit misschien niet helemaal goed is, en anders eventueel dat de firmware ge-upt moet worden....

[Verwijderd]

Als dit geen productie machine is (dan moet dit tijdens een maintenance window) kun je dan eens 1 disk en de cdrom drive van de ide controller aftrekken en het nog een keer proberen?
Hangt er een monitor aan het systeem ('t zou natuurlijk maar zo kunnen dat ie wel oops't of paniced, maar dat je dat niet ziet omdat er geen monitor aanhangt)
Ondertussen, probeer je kernel eens te upgraden naar vanilla 2.4.20 en kijk of het probleem zich nog een keer voordoet.

edit:

Heb je al de laatste mt utils geinstalled?

[ Voor 8% gewijzigd door Verwijderd op 14-01-2003 16:12 ]

[Zwerver]

ik heb de tapestreamer alleen aan een ide kabel gehad (met veel moeite, achterlijke dell bak), geen resultaat. Ik heb 2.4.20 vanilla sources gecompiled, geen resultaat. Ik heb hem nu met ide-scsi en sr draaiend en kan nu iig zien dat de status met ps D is.... Dus hij wacht ergens op.... Na een tijdje (heb er niet opgewacht, was lang iig) zit het systeem dan toch weer vast.

[Zwerver]

even wat extra info nog: het is een seagate STT20000A, ATAPI interface, ide-tape als driver, en nu ide-scsi met sr als driver

[gwystyl]

Hmm lijkt niet echt te lukken he? Heb je de machine verder al getest met de tapestreamer eraf? Dattie niet toevallig ergens anders op hangt

[Verwijderd]

En krijg je hetzelfde als je de tapestreamer op een andere machine aansluit?

[Zwerver]

ik heb geen andere machine paraat, en nee, het systeem hangt niet op iets anders. Ben nu een uitgebreide tar aan het maken van mijn / (root dus) zodat ik iig een backup heb, en die draait iig perfect. Verder heeft dell die kast zo #$%^&* in elkaar zitten dat ik die tapestreamer er niet uit krijg... anders had ik hem wel even in mijn ws gestopt

[Verwijderd]

stomme dingen misschien, maar de moeite misschien waard :

1 : er zit een tape in de drive ?.
2 : brand het oranje lampje op de drive ? ( cleaning led )
3 : gaat het groene activiteit lampje branden als je tar doet ?
4 : kun je remote niet op de machine komen als ie hangt ? ( telnet ssh ) ( kijk of er een process ettert )

[mvdejong]

Wat zijn de laatste paar regels van de output van het tar-commando ?

[Zwerver]

scsi-freak: ja er zit een tape in, oranje lampje brand, heb geen groen lampje (ook niet toen die aan een w$ xp bak hing), en nee ik kom er remote ook niet op. ps axu geeft bij tar de D status dus hij wacht blijkbaar ergens op. mvdejong: geen output regels behalve de dir listing die weergegeven wordt.

[mvdejong]

zwerver schreef op 24 January 2003 @ 09:23:
mvdejong: geen output regels behalve de dir listing die weergegeven wordt.

Is het de hele listing, of stopt die ergens ?

Wat ik wil weten is of het tar-commando misschien tegen een file-type aanloopt waar het zich in verslikt, dus wil ik weten of de listing compleet is, of ergens halverwege stopt. Heb je al eens geprobeerd wat er gebeurd als je de tape probeert terug te lezen ? Is de backup dan compleet of krijg je een fout-melding ?

Er ontwikkelen zich de laatste jaren nogal wat exotische file-type voor specifieke communicatie, en de backup-tools kunnen daar niet altijd tegen. Juist dat soort dingen kan onder /etc huizen. Een voorbeeld is dat Sun in Solaris het type "door" heeft ingevoerd als een experimentele variatie op "socket".

[Zwerver]

er staat helemaal niks op die tape, hij maakt *zover ik kan overzien* eerst een tar in het geheugen aan voordat die weg gaat schrijven, dan wil die weg schrijven en blokkeerd die. Overigens heb ik op advies van seagate nu niet meer de ide-tape drivers maar de sg driver met ide-scsi draaien en dat geeft me de tijd om iets langer door te werken. Maar uiteindelijk loopt die dan toch weer vast en staat er niks op de tape... Iemand een idee waar die D voor staat als status als ik ps doe?

[u_nix_we_all]

zwerver schreef op 24 January 2003 @ 17:40:
er staat helemaal niks op die tape, hij maakt *zover ik kan overzien* eerst een tar in het geheugen aan voordat die weg gaat schrijven, dan wil die weg schrijven en blokkeerd die. Overigens heb ik op advies van seagate nu niet meer de ide-tape drivers maar de sg driver met ide-scsi draaien en dat geeft me de tijd om iets langer door te werken. Maar uiteindelijk loopt die dan toch weer vast en staat er niks op de tape... Iemand een idee waar die D voor staat als status als ik ps doe?

Eh Defunct ?
Dat oranje lampje , wat zegt de manual van de tapedrive daarvan ? is dat een
goeie status ?
Heb je al eens geprobeert een tape te lezen ?

Het kan zijn dat je tapedrive gewoon stuk is natuurlijk.....

[u_nix_we_all]

Uh , en is het niet "tar cvvf ...." ipv met een minnetje "tar -cvvf ......"

[mvdejong]

Nee hoor, tar behoort bij de hele, hele oude UNIX-commando's, en die gebruikten nog geen "-" voor de opties. Bij de meeste tar-implementaties is de "-" nu optioneel, maar doe maar een een "man dd".

[ Voor 12% gewijzigd door mvdejong op 24-01-2003 20:16 . Reden: "een" i.p.v. "geen" op de cruciale plek doet vervelende dingen met de tendens van een pleidooi. ]

[mvdejong]

zwerver schreef op 24 January 2003 @ 17:40:
er staat helemaal niks op die tape, hij maakt *zover ik kan overzien* eerst een tar in het geheugen aan voordat die weg gaat schrijven, dan wil die weg schrijven en blokkeerd die. Overigens heb ik op advies van seagate nu niet meer de ide-tape drivers maar de sg driver met ide-scsi draaien en dat geeft me de tijd om iets langer door te werken. Maar uiteindelijk loopt die dan toch weer vast en staat er niks op de tape... Iemand een idee waar die D voor staat als status als ik ps doe?

tar buffert maar weinig, en maakt zeker geen volledig image aan voordat het wordt weggeschreven (zou toch pijnlijk worden als je 100+ GByte naar een DLT7000 schrijft (die comprimeert de handel, dus dat haal je soms wel). tar werkt enigzins wel "vooruit", dus als er weinig onder je /etc-directory staat, dan kan het zijn dat, bij een grote block-size, er niets op tape staat.

Het volgende huiswerk voor je :
- maak dezelfde tar naar file op schijf en kijk of het systeem dat overleeft;
- verifieer de aangemaakte tar-file met "tar -tvvf ...";
De bedoeling hiervan was om te kijken of je tar-commando wel levensvatbaar is.

- doe dan een "dd if=<een of andere file> of= /dev/tapes/tape0/mt"
- doe dan een "dd if=/dev/tapes/tape0/mt /tmp/teruglezer"
- doe dan een "cmp /tmp/teruglezer <een of andere file> voor de zekerheid
En dit controleert dus of je tape-drive en de bijbehorende driver naar behoren werken.

Heb je trouwens enig idee waarop de blocksize voor je tar ingesteld staat ? Experimenteer eens met "tar -ccvbf 20 /dev/tape/tape0/mt", en voeg eventueel de "bs=20b" toe aan de hierboven vermelde "dd"-commando's, dan forceer je de blocksize naar 10 kByte. Ik heb ooit een tape-drive gek gekregen door een iets te hoge blocksize te gebruiken.

[ Voor 9% gewijzigd door mvdejong op 24-01-2003 20:17 ]

[u_nix_we_all]

mvdejong schreef op 24 januari 2003 @ 20:06:
Nee hoor, tar behoort bij de hele, hele oude UNIX-commando's, en die gebruikten nog geen "-" voor de opties. Bij de meeste tar-implementaties is de "-" nu optioneel, maar doe maar een een "man dd".

Juist, dat bedoelde ik dus ook
Maar de optionele "-" kan dus geen kwaad, en dat was de strekking van
mijn vraag/opmerking.

[Verwijderd]

oranje lampje is in mijn optiek een fout lampje... al een cleaning tape erin gehad ?

[Zwerver]

pff, oke, even snel een korte samenvatting van de antwoorden op de vragen:

Eh Defunct ?
Dat oranje lampje , wat zegt de manual van de tapedrive daarvan ? is dat een
goeie status ?
Heb je al eens geprobeert een tape te lezen ?

Het kan zijn dat je tapedrive gewoon stuk is natuurlijk.....

oranje lampje is gewoon functie lampje dat aangeeft dat de tapedrive draait. Heb onder M$ XP de tapedrive draaiend gehad, zowel schrijvend als lezend.

tar buffert maar weinig, en maakt zeker geen volledig image aan voordat het wordt weggeschreven (zou toch pijnlijk worden als je 100+ GByte naar een DLT7000 schrijft (die comprimeert de handel, dus dat haal je soms wel). tar werkt enigzins wel "vooruit", dus als er weinig onder je /etc-directory staat, dan kan het zijn dat, bij een grote block-size, er niets op tape staat.

/etc is idd niet echt groot op deze bak... weinig progseltjes dus weinig conf files.

Het volgende huiswerk voor je :
- maak dezelfde tar naar file op schijf en kijk of het systeem dat overleeft;
- verifieer de aangemaakte tar-file met "tar -tvvf ...";
De bedoeling hiervan was om te kijken of je tar-commando wel levensvatbaar is

Werkt goed. Tarretje is oke

- doe dan een "dd if=<een of andere file> of= /dev/tapes/tape0/mt"
- doe dan een "dd if=/dev/tapes/tape0/mt /tmp/teruglezer"
- doe dan een "cmp /tmp/teruglezer <een of andere file> voor de zekerheid
En dit controleert dus of je tape-drive en de bijbehorende driver naar behoren werken

hmz, ik heb de tape er blijkbaar uitliggen en ben !@work nu... zal dit maandag direct ff proberen

Heb je trouwens enig idee waarop de blocksize voor je tar ingesteld staat ? Experimenteer eens met "tar -ccvbf 20 /dev/tape/tape0/mt", en voeg eventueel de "bs=20b" toe aan de hierboven vermelde "dd"-commando's, dan forceer je de blocksize naar 10 kByte. Ik heb ooit een tape-drive gek gekregen door een iets te hoge blocksize te gebruiken.

zelfde verhaal, doe dit maandag... Iig weet ik nu dat mijn tar oke is... lampje is gewoon activity lampje, en meer kan ik nu remote niet doen helaas

[Zwerver]

- doe dan een "dd if=<een of andere file> of= /dev/tapes/tape0/mt"
- doe dan een "dd if=/dev/tapes/tape0/mt /tmp/teruglezer"
- doe dan een "cmp /tmp/teruglezer <een of andere file> voor de zekerheid
En dit controleert dus of je tape-drive en de bijbehorende driver naar behoren werken

dd if=/tmp/test.tar of= /dev/tapes/tape0/mt gedaan, dit zorgt voor een totale hang... Of had ik hier geen tar mogen pakken? In iedergeval is de hang dusdanig dat ik nu morgen de bak moet herstarten als ik @ work ben.... Kan er nu iig helemaal niet meer bij.... in ieder geval niet remote

[mvdejong]

Of je hier een tar-archive of niet voor pakt maakt niets uit, het bestand wordt als een volkomen betekenis-loze reeks van bytes gezien, en je eerdere verificatie daarvan toonde wel aan dat het lezen op zich daarvan niet storend is voor het probleem.

Het probleem is dus niet gelegen aan het tar-commando, of de manier waarop die de device-driver aanspreekt (dat was de bedoeling van mijn huiswerk, eliminatie van mogelijke schuldigen).

Je hebt dus ofwel een probleem met de tape-drive zelf, of met de device-driver. Het laatste is het meest waarschijnlijk, omdat een rottige tape-drive gewoonlijk niet het hele systeem zou mogen verzieken (behalve bij SGI-bakken waar het SCSI-id van de SCSI-controller 0 is, met als gevolg dat alle devices, inclusief een eventueel overstuur zijnde tape-drive, de bus permanent in kunnen pakken). Het lijkt wel of er een continuous loop in de device-driver optreedt, en aangezien een device-driver in kernel-mode werkt, is die niet zo makkelijk te onderbreken.

[Zwerver]

oke, maar dan zou het dus geen verschil op mogen leveren of ik dit met deze seagate doe of bijvoorbeeld een onstream drive? Want er wordt gebruik gemaakt van de standaard kernel (2.4.20) die ik van kernel.org gehaald heb. En is het niet een beetje raar dat zowel de ide-tape als de sr driver hetzelfde probleem geven?

[Zwerver]

goed, als ik het goed heb staat er nu wat op de tape (heb de blocksize naar 20b gezet) maar nu freesed die met een tar tvvf /dev/tapes/tape0/mt moet ik daar soms ook die tar tvvfb 20 /dev/tapes/tape0/mt van maken?

[mvdejong]

Het is wel te adviseren, want vaak kan tar wel een foutieve blocksize "on the fly" oppikken, maar daarvoor moet wel het eerste block worden ingelezen, met de default blocksize als er geen blocksize is gespecificeerd.

Het lijkt erop dat de default blocksize zo groot is (of zo gek, misschien geen veelvoud van 512 bytes) dat er een buffer-overflow in de driver optreedt. Wel een bug in de driver dus, maar je kunt er omheen door de blocksize expliciet mee te geven.

Het hangt helemaal van je OS af waar de default blocksize staat, en of die te veranderen is, (modernere UNIX-versies hanteren /etc/default/tar) maar dat zal de man-page van tar je moeten leren. Is dat in te stellen, dan is 20 blocks/10 kByte een hele goede waarde om te beginnen.

Je kunt nog experimenteren met de waarde van de blocksize. De eenheid voor tar is "blocks" dus de standaard 512 bytes (de standaard data-eenheid voor UNIX). 20 is dus 10 kByte. Je kunt met "dd" de blocksize opgeven met "bs=20b", of "bs=10k". Sommige drives doen het beter als je de blocksize hoger zet (een 150 MByte QIC-tape komt met een blocksize van 512 bytes niet in streaming-mode en staat dus constant heen en weer te spoelen, met een blocksize van 10k lukt het streamen wel en loopt de backup 4-5 keer zo snel).

[Zwerver]

hmz, nadat daarnet de bak weer vastgelopen was een collega gebeld om hem te rebooten.... toen heb ik voor de gein gewoon een tar tvv /dev/tapes/tape0/mt gegeven en wat bleek? De ps output was S (sleep neem ik aan?) toen nog eens tar tvvf /dev/tapes/tape0/mt gegeven en ps out was D.... oftewel, kan het zijn dat die niet alleen zichzelf verslikt in de blocksize (opgegeven via tar cvvfb 10k /dev/tapes/tape0/mt voor het erop spoolen maar tar tvvfb 10k /dev/tapes/tape0/mt wilde die niet doen) maar ook op die f? Ik kan er nu niet meer bij en de collega is nu ook naar huis maar kga ff op internet neuzen wat die f ookalweer doet.... zegt het je iets?

[mvdejong]

Let erop dat de volgorde voor switches met parameters belangrijk is, de parameters moeten in dezelfde volgorde staan als de switches !
"b" staat voor "blocksize"
"f" staat voor "file" (het bestand of device waar de backup staat/moet staan)

Als je in de lijst van switches eerst de "b" en dan de "f" doet, dan moeten de volgende parameters in de overeenkomstige volgorde "10k /dev/..." staan :

code:

tar tvvbf 10k /dev/...

Als je in de lijst van switches eerst de "f" en dan de "b" doet, dan moeten de volgende parameters in de overeenkomstige volgorde "/dev/... 10k" staan :

code:

tar tvvfb /dev/... 10k

Als je het verkeerd om doet probeert tar iets te doen met het bestand of device "10k", met een blocksize van "/dev/...", wat tar daar dan ook van moge maken !

Dit is UNIX, niet zoals bij Windows WYSIWYG (what You see is what You get), maar "You asked for it, You've got it !".

[ Voor 29% gewijzigd door mvdejong op 28-01-2003 14:36 ]

[Zwerver]

hmz, ik vind het vervelend om te zeggen, maar heb er nu RH73 opgezet omdat deze jongen nu echt moet gaan draaien en tot mijn verdriet (het is geen gentoo) maar ook een beetje mijn plezier doet die t nu wel... Waar kan ik uitvinden wat het verschil is in blocksize ed als ik die twee tarren wil vergelijken? Of zou het probleem gewoon in de > 2.4.18 kernel zitten