[Linux Ext3] Vele corrupte inodes na verwijderen ISO's

[Verwijderd]

Op een systeem waarop enkele honderden ISO's gemount worden, die vervolgens weer geshared worden, is een probleem opgetreden.

Namelijk er zijn (terwijl ze gemount waren), via samba op een onverklaarbare manier enkele ISO's door iemand verwijderd..
Met als gevolg dat de mounts vastliepen, zelfs de gehele partitie waarop deze ISO's stonden reageerde niet meer! (ls e.d. zorgen ervoor dat de console crashte)

Het filesysteem is ext3, nu wilde ik het systeem rebooten, maar na het commando shutdown -r now liep het systeem gewoon door.
Hierna maar shutdown -h now gedaan, dit werkte wel..
Systeem herstart, en je raad het al, bladiebla corrupted, run fsck manually... (journal replay leek ook mislukt te zijn...)
Zo gezegd zo gedaan, maarja nu heb ik dus al een kwartier de enter toets ingehouden voor het fixen van de inodes... (hierna maar iets zwaars op de enter toets gelegd)..

Nu is mijn vraag aan jullie, hoe kan het filesysteem zo kapot gaat als er iemand een gemounte iso verwijderd?

Het betreft een Red Hat Linux 9 systeem.

En, nee ik was niet diegene die de iso verwijderde

edit:

Inmiddels is hij al een 45 minuten aan het fsk'en en fixen...
Het zal misschien om 5 verwijderde iso's gaan..

Ik begin er een hard hoofd in te krijgen dat dit snel opgelost gaat worden

[ Voor 38% gewijzigd door Verwijderd op 08-12-2004 14:03 . Reden: status ]

[Straphka]

Ik weet niet echt wat je hieraan kan doen, maar ik weet wel dat je met

code:

 fsck -a /dev/hdx

geen zware dingen op de enter toets hoeft te leggen en je fsck een stuk sneller loopt

[Pastinakel]

Is het niet andersom? Dat je schijf aan het kapotgaan is en dat er daardoor iso's verdwijnen en je filesystem errors krijgt?

Wat is de SMART status van deze schijf? (om maar eens een balletje op te gooien)

[ Voor 28% gewijzigd door Pastinakel op 08-12-2004 13:01 ]

[Wilke]

Als je dit kunt reproduceren dan is het een bug. Het zou gewoon prima moeten kunnen om een iso onder een mount weg te deleten. Pas als je ook unmount moet de iso 'echt' weg zijn (en de ruimte vrijgegeven). Zolang ze nog gemount waren had je in principe dus zelfs alle gegevens er nog uit moeten kunnen kopieeren.

Don't be timid about moving or renaming the image file just because it's loop mounted. The filesystem uses inodes under the hood, and even if you move or rename the file, the inode stays the same. You won't hurt the filesystem mounted under /mnt. As for deleting the ISO file, that won't hurt the mounted filesystem either. A file's inode gets deallocated only when the inode's reference count drops to zero. Mounting the ISO image bumps the reference count up, so the file really gets deleted only after you rm the file and umount the loop device. All you people who are updating the CD don't have to worry about any of this. :-)

bron

Dus ik zou een hardware probleem zeker niet uitsluiten!

[Verwijderd]

Hmmmm, misschien is het dus een brakke schijf dan ja

Het is namelijk een systeem met een supertrak raid controller met een raid 5 configuratie...
Dan is het niet zo best dat ik nu die dingen aan et fixen ben, had beter dan de schijf die stuk was kunnen laten rebuilden..

Ik ga zometeen eens naar die raid configuratie kijken...

edit:

Gekeken in raid configuratie, maar alle schijven zijn functional volgens de controller..

Echter fsck geeft aan dat het superblock corrupt is..
Nu kan ik misschien een alternatief superblock selecteren..
Even zoeken waar deze gebackupped worden.

hmzz, door

code:

mke2fs -n /dev/sda2

te doen kon ik zien waar allemaal gebackupte superblocks staan.
Nu heb ik maar het superblock gepakt wat het grootste getal had..
Nu is het systeem bezig met allerlei dingen te fixen en het oude superblock te verwijderen, als eerste werd zelfs het ext3 journal kompleet weggegooid...

[ Voor 51% gewijzigd door Verwijderd op 08-12-2004 14:04 . Reden: nieuws ]

[Pastinakel]

Wat zegt cat /proc/mdstat?

[Verwijderd]

Pastinakel schreef op woensdag 08 december 2004 @ 14:30:
Wat zegt cat /proc/mdstat?

Aangezien hij nog steeds aan het checken is kan ik dat helaas niet zeggen, maar het is in ieder geval wel een systeem met hardware raid, waar het bestuuringssysteem niets vanaf weet, dan staat er toch niet veel bijzonders in mdstat?
Of is mdstat niet alleen voor software-raid?

hij geeft nu meldingen:

code:

clone duplicate/bad blocks <y>?

en ik zie allemaal modification date's voorbijkomen die echt NIET kunnen kloppen zoals 23 december 2023 e.d.

[Wilke]

Ok, het is natuurlijk niet 100% uit te sluiten dat het een bug is in de filesystems van Linux. Maar bij mijn weten zijn die vrij zeldzaam (tenzij je experimentele kernels gebruikt - welke versie heb je?), zeker voor ext3. De toepassing die jullie hebben wordt veel gebruikt, dus ik kan me niet voorstellen dat er zulke basis-fouten in voorkomen eerlijk gezegd.

Als het niet in een combinatie van driver/filesystem ligt (en daar zou ik niet als eerste van uit gaan als het al tijden prima werkt), zou ik toch echt eerst gaan kijken naar geheugen (memtest86) en of die RAID-controller wel helemaal lekker bezig is (en de harddisks er in). Want dit ziet er toch niet echt zo fijn uit

[Verwijderd]

Wilke schreef op woensdag 08 december 2004 @ 15:54:
Ok, het is natuurlijk niet 100% uit te sluiten dat het een bug is in de filesystems van Linux. Maar bij mijn weten zijn die vrij zeldzaam (tenzij je experimentele kernels gebruikt - welke versie heb je?), zeker voor ext3. De toepassing die jullie hebben wordt veel gebruikt, dus ik kan me niet voorstellen dat er zulke basis-fouten in voorkomen eerlijk gezegd.

Als het niet in een combinatie van driver/filesystem ligt (en daar zou ik niet als eerste van uit gaan als het al tijden prima werkt), zou ik toch echt eerst gaan kijken naar geheugen (memtest86) en of die RAID-controller wel helemaal lekker bezig is (en de harddisks er in). Want dit ziet er toch niet echt zo fijn uit

Hij is nog steeds aant checken, maar hij draait iig red hat 9 met een 2.4.20 of een 2.4.22 kernel, die zijn inmiddels stable toch?

Wat betreft de RAID controller, het is een Promise Supertrak SX6000.
Hij heeft een zeer goed diagnotische setup utility en deze geeft aan dat de schijven fully functional zijn .

Het geheugen is natuurlijk niet uitgesloten, een memtest kan natuurlijk nooit kwaad

Ik vind het er ook steeds minder fijn uit gaan zien, ik heb namelijk het gevoel dat het file systeem langzamerhand in een dermate staat van ontbinding is dattie niet meer echt te redden is.
Damn dan heb je een raid 5 config voor de zekerheid, en dan gaat het file systeem over zn nek

Ik denk dat ik inmiddels ext2 heb omdat de journal verwijderd werd omdat deze corrupt was..


*****

Ok dan, hij bleef iedere keer in een loop met dezelfde corrupte inodes aan komen zetten....
Dus ik denk dan maar:
ctrl-c -> geen resultaat
ctrl-alt-del -> geen resultaat
wacht wacht....
reset

Maar het positieve is dat hij nu tijdens de start-up automatisch het file systeem gaat checken
Waar hij waarschijnlijk halverwege wel weer op vast zal lopen ...

[ Voor 11% gewijzigd door Verwijderd op 08-12-2004 16:18 ]

[Verwijderd]

Doordat ik vergeten was een aantal mount scripts uit te zetten is vannacht WONDERBAARLIJK, de partitie gemount...
De fsck heeft toch zn vruchten afgeworpen

van de 84Gb aan data is er nu nog 71Gb beschikbaar, de rest is kwijt.

Dit is al een heel stuk beter dan geen data , nu even de data aan het backuppen op een ander systeem, en dan straks de partitie verder proberen te fixen, om meer data te redden.
Als dat niet lukt wordt ie verwijderd en komt er een XFS partitie

[Verwijderd]

Backup geslaagd, XFS werkte niet echt met Red Hat 9, dus heb ik er maar reiserfs van gemaakt..

Nu zag ik ergens dat je perse bij de RAID controller (Promise Supertrak SX6000), als O.S. other moest kiezen, en NIET Linux (ik kwam hierachter na problemen met pti_st)..

Kan iemand mij misschien vertellen of de file systeem corruptie misschien hierdoor veroorzaakt is?

De controller staat inmiddels op Other

[DGTL_Magician]

Straphka schreef op woensdag 08 december 2004 @ 12:53:
Ik weet niet echt wat je hieraan kan doen, maar ik weet wel dat je met

code:

 fsck -a /dev/hdx

geen zware dingen op de enter toets hoeft te leggen en je fsck een stuk sneller loopt

De pest is dat 'fsck -a' niet werkt bij een fout filesysteem. Het werkt alleen maar als je het zelf opstart zonder aanleiding.

[Verwijderd]

DGTL_Magician schreef op donderdag 09 december 2004 @ 15:51:
[...]

De pest is dat 'fsck -a' niet werkt bij een fout filesysteem. Het werkt alleen maar als je het zelf opstart zonder aanleiding.

klopt

code:

fsck -b <backup block nummer> -y /dev/sda2

deed het voor mij, maar dan wel pas het 6de backup superblock
En nog niet volledig..

[ Voor 4% gewijzigd door Verwijderd op 09-12-2004 16:07 ]