Re: ext3, XFS, Reiser

[Ingo Juergensmann <ij@2005.bluespice.org>]

On Fri, Mar 11, 2005 at 01:27:00PM +0100, Jan Kesten wrote:

> > Erwaehnte ich schon, dass ich Sun nicht mag? Muss wohl daran liegen,
> > dass ich aus der SGI-Ecke komme. Aber wenn OpenSolaris fuer die
> > ODW/Pegasos Rechner fertig ist, werde ich mir das auch mal
> > anschauen...
> *g* Bin fast mit Sun aufgewachsen - mag vielleicht daran liegen, das ich
> da einen Hang zu den sonnigen Leuten (ja, ich weiss auch, dass Sun in
> dem Sinne hier nicht mit der Sonne zu tun hat *g*) her hab ;-) Und auch
> zur Zeit auf der Arbeit mit denen zu tun hab...

Meine Abneigung gegen Sun ist ziemlich trivial: 
- ich finde deren Design im Vergleich zu dem der SGIs geradezu haesslich
- die Tastaturen sind einfach nur schauderhaft vom Layout her... 
Also vollkommen objektive Gruende... ;)

> Hab aber auch man den Genuss gehabt, auf einer Origin 2000 zu
> programmieren, das war richtig Spass (und das war auch der Zeitpunkt wo
> ich XFS für mich entdeckt hab...)

:-)

> > Ganz einfach: Der Bedarf ist nicht da. Die Entwickler auf #xfs haben
> > sich mal dahingehend geaeussert, dass man das Verkleinern durchaus
> > auch implementieren koennte, wenn es ein (zahlender) Kunde wuensche.
> Sollte vielleicht doch dort öfter mitlesen - hatte mir aber auch schon
> soetwas gedacht, denn vom prinzipiellen Aufbau her sollte das bei XFS
> eigentlich kein unlösbares Problem sein. Leider bin ich selbst nicht fit
> genug mich damit mal zu beschäftigen..

Tja, das verstehe ich ja z.B. auch nicht... 
Staendig wird herumgelaestert, dass XFS kein shrinking kann, aber niemand
kommt auf Idee, da mal selber seine Nase in den vorhandenen Source-Code zu
stecken und es dann halt mal zu implementieren, obwohl man ansonsten bei
jeder noch so kleinen Gelegenheit ein UTSL an den Kopf geschmissen
bekommt... ;)

> > Nur braucht es anscheinend niemand (ausser ein paar 
> > LVM-Linux-Freaks), also werden die wenigen Ressourcen, die man hat,
> > nicht auf Features verschwendet, die eh niemand (Zahlendes) braucht.
> Interessant ist einfach nur, dass man eine anfängliche Aufteilung des
> vorhandenen Platzes vornehmen kann und danach dynamisch umverteilen.
> Sprich wenn es in einem Bereich zum Engpass kommt, kann man einen
> anderen verkleinern (ohne Umkopieren) und dann den anderen vergrößern -
> dafür ist ja LVM da. Andererseits, kann man natürlich (so wie ich es
> auch mache und daher auch fast nur wachsende Dateisysteme kenne) einfach
> mit kleinen Bereichen anfangen und immer on-demand vergrößern. Nur das
> zerstückelt natürlich die PE quer über eine Volume Group (und
> unterschiedliche Platten u.U.), was wiederum ein Performance Problem
> werden kann.

Naja, wer solch eine Funktionalitaet braucht, kann ja auch zum CXFS greifen.
;)
Ich persoenlich kaeme z.B. nie auf die Idee, ein LVM ueber mehrere Platten
hinweg ohne (mindestens) ein RAID(5) zu benutzen... 
 
> >> Dafür ist die Baumreorganisation eine schöne Option, wenn man die
> >> Zugriffszeiten optimieren will/muss.
> > In der Tat... wobei ich da nun auf einem Raid irgendwie auf einen
> > seltsamen Effekt gestossen bin, aber naja...
> Lass mich nicht unwissend sterben - welche Effekte hattest Du denn
> beobachten können? Mit ist aufgefallen, dass die Reorganisation auf
> einem RAID-5-Verbund wesentlich langsamer ist als auf einer einzelnen
> Platte für sich. Aber sonst?

Naja, auf dem P200 dauert das so oder so schon was laenger... ;) 
Aber der Effekt war der, dass scheinbar alle Files eine recht hohe
Fragmentierung bzw. Anzahl der extents aufwiesen (ca. 67, 48 oder 27). 

Lustigerweise stelle ich allerdings gerade fest, dass das nicht die Files
auf dem Raid betrifft, sondern auf /.... *sehr* strange... ;)

Naja, mal weiterhin beobachten...

-- 
Ciao...              // 
      Ingo         \X/