Re(9): 60 tage disc check

60 tage disc check (22 Beiträge, 938 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hallo,

ich besitze Linux in der Version 9.3!
Linux führt bei mir regelmäßig (nach 60 tagen) einen "Disk-Check" durch...! Nun ist meine Frage:
Wie schalte ich diesen ab?

ich bedanke mich wieder an jeden helfenden in diesem Forum und freue mich über jede antwort!

mit freundlichen grüßen

Dave

10.01.2006, 15:11 Uhr - Editiert von -"Dave"-, alte Version: hier

Re: 60 tage disc check (Raydoo am 10.01.2006, 15:24:33)

Re(2): 60 tage disc check (-"Dave"- am 10.01.2006, 15:28:26)

Re(3): 60 tage disc check (Raydoo am 10.01.2006, 15:33:39)

Re(3): 60 tage disc check (sharky2 am 10.01.2006, 18:51:47)

Re: 60 tage disc check (hariw am 10.01.2006, 15:29:37)

Re(2): 60 tage disc check (gepeinigter_aon_neukunde am 10.01.2006, 16:06:33)

Re(3): 60 tage disc check (Robe am 11.01.2006, 17:21:10)

Re(4): 60 tage disc check (gepeinigter_aon_neukunde am 13.01.2006, 13:11:59)

Re(5): 60 tage disc check (Robe am 13.01.2006, 16:37:41)

Re(6): 60 tage disc check (gepeinigter_aon_neukunde am 13.01.2006, 23:19:44)

Re(7): 60 tage disc check (Robe am 15.01.2006, 18:31:20)

Re(8): 60 tage disc check (gepeinigter_aon_neukunde am 15.01.2006, 19:55:57)

Ich war gewillt mein reply jetzt auch mal mit "Nochmal" einzuleiten, lass es jetzt aber doch.

In dem Posting [1] hat Theodore T'so darauf hingewiesen, dass diese Beobachtungen von einem SGI-Entwickler gemacht wurden. Wenn du das anzweifelst bzw. als Schwachsinn abtun möchtest kannst du ihn gerne kontaktieren, ich bin mir sicher, dass er dir den betreffenden Mailverkehr forwarden kann bzw. eine Kontaktadresse der betreffenden Person geben kann. Den Power fail interrupt gibt es jedenfalls bei IRIX: [2]. Ich maße mir jedenfalls nicht an, genug wissen über die Vorgänge zu haben, um diesbezüglich irgendwelche Wahrscheinlichkeiten treffen zu können, ich kanns höchstens testen.

Deinen Ausführungen über Reordering, Lügen der ext3-Developer und sonstiger "crap"-Aussagen konnte ich nur bedingt folgen, kann dir aber keine definitiven Antworten geben da ich mich mit der Materie nicht gut genug auskenne.

Wenn ich Theodore T'so richtig verstanden habe, ist das Haupt"problem" von reiser und xfs, das sie mehrere Inode-Aktualisierungen in einen Journal-Block (viele aktualisierungen in 512 Byte) schreiben, wohingegen ext3 einfach die aktualisierten Blöcke als solches komplett (512 Byte (oder mehr) pro Aktualisierung) ins Journal schreibt. Es macht schon einen Unterschied ob bei einem Crash mit einem "verdampften" Block 1 Update oder 3-5 Updates (weiss nicht wieviel Updates reiserfs in einen Block reinbringt) verloren gehen.

Ad Polemik:
Das mit dem resizen war keine Polemik, sondern ein Fakt, und das hab ich auch nicht bemängelt. Mir gings um deine Aussage, dass "nicht mal ext3 Entwickler ext3 vertrauen würden, weils ja ein funktionierendes e2fsck gibt". Das ist einfach nurmehr Schwachsinn.

Da würde sich dann "Reiserfs ist total super, weil für das gibts kein gscheits fsck [3], weils ja nicht gebraucht wird!" nahtlos einreihen

Ad [bp]dflush:

Der hat damals (2.4) wie heute ein commit intervall von 5 sekunden als Standardwert, siehe /proc/sys/vm/dirty_writeback_centisecs bei modernen Kernel.

Ad journalling:

Nochmal: (jetzt aber! ha!)

Du gewinnst bei Journalling genau die Zeit fürs fsckn. Sonst nix. Überhaupt nix. Dateien/Directories die in einem kritischen Zeitpunkt angelegt wurden können sowohl beim Journalling fs als auch beim "nicht journalling fs aber fsck nach dem crash" da sein _ODER_ nicht. (oder ein bisschen, wenn man sehr viel pech hat)

Viel wichtiger ist (zumindestens in meiner Wahrnehmungssphäre, bei "fundamentalistischen" usern schaut das anscheinend etwas anders aus) was mit dem Inhalt von Dateien passiert:

Bei ext2 [6], ext3 mit data=writeback und reiser3 hast du in den Dateien die schreibend geöffnet waren mit hoher Wahrscheinlichkeit Müll drinnen.[4] (Ich sag nur ^@^@^@ [5])

Bei ext3 mit data=ordered (default mode) hast du entweder den Zustand vor oder nach dem Write.

Ad nichtjournalling:

Vielleicht ist das einfach nur das Verständnigsproblem: Natürlich mach ich auf den Servern auf denen ich kein journalling FS verwende nach jedem Crash ein fsck. Und auf Servern mit journalling ist ein


Jan 11 10:20:13 mirror kernel: EXT3-fs: md11: orphan cleanup on readonly fs
Jan 11 10:20:13 mirror kernel: ext3_orphan_cleanup: deleting unreferenced inode 360361
Jan 11 10:20:13 mirror kernel: ext3_orphan_cleanup: deleting unreferenced inode 360352
[..]
Jan 11 10:20:13 mirror kernel: EXT3-fs: md11: 14 orphan inodes deleted
Jan 11 10:20:13 mirror kernel: EXT3-fs: recovery complete.
Jan 11 10:20:13 mirror kernel: EXT3-fs: mounted filesystem with ordered data mode.

oder


Dec 21 01:16:45 mirror kernel: ReiserFS: md0: checking transaction log (md0)
Dec 21 01:16:45 mirror kernel: ReiserFS: md0: replayed 20 transactions in 3 seconds
Dec 21 01:16:45 mirror kernel: ReiserFS: md0: Using r5 hash to sort names

genauso "dramatisch" wie:


e2fsck 1.36 (05-Feb-2005)  
/dev/hda9 was not cleanly unmounted, check  
forced.  
Pass 1: Checking inodes, blocks, and sizes  
Inode 12, i_blocks is 16, should be 2.  Fix? yes  
 
Pass 2: Checking directory structure  
Entry '0003' in / (2) has deleted/unused inode 13.  Clear? yes  
 
Pass 3: Checking directory connectivity  
Pass 4: Checking reference counts  
Pass 5: Checking group summary information  
Block bitmap differences:  -21  
Fix? yes  
 
Free blocks count wrong for group #0 (38, counted=39).  
Fix? yes  

[..]

/dev/hda9: ***** FILE SYSTEM WAS MODIFIED  *****  
/dev/hda9: 12/16 files (0.0% non-contiguous), 21/60 blocks

Genau überhauptnicht.

mfg,
michael - der sich wünschen würde weitere diskussionen darüber in persona zu führen, da das hier zunehmend anstrengend wird.

[1] vielleicht hast du nur den Link verloren? Hier nochmal: http://linuxmafia.com/faq/Filesystems/reiserfs.html

[2] SIGPWR/19 http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/cat5/signal.z

[3] Hans Reiser und fsck. http://lkml.org/lkml/2005/6/24/192 Lesenswerter Thread.

[4] http://www.uwsg.iu.edu/hypermail/linux/kernel/0109.3/0335.html + http://www.uwsg.iu.edu/hypermail/linux/kernel/0109.3/0654.html

[5] http://lists.debian.org/debian-user/2005/03/msg01735.html

[6] muss ich zugeben, wusste ich nicht, wär mir aber in der Zeit in der ich ext2 verwendet hab nicht aufgefallen.

Google-Pagerank-Abuseage:
mirror
random crap
slackware mirror

Re(10): 60 tage disc check (gepeinigter_aon_neukunde am 15.01.2006, 23:06:01)

Re(2): 60 tage disc check (-"Dave"- am 10.01.2006, 15:36:52)

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung