[redhat 7.2] hard disks controleren of fouten

[JVaags]

All,

Onlangs is mijn server op een wazige manier gecrashed Ik kreeg allemaal foutmeldingen dat samba zijn log niet kon schrijven over het scherm. Ik dus ff rebooten krijg ik een melding dat /dev/hda fouten bevat die fsck niet automatisch kon reparen...
Ik handmatig de check gedaan en toen ging ie allemaal innode's herstellen en toen was het zover die ie niet meer wilde booten...

Dus opnieuw ingericht met redhat 7.2 op dezelfde schijven. Ze draaien nu als een zonnetje en geven geen problemen maar ik wil ze toch graag goed controleren.

Maar zoiets als scandisk zit niet standaard in redhat. Wat is een goede en betrouwbare tool om mijn schijven mee te controleren?

[Verwijderd]

fsck zit bij je Linux distro en al geinstalleerd hoogstwaarschijnlijk. Die checkt na zoveel mounts oa je harde schijven. Als die roept dat er niet automagisch kan reparen dien je de handmatige optie kiezen, fsck -r <drive> . Een journaled filesystem is beter bestand tegen crashed en de fsck gaat vaak beter en sneller. Dat kun je ook nog overwegen als extra optie.

[XTerm]

man badblocks

[JVaags]

Een journaled filesystem is beter bestand tegen crashed en de fsck gaat vaak beter en sneller. Dat kun je ook nog overwegen als extra optie.

Hoe doe ik dat? En wat doet ie dan precies? Ik kan het in de manpages niet vinden...

[Verwijderd]

Lees deze howto op de site van Redhat even na.

RH7.2 komt standaard met EXT3 als journaling filesystem. Net omdat het gewoon EXT2 is met een journaling systeem, kan je gemakkelijk overschakelen naar EXT3. Ik heb echter nog niet zo veel ervaring met EXT3 (geef mij maar ReiserFS ), maar een aantal van m'n kennissen gebruiken het met goede resultaten.

Enneuh, om je HD's te 'scandisken', daarvoor moeten eerst de partities geunmount worden. Als je alles in een partitie / hebt gezet (bad idea), dan zal je enkel kunnen checken tijdens het booten. man fsck om de optie te vinden die een check tijdens de volgende reboot forceert.

[Verwijderd]

Voor de duidelijkheid:

Voor het controleren van je filesystem gebruik je fsck.
Voor het controleren van de schijf zelf gebruik je badblocks.

[JVaags]

Lees deze howto op de site van Redhat even na.

Heb deze gelezen. Wel grappig ik had eigenlijk nooit de voordelen van ext3 gezien maar ze staan me wel aan Toen ik Redhat 7.2 heb geinstalleerd heb ik er dus maar direct een ext3 van gemaakt en zo te zien is deze saver dan ext2

Maar als ik nu regelmatig fsck draai (bv weekelijks) kan ik dan zo'n plotselinge crash voorkomen?

By the way ik heb nu badblocks gedraaid en het resultaat is (gelukkig ) 0 voor beide schijven...

[Verwijderd]

Op zondag 06 januari 2002 21:36 schreef JVaags het volgende:
Maar als ik nu regelmatig fsck draai (bv weekelijks) kan ik dan zo'n plotselinge crash voorkomen?

Zou me verbazen. Ik denk eerder dat Samba gewoon in de soep is gedraaid. Zou me niet verbazen, want dat ding is echt wel brak, en een hoop vrienden van me hebben er al de meest bizarre foutmeldingen en problemen mee gekregen.

Maar kan je anders wat meer info posten over dat 'wazig' probleem van samba die klaagde dat hij niet in zijn log kon schrijven ? Volges mij zit het probleem ergens bij een te grote log, een log rotate die maar niet lukt of een logfile waar niet in te schrijven is door Samba of iets in die aard.

Enneuh, die filesystemcheck wordt om de 120 dagen automatisch uitgevoerd, en ook na elke 20 reboots of zo. Is eigenlijk volledig overbodig, want zolang er geen 'ungraceful' shutdown was, en de kernel alles uit zijn buffers naar het filesysteem heeft kunnen schrijven voor het unmounten, is er echt weinig dat EXT2/3 kan doen op hol slaan.

[JVaags]

Maar kan je anders wat meer info posten over dat 'wazig' probleem van samba die klaagde dat hij niet in zijn log kon schrijven ? Volges mij zit het probleem ergens bij een te grote log, een log rotate die maar niet lukt of een logfile waar niet in te schrijven is door Samba of iets in die aard.

Helaas nee, ik heb geen info meer. De server is opnieuw ingericht