Re: Partition nachträglich vergrößern (/usr)
On 03/22/2010 07:47 PM, Martin Steigerwald wrote:
> XFS läßt sich jedoch derzeit *nicht* verkleinern, zumindest ohne Backup
> und Wiederherstellen.
Ja, das hatte ich auch weiter oben erwähnt gehabt. ;)
Ansonsten gab es auch mal ein Statement das XFS wohl nie ein verkleinern
unterstützen wird. Halte ich aber auch nicht für all zu schlimm.
Ansonsten gab es noch eine art "Hack". Irgendwie mit dumpen und hin und
her schieben konnte man es auch noch verkleinern. Wird aber offiziel
nicht Supported und ist naja, halt ein Hack. Würde ich aber auch nicht
anwenden.
> Ob sich XFS einsetzen würde, hängst stark vom Workload ab. Für Desktop-
> Systeme empfehle ich mittlerweile Ext4, da dies zumindest auf meinen
> Notebooks in typischen Workloads wie apt-get upgrade, tar.gz-Archive
> auspacken, Mails löschen etc. subjektiv beobachtet *deutlich* schneller
> arbeitet. Bei Ext4 unter Lenny sind jedoch ein paar Dinge zu beachten
> (mindestens Backport-Kernel >=2.6.30, rootfstype=ext4 falls / auf Ext4).
Ich persönlich halte von ext4 noch nicht all zu viel. Es ist immer noch
relativ neu und muss sich erstmal bewähren das es Dateien überhaupt
sicher abspeichert. XFS hat hier den Vorteil das es schon seit dem 2.4er
Kernel gab und seit 2.6 offiziel dabei ist. Es ist mitlerweile sehr
ausgereift und auch seine Features funktionieren.
Mitlerweile kann man es in jeder Distribution nutzen und an Support mag
es da nicht mangeln. Ich nutze XFS auch schon/noch in Debian Lenny, ext4
würde ich da noch nicht nutzen.
Aber ob nun ext4 oder XFS mag wohl schon mehr eine persönliche
entscheidung sein. Hauptsache eins von beiden und beide sollten besser
als ext3 sein. Aber wenn ext4 dann würde ich es nicht mit Lenny nutzen
sondern noch auf Squeeze warten.
Apropro Squeeze, wenn Debian/KFreeBSD drausen ist wird sicherlich ZFS
nochmal interessant werden. ;)
> Für große Systeme mit vielen CPUs, RAID mit vielen Festplatten, evtl. auch
> MySQL/Datenbank-Workloads mag XFS noch besser geeignet sein. Interessant
> wirds natürlich mit zukünftigen Kernel, da gerade in 2.6.34 erste
> Vorarbeiten für eine deutliche Beschleunigung von Metadaten-Operationen
> einfließen.
Davon werden wir wohl in Debian Squeeze nichts mehr mitbekommen, laut
letztem Stand setzt Squeeze ja auf 2.6.32 auf, und dann muss man wohl
erstmal 2-3 jahre damit leben, auser man kompiliert natürlich den Kernel
selber.
Reply to: