file system check automatisieren

cron regelt solche regelmäßigen Jobs und der Checker slebst ist fsck.ext3

HJS

hjs

Vielleicht liege ich ja falsch, aber für einen fsck darf die Partition nicht oder nur read only gemountet sein. Wie machst Du das dann mit cron?

Hallo !

Ab der nächsten Version von LinVDR (0.7) soll der Filecheck standardmässig beim Herunterfahren durchgeführt werden.

Wann diese Version kommt ist dann die nächste Frage.

Vermutlich erst nach der nächsten VDR-Stable-Version...

Geuß,

Sascha

Einfach ein Script schreiben, dass folgenden Befehl enthaelt:

mount -no remount, ro /
fsck.ext3
mount -no remount, rw /

Per Cronjob aufrufen, fertig.

Bye, Klaus

Ja schön,

aber wenn der Cron Job während einer Aufnahme oder einem sonstigen Schreibzugriff kommt wird es mit Sicherheit krachen.

Dann lieber in die poweroff.pl...

Servus,

... das hatten wir doch alles schon mal. Warum benutzt du nicht einfach tune2fs, um auf einen fsck pro Monat statt alle 25 mounts umzuschalten?

Ansonsten, in der poweroff.pl hat das ganze nichts zu suchen, sondern sinnvollerweise in der rcShutdown:

#!/bin/bash
ROOTDISK=/dev/hda1


PATH=/sbin:/bin:/usr/sbin:/usr/bin
export PATH


# VDR stoppen
/etc/init.d/runvdr stop
sleep 1
killall -9 vdr 2>/dev/null
sleep 1


rm -fr /var/cache/ramdisk/* 2>/dev/null
rm -fr /vtx/* 2>/dev/null
cp -a /ramdisk/* /var/cache/ramdisk


killall() {
  SIG=$1
  shift
  kill $SIG $@ 2>/dev/null
}


OURPID=$$
INITPID=`ps -C init -o "%p" | tail -n 1`
PIDS=`ps axo "%p" | grep -vw PID | grep -vw 1 | grep -vw "$INITPID" | grep -vw "$OURPID"`


killall -15 $PIDS
sleep 1
killall -9 $PIDS
sleep 1


umount -a -r


# Vorgezogener fsck, falls ein fsck innerhalb der nächsten 24h ansteht
NextFsck=`tune2fs -l $ROOTDISK | grep "Next check after" | cut -d":" -f2-`


if [ `date -d "$NextFsck" +%s` -lt $[`date +%s`+86400] ]; then
  touch /etc/mtab
  if [ $? -eq 0 ]; then
    echo "root fs still mountet, skipping fsck!"
  else
    echo "Running fsck in advance"
    fsck -y -f $ROOTDISK
    echo "fsck done"
  fi
else
  echo "No fsck needed" >/dev/tty1
fi

Du musst dann noch das Busybox-Grep gegen das Original austauschen, fertig.

Viele Grüße, Mirko

Zitat

Original von Scorp
aber wenn der Cron Job während einer Aufnahme oder einem sonstigen Schreibzugriff kommt wird es mit Sicherheit krachen.

Da haste leider wahr
Das aktive Laufwerk wird sich zwar nicht remounten lassen , sondern der Befehl kommt mit ner Fehlermeldung , aber leider wird die vorangegangene Fehelrmeldung den folgenden fsck nicht daran hindern , seinen Check auf der gemounteten Partition zu fahren - Ergebnis i.d.R.

Wäre allerdings ne Variante , ( sofern /video(0) ne eigene Partition ist ) , die Partition zu umounten , die Existenz eines Files in /video(0) zu prüfen , wenn ja , isse gemountet und der Check darf nicht gefahren werden , wenn nein isse nicht gemountet und der Check kann gefahren werden .

Wär halt ne Alternative ...

HJS

cooper

Von mir aus auch in der rcShutdown.

hjs

Ist es nicht so das ein fsck bei einer gemounteten Partition gar nicht funktioniert?

Scorp : Dann würde deine Aussage , daß es bei aktiven Aufnahmen kracht , nicht den Tatsachen entsprechen

Aber damit hast du recht - es ist mehr als sinnig , fsck NICHT auf ein gemountetes fs loszulassen - es sei denn , man sucht nen Grund die Partition mal endlcich wieder zu formatieren

Zumindest ist das mein Kenntnisstand - stammt von irgendwo hier ausm Board- frag mich nich wo .

HJS

hjs

Ich hatte mal eine gemountete Partition in Knoppix. Darauf hab ich ein fsck losgelassen und wenn ich micht recht entsinne gabs da ne Fehlermeldung. Ich lege aber keinen gesteigerten Wert darauf das auszuprobieren...

Hallo,

nach der Selbsteinschätzung von xfs ist ein Filesystemcheck dort unnötig. Wäre das vielleicht ein Grund, auf xfs umzusteigen? (Bitte nicht schlagen, Cooper :))

Heissduscher

Also ich fahre schon seit ca. 2Jahren mit Reiserfs einwandfrei. Dort gibt es das fsck nicht mehr weil Journaling Filesystem. Das war für mich ein Quantensprung. Und ich kann euch sagen ich habe viele Netzstecker einfach so im laufenden Betrieb gezogen ohne das es jemals ein Problem gab.

Also ich bin davon begeistert und würde nichts anderes mehr auf meine Platten lassen

Gruss,

Jörg

Zitat

Original von Scorp
Ich hatte mal eine gemountete Partition in Knoppix. Darauf hab ich ein fsck losgelassen und wenn ich micht recht entsinne gabs da ne Fehlermeldung. Ich lege aber keinen gesteigerten Wert darauf das auszuprobieren...

Wieso denn nicht ? Keine Daten , die mal langsam vorm Verstauben gerettet werden müssen ?

HJS

Zitat

Original von hjs
Wieso denn nicht ? Keine Daten , die mal langsam vorm Verstauben gerettet werden müssen ?

Hehe- danach müßten sie gerettet werden, ja

Aber zurück zum Thema, Faktensammlung:

1. Der Filesystemcheck stört einfach. Habe ich gerade heute durch, meine lokale 40er Platte wollte unbedingt checken- bis mir das klar wurde, was da läuft, hatte ich auch schon den Monitor angeschleppt und angeklemmt
2. Ja, man kann ihn mittels tune2fs hinauszögern, sollte ihn aber nicht komplett deaktivieren.
3. Im laufenden System auf der /- Partition einen fsck laufen zu lassen ist definitiv KEINE gute Idee- es sei denn, man will seine Datensicherung überprüfen!
4. Evtl. gibts einen Weg über die rcShutdown, ist aber wohl erst für die 0.7er vorgesehen- wenn überhaupt
5. Es gibt Journaling- Filesysteme (reiser, ext3, xfs,jfs etc.), bei denen tritt das Problem systembedingt nicht auf.

Lösungsmöglichkeiten:
1.
Es ist zu empfehlen, die /- Partition deutlich zu verkleinern und von /video und auch /pub zu befreien. Das geht auch mit LinVDR wunderbar- allerdings sollte man dafür dann mal ein Knoppix einsetzten und wissen, was man tut. Stichwort: resize2fs sowie entsprechende Partitionstools.
=> Der fsck kommt immer noch, geht auf / aber wesentlich schneller- und die anderen Partitionen kann man dann im laufenden Betrieb umounten und manuell checken.
2.
Keinen fsck (mittels tune2fs).
=> Es ist halt immer schneller, könnte aber auch (theoretisch!) zu Dateninkonsistenzen kommen. Eigene Entscheidung, wie wichtig die Daten sind.
3.
LinVDR ein JournalingFS beibringen und damit erweitern. Bin gerade nich an meinem VDR, kann nicht prüfen, ob der LinVDR (05./0.6) das ext3 unterstützt, vermute nicht. Dann muß man ein Woody aufsetzen und sich einen eigenen Kernel damit backen.
=> Die perfekte Lösung, aber mit deutlichem Aufwand, insbesondere der Entwicklungsumgebung verbunden. Schön wäre es, wenn zumindest ext3 schon fest im Kernel drinnen wäre, dann hätte man das Problem gleich garnicht. tune2fs -j /dev/hda1 und gut iss.....
[EDIT] Kommt davon, wenn man nicht am VDR sitzt. Der hat jat ext3 drauf! Also:
streiche Punkt 3 ersatzlos.
[/EDIT]

Fazit:
Mache jeder was er will, aber er möge aufhören zu nörgeln

Servus,

Zitat

Also ich fahre schon seit ca. 2Jahren mit Reiserfs einwandfrei.

Da hast du aber Glück gehabt.

Zitat

Dort gibt es das fsck nicht mehr weil Journaling Filesystem.

Ext3 ist genauso ein Journaling-FS, nur guckt es eben hin und wieder mal komplett nach den Daten. Das ist ein Vorteil, kein Nachteil, weil so entdeckst du ein fehlerhaftes Journal überhaupt erst. Der Standard-Wert von 25-30 mounts zwischen den Checks ist für normale Desktop-Systeme gedacht, die einmal pro Tag gestartet werden -- er checkt also einmal im Monat. Bei VDR passiert das natürlich öfter, weil die Kiste eben 4-5 mal am Tag bootet. Deshalb ja auch die Verlängerung der Zyklen auf definitiv einmal pro Monat statt abhängig von den mount-counts. LinVDR 0.6 deaktiviert übrigens den Mount-Count automatisch nach Formatieren der Platte (was bei einem Update ja nicht passiert). Ich gehe mal davon aus, dass du dein Dateisystem noch nicht auf ein check pro Monat umgestellt hast.

Zitat

ohne das es jemals ein Problem gab.

Nun, ich habe bereits zwei Datenpartitionen wegen ReiserFS verloren, weil infolge einmal eines Absturzes und einmal eines Festplatten-Defekts keinerlei Zugriff auf das FS mehr möglich war. Ein reiserfsck anschließend war sehr gründlich, ich hätte genauso gut "badblocks -w" nehmen können, das wäre vielleicht sogar schneller gegangen.

Überspitzt formuliert gibt es für mich nur einen Unterschied zwischen Reiser-FS und /dev/null: Bei /dev/null weißt du wenigstens sicher, dass deine Daten weg sind

Also, ich habe schlechte Erfahrungen mit Reiser-FS gemacht (und ein paar andere ja nun auch), weshalb mir kein Reiser-FS bei LinVDR in die Tüte kommt. XFS kenne ich nicht gut genug, als dass ich ihm meine Daten anvertrauen würde. Also bleiben nur noch Ext2 und Ext3. Wobei Ext3 den Vorteil hat, jederzeit (auch bei fehlerhaftem Journal) als Ext2 gemountet zu werden -- was z.B. bei einem Backup nach Plattenfehler sehr hilfreich ist, weil er nicht erst versucht, das Journal wieder zu korrigieren und dabei auf defekte Bereiche der Platte zuzugreifen.

Zitat

Also ich bin davon begeistert und würde nichts anderes mehr auf meine Platten lassen

Also ich lasse ReiserFS bis auf weiteres nicht an irgend welche wichtigen Daten. Selbst meine Test- und Benchmark-Ergebnisse speichere ich lieber auf einem Ext2.

Mit einem fsck pro Monat, vorzugsweise beim Runterfahren ausgeführt, kann ich sehr gut leben. Das sind mir meine Daten wert.

Viele Grüße, Mirko

Zitat

Original von knebb
Fazit:
Mache jeder was er will, aber er möge aufhören zu nörgeln

Warum so ausführlich , wenns auch so kurz , knapp und treffend geht ?!

HJS