[gentoo-user-de] Dateisystem für Portage-Tree

[gentoo-user-de] Dateisystem für Portage-Tree

[Jens Meißner]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

Hallo Gruppe,

das Gentoo-Wiki [1] empfiehlt, für den Portage-Tree Reiser4 als
Dateisystem zu verwenden. Im Gegensatz zu ext3 ist wirklich ein
Unterschied zu spüren. Reiser4 hat allerdings den Nachteil, das man
jeden Kernel vorher von Hand patchen muss, wozu ich nicht wirklich Lust
habe. Wie sieht es mit den anderen im Kernel vorhanden Dateisystem aus?
Bringen ext4 oder xfs eine ähnliche Performance wie Reiser4? Welches
Dateisystem empfiehlt sich für einen solchen Zweck?

Gruß
Jens

-- 
[1] http://de.gentoo-wiki.com/wiki/Emerge_beschleunigen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Bernd Wurst]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

Hallo.

Am Freitag 15 Mai 2009 12:26:00 schrieb Jens Meißner:
> Reiser4 hat allerdings den Nachteil, das man
> jeden Kernel vorher von Hand patchen muss, wozu ich nicht wirklich Lust
> habe. Wie sieht es mit den anderen im Kernel vorhanden Dateisystem aus?
> Bringen ext4 oder xfs eine ähnliche Performance wie Reiser4? Welches
> Dateisystem empfiehlt sich für einen solchen Zweck?

ReiserFS 3. ;-)

Also ReiserFS im Ganzen hat ja zu Recht einen sehr zweifelhaften Ruf. Wer noch 
nie damit Probleme hatte, kann sich glücklich schätzen, aber wenn was kaputt 
geht ist meist alles weg.
Im Gegenzug dazu ist Reiser bei vielen kleinen Dateien um Längen schneller als 
alles andere was ich bisher je getestet habe.

Für /usr/portage mit seinen vielen kleinen Dateien und mit komplett 
unwichtigen weil einfach restaurierbaren Daten ist es also optimal.

Die Version spielt dabei eine untergeordnete Rolle, wenn man einen Kernel 
einsetzt, der von sich aus kein Reiser4 kann, nimmt man halt Reiser3.

Gruß, Bernd

-- 
Hilf einem Freund in der Not,
und er wird sich an dich erinnern,
wenn er wieder in Not ist!


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Jens Meißner]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

Am Fri, 15 May 2009 13:14:09 +0200
schrieb Bernd Wurst <bernd@bwurst.org>:

> Hallo.
> 
> Am Freitag 15 Mai 2009 12:26:00 schrieb Jens Meißner:
>> Reiser4 hat allerdings den Nachteil, das man
>> jeden Kernel vorher von Hand patchen muss, wozu ich nicht wirklich
>> Lust habe. Wie sieht es mit den anderen im Kernel vorhanden
>> Dateisystem aus? Bringen ext4 oder xfs eine ähnliche Performance
>> wie Reiser4? Welches Dateisystem empfiehlt sich für einen solchen
>> Zweck?
> 
> ReiserFS 3. ;-)
> 
> Also ReiserFS im Ganzen hat ja zu Recht einen sehr zweifelhaften Ruf.
> Wer noch nie damit Probleme hatte, kann sich glücklich schätzen, aber
> wenn was kaputt geht ist meist alles weg.
> Im Gegenzug dazu ist Reiser bei vielen kleinen Dateien um Längen
> schneller als alles andere was ich bisher je getestet habe.
> 
> Für /usr/portage mit seinen vielen kleinen Dateien und mit komplett 
> unwichtigen weil einfach restaurierbaren Daten ist es also optimal.
> 
> Die Version spielt dabei eine untergeordnete Rolle, wenn man einen
> Kernel einsetzt, der von sich aus kein Reiser4 kann, nimmt man halt
> Reiser3.

Was mir zu denken gibt, sind folgende zwei Dinge:
- "Warnung: Die Performance von ReiserFS3 verschlechtert sich mit jedem
Update des Portage Trees." (Gentoo-Wiki)

- "Viele Entwickler schätzen XFS leistungsfähiger als ReiserFS
  ein." (Wikipedia)

Demnach scheint mir ReiserFS3 nur bedingt geeignet. Wie sieht es denn
eigentlich mit der Performance von ext4 bei kleinen Dateien aus, die
soll ja besser sein als die von ext3, aber im Vergleich zu ReiserFS?

Gruß
Jens

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Christian Stern]

> Demnach scheint mir ReiserFS3 nur bedingt geeignet. Wie sieht es denn
> eigentlich mit der Performance von ext4 bei kleinen Dateien aus, die
> soll ja besser sein als die von ext3, aber im Vergleich zu ReiserFS?

Diese Frage kann dir das Internet sehr gut beantworten. Wenn man nach
"benchmarks" sucht findest du unzählige Berichte von Person auf
unterschiedlichen Systemen, die auch auführliche Statistiken führen.

Teste doch einfach selbst aus?

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Bernd Wurst]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

Hallo.

Am Freitag 15 Mai 2009 14:49:24 schrieb Jens Meißner:
> Was mir zu denken gibt, sind folgende zwei Dinge:
> - "Warnung: Die Performance von ReiserFS3 verschlechtert sich mit jedem
> Update des Portage Trees." (Gentoo-Wiki)

Ich synce zwar nicht oft, kann das aber bisher nicht spürbar bestätigen.


> - "Viele Entwickler schätzen XFS leistungsfähiger als ReiserFS
>   ein." (Wikipedia)

"leistungsfähiger" kann alles bedeuten. Bei größeren Dateien soll XFS 
wesentlich besser sein.

Meiner Erfahrung nach ist XFS bei Schreiboperationen im Dateisystem sehr 
speicherhungrig. Auf einem Server hatten wir mal XFS wegen der eleganten 
Quota-Mechanismen. Haben wir schnell wieder abgeschafft, weil mehrere hundert 
MB für den Dateisystem-Treiber war dann doch etwas viel.

Bei vielen Zugriffen auf kleine Dateien habe ich bisher sehr schlechte 
Erfahrungen mit XFS gemacht.


> Demnach scheint mir ReiserFS3 nur bedingt geeignet. Wie sieht es denn
> eigentlich mit der Performance von ext4 bei kleinen Dateien aus, die
> soll ja besser sein als die von ext3, aber im Vergleich zu ReiserFS?

Probier's aus und erzähl uns darüber. ;-)

Gruß, Bernd

-- 
Only one book has been printed in more copies than The Bible...
...the IKEA catalogue  -  Song "Facts of Life" by "Lazyboy"


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[David Saro]

Hallo,

Am Freitag, 15. Mai 2009 schrieb Jens Meißner:
> Was mir zu denken gibt, sind folgende zwei Dinge:
> - "Warnung: Die Performance von ReiserFS3 verschlechtert sich mit jedem
> Update des Portage Trees." (Gentoo-Wiki)

Das ist doch bestimmt auf die Fragmentierung zurückzuführen, oder? Kann man 
das nicht mit dem Tool sys-fs/shake in den Griff bekommen?

LG David

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Benedikt Gievert]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Am Fri, 15 May 2009 12:26:00 +0200
schrieb Jens Meißner <meissnerj@temporaryforwarding.com>:

> Hallo Gruppe,
> 
> das Gentoo-Wiki [1] empfiehlt, für den Portage-Tree Reiser4 als
> Dateisystem zu verwenden. Im Gegensatz zu ext3 ist wirklich ein
> Unterschied zu spüren. Reiser4 hat allerdings den Nachteil, das man
> jeden Kernel vorher von Hand patchen muss, 

Hmm, ich habe hier Reiser4 als /  ;
die zen-sources (aus dem zen-overlay) laufen hier seit einiger Zeit
(Jahre?) stabil und bringen den reiser4-patch gleich mit.
Auch die hitchhiker-sources haben den Patch ;)

Gruß
Benedikt

-- 
Bewusstsein und Geist sind nicht notwendigerweise dasselbe. Nicht jeder,
der keinen Geist hat, ist auch bewusstlos...


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Jens Meißner]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

Am Fri, 15 May 2009 15:05:27 +0200
schrieb Bernd Wurst <bernd@bwurst.org>:

> Am Freitag 15 Mai 2009 14:49:24 schrieb Jens Meißner:
>> - "Viele Entwickler schätzen XFS leistungsfähiger als ReiserFS
>>   ein." (Wikipedia)
> 
> "leistungsfähiger" kann alles bedeuten. Bei größeren Dateien soll XFS 
> wesentlich besser sein.

Da es mir aber um kleine geht...
 
> Meiner Erfahrung nach ist XFS bei Schreiboperationen im Dateisystem
> sehr speicherhungrig. Auf einem Server hatten wir mal XFS wegen der
> eleganten Quota-Mechanismen. Haben wir schnell wieder abgeschafft,
> weil mehrere hundert MB für den Dateisystem-Treiber war dann doch
> etwas viel.

Das hört sich kontraproduktiv an.

>> Demnach scheint mir ReiserFS3 nur bedingt geeignet. Wie sieht es
>> denn eigentlich mit der Performance von ext4 bei kleinen Dateien
>> aus, die soll ja besser sein als die von ext3, aber im Vergleich zu
>> ReiserFS?
> 
> Probier's aus und erzähl uns darüber. ;-)

Nun gut, XFS fällt dann wohl weg, Hauptspeicher kann ich auch anders
ganz gut verwenden...
Dann wären noch ext4 und Reiser4... Naja ich werde mal was ausprobieren
und euch dann das Ergebnis erzählen...

Bis später
Jens

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Jens Meißner]

[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]

Mein Test zur Eignung von Dateisystem zum Speichern des Portage-Trees.
Ablauf:
- Anlegen des Dateisystems
- Entpacken eines älteren Portage-Snapshots (8 Tage alt)
- Updaten des Portage-Trees (Server per Fast-Ethernet angebunden)
- Ausführen von update-eix.
- Suchen von Paketen, welche geupdated werden müssen. (emerge -DuNpv
@world)

Ext3:
=====
Entpacken: real 1m40.642s, user 0m20.037s, sys 0m6.832s
Syncen:    real 1m28.314s, user 0m29.026s, sys 0m3.356s
Eixupdate: real	0m8.829s,  user 0m2.152s,  sys 0m1.032s
Updates:   real 0m50.450s, user 0m16.677s, sys 0m0.528s

Ext4:
=====
Entpacken: real 1m3.503s,  user 0m19.189s, sys 0m6.332s
Syncen:    real	0m43.884s, user	0m6.264s,  sys 0m3.576s
Eixupdate: real	0m9.298s,  user 0m2.208s,  sys 0m1.048s
Updates:   real 0m42.233s, user 0m16.733s, sys 0m0.448s

ReiserFS3:
==========
Entpacken: real 0m52.013s, user 0m19.149s, sys 0m13.769s
Syncen:    real 1m24.752s, user 0m6.680s,  sys 0m4.812s
Eixupdate: real 0m6.363s,  user 0m2.100s,  sys 0m0.932s
Updates:   real 0m42.032s, user 0m16.485s, sys 0m0.504s

Reiser4:
========
Entpacken: real 0m34.459s, user 0m21.481s, sys 0m10.965s
Syncen:    real 1m12.140s, user 0m6.528s,  sys 0m6.100s
Eixupdate: real 0m5.503s,  user	0m2.148s,  sys 0m1.076s
Updates:   real 0m26.666s, user 0m16.525s, sys 0m0.572s

XFS:
====
Entpacken: real 1m7.053s,  user 0m21.481s, sys 0m9.461s
Syncen:    real 1m22.923s, user 0m6.516s,  sys 0m3.768s
Eixupdate: real 0m19.025s, user 0m2.444s,  sys 0m1.220s
Updates:   real 0m51.045s, user 0m16.725s, sys 0m0.572s

btrfs:
======
Entpacken: real 0m43.970s, user 0m19.589s, sys 0m15.233s
Syncen:    real 1m7.708s,  user 0m6.828s,  sys 0m9.825s
Eixupdate: real 0m9.685s,  user 0m2.044s,  sys 0m2.300s
Updates:   real 0m30.338s, user 0m16.589s, sys 0m1.472s

System-Info:
============
Die Tests wurde unter folgenden Bedingungen durchgeführt:
Kernel: 2.6.28-gentoo-r5
Portage: 2.2_rc33
Baselayout: 1.12.11.1
Für die Tests mit btrfs wurde der Kernel 2.6.30_rc5 verwendet.

Das dieser Test nicht repräsentativ ist, versteht sich von selbst, ich
glaube aber das er zur Eignung für den Portage-Tree eine Aussage
treffen kann.

------------------------------------------------------------------------

Naja, dass sieht ganz so aus, als ob ich auch in Zukunft meinen Kernel
mit dem Reiser4-Patch patchen werde. Was ich nicht verstehe ist, warum
gerade beim Syncen ext4 schneller als Reiser4 ist und Reiser4 sonst
überall den besten Wert hat.

Gruß
Jens

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Christian Stern]

Das geben auch die anderen Berichte grob auch wieder! (:

Mal was anderes. Nutzt du es so oft, dass die Zeitersparnis, die
entsteht, in Relation steht mit dem Aufwand des Beitrag Schreibens und
dem Durchführen der Tests?

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Jens Meißner]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Am Fri, 15 May 2009 22:56:10 +0200
schrieb Christian Stern <der.raecher@googlemail.com>:

> Das geben auch die anderen Berichte grob auch wieder! (:
> 
> Mal was anderes. Nutzt du es so oft, dass die Zeitersparnis, die
> entsteht, in Relation steht mit dem Aufwand des Beitrag Schreibens und
> dem Durchführen der Tests?

Ach, in ein paar Jahren ist die Zeit schon wieder drin ;-)
Trotzdem gut, das mal selbst probiert zu haben. So viel Zeit hab ich
auch nicht investiert.

Eigentlich kann man damit auch die Nutzung von Gentoo in Frage stellen,
denn die Zeit, welche man für das Kompilieren verwendet, spart man auch
nicht wieder ein.

Gruß
Jens

P.S: Das war jetzt kein Aufruf, eine Diskussion mit mit über 200
Beträgen über den Sinn von Gentoo anfangen...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

Jens Meißner schrieb:
[...]
> 
> Demnach scheint mir ReiserFS3 nur bedingt geeignet. Wie sieht es denn
> eigentlich mit der Performance von ext4 bei kleinen Dateien aus, die
> soll ja besser sein als die von ext3, aber im Vergleich zu ReiserFS?
> 
> Gruß
> Jens

Also nach dem zu urteilen, was in der letzten c't über Ext4 stand, sehe
ich im Vergleich zu Ext3 keine Vorteile im Handling kleiner Dateien,
zumindest was die FS-Architektur angeht. Es ist natürlich durchaus
möglich, dass einige kleinere Tweaks vorgenommen wurden.

Zukünftig sollten sich ein paar kleine Vorteile ergeben:
- Es soll endlich einen online-Defragmentierer geben. Der ist aber noch
in der Entwicklung.
- Ab 2.6.30 (31?) soll sich das Journal abschalten lassen. Das dürfte
Speicherplatz sparen und das Syncen beschleunigen (sofern dabei die
Platte das limitierende Element ist). Außerdem wird damit Ext2 endgültig
obsolet.

Ach ja, ich persönlich verwende momentan Ext2. Ich hab dafür vor ewigen
Zeiten mal ein Benchmark durchgeführt: time emerge -pv --emptytree
kde-meta (war ein Gnome-System). Keine Ahnung, wie aussagekräftig so
etwas ist. Insgesamt war Ext2 und Reiserfs3 dabei gleich auf, wenn ich
mich recht entsinne.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Johannes Hirte]

Am Freitag 15 Mai 2009 15:05:27 schrieb Bernd Wurst:

> > - "Viele Entwickler schätzen XFS leistungsfähiger als ReiserFS
> >   ein." (Wikipedia)
>
> "leistungsfähiger" kann alles bedeuten. Bei größeren Dateien soll XFS
> wesentlich besser sein.
>
> Meiner Erfahrung nach ist XFS bei Schreiboperationen im Dateisystem sehr
> speicherhungrig. Auf einem Server hatten wir mal XFS wegen der eleganten
> Quota-Mechanismen. Haben wir schnell wieder abgeschafft, weil mehrere
> hundert MB für den Dateisystem-Treiber war dann doch etwas viel.

Also das ist ziemlicher Quark. Wie hast du denn den Speicherverbrauch vom XFS-
Treiber gemessen?

> Bei vielen Zugriffen auf kleine Dateien habe ich bisher sehr schlechte
> Erfahrungen mit XFS gemacht.

Hat weniger etwas mit dem Zugriff auf kleine Dateien zu tun. XFS ist bei 
Operationen auf Metadaten nicht sehr effizient, sofern nur wenige Platten zum 
Einsatz kommen. Das ist der Tatsache geschuldet, dass XFS eigentlich darauf 
optimiert wurde, in sehr großen Arrays möglichst viele Platten beschäftigt zu 
halten. Wenn man auf einer einzelnen Platte testet, fällt XFS bei 
Schreiboperationen recht stark gegen andere Dateisysteme (z.B. ext3) ab.

Ein Vorteil von XFS ist das dellayed allocation, welches den 
Fragmentierungsgrad der Dateien vermindert. Das ist dann für große Dateien 
sehr von Vorteil. Reiser4 dürfte hier durch das CoW eher benachteiligt sein. 
Gerade beim portage-Baum dürfte das Dateisystem sehr fix fragmentieren.

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Johannes Hirte]

Am Freitag 15 Mai 2009 21:25:03 schrieb Jens Meißner:

> Naja, dass sieht ganz so aus, als ob ich auch in Zukunft meinen Kernel
> mit dem Reiser4-Patch patchen werde. Was ich nicht verstehe ist, warum
> gerade beim Syncen ext4 schneller als Reiser4 ist und Reiser4 sonst
> überall den besten Wert hat.

Achtung Vermutung:

Reiser4 verrichtet beim syncen wesentlich mehr Arbeit als ext4. Grund 1 
könnten die "dancing trees" von Reiser4 sein, die beim sync erst noch 
ausbalanciert werden müssen. Grund 2 könnte das dellayed allocation sein. Das 
machen zwar eigentlich beide Dateisysteme, aber ext4 könnte schon auf das alte 
ext3 Verhalten gepatcht sein, spätestens alle 5s zu commiten. Damit fällt am 
Ende natürlich wesentlich weniger Arbeit an.

Gruß,
Johannes

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Bernd Wurst]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

Hallo.

Am Dienstag 19 Mai 2009 22:23:45 schrieb Johannes Hirte:
> Also das ist ziemlicher Quark. Wie hast du denn den Speicherverbrauch vom
> XFS- Treiber gemessen?

Die Treiber werden in der System-Prozessliste als einzelne Kernel-Threads 
separat geführt. Und da wird jedem Prozess ein Speicherverbrauch zugeteilt.

Zudem eben der Unterschied in der gesamten RAM-Auslastung wenn /home mit XFS 
läuft oder wenn /home mit ext3 läuft.

Das ist kein wissenschaftlicher Test, das war auch nicht der Anspruch.

Gruß, Bernd

-- 
"Ich moechte Windows kaufen." "Sind Sie verrueckt?"
"Gehoert das zu den Lizenzbedingungen?"


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Johannes Hirte]

Am Mittwoch 20 Mai 2009 10:47:22 schrieb Bernd Wurst:
> Hallo.
>
> Am Dienstag 19 Mai 2009 22:23:45 schrieb Johannes Hirte:
> > Also das ist ziemlicher Quark. Wie hast du denn den Speicherverbrauch vom
> > XFS- Treiber gemessen?
>
> Die Treiber werden in der System-Prozessliste als einzelne Kernel-Threads
> separat geführt. Und da wird jedem Prozess ein Speicherverbrauch zugeteilt.

Was ist bei dir die "System-Prozessliste"? Ich weiß bis jetzt keine 
Möglichkeit, den RAM Bedarf von Kernel-Threads aufzuzeigen.

> Zudem eben der Unterschied in der gesamten RAM-Auslastung wenn /home mit
> XFS läuft oder wenn /home mit ext3 läuft.

Was schon alleine unterschiedlichem Caching-Verhalten geschuldet sein kann. 
Und da wäre eine bessere RAM-Nutzung sogar vorteilhaft.

Gruß, Johannes

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Daniel Troeder]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

On Fri, 2009-05-15 at 21:25 +0200, Jens Meißner wrote:
> Mein Test zur Eignung von Dateisystem zum Speichern des Portage-Trees.
> Ablauf:
> - Anlegen des Dateisystems
> - Entpacken eines älteren Portage-Snapshots (8 Tage alt)
> - Updaten des Portage-Trees (Server per Fast-Ethernet angebunden)
> - Ausführen von update-eix.
> - Suchen von Paketen, welche geupdated werden müssen. (emerge -DuNpv
> @world)

> XFS:
> ====
> Entpacken: real 1m7.053s,  user 0m21.481s, sys 0m9.461s
> Syncen:    real 1m22.923s, user 0m6.516s,  sys 0m3.768s
> Eixupdate: real 0m19.025s, user 0m2.444s,  sys 0m1.220s
> Updates:   real 0m51.045s, user 0m16.725s, sys 0m0.572s

Hallo Jens :)

Ich wollte dich mal fragen, ob es dir viel Arbeit bereiten würde, den
Test mit XFS mit folgenden Flags zu wiederholen:

mkfs.xfs -l lazy-count=1,version=2,size=128m -i attr=2 -d
agcount=4 /dev/XYZ

mount /dev/XYZ /mnt/XYZ -o noatime,nodiratime,logbufs=8,logbsize=256k

Ich habe gelesen, dass insb. "-l lazy-count=1" wichtig für meta-data
intensive Arbeit ist (siehe mkfs.xfs manpage).

Nun frage ich mich natürlich, ob dem denn wirklich so ist... Und da du
schon so viele vergleichbare Tests gemacht hast... Wäre klasse :)

BTW: hast du immer die gleichen mount-Optionen für alle FS verwendet?
(Insb. natürlich "noatime")?

Grüße,
Daniel

-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Christian Stern]

> Was ist bei dir die "System-Prozessliste"? Ich weiß bis jetzt keine
> Möglichkeit, den RAM Bedarf von Kernel-Threads aufzuzeigen.

Sehen kann man sie, wenn man htop nutzt und dort einfach "hide kernel
threads" deaktiviert.

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Matthias Schwarzott]

On Samstag, 23. Mai 2009, Christian Stern wrote:
> > Was ist bei dir die "System-Prozessliste"? Ich weiß bis jetzt keine
> > Möglichkeit, den RAM Bedarf von Kernel-Threads aufzuzeigen.
>
> Sehen kann man sie, wenn man htop nutzt und dort einfach "hide kernel
> threads" deaktiviert.


Also ich weiß ja nicht ob dein Kernel Spezialoptionen hat, aber soweit ich 
weiß wird der Speicher nicht pro Thread verwaltet im Kernel.
Außerdem: Ist jeder Dateisystemtreiber ein Thread? Ich denke eher nicht.

Gruß
Matthias

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Johannes Hirte]

Am Samstag 23 Mai 2009 07:55:36 schrieb Christian Stern:
> > Was ist bei dir die "System-Prozessliste"? Ich weiß bis jetzt keine
> > Möglichkeit, den RAM Bedarf von Kernel-Threads aufzuzeigen.
>
> Sehen kann man sie, wenn man htop nutzt und dort einfach "hide kernel
> threads" deaktiviert.

Zeigt bei mir die selbe Anzeige wie top. Beispiel:

1180 root      16  -4 12516   360   280 S  0.0  0.0  0:01.04  `- /sbin/udevd 
--daemon
2 root      15  -5     0     0     0 S  0.0  0.0  0:00.00 kthreadd
...
27081 root      20   0     0     0     0 S  0.0  0.0  0:00.00  `- pdflush
27057 root      20   0     0     0     0 S  0.0  0.0  0:09.93  `- pdflush
2475 root      15  -5     0     0     0 S  0.0  0.0  0:03.10  `- xfssyncd
2474 root      15  -5     0     0     0 S  0.0  0.0  0:01.82  `- xfsaild
2473 root      15  -5     0     0     0 S  0.0  0.0  0:04.44  `- xfsbufd
2394 root      15  -5     0     0     0 S  0.0  0.0  0:00.00  `- kdmflush
1075 root      15  -5     0     0     0 S  0.0  0.0  0:01.72  `- xfssyncd
1074 root      15  -5     0     0     0 S  0.0  0.0  0:01.00  `- xfsaild
1073 root      15  -5     0     0     0 S  0.0  0.0  0:02.46  `- xfsbufd

keinerlei Speicherinformationen der Kernelthreads. 

[gentoo-user-de] xorg nach kernel update unbrauchbar

[Roland Huehn]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

hallo,

habe meinen kernel von 2.6.28-gentoo nach 2.6.29-gentoo-r5 upgedatet
xorg startet zwar die anzeige is aber total im arsch, außer weiß sieht
man fast gar nix mehr habe schon verschiedene einstellungen am x-server
und am kernel durchprobiert aber ohne erfolg.

bei der von mir eingesetzten graphikkarte handelt es sich um eine intel:

mobi tmp # lspci | grep 00:02.0
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM
Integrated Graphics Device (rev 02)

welche in einem laptop verbaut ist (dual head)...

die graphik arbeitete bisher nach so ziemlich jeden update eigendlich
immer besser opengl etc. ..

weiß jemand wo das problem liegen könnte?
nehme all hinweise und anregungen werden dankend entgegen.

Roland


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-user-de] xorg nach kernel update unbrauchbar

[Norman Rieß]

Roland Huehn schrieb:
> hallo,
>
> habe meinen kernel von 2.6.28-gentoo nach 2.6.29-gentoo-r5 upgedatet
> xorg startet zwar die anzeige is aber total im arsch, außer weiß sieht
> man fast gar nix mehr habe schon verschiedene einstellungen am x-server
> und am kernel durchprobiert aber ohne erfolg.
>
> bei der von mir eingesetzten graphikkarte handelt es sich um eine intel:
>
> mobi tmp # lspci | grep 00:02.0
> 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM
> Integrated Graphics Device (rev 02)
>
> welche in einem laptop verbaut ist (dual head)...
>
> die graphik arbeitete bisher nach so ziemlich jeden update eigendlich
> immer besser opengl etc. ..
>
> weiß jemand wo das problem liegen könnte?
> nehme all hinweise und anregungen werden dankend entgegen.
>
> Roland
>
>   
Hallo,

bei einem Kernelupdate kann es schon vorkommen, daß du manche Sachen neu 
bauen musst.
Hast du mal den Grafiktreiber neu kompiliert? Nehme an, das wäre 
x11-drivers/xf86-video-intel, wenn du den denn nimmst.
Für Kernelmodule steht dafür auch ein extra Tool "module-rebuild" zur 
Verfügung.

Grüße
Norman

Re: [gentoo-user-de] xorg nach kernel update unbrauchbar

[Roland Huehn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Norman Rieß schrieb:
> Roland Huehn schrieb:
>> hallo,
>>
>> habe meinen kernel von 2.6.28-gentoo nach 2.6.29-gentoo-r5 upgedatet
>> xorg startet zwar die anzeige is aber total im arsch, außer weiß sieht
>> man fast gar nix mehr habe schon verschiedene einstellungen am x-server
>> und am kernel durchprobiert aber ohne erfolg.
>>
>> bei der von mir eingesetzten graphikkarte handelt es sich um eine intel:
>>
>> mobi tmp # lspci | grep 00:02.0
>> 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM
>> Integrated Graphics Device (rev 02)
>>
>> welche in einem laptop verbaut ist (dual head)...
>>
>> die graphik arbeitete bisher nach so ziemlich jeden update eigendlich
>> immer besser opengl etc. ..
>>
>> weiß jemand wo das problem liegen könnte?
>> nehme all hinweise und anregungen werden dankend entgegen.
>>
>> Roland
>>
>>   
> Hallo,
> 
> bei einem Kernelupdate kann es schon vorkommen, daß du manche Sachen neu
> bauen musst.
> Hast du mal den Grafiktreiber neu kompiliert? Nehme an, das wäre
> x11-drivers/xf86-video-intel, wenn du den denn nimmst.
> Für Kernelmodule steht dafür auch ein extra Tool "module-rebuild" zur
> Verfügung.

hmm ja, habe ich jetz schon mal gemacht und nicht nur
x11-drivers/xf86-video-intel sondern alle dreiber emerge `qlist -I
x11-drivers | xargs` und vorher noch xorg-server und hat nix gebracht.
mittlerweile tritt noch ein anderes problem zeitweilig auf nämlich das
sich der ganze rechner nach starten von xorg einfach aufhängt :(

also muß das wohl doch an irgendwelchen xorg parametern liegen nur, welche?

Grüße + Danke
Roland

> 
> Grüße
> Norman
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkohd5wACgkQR3MKHkmnok0wOACfVbyEonsOHjT6BxLReUTXkNaS
RN0Anih5mKUhKTbAoxXfWLrLZNCUKc0W
=S34H
-----END PGP SIGNATURE-----

Re: [gentoo-user-de] xorg nach kernel update unbrauchbar

[Sebastian Gaebel]

> 
> hmm ja, habe ich jetz schon mal gemacht und nicht nur
> x11-drivers/xf86-video-intel sondern alle dreiber emerge `qlist -I
> x11-drivers | xargs` und vorher noch xorg-server und hat nix gebracht.
> mittlerweile tritt noch ein anderes problem zeitweilig auf nämlich das
> sich der ganze rechner nach starten von xorg einfach aufhängt :(
> 
> also muß das wohl doch an irgendwelchen xorg parametern liegen nur, welche?
> 
> Grüße + Danke
> Roland

Hallo Roland,

hast Du noch die .config vom 2.6.28'er? (die ja funktionierte)
guck doch mal nach den Veränderungen zur jetzigen .config.

der 2.6.29'er bringt ne Menge Änderungen in Grafiksteuerungsbereich mit
ein neuer Kandidat ist evt. DRM_I915_KMS (Enable modesetting on intel by
default).

Gibt Dein X noch Fehler im logfile aus?

Wie ist deine X-Version und config?

Cu, Sebastian.

Re: [gentoo-user-de] xorg nach kernel update unbrauchbar

[Roland Huehn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sebastian Gaebel schrieb:
>> hmm ja, habe ich jetz schon mal gemacht und nicht nur
>> x11-drivers/xf86-video-intel sondern alle dreiber emerge `qlist -I
>> x11-drivers | xargs` und vorher noch xorg-server und hat nix gebracht.
>> mittlerweile tritt noch ein anderes problem zeitweilig auf nämlich das
>> sich der ganze rechner nach starten von xorg einfach aufhängt :(
>>
>> also muß das wohl doch an irgendwelchen xorg parametern liegen nur, welche?
>>
>> Grüße + Danke
>> Roland
> 
> Hallo Roland,
> 
> hast Du noch die .config vom 2.6.28'er? (die ja funktionierte)
> guck doch mal nach den Veränderungen zur jetzigen .config.

habe die alte config mit make oldconfig übernommen.
die alte .config habe ich auch noch werd das mal prüfen.

> 
> der 2.6.29'er bringt ne Menge Änderungen in Grafiksteuerungsbereich mit
> ein neuer Kandidat ist evt. DRM_I915_KMS (Enable modesetting on intel by
> default).

ist mir auch aufgefallen, nur weis ich nich was ich damit anfangen soll,
habe es mal eingeschaltet und dann wieder ab, ergebnis ist das selbe evt
. kenne ich aber die richtigen xorg einstellungen dazu nicht aber, das
ist im moment jedenfalls mein kandidat der fehler ursache und, hmm ja
scheint es auch zu sein
http://www.gossamer-threads.com/lists/linux/kernel/1064119?do=post_view_flat

werd mich da mal durchlesen.
> 
> Gibt Dein X noch Fehler im logfile aus?

nein im log kann ich nix auffäliges finden.

> 
> Wie ist deine X-Version und config?

X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.29-gentoo-r5 i686
Current Operating System: Linux mserve 2.6.28-gentoo #10 PREEMPT Wed Jan
14 11:09:29 CET 2009 i686
Build Date: 30 May 2009  07:41:38PM

xorg.conf: http://webmail.nr67.de/xorg.conf

> 
> Cu, Sebastian.
> 
Gruß und Dank, Roland
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkohyV8ACgkQR3MKHkmnok1W6wCfRSZhNfJb/YmYnQMXMjrRJZL5
36wAn1f6mcCBoqBhFR+C/ll2erMFM/Bx
=w7oe
-----END PGP SIGNATURE-----

Re: [gentoo-user-de] xorg nach kernel update unbrauchbar

[Roland Huehn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland Huehn schrieb:
> Sebastian Gaebel schrieb:
>>> hmm ja, habe ich jetz schon mal gemacht und nicht nur
>>> x11-drivers/xf86-video-intel sondern alle dreiber emerge `qlist -I
>>> x11-drivers | xargs` und vorher noch xorg-server und hat nix gebracht.
>>> mittlerweile tritt noch ein anderes problem zeitweilig auf nämlich das
>>> sich der ganze rechner nach starten von xorg einfach aufhängt :(
>>>
>>> also muß das wohl doch an irgendwelchen xorg parametern liegen nur, welche?
>>>
>>> Grüße + Danke
>>> Roland
>> Hallo Roland,
> 
>> hast Du noch die .config vom 2.6.28'er? (die ja funktionierte)
>> guck doch mal nach den Veränderungen zur jetzigen .config.
> 
> habe die alte config mit make oldconfig übernommen.
> die alte .config habe ich auch noch werd das mal prüfen.
> 
>> der 2.6.29'er bringt ne Menge Änderungen in Grafiksteuerungsbereich mit
>> ein neuer Kandidat ist evt. DRM_I915_KMS (Enable modesetting on intel by
>> default).
> 
> ist mir auch aufgefallen, nur weis ich nich was ich damit anfangen soll,
> habe es mal eingeschaltet und dann wieder ab, ergebnis ist das selbe evt
> . kenne ich aber die richtigen xorg einstellungen dazu nicht aber, das
> ist im moment jedenfalls mein kandidat der fehler ursache und, hmm ja
> scheint es auch zu sein
> http://www.gossamer-threads.com/lists/linux/kernel/1064119?do=post_view_flat

also jetz gehts, in Section Device der xorg.conf brauchte ich:

Option      "Tiling"            "False"

das der rechner sich aufgehängt hat kommt wohl von der kernel option:

DRM_I915_KMS

diese habe ich nun aus.

> 
> werd mich da mal durchlesen.
>> Gibt Dein X noch Fehler im logfile aus?
> 
> nein im log kann ich nix auffäliges finden.
> 
>> Wie ist deine X-Version und config?
> 
> X.Org X Server 1.5.3
> Release Date: 5 November 2008
> X Protocol Version 11, Revision 0
> Build Operating System: Linux 2.6.29-gentoo-r5 i686
> Current Operating System: Linux mserve 2.6.28-gentoo #10 PREEMPT Wed Jan
> 14 11:09:29 CET 2009 i686
> Build Date: 30 May 2009  07:41:38PM
> 
> xorg.conf: http://webmail.nr67.de/xorg.conf
> 
>> Cu, Sebastian.
> 
> Gruß und Dank, Roland
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoh36EACgkQR3MKHkmnok1n5wCffAOnJa1wPSgk76rtO6vKVye/
8TwAn2X+L93YxwlrX2ePxxtPUehX9fIX
=vibG
-----END PGP SIGNATURE-----

Re: [gentoo-user-de] xorg nach kernel update unbrauchbar

[Sebastian Gaebel]

> 
> also jetz gehts, in Section Device der xorg.conf brauchte ich:
> 
> Option      "Tiling"            "False"
> 
> das der rechner sich aufgehängt hat kommt wohl von der kernel option:
> 
> DRM_I915_KMS
> 
> diese habe ich nun aus.
> 
Im zweifel alles raus von dem du nicht weißt das du es brauchst.

Auch ganz ohne config-file sollte das X mindestens brauchbar hochkommen.

Re: [gentoo-user-de] xorg nach kernel update unbrauchbar

[Roland Huehn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sebastian Gaebel schrieb:
>> also jetz gehts, in Section Device der xorg.conf brauchte ich:
>>
>> Option      "Tiling"            "False"
>>
>> das der rechner sich aufgehängt hat kommt wohl von der kernel option:
>>
>> DRM_I915_KMS
>>
>> diese habe ich nun aus.
>>
> Im zweifel alles raus von dem du nicht weißt das du es brauchst.
> 
> Auch ganz ohne config-file sollte das X mindestens brauchbar hochkommen.
> 
>
nö also ohne
Option      "Tiling"            "False"
kommt bei mir gar nix brauchbar hoch und mit DRM_I915_KMS im kernel
hängt sich der rechner auf, so wie ichs jetz hab leufts aber vorerst mal

Danke für die anregungen

Roland

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoiF6wACgkQR3MKHkmnok2jVQCfSj6OTIJZBjTsIUTCDsHYm4DM
y6QAnRb6rkItMBtsQ7vs9b7ozvNxWoQx
=usbT
-----END PGP SIGNATURE-----

Re: [gentoo-user-de] xorg nach kernel update unbrauchbar

[Markus Heidelberg]

Roland Huehn, 31.05.2009:
> > Sebastian Gaebel schrieb:
> >> der 2.6.29'er bringt ne Menge Änderungen in Grafiksteuerungsbereich mit
> >> ein neuer Kandidat ist evt. DRM_I915_KMS (Enable modesetting on intel by
> >> default).
> 
> das der rechner sich aufgehängt hat kommt wohl von der kernel option:
> 
> DRM_I915_KMS
> 
> diese habe ich nun aus.

Vermutlich kamen sich bei dir Kernel und X-Server in die Quere:

http://www.heise.de/open/Kernel-Log-Was-2-6-29-bringt-2-Grafik-Kernel-verwaltet-Bildschirmaufloesung--/artikel/121732

"[..] diese Teile noch in Entwicklung und KMS vorerst nur für Entwickler
gedacht; ohne passende Userspace-Unterstützung sollte man KMS bei der
Kernel-Konfiguration daher nicht aktivieren."

Aus dem commit-Log 79e539453b34e35f39299a899d263b0a1f1670bd, in dem
DRM_I915_KMS eingeführt wurde:

    Note that if mode setting is enabled, user level drivers that access
    display registers directly or that don't use the kernel graphics memory
    manager will likely corrupt kernel graphics memory, disrupt output
    configuration (possibly leading to hangs and/or blank displays), and
    prevent panic/oops messages from appearing.  So use caution when
    enabling this code; be sure your user level code supports the new
    interfaces.

Markus

Re: [gentoo-user-de] Dateisystem für Portage-Tree

[Jens Meißner]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

Am Sat, 23 May 2009 05:24:19 +0200
schrieb Daniel Troeder <daniel@admin-box.com>:

Hallo,

> Ich wollte dich mal fragen, ob es dir viel Arbeit bereiten würde, den
> Test mit XFS mit folgenden Flags zu wiederholen:
> 
> mkfs.xfs -l lazy-count=1,version=2,size=128m -i attr=2 -d
> agcount=4 /dev/XYZ
> 
> mount /dev/XYZ /mnt/XYZ -o noatime,nodiratime,logbufs=8,logbsize=256k
> 
> Ich habe gelesen, dass insb. "-l lazy-count=1" wichtig für meta-data
> intensive Arbeit ist (siehe mkfs.xfs manpage).
> 
> Nun frage ich mich natürlich, ob dem denn wirklich so ist... Und da du
> schon so viele vergleichbare Tests gemacht hast... Wäre klasse :)

Ich kann es machen, nur eventuell verliert das ganze seine Richtigkeit,
weil ich die exakten Test-Bedingungen nicht mehr nachstellen kann. (Der
Mirror enthält mittlerweile andere Daten, so das das Syncen
wahrscheinlich länger dauert.)

> BTW: hast du immer die gleichen mount-Optionen für alle FS verwendet?
> (Insb. natürlich "noatime")?

Ja habe ich

Gruß
Jens

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]