Kernel-Meldung blockiert Alles (vs-3050)

[NiceDay]

Moin.
Habe mal wieder nen besonders harten Fall hier, unzwar tritt beim kopieren (einige GB's) von ner Partition zu einer anderen, die auf ner anderen Platte liegt nach ner gewissen Zeit dann plötzlich das auf :

vs-3050: wait_buffer_until_released: nobody releases buffer (dev 22:42, size 4096, blocknr 9011200, count 3, list 0, state 0x10019, page c1a41980, (UPTODATE, CLEAN, UNLOCKED)). Still waiting (1680000000) JDIRTY !JWAIT
vs-3050: wait_buffer_until_released: nobody releases buffer (dev 22:42, size 4096, blocknr 9011200, count 3, list 0, state 0x10019, page c1a41980, (UPTODATE, CLEAN, UNLOCKED)). Still waiting (1710000000) JDIRTY !JWAIT
vs-3050: wait_buffer_until_released: nobody releases buffer (dev 22:42, size 4096, blocknr 9011200, count 3, list 0, state 0x10019, page c1a41980, (UPTODATE, CLEAN, UNLOCKED)). Still waiting (1740000000) JDIRTY !JWAIT

usw. usw. das hat kein Ende, Reboot nicht möglich gar nix möglich nur da weiterarbeiten wo man gerade ist, neue Programme starten auch nimmer möglich.
Was bleibt ist ein starker Druck auf den Powerbutton vom PC, Ende.

Ich will das nimmer, wie bekomm ich das weg und kann vernünftig so wie in alten Zeiten ganz normal kopieren?!

- keine neue Modifikationen am Kernel gemacht
- kein spezielles Kopierkommando, lediglich normal per mc
- keine große Hintergrundbelastung am laufen wie Encoding o.ä.
- Quell-FS: FAT32
- Ziel-FS: ReiserFS (evtl. liegt da auch der Hund begraben, hab grad nen fsck gemacht und der hat ne ganze Ecke lang nur Fehler korregiert...)

 

[devilz]

Lags nun am ReiserFS ?
Ging es nach dem fsck wieder ?

 

[DennisM]

Hast du die Fehler mit reiserfsck --rebuild-tree behoben?

MFG

Dennis

 

[NiceDay]

Hast du die Fehler mit reiserfsck --rebuild-tree behoben?

Ja habe ich nach Aufforderung, hat knapp 20-30Mins mind. gedauert...
Danach nochmal versucht zu kopieren und dann ging es, was mich aber stutzig gemacht hat und ich auch ziehmlich nervend fand, war das er nach 4od 5 Dateien immer erst ne ganze Ecke noch auf das Ziel wohl warten musste bis die andere Part. also die neuen Daten erstmal verarbeitet hatte.
Kann ich das darauf zurückführen das FAT32 schneller ist als Reiser ?

 

[Zico]

Hmm weiss nicht, ob FAT schneller oder langsamer ist, als Reiser, aber vllt könntest du ja mal - lediglich um auf der sicheren Seite zu sein - ein badblock check durchführen.

 

[NiceDay]

Ja, hast Recht mit dem BB-Check. Aber, naja, also das sind knapp 44G das kann dauern habsch die ganze Zeit keine Musik :'-(
Naja muss ich mir halt das Zeugs von der externen Platte anhören.
Theoretisch (nur mal wieder eine von meinen verwirrten Theorien) könnte es ja sein das Reiser langsamer ist, da es mit nem Journal arbeitet und FAT nicht.

 

[Zico]

Naja "it's better to be safe, than sorry"
Zu den Geschwindigkeiten.. naja: Wesentliche Geschwindigkeitsunterschiede sollte es eigentlich nicht wirklich geben.
Ich beobachte meistens beim kopieren über den Konqueror, dass es bei großen Dateien/dateimengen, dass der Transfer oft "stehen bleibt" und dann später weitermacht. bei cp habe ich das bishe rnoch nicht gemerkt, wodurch is es auf den Konqeror schiebe.
Andernfalls kannst du ja mal sehen, ob mit DMA alles in ordnung ist ... nur zur Sicherheit. kann ja immer mal was sein, was man nicht vermuten würde. Andernfalls würde ich vermusten, dass es einfach daran liegt, dass du von einer, zur anderen Partition kopierst. Je nachdem wie die Sektoren auf der platte unterteilt sind, ist es natürlich klar, dass die platte erstmal die Daten einliest und sie dann schreibt.
Versuch doch mal Daten von einer DVD auf deine Reiser zu kopieren. Dann dürfte zumindest dieser Effekt des "Aussetzns" verschwinden...
sind jetzt alles nur wilde Lösungsansätze, aber vllt hilft dir ja irgendwas.

 

[NiceDay]

ndo:/sbin# badblocks -s /dev/hdh2
Suche nach defekten Blöcken (Nur-Lesen-Modus):454800125451968/ 45480015
45480013
45480014
erledigt

Was genau bringt mir das jetzt und wie verfahre ich da weiter ?
(habe keine andere Möglichkeit gefunden nach BB zu checken, dieses fsck.reiser4 bietet das irgendwie nicht an)

 

[liquidnight]

- keine neue Modifikationen am Kernel gemacht
- kein spezielles Kopierkommando, lediglich normal per mc
- keine große Hintergrundbelastung am laufen wie Encoding o.ä.
- Quell-FS: FAT32
- Ziel-FS: ReiserFS (evtl. liegt da auch der Hund begraben, hab grad nen fsck gemacht und der hat ne ganze Ecke lang nur Fehler korregiert...)

hi,
ich würde dir empfehlen, die reiserfs-partition einzuebnen und ein anderes dateisystem zu verwenden. hatte reiserfs vor 2a mal in betrieb, da wars noch net stabil genug. hatte es vor nem 3/4 a bis vor 2 monaten nochmal in betrieb, war immer noch net stabil. dabei war ich komplett auf dem gentoo stable stand, auch das kernel. reiserfs gibt beim unmounten zu wenig acht, dass die partition sauber ist. in der doku steht auch, dass man eine komplette datensicherung vor dem rebuild machen soll, bei der gelegenheit hab ich die partition gleich geplättet. meine empfehlung: wenn du auf stabilität achtest, nimm ext2-j oder ext3.

mein kernel wurde wegen der reiserfs-partition auch unstabil, aber halt nur in bestimmten situationen. sah ähnlich aus wie bei dir :-)

ich hab für den zweck, für den ich die reiser-partition am laufen hatte, jetzt mal xfs am laufen. noch nicht arg lang, schaumermal wie stabil es sich verhält. bisher hab ich noch keine instabilitäten durch agressiven caching erlebt, selbst bei reboot ohne shutdown nicht.

 

[NiceDay]

Ja xfs... hab ich auch in benutzung - ohne Probs - auf ner anderen Part.
Warum habe ich überhaupt Reiser genommen? Weil ich dachte, dass ich evtl. nochmal an der Part.-Größe was machen muss sprich vergrößern etc. und mit Reiser geht das glaube ich ganz locker, was man von ext2/3/xfs nicht behaupten kann, da darf man dann erstmal gleich die ganze Part. neumachen.
Sowas wie ext2resize etc. ist ja doch ziehmlich frickelig - wenn es denn mal richtig funzt...

 

[DennisM]

Kann man einen Geschwindigkeitsvorteil bei XFS feststellen. Ich habe auch schon mit dem Gedanken gespielt XFS einzusetzen.

MFG

Dennis

 

[NiceDay]

Zur xfs-Geschw. kann ich nicht viel sagen, da ich es nur auf der externen nutze und die Übertragung ist ja dank USB2 sowieso etwas eingeschränkter als lokal.
Genaue Tests oder Daten kann ich jetzt auch nicht nennen.

 

[liquidnight]

Kann man einen Geschwindigkeitsvorteil bei XFS feststellen. Ich habe auch schon mit dem Gedanken gespielt XFS einzusetzen.

MFG

Dennis

mir ist bisher noch nichts aufgefallen. auf meiner xfs partition (unter /mnt/scratch ) hab ich alles temporäre zeugs, compiler cache, bilder cache, sound cache, tmp-verzeichnisse, massig kleinkram, kernel, portage-tmp usw.

evtl. ist es bei vielen kleinen dateien minimal langsamer, aber so richtig ist mir das noch net aufgefallen, weil die prozesse, die da drauf rödeln (diverse scripte, + emerge + make usw ...) lass ich eigentlich immer mit nice -n 10 laufen und da is es mir egal wie lang sie laufen.