Linux zegt: HD is stuk; maar dat is niet zo? Vaag probleem..

[Wilke]

Wat ik nu weer heb...dit is echt heel vaag.

Het probleem is in feite heel simpel: ik heb een nieuwe en een oude harddisk. Op de oude stond al Linux, op de nieuwe nu ook, en ik wilde natuurlijk de data die nog op de oude stond kopieeren naar de nieuwe. Dat ging goed, op de laatste partitie na. Dit is wat ik krijg:

# mount /dev/hdb8 /mnt/temp -t reiserfs

mount: wrong fs type, bad option, bad superblock on /dev/hdb8,
or too many mounted file systems

Tegelijk verschijnen dit soort scary meldingen in de log:

May 20 14:54:58 bruggenmors kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
May 20 14:54:58 bruggenmors kernel: hdb: read_intr: error=0x04 { DriveStatusError }
[herhaalt een paar keer]
May 20 14:54:58 bruggenmors kernel: end_request: I/O error, dev 03:48 (hdb), sector 31719424

reiserfsck zegt inderdaad ook netjes dat het 'superblock' kapot is en dat het op een Hardware probleem lijkt.

Met andere woorden: dit ziet er ernstig fout uit, het lijkt er op dat die HD screwed is.

Alleen!!! - die HD is niet screwed! Ik heb de nieuwe HD losgetrokken, de oude weer op master gezet, geboot, en dat ding werkt 100% perfect! Heb alle data maar gekopieerd naar een andere partitie, en vanaf daar gekopieerd naar de nieuwe hd . Geen enkele foutmelding of I/O error gezien.

Die data heb ik nu dus al ('problem solved' wat dat betreft dus), maar ik ben alsnog reuze benieuwd wat ter wereld dit nou weer zou kunnen veroorzaken.

Het gaat om dezelfde computer (dus I/O-controller), dezelfde kernel-versie (nl. vanilla 2.4.20 + ptrace patch), uiteraard ondersteuning voor de I/O-controller er ingezet, en zelfs geprobeerd DMA etc. uit te zetten op alle HD's. Mocht allemaal niet baten.


Wie heeft enig idee wat dit soort problemen zou kunnen veroorzaken?

[XTerm]

Versmikkel dat ding eens naar hdc of hdd, en kijk eens wat er dan gebeurt ?

Als ie het dan wel doet mag jij voor mij een eitje bakken

[Verwijderd]

Grote kans dat het een ide-kabel is geweest die niet helemaal goed vast zat.

Hoe vaak ik daar al wel niet gedonder mee gehad heb in verschillende systemen

[Wilke]

Nelske: Hmm....alleen heb ik nu dus die HD's al 2 keer los getrokken om die master/slave setup om te ruilen (dat maakt uit bij UDMA-66/100 blijkbaar)....dus dan weet ik wel heel trefzeker die kabel steeds op precies dezelfde foute manier te bevestigen (als in: niet waarschijnlijk dus ).

Daarnaast vind ik het dan ook vrij raar dat ik van de andere partities gigabytes data kan sleuren zonder 1 foutmelding.

Oh ja, needless to say: het BIOS detecteert beide drives automatisch, en de groottes kloppen ook e.d. (er staan dus ook geen jumpers fout o.i.d.)

[BoAC]

Geen LBA of CHS probleem in je bios?
Misschien moet je in de bios de harddisk keihard op LBA zetten.

[Verwijderd]

The BIOS-routine wants lots of unnecessary data, and it's less
! "interesting" anyway. This is how REAL programmers do it.

[deadinspace]

Hoe hingen de HDs precies toen het fout ging en toen het goed ging?

Als ik het goed begrijp hingen ze beiden aan dezelfde kabel (met de nieuwe als master en de oude als slave) toen het fout ging, en hing de oude als master aan diezelfde kabel toen het goed ging?

Hou je er rekening mee dat (bij udma-66/100 modi iig) de master op het einde van de kabel moet en de slave in het midden (iirc). Ook is er een specificieke kant die aan het moederbord hoort. Ook vallen lange IDE-kabels (1 meter enzo) buiten de IDE specs en kunnen dus problemen opleveren (meestal doen ze dat niet, maar het is buiten spec dus je loopt het risico).

[Verwijderd]

knip: van: http://www.linuxnetmag.com/en/issue7/m7hdparm1.html


>> hdparm -d1 -Xzz -i -v -t /dev/hda

with zz replaced by appropiate parameters.
Please note to set the switch -d1 always because this switch enables DMA. The timing switch (-t) will measure your current speed after setting up the new configuration. The higher the zz variable the faster you system will be and the more error are to be expected. So keep tracking on the second terminal to prevent too many CRC errors.
If you notice errors like these slow down:

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

[Verwijderd]

Dit heeft mij ooit uit de brand geholpen:

Kernel optie:
--> ATA/IDE/MFM/RLL support
--> IDE, ATA and ATAPI Block devices
-->Include IDE/ATA-2 DISK support
Use multi-mode by default

CONFIG_IDEDISK_MULTI_MODE:
If you get this error, try to say Y here:

hda: set_multmode: status=0x51 { DriveReady SeekComplete Error }
hda: set_multmode: error=0x04 { DriveStatusError }


Ik weet dat de meldingen niet 't zelfde zijn (set_multimode vs read_intr) maar bij mij werkte het.

[Wilke]

deadinspace schreef op 20 mei 2003 @ 21:05:
Als ik het goed begrijp hingen ze beiden aan dezelfde kabel (met de nieuwe als master en de oude als slave) toen het fout ging, en hing de oude als master aan diezelfde kabel toen het goed ging?

100% correct

Hou je er rekening mee dat (bij udma-66/100 modi iig) de master op het einde van de kabel moet en de slave in het midden (iirc). Ook is er een specificieke kant die aan het moederbord hoort.

Ja, ja, en ja. Dat is bij mijn kabel gelabeled, dus dat kan ook haast niet mis gaan he

Ook vallen lange IDE-kabels (1 meter enzo) buiten de IDE specs en kunnen dus problemen opleveren (meestal doen ze dat niet, maar het is buiten spec dus je loopt het risico).

Nou, deze kreeg ik bij m'n mobo, en als 'ie 40 cm lang is dan is het veel...eerder 30 denk ik. Dus nee, dat zal het probleem ook niet zijn.

Bovendien lijkt het me in het geval het echt aan hardware ligt heel sterk dat ik 3 andere partities volledig kan kopieeren zonder 1 foutmelding, maar de laatste alleen niet eens kan mounten...daarnaast lijkt het me dan nog sterker, dat als ik de oude versie boot, het gewoon perfect werkt. Dus ik verdenk echt Linux .... raar maar waar

Ja ja, als ik een probleem 'vaag' noem, dan heb ik daar wel reden voor

[deadinspace]

Wilke schreef op 21 mei 2003 @ 00:08:
Bovendien lijkt het me in het geval het echt aan hardware ligt heel sterk dat ik 3 andere partities volledig kan kopieeren zonder 1 foutmelding, maar de laatste alleen niet eens kan mounten...daarnaast lijkt het me dan nog sterker, dat als ik de oude versie boot, het gewoon perfect werkt. Dus ik verdenk echt Linux .... raar maar waar

Ah, dus je bootte ook van de nieuwe schijf (en dus van een ander systeem) als de nieuwe HD erin hing?

Dan verander je dus twee dingen tegelijk, namelijk de software, en de HD-aansluitingen. Wat als je de nieuwe HD erbij hangt, maar boot van de oude HD? Gaat het dan wel goed, of ook niet?

[MrC4u]

Hmm, het ligt toevallig niet aan de kernel? Ik heb van de week met up2date een nieuwe kernel gedownload en geinstalleerd voor mijn RH7.2 bak, alleen werkte de HD aansturing niet meer met de nieuwste kernel (HPT370). En aangezien er geen toetsenbord en scherm ophangt ed ff snel de oude kernel weer opgestart, en deze deed het zonder enkele problemen...

[Wilke]

deadinspace schreef op 21 May 2003 @ 01:18:
[...]

Ah, dus je bootte ook van de nieuwe schijf (en dus van een ander systeem) als de nieuwe HD erin hing?

Dan verander je dus twee dingen tegelijk, namelijk de software, en de HD-aansluitingen. Wat als je de nieuwe HD erbij hangt, maar boot van de oude HD? Gaat het dan wel goed, of ook niet?

Dat klopt. Maar dus wel met dezelfde kernel-versie etc.

Oh, als ik gewoon de oude boot dan kan die gewoon de partitie mounten - zou me ook heel sterk lijken dat ik ineens een partitie niet kan mounten omdat ik er een andere harddisk bij plaats

Het ligt dus ergens aan die nieuwe linux-install, maar ik snap niet wat - zelfs in theorie - dergelijk gedrag kan verklaren. De versies van ReiserFS zijn ook gelijk, dat moet wel want de kernel-versies zijn gelijk. Trouwens, als het daar ergens in zou zitten (of in optimalisaties, of weet ik veel wat er verder net even iets anders zou kunnen zijn tussen deze twee linux-installaties), dan lijkt het me dat ik ook de andere partities niet meer had kunnen mounten (die zijn ook reiserFS).

Nou ja, ik ga het nu ook niet meer proberen....de oude harddisk gaat in m'n server, en de nieuwe blijft in m'n desktop; dit omdat die van m'n server een weekje geleden was gecrashed

Dus ik ga nu niet meer experimenteren met allerlei verschillende combinaties etc. want die schijf is alweer geformatteerd inmiddels

Toch is dit denk ik wel het meest onverklaarbare probleem dat ik tot nu toe heb gezien met Linux.

[Wilke]

Als we het dan trouwens toch hebben over rarigheidjes in Linux: iets anders wat ik al jarenlang niet snap, is dit:

Nadat je de partitie-tabel wijzigt (met fdisk ofzo), moet je rebooten. Doe je dit niet, dan heb je de kans dat het aanmaken van filesystems verkeerd gaat. In ieder geval kreeg ik, op mijn nieuwe harddisk, allemaal wazige meldingen over bad sectors etc. etc - dit nadat ik niet had gereboot na het aanmaken van alle partities.
Dus ik dacht: sure, dat zal wel, eerst eens opnieuw proberen en dan wel netjes rebooten na fdisk. Geen foutmelding meer gezien. Omdat ik het toch niet vertrouwde ook nog eens geformatteerd met de 'check for bad sectors' optie van mke2fs. Die vond alles prima. Later ook nog eens de hele HD laten scannen onder Windows (tja...je moet wat he ), die vond ook helemaal niets. Met andere woorden: die HD is niks mis mee.

De vraag is dan: Waarom moet Linux rebooten na het wijzigen van de partitie-tabel? Is dit een design flaw in Linux? Die tabel staat toch gewoon op de HD, en dit heeft toch niets te maken met BIOS of andere hardware die echt 'gereset' moet zijn voordat de wijzigingen doordringen? Dus wat gaat er precies fout als je niet reboot, en waarom is deze "bug" nog niet jaren geleden gefixed?

Ik bedoel: waarom kunnen Windows XP en Windows 2000 dit anders wel zonder problemen en zonder te rebooten tussendoor?

Opnieuw: just wondering, maar dit is toch vreemd, vinden jullie niet?

[Bart Coppens]

Wilke schreef op 21 May 2003 @ 13:28:
De vraag is dan: Waarom moet Linux rebooten na het wijzigen van de partitie-tabel
Opnieuw: just wondering, maar dit is toch vreemd, vinden jullie niet?

Van wat ik er me van herinner toen ik het laatst moest partitioneren is dit alleen het geval met de drive waar je root-fs opstaat, of iets in die aard. In ieder geval heb ik destijds gepartitioneerd en geformateerd zonder te rebooten.
En uit de cfdisk manpages (die je als lm zeeeker gecheckt hebt )

W Write partition table to disk (must enter an upper case W). Since this might destroy data on the disk,
you must either confirm or deny the write by entering `yes' or `no'. If you enter `yes', cfdisk will
write the partition table to disk and the tell the kernel to re-read the partition table from the disk.
The re-reading of the partition table works is most cases, but I have seen it fail. Don't panic. It will
be correct after you reboot the system. In all cases, I still recommend rebooting the system--just to be
safe.

Edit:
en met fdisk? Voor zover ik weet wordt fdisk gebruik afgeraden ten voordele van cfdisk in zijn eigen manpages

[ Voor 7% gewijzigd door Bart Coppens op 21-05-2003 15:02 ]

[Wilke]

Hmm...makes me wonder...wat is er mis met fdisk

Maar je hebt gelijk, staan inderdaad enge dingen in de 'BUGS' sectie van de manpage.

fdisk is a buggy program that does fuzzy things - usually it happens to produce reasonable results.

En dit in hun eigen manpage

Echt zo'n opmerking van: "Meestal werkt het, your mileage may vary". Joy..precies wat je graag ziet bij een prog dat je partities manipuleert

Voor de rest: dit is dus inderdaad een onvolkomenheid in Linux; want zelfs cfdisk durft niet te garanderen dat je niet hoeft te rebooten, en ik heb het dus inmiddels wel eens mis zien gaan (okee, met fdisk, maar toch )

[deadinspace]

Maar fdisk en cfdisk melden dat toch ook bij het schrijven?
fdisk:

code:

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

cfdisk:

code:

Wrote partition table, but re-read table failed.  Reboot to update table.

Dus het is documented en het wordt je gemeld

Enige vraag is dan nog waarom het opnieuw inlezen faalt. Volgensmij werkt dit niet op het moment dat een filesystem op die disk gemount is, wat redelijk logisch zou zijn. Het is dan alleen lastig dat je de schijf met je root partition niet kunt herpartitioneren.

[Wilke]

deadinspace: mijn fdisk heeft daar dus helemaal niets van gezegd bij het wegschrijven. Alleen dat het wegschrijven lukt, en dat hij de HD synct om het permanent te maken. Inderdaad heb ik die melding vroeger wel eens gezien, maar de laatste tijd dus niet meer.

Trouwens, op die betreffende disk was (uiteraard) nog geen enkele partitie gemount, want het was een nieuwe HD. Alleen de CD was gemount. Dus dat kan geen reden zijn waarom de kernel de tabel niet kan herladen, right?

* Wilke houdt het toch op een bug dus.

[Vae Victis]

Wilke schreef op 21 May 2003 @ 13:20:
Het ligt dus ergens aan die nieuwe linux-install, maar ik snap niet wat - zelfs in theorie - dergelijk gedrag kan verklaren. De versies van ReiserFS zijn ook gelijk, dat moet wel want de kernel-versies zijn gelijk. Trouwens, als het daar ergens in zou zitten (of in optimalisaties, of weet ik veel wat er verder net even iets anders zou kunnen zijn tussen deze twee linux-installaties), dan lijkt het me dat ik ook de andere partities niet meer had kunnen mounten (die zijn ook reiserFS).

Heb even je topic gevolgd, had nl een soortgelijk probleem een tweetal weken terug.

Kernel 2.4.20
Eerst waren al mijn linux partities ext2 geen probleem liep weken goed.
Daarna een 6 tal schijven van fat32 waar mijn data opstond, omgezet naar ext3, daarna een paar partities op mijn 'linux' schijf omgezet van ext2 naar ext3.
MAAR niet allemaal ik had er nog een 4 tal partities die ext2 waren.

Zodra ik ext3 partities had, kreeg ik foutmeldingen bij mijn ext2 partities. (eerst 1 later de ander)
Soortgelijke foutmelding als jij en het niet kunnen mounten van die partities.
+ dat het superblock kapot was.
Kijk ik met cfdisk naar die schijf, staat er heel leuk ext3 ipv ext2 bij de schijven waar ik errors op kreeg.
Hoe dat komt, niet door mij iig.

Kon deze partities mounten door ext2 bij mount opdracht te geven, koperien was dan ook geen probleem.
partitie weggegooid en ext3 er voor in de plaats gezet.
En het loopt nu weer als een trein.

Lijkt er dus idd op dat er een bug ergens zit.
In mijn onwetendheid zou ik zeggen dat het iets met journaling te maken heeft.

[deadinspace]

Ah, dan hoort het gewoon goed te gaan ja...
Hmm, die "reboot just to be safe" uit die manpage is dus niet gewoon overdreven voorzichtigheid

Overigens heb ik er nooit problemen mee gehad, terwijl ik wel eens schijven gepartitioneerd heb op een draaiend systeem.