[RH9] Doorbooten als e2fsck failed

[Olaf van der Spek]

Ik heb een kleine MySQL server met een ext2fs. Omdat de server soms onvrijwillig reboot en ik niet altijd in de buurt ben om te kijken wat er mis is als hij er niet is, wil ik graag dat hij altijd doorboot.
Meestal gaat dit goed, maar laatst niet, omdat hij wachtte op user input na de gefaalde fsck. Welke optie moet ik veranderen om zonder user input verder te gaan?
In een andere thread vond ik /etc/init.d/checkroot.sh, maar dat bestand kon ik niet vinden (op RH9).
Upgraden naar ext3fs wil ik ook (liever) niet.

[MikeN]

Waarom wil je niet naar ext3?

Alles maar even forcen zie ik als nogal gevaarlijk voor je data. En ik heb liever een server die niet start omdat hij nog wat input wil dan een server waar ineens al m'n mysql databases weg zijn omdat fsck dacht dat dat wel kon.

[Valium]

Allereerst: Misschien moet je eens even naar de bak zelf kijken. Dat een servertje spontaan reboot is een zeer slechte situatie wat op den duur je systeem helemaal kan verranzen. Kijk in de logs naar mogelijke problemen.

Om dit op de goede manier te voorkomen: Installeer een journalling filesystem. Die zal veel minder gevoelig zijn voor dit soort problemen. (ext3, reiser, XFS of JFS)

Je kunt in de bootscripts de check forceren, maar dit is iets wat je NIET wilt. Het kan je hele systeem naar z'n grootje helpen.

[Olaf van der Spek]

Valium schreef op 12 december 2003 @ 16:25:
Allereerst: Misschien moet je eens even naar de bak zelf kijken. Dat een servertje spontaan reboot is een zeer slechte situatie wat op den duur je systeem helemaal kan verranzen. Kijk in de logs naar mogelijke problemen.

Om dit op de goede manier te voorkomen: Installeer een journalling filesystem. Die zal veel minder gevoelig zijn voor dit soort problemen. (ext3, reiser, XFS of JFS)

Je kunt in de bootscripts de check forceren, maar dit is iets wat je NIET wilt. Het kan je hele systeem naar z'n grootje helpen.

De server staat in een gedeelde ruimte van een oud studentenhuis. Het is dus een 'externe' oorzaak waar niet veel aan te doen is.

Wat kan er mis gaan als je de check forceert?

MikeN schreef op 12 december 2003 @ 15:46:
Waarom wil je niet naar ext3?

Alles maar even forcen zie ik als nogal gevaarlijk voor je data. En ik heb liever een server die niet start omdat hij nog wat input wil dan een server waar ineens al m'n mysql databases weg zijn omdat fsck dacht dat dat wel kon.

Ik denk dat ik tijdens de install gelezen had dat ext3 langzamer was en omdat het al een trage machine was heb ik voor ext2 gekozen. Kan ik het fs nog converteren zonder reinstall?

[Logic]

quote:
An ext2 filesystem maybe converted to ext3 by creating a journal file on it.
To do this, run tune2fs -j /dev/hdXX

[imdos]

Zoveel langzamer is het niet hoor ... althans niet merkbaar! Scheelt misschien 2 of 3% dacht ik ooit eens te hebben gelezen maar ik kan het mis hebben...

code:

tune2fs -j /dev/hd?

is al genoeg als je ondersteuning voor ext3 in je kernel hebt! Eventueel nog in /etc/fstab van ext2 naar auto of ext3 gaan.

Let wel op dat je een hoeveelheid data kwijt bent door de journaling bestanden

[MikeN]

imdos schreef op 12 december 2003 @ 18:14:
Let wel op dat je een hoeveelheid data kwijt bent door de journaling bestanden

Nee, je bent ruimte kwijt, geen data (Gelukkig niet )

[Valium]

OlafvdSpek schreef op 12 december 2003 @ 18:06:
De server staat in een gedeelde ruimte van een oud studentenhuis. Het is dus een 'externe' oorzaak waar niet veel aan te doen is.

Ah, dat verklaart al een hoop.

Wat kan er mis gaan als je de check forceert?
[...]

Als fouten niet gerepareerd worden (wat gebeurt bij een forced check of , zoals jij het noemt, toch doorstarten wanneer de check foutloopt), worden nieuwe bestanden bijvoorbeeld over oude bestanden geschreven. Of een bestand wat eerst in /usr zat, verplaatst ineens naar /home...etc... je weet niet wat er gaat gebeuren omdat je filesystem gewoon verranst is. Een fs als ext3 biedt daarvoor een prima oplossing. In ieder geval goed genoeg voor een studentenhuis.

Misschien is een regelmatige backup van belangrijke zaken geen overbodige luxe. Een wekelijkse dump van de database bijvoorbeeld. Die zet je dan op een aparte partitie. Als je het doet via een "mount", "dump", "unmount" blijft dat ding veilig staan...ook als je systeem op z'n plaat gaat.

[Olaf van der Spek]

Valium schreef op 13 december 2003 @ 00:30:
Als fouten niet gerepareerd worden (wat gebeurt bij een forced check of , zoals jij het noemt, toch doorstarten wanneer de check foutloopt), worden nieuwe bestanden bijvoorbeeld over oude bestanden geschreven. Of een bestand wat eerst in /usr zat, verplaatst ineens naar /home...etc... je weet niet wat er gaat gebeuren omdat je filesystem gewoon verranst is. Een fs als ext3 biedt daarvoor een prima oplossing. In ieder geval goed genoeg voor een studentenhuis.

Misschien is een regelmatige backup van belangrijke zaken geen overbodige luxe. Een wekelijkse dump van de database bijvoorbeeld. Die zet je dan op een aparte partitie. Als je het doet via een "mount", "dump", "unmount" blijft dat ding veilig staan...ook als je systeem op z'n plaat gaat.

Voor de DB zelf is al bijna geen plaats, laat staan voor een backup. Handmatig maak ik af en toe wel backups naar mijn eigen systeem, maar dat gebeurd eigenlijk niet regelmatig genoeg.

Maar wat kun je nog handmatig repareren na e2fchk dan? De meeste fouten worden door e2fchk zelf al opgelost.

Is het niet mogelijk om ieder geval wel SSHd te starten zodat ik reboot kan doen wat ik eigenlijk lokaal zou doen (eigenlijk toch gewoon op enter drukken)?

[ Voor 9% gewijzigd door Olaf van der Spek op 13-12-2003 14:00 ]