Ingo Juergensmann wrote: > Das fsck ist bei XFS angenehm zuegig... :-) Das stimmt wohl :-) Aber eigentlich trifft das schon fast für alle Journaling Dateisysteme zu.. Nur unter ext2 war das damals eine Krankheit und wirklich getraut, den üblichen Check nach n-Mounts abzuschalten hatte ich mich dann doch nicht.. > 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... 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.. > 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. >> 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? Cheers, Jan
Attachment:
signature.asc
Description: OpenPGP digital signature