Re: Fehler von Swappartition

On Wed, May 25, 2005 at 05:40:22PM +0200, Oliver Fromme wrote:
> Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > On Wed, May 25, 2005 at 03:32:36PM +0200, Oliver Fromme wrote:
> > > Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > > > Hier mag es aber nur bedeuten, dass die Platte mit anderen Requests
> > > > derart ausgelastet ist, dass der Request vom swap_pager einfach nur
> > > > lange dauert.
>
> Übrigens 20 Sekunden, wie ich gerade im Source nachgeschla-
> gen habe (src/sys/vm/swap_pager.c). Das ist eigentlich
> schon eine ziemlich lange Zeit.

Ja - das ist lange, aber ein Spin-Up einer Platte kann durchaus
länger dauern - vom reboot eines NFS Servers mal abgesehen.

> > > Das habe ich noch nie erlebt. Es ist anzunehmen, daß Re-
> > > quests des Swap-Pagers mit höchster Priorität behandelt
> > > werden, allein schon um Deadlocks zu vermeiden.
> >
> > Wäre mal eine Überprüfung wert, macht aber wenig Sinn mit hoher
> > Prio zu arbeiten, falls man vorsorglich auslagert.
>
> Es geht hier um Lesezugriffe. Bei denen ergibt es Sinn.

Das macht auch beim Schreiben nicht mehr oder weniger Sinn, da beim
Schreiben schließlich Mechanismen warten müssen, die dafür sorgen, dass
das System genügen Luft hat.
Dann stellt sich aber auch die Frage, warum bei swap_pager und nicht
beim vnode_pager - oder ob man beim vnode_pager zufällig an NFS gedacht
hat?

> > In der Meldung steht ja leider nicht mal ob es ein Schreib- oder
> > Lesezugriff war.
>
> Ein Lesezugriff. Bei Schreibzugriffen können keine solchen
> Fehler auftreten.
>
> > > > Sehr ärglich ist das im mit swap auf NFS, wo es diese Meldungen
> > > > bereits gibt, wenn man nur mal den Server rebootet.
> > >
> > > Das stimmt.
> > >
> > > > Was ich bis jetzt nur nicht weiß ist, ob das als Fehler oder Warnung
> > > > behandelt wird.
> > >
> > > Nach meiner Erfahrung hängen die betreffenden Prozesse nur
> > > und werden nicht etwa gekillt (wie es etwa bei Speicher-
> > > mangel gemacht wird) -- würde ja auch nichts nützen.
> > > Insofern ist es aus Sicht des Swap-Pagers »nur« eine War-
> > > nung.
> >
> > In Anbetracht, dass ich hier ein paar Maschinen habe, die beim
> > reboot des NFS Servers mit einem Panic aussteigen bin ich da sehr
> > ein wenig Sketisch.
> > Der Panic ist sicherlich ein Bug - muss das mal mit einer aktuellen
> > OS Version überprüfen, aber es fällt mir schwer zu glauben, das so
> > ein Bug existieren kann, wenn der betroffene Prozess einfach nur
> > solange blockiert wird.
>
> Der Swap-Pager (swap_pager.c) weiß gar nichts von Prozes-
> sen. Die Pages können ja auch gar nicht eindeutig irgend-
> welchen Prozessen zugeordnet werden.
>
> Das Handling von Prozessen übernimmt der »Page-out Daemon«
> (vm_pageout.c). Der weiß wiederum nichts von Swap-Areas
> und wo sie liegen (lokale Partitionen, NFS oder sonstwas).

Irgendwie kann ich dir nicht ganz folgen.
Natürlich muss der über die Lage nichts wissen - eben dafür hat er
ja einen zugeordneten Pager, wie z.B. den swap_pager.
Außerdem hast du ja bereits selber geschrieben, dass es ums lesen
geht - aufs lesen sollte der Page-out Daemon IMHO niemals warten müssen.
Gelesen wird normalerweise nach einem Page-Fault oder vergleichbarem -
und der Thread, der den Fault ausgelöst hat muss logischerweise auf
den zuständigen Pager warten.

> Der ganze Code ist schon relativ sauber strukturiert. Bei
> der von Dir genannten Panic hätte man anhand des Traces
> vermutlich schon die Stelle recht genau eingrenzen können,
> in der der Bug steckt.

Ich hatte mir das damals nicht genauer angesehen, da die beiden
betroffenen Systeme beim ersten reboot des NFS-Servers schon recht
alt waren und ich demnächst eine updaten wollte.
Dabei ist es Mangels Zeit dann leider auch geblieben.
Nicht zuletzt hätte ich zum testen eine extra Umgebung schaffen müssen,
da auch mein Arbeitsplatzrechner betroffen ist.
Du hast aber recht - der Code ist übersichtlich und die Meldung dürfte
kaum für den Panic verantwortlich sein - es ist wohl eher der Fall,
dass die Meldung und der Panic den gleichen Auslöser haben.
Der kehrt nach der Meldung wieder zum warten zurück - einziger Fehler
ist, dass der v_intrans wiederholt hochzählt, obwohl die Transaktion
bereits gezählt wurde.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message