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
signature.asc
Description: OpenPGP digital signature
