Liebe Liste, ich habe eine Partition, die heillos Defragmentiert zu sein scheint: server:~ # fsck /home/Privat -CVDfF fsck 1.40.2 (12-Jul-2007) [/sbin/fsck.ext3 (1) -- /home/Privat] fsck.ext3 -DfF -C0 /dev/mapper/nvidia_dbbfdiea_part13 e2fsck 1.40.2 (12-Jul-2007) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 3A: Optimizing directories Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/mapper/nvidia_dbbfdiea_part13: ***** FILE SYSTEM WAS MODIFIED ***** /dev/mapper/nvidia_dbbfdiea_part13: 96671/24870912 files (80.1% non-contiguous), 29811564/49715142 blocks Die Platte ist aber nur zu 64,41% voll. Kann man da auch ohne hin und her zu kopieren Abhilfe schaffen? Falls nein, muss ich beim Kopieren etwas beachten? <--- Ich möchte, dass die Rechte etc. erhalten bleiben. Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Alex Winzer wrote:
ich habe eine Partition, die heillos Defragmentiert zu sein scheint:
server:~ # fsck /home/Privat -CVDfF fsck 1.40.2 (12-Jul-2007) [/sbin/fsck.ext3 (1) -- /home/Privat] fsck.ext3 -DfF -C0 /dev/mapper/nvidia_dbbfdiea_part13 e2fsck 1.40.2 (12-Jul-2007) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 3A: Optimizing directories Pass 4: Checking reference counts Pass 5: Checking group summary information
/dev/mapper/nvidia_dbbfdiea_part13: ***** FILE SYSTEM WAS MODIFIED ***** /dev/mapper/nvidia_dbbfdiea_part13: 96671/24870912 files (80.1% non-contiguous), 29811564/49715142 blocks
Die Platte ist aber nur zu 64,41% voll.
Kann man da auch ohne hin und her zu kopieren Abhilfe schaffen? Falls nein, muss ich beim Kopieren etwas beachten? <--- Ich möchte, dass die Rechte etc. erhalten bleiben.
Die Frage ist, hast Du merkliche Performance-Probleme? Unter "normalen" Umstaenden ist ein Defragmentieren eines ext Filesystems naemlich nicht erforderlich. Wenn genug Platz ist, kann sich ein ext Filesystem quasi auch langsam selbst defragmentieren. Waere interessant zu wissen, was Du generell auf der Partition gemacht hast - war sie evtl. schon einmal ziemlich voll (z.B. >90%). Falls Du tatsaechlich "manuell" defragmentieren willst, wirst Du um ein Kopieren quasi nicht umhin kommen (es gab mal ein defrag Programm, aber das wird glaube ich schon lange nicht mehr maintained). Zum Umkopieren bietet sich evtl. tar an, siehe http://suse-linux-faq.koehntopp.de/q/q-filesystems-kopieren.html bzw. http://de.opensuse.org/SDB:SuSE_Linux_umkopieren, das Vorgehen handhabt auch Links und Rechte etc. korrekt. Cheers, Th. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
From: "Thomas Hertweck" Sent: Wednesday, September 24, 2008 8:50 PM
Alex Winzer wrote:
ich habe eine Partition, die heillos Defragmentiert zu sein scheint:
[...]
/dev/mapper/nvidia_dbbfdiea_part13: 96671/24870912 files (80.1% non-contiguous), 29811564/49715142 blocks
Die Platte ist aber nur zu 64,41% voll.
Kann man da auch ohne hin und her zu kopieren Abhilfe schaffen? Falls nein, muss ich beim Kopieren etwas beachten? <--- Ich möchte, dass die Rechte etc. erhalten bleiben.
Die Frage ist, hast Du merkliche Performance-Probleme? Unter "normalen" Umstaenden ist ein Defragmentieren eines ext Filesystems naemlich nicht erforderlich. Wenn genug Platz ist, kann sich ein ext Filesystem quasi auch langsam selbst defragmentieren.
Was heißt langsam selbst defragmentieren? Wo kann ich dazu mal Infos zum besseren Verständnis finden? Ich gehe davon aus, dass ext3 die vorhandenen Daten in ihrer physikalischen Position auf der Platte nicht anrührt, oder? Also dürfte es nach meinem Verständnis nicht zu einer Defragmentierung kommen, wenn die Platte immer mehr gefüllt wird.
Waere interessant zu wissen, was Du generell auf der Partition gemacht hast - war sie evtl. schon einmal ziemlich voll (z.B. >90%).
Auf der Platte lungern tausende kleine Dateien rum, weil das System als Fileserver über Samba tätig ist. Hin und wieder mache ich Experimente mit Lazarus und Delphi. Ich arbeite an einem elektronische Dokumentenordner... Die Platte war nie über 60% belegt.
Falls Du tatsaechlich "manuell" defragmentieren willst, wirst Du um ein Kopieren quasi nicht umhin kommen (es gab mal ein defrag Programm, aber das wird glaube ich schon lange nicht mehr maintained). Zum Umkopieren bietet sich evtl. tar an, siehe http://suse-linux-faq.koehntopp.de/q/q-filesystems-kopieren.html bzw. http://de.opensuse.org/SDB:SuSE_Linux_umkopieren, das Vorgehen handhabt auch Links und Rechte etc. korrekt.
Cheers, Th.
Werde ich mir mal ansehen. Danke, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi Alex! On Wed, 24 Sep 2008, Alex Winzer wrote:
From: "Thomas Hertweck"
Die Frage ist, hast Du merkliche Performance-Probleme? Unter "normalen" Umstaenden ist ein Defragmentieren eines ext Filesystems naemlich nicht erforderlich. Wenn genug Platz ist, kann sich ein ext Filesystem quasi auch langsam selbst defragmentieren.
Was heißt langsam selbst defragmentieren? Wo kann ich dazu mal Infos zum besseren Verständnis finden?
http://kris.koehntopp.de/inkomploehntopp/01099.html
Ich gehe davon aus, dass ext3 die vorhandenen Daten in ihrer physikalischen Position auf der Platte nicht anrührt, oder? Also dürfte es nach meinem Verständnis nicht zu einer Defragmentierung kommen, wenn die Platte immer mehr gefüllt wird.
Nun ja, Dateien werden grundsätzlich mit einer gewissen Fragmentierung angelegt. Das ist so gewünscht und erlaubt das Wachsen von Dateien. Wir reden hier doch nicht von einem read-only Filesystem?
Auf der Platte lungern tausende kleine Dateien rum, weil das System als Fileserver über Samba tätig ist. Hin und wieder mache ich Experimente mit Lazarus und Delphi. Ich arbeite an einem elektronische Dokumentenordner... Die Platte war nie über 60% belegt.
Und Performance Probleme hast Du nicht? dir_index aktiviert?
Falls Du tatsaechlich "manuell" defragmentieren willst, wirst Du um ein Kopieren quasi nicht umhin kommen (es gab mal ein defrag Programm, aber das wird glaube ich schon lange nicht mehr maintained). Zum Umkopieren bietet sich evtl. tar an, siehe http://suse-linux-faq.koehntopp.de/q/q-filesystems-kopieren.html bzw. http://de.opensuse.org/SDB:SuSE_Linux_umkopieren, das Vorgehen handhabt auch Links und Rechte etc. korrekt.
Cheers, Th.
Werde ich mir mal ansehen.
Zu Zeiten von ext2 gab es ein spezielles defrag Tool, das aber so weit ich weiß seit langem nicht mehr entwickelt wurde. Des Weiteren existiert http://ck.kolivas.org/apps/defrag/defrag-0.06/defrag und ext4 soll Online-Defragmentierung beherrschen. Mit freundlichen Grüßen Christian -- Why is "abbreviation" such a long word? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Alex Winzer wrote:
[...] Was heißt langsam selbst defragmentieren?
Sorry, das war vielleicht etwas irrefuehrend. Du solltest Dir nicht vorstellen, dass im Hintergrund und transparent fuer einen User aktiv Bloecke umkopiert werden - soweit ich weiss, beherrscht das ext Filesystem so etwas nicht (im Gegensatz zu anderen Filesystemen; unser Cluster-Filesystem kopiert z.B. aktiv Dateien/Dateifragmente um).
Wo kann ich dazu mal Infos zum besseren Verständnis finden? Ich gehe davon aus, dass ext3 die vorhandenen Daten in ihrer physikalischen Position auf der Platte nicht anrührt, oder? Also dürfte es nach meinem Verständnis nicht zu einer Defragmentierung kommen, wenn die Platte immer mehr gefüllt wird.
Wenn genuegend Platz auf der Platte ist, sollte die relative Fragmentierung eigentlich abnehmen, es sei denn, neu angelegte Daten werden mit dem gleichen Fragmentierungsgrad geschrieben. Das ext Filesystem ist relativ gut im Vermeiden von Fragmentierung, es hat da ein paar ausgekluegelte Eigenschaften. Nachlesen kann man das z.B., wenn Du den Links auf http://e2fsprogs.sourceforge.net/ext2.html folgst (es gab allerdings ein paar Aenderungen seit Einfuehrung von ext2). Auch Wikipedia (http://en.wikipedia.org/wiki/Ext3) hat eine recht praegnante Zusammenstellung der Eigenschaften. Ext4 wird wohl weiter verbesserte Eigenschaften zum Vermeiden von Fragmentierung haben, es wird soweit ich weiss allerdings trotzdem mit einem online Defragmentierungstool daherkommen, zumindest war das im Gespraech. Ich nutze ext2/ext3 neben xfs schon sehr lange und habe es noch nie fuer noetig erachtet, das ext2/3 Filesystem zu defragmentieren. Allerdings messe ich die Performance auch nicht direkt - ein Performanceverlust muesste mir insofern quasi schon bei der alltaeglichen Arbeit auffallen, damit ich reagiere...
[...] Auf der Platte lungern tausende kleine Dateien rum, weil das System als Fileserver über Samba tätig ist. Hin und wieder mache ich Experimente mit Lazarus und Delphi. Ich arbeite an einem elektronische Dokumentenordner... Die Platte war nie über 60% belegt.
Samba koennte vielleicht etwas mit der Sache zu tun haben...? Cheers, Th. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
From: "Thomas Hertweck" Sent: Wednesday, September 24, 2008 11:43 PM
Alex Winzer wrote:
[...] Was heißt langsam selbst defragmentieren?
Sorry, das war vielleicht etwas irrefuehrend. Du solltest Dir nicht vorstellen, dass im Hintergrund und transparent fuer einen User aktiv Bloecke umkopiert werden - soweit ich weiss, beherrscht das ext Filesystem so etwas nicht (im Gegensatz zu anderen Filesystemen; unser Cluster-Filesystem kopiert z.B. aktiv Dateien/Dateifragmente um).
Wo kann ich dazu mal was lesen? [...]
Wenn genuegend Platz auf der Platte ist, sollte die relative Fragmentierung eigentlich abnehmen, es sei denn, neu angelegte Daten werden mit dem gleichen Fragmentierungsgrad geschrieben. Das ext Filesystem ist relativ gut im Vermeiden von Fragmentierung, es hat da ein paar ausgekluegelte Eigenschaften. Nachlesen kann man das z.B., wenn Du den Links auf http://e2fsprogs.sourceforge.net/ext2.html folgst (es gab allerdings ein paar Aenderungen seit Einfuehrung von ext2). Auch Wikipedia (http://en.wikipedia.org/wiki/Ext3) hat eine recht praegnante Zusammenstellung der Eigenschaften. Ext4 wird wohl weiter verbesserte Eigenschaften zum Vermeiden von Fragmentierung haben, es wird soweit ich weiss allerdings trotzdem mit einem online Defragmentierungstool daherkommen, zumindest war das im Gespraech.
Ich nutze ext2/ext3 neben xfs schon sehr lange und habe es noch nie fuer noetig erachtet, das ext2/3 Filesystem zu defragmentieren. Allerdings messe ich die Performance auch nicht direkt - ein Performanceverlust muesste mir insofern quasi schon bei der alltaeglichen Arbeit auffallen, damit ich reagiere...
Nur als Beispiel: Ich habe es nicht gemessen. Aber das Compilieren und linken mit FPC dauerte mit der Zeit immer länger.
[...] Auf der Platte lungern tausende kleine Dateien rum, weil das System als Fileserver über Samba tätig ist. Hin und wieder mache ich Experimente mit Lazarus und Delphi. Ich arbeite an einem elektronische Dokumentenordner... Die Platte war nie über 60% belegt.
Samba koennte vielleicht etwas mit der Sache zu tun haben...?
Das vermute ich sehr stark! Ich hatte dazu mal einen Artikel gelesen, dass es wohl Probleme mit Samba und dem Preallocation von ext3 geben würde. Das scheint zu stimmen. Es wurde geraten, auf ext4 umzusteigen: Ich warte und warte und warte ... Habe es schon mal auf einem Testsystem genutzt. Mir fehlt aber der Mut, es produktiv einzusetzen. Nach der nächtlichen Kopier-Session (übrigens mittels Midnight Commander), sieht es jetzt so aus: /dev/mapper/nvidia_dbbfdiea_part13: ***** FILE SYSTEM WAS MODIFIED ***** /dev/mapper/nvidia_dbbfdiea_part13: 96091/24870912 files (1.1% non-contiguous), 28654809/49715142 blocks Ein Spitzenwert, den ich auf keiner meiner ext3-Partitionen mehr habe. Ich habe nach dem Wegkopieren nut 2 Verzeichnisse auf der Partition gelassen: lost+found und RECYCLER für das Samba vfs. Non-contiguos betrug danach immer noch über 10%. Das hat mich doch verwundert. Ich würde die Performance mal Testen. Dazu gibt es bestimmt ein Programm unter Linux. Könnt ihr mir da auch helfen? Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Thomas Hertweck, Mittwoch, 24. September 2008 20:50:
Die Frage ist, hast Du merkliche Performance-Probleme? Unter "normalen" Umstaenden ist ein Defragmentieren eines ext Filesystems naemlich nicht erforderlich. Wenn genug Platz ist, kann sich ein ext Filesystem quasi auch langsam selbst defragmentieren.
Da hat vor einiger Zeit mal die ct was dazu geschrieben. Es ging um eine Partition, auf der ein Cyrus-Imap-Server seinen Spool hatte, und die bei weitem noch nicht voll war. Ich erinnere mich nicht mehr genau, aber Quintessenz war, daß es durchaus nützlich ist zu defragmentieren, indem man die ganzen Daten runter und dann wieder draufkopiert. Das soll das IO um den Faktor 2 oder 3 gesenkt haben. Wie gesagt IIRC, vielleicht weiß jemand hier genaueres. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann schrieb:
Thomas Hertweck, Mittwoch, 24. September 2008 20:50:
Die Frage ist, hast Du merkliche Performance-Probleme? Unter "normalen" Umstaenden ist ein Defragmentieren eines ext Filesystems naemlich nicht erforderlich. Wenn genug Platz ist, kann sich ein ext Filesystem quasi auch langsam selbst defragmentieren.
Da hat vor einiger Zeit mal die ct was dazu geschrieben. Es ging um eine Partition, auf der ein Cyrus-Imap-Server seinen Spool hatte, und die bei weitem noch nicht voll war. Ich erinnere mich nicht mehr genau, aber Quintessenz war, daß es durchaus nützlich ist zu defragmentieren, indem man die ganzen Daten runter und dann wieder draufkopiert. Das soll das IO um den Faktor 2 oder 3 gesenkt haben.
Wie gesagt IIRC, vielleicht weiß jemand hier genaueres.
Hier zu finden c't 14/04, Seite 199 So wie ich das in Erinnerung habe, bringt was, aber nur in Ausnahmefällen, und dann auch nur marginal Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Manfred Kreisl schrieb:
Andre Tann schrieb:
Thomas Hertweck, Mittwoch, 24. September 2008 20:50:
Die Frage ist, hast Du merkliche Performance-Probleme? Unter "normalen" Umstaenden ist ein Defragmentieren eines ext Filesystems naemlich nicht erforderlich. Wenn genug Platz ist, kann sich ein ext Filesystem quasi auch langsam selbst defragmentieren.
Da hat vor einiger Zeit mal die ct was dazu geschrieben. Es ging um eine Partition, auf der ein Cyrus-Imap-Server seinen Spool hatte, und die bei weitem noch nicht voll war. Ich erinnere mich nicht mehr genau, aber Quintessenz war, daß es durchaus nützlich ist zu defragmentieren, indem man die ganzen Daten runter und dann wieder draufkopiert. Das soll das IO um den Faktor 2 oder 3 gesenkt haben. Wie gesagt IIRC, vielleicht weiß jemand hier genaueres.
Hier zu finden c't 14/04, Seite 199 Ähhm, der war's wohl nicht. Aber an den von Andre erwähnten Artikel kann ich mich sehr wohl erinnern ;-)
Sorry für die Irreführung :-( Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
From: "Manfred Kreisl", Thursday, September 25, 2008 10:10 AM Manfred Kreisl schrieb:
Andre Tann schrieb:
Thomas Hertweck, Mittwoch, 24. September 2008 20:50:
Die Frage ist, hast Du merkliche Performance-Probleme? Unter "normalen" Umstaenden ist ein Defragmentieren eines ext Filesystems naemlich nicht erforderlich. Wenn genug Platz ist, kann sich ein ext Filesystem quasi auch langsam selbst defragmentieren.
Da hat vor einiger Zeit mal die ct was dazu geschrieben. Es ging um eine Partition, auf der ein Cyrus-Imap-Server seinen Spool hatte, und die bei weitem noch nicht voll war. Ich erinnere mich nicht mehr genau, aber Quintessenz war, daß es durchaus nützlich ist zu defragmentieren, indem man die ganzen Daten runter und dann wieder draufkopiert. Das soll das IO um den Faktor 2 oder 3 gesenkt haben. Wie gesagt IIRC, vielleicht weiß jemand hier genaueres.
Hier zu finden c't 14/04, Seite 199 Ähhm, der war's wohl nicht. Aber an den von Andre erwähnten Artikel kann ich mich sehr wohl erinnern ;-)
Sorry für die Irreführung :-(
Überhaupt kein Problem :-) Fürs Archiv: Ich habe hier etwas gefunden, das dem Artikel nah kommt: http://www.heise.de/open/Das-Dateisystem-Ext3-tunen--/artikel/104859/0 Und doch noch ein Tool (bislang von mir nicht gestestet): https://launchpad.net/fidefrag Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Alex Winzer schrieb:
From: "Manfred Kreisl", Thursday, September 25, 2008 10:10 AM
Sorry für die Irreführung :-(
Überhaupt kein Problem :-)
Fürs Archiv: Ich habe hier etwas gefunden, das dem Artikel nah kommt: http://www.heise.de/open/Das-Dateisystem-Ext3-tunen--/artikel/104859/0 Ja, genau, der kommt dem nicht nur nahe, der ist es exakt
Und doch noch ein Tool (bislang von mir nicht gestestet): https://launchpad.net/fidefrag
Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
2008/9/25 Andre Tann
Ich erinnere mich nicht mehr genau, aber Quintessenz war, daß es durchaus nützlich ist zu defragmentieren, indem man die ganzen Daten runter und dann wieder draufkopiert. Das soll das IO um den Faktor 2 oder 3 gesenkt haben.
Man könnte auch xfs benutzen. Dafür gibt's dann auch 'nen Optimierer (xfs_fsr). Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
Thomas Hertweck, Mittwoch, 24. September 2008 20:50:
Die Frage ist, hast Du merkliche Performance-Probleme? Unter "normalen" Umstaenden ist ein Defragmentieren eines ext Filesystems naemlich nicht erforderlich. Wenn genug Platz ist, kann sich ein ext Filesystem quasi auch langsam selbst defragmentieren.
Da hat vor einiger Zeit mal die ct was dazu geschrieben. Es ging um eine Partition, auf der ein Cyrus-Imap-Server seinen Spool hatte, und die bei weitem noch nicht voll war. Ich erinnere mich nicht mehr genau, aber Quintessenz war, daß es durchaus nützlich ist zu defragmentieren, indem man die ganzen Daten runter und dann wieder draufkopiert. Das soll das IO um den Faktor 2 oder 3 gesenkt haben.
Wie gesagt IIRC, vielleicht weiß jemand hier genaueres.
Ne, Du hast schon recht. Unter gewissen Umstaenden kann es durchaus Sinn machen, zu "defragmentieren". Deswegen auch die Frage nach Performance Problemen. Im Alltag eines normalen Users bringt es erfahrungsgemaess so gut wie gar nichts. Allerdings scheinen Datenbank-Applikationen und sonstige Server-Software, die viele Daten handhaben muessen (wie IMAP Server) etwas besonderes zu sein in der Art und Weise, wie sie Dateien ablegen/adressieren. Ich erinnere mich, dass es hier auf der Liste dazu auch schon Diskussionen gab, vielleicht einfach mal im Archiv suchen. Eventuell faellt Samba eben auch in diese Kategorie von Applikationen?!? Cheers, Th. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
From: "Thomas Hertweck" Sent: Thursday, September 25, 2008 9:23 PM>
Andre Tann wrote:
Thomas Hertweck, Mittwoch, 24. September 2008 20:50:
Die Frage ist, hast Du merkliche Performance-Probleme? Unter "normalen" Umstaenden ist ein Defragmentieren eines ext Filesystems naemlich nicht erforderlich. Wenn genug Platz ist, kann sich ein ext Filesystem quasi auch langsam selbst defragmentieren.
Da hat vor einiger Zeit mal die ct was dazu geschrieben. Es ging um eine Partition, auf der ein Cyrus-Imap-Server seinen Spool hatte, und die bei weitem noch nicht voll war. Ich erinnere mich nicht mehr genau, aber Quintessenz war, daß es durchaus nützlich ist zu defragmentieren, indem man die ganzen Daten runter und dann wieder draufkopiert. Das soll das IO um den Faktor 2 oder 3 gesenkt haben.
Wie gesagt IIRC, vielleicht weiß jemand hier genaueres.
Ne, Du hast schon recht. Unter gewissen Umstaenden kann es durchaus Sinn machen, zu "defragmentieren". Deswegen auch die Frage nach Performance Problemen. Im Alltag eines normalen Users bringt es erfahrungsgemaess so gut wie gar nichts. Allerdings scheinen Datenbank-Applikationen und sonstige Server-Software, die viele Daten handhaben muessen (wie IMAP Server) etwas besonderes zu sein in der Art und Weise, wie sie Dateien ablegen/adressieren. Ich erinnere mich, dass es hier auf der Liste dazu auch schon Diskussionen gab, vielleicht einfach mal im Archiv suchen. Eventuell faellt Samba eben auch in diese Kategorie von Applikationen?!?
Es liegt an Samba. Dazu gab es mal einen sehr interessanten Artikel dazu, dass Samba bei ext3 sehr stark fragmentiert. Ich habe leider den Links nicht mehr. Aber es liegt wohl daran, dass ext3 das hier nicht hat: http://en.wikipedia.org/wiki/Ext4#Delayed_allocation Das ist ein Grund, warum ich seit über einem Jahr darauf warte, dass ext4 endlich auch als für produktive Umgebungen freigegeben erklärt wird: http://lists.opensuse.org/opensuse-de/2007-10/msg00107.html Wie gesagt: Ich habe viele kleine Dateien, die aber größer als 1 Block sind. Außerdem habe ich - aus Performance-Gründen - die "Eigene Dateien"- Verzeichnisse aller angeschlossenen WinXP-Clients auf den Server umgelenkt. Nach dem umkopieren geht es merklich schneller. Wenn ich vorher z.B. bloß eine Datei löschen wollte, musste ich mind. eine Gedenksekunde warten. Evtl. war es auch nur eine halbe. Aber es nervte trotzdem. Ich mache mir nur Gedanken, wie ich das "Problem" zukünftig löse. Denn das mit dem Hin-Und-Her-Kopieren war eine ziemliche Aktion. Es geht immerhin um ca. 350 GB. Ich habe fidefrag noch nicht zum Laufen bekommen. Aber das schaffe ich auch noch!!! Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
From: "Alex Winzer" Sent: Friday, September 26, 2008 10:15 AM
[...]
Ich habe fidefrag noch nicht zum Laufen bekommen. Aber das schaffe ich auch noch!!!
Fürs Archiv: 1. Schauen, ob python und bzr installiert sind; ggf. nachholen 2. Besser root-Rechte besorgen 2. *bzr branch lp:fidefrag* aufrufen (fidefrag ist dann im Unterverzeichnis /fidefrag/src des home-Verzeichnisses des jeweiligen users) 3. z.B. über */root/fidefrag/src/fidefrag.py* starten 4. Wer es bequem mag, kann 2 Zeilen jeweils + Enter tippen: echo 'python /root/fidefrag/src/fidefrag.py $1 $2'>/usr/local/bin/defrag chmod 700 /usr/local/bin/defrag Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Alex Winzer schrieb:
From: "Thomas Hertweck" Sent: Thursday, September 25, 2008 9:23 PM>
Andre Tann wrote:
Thomas Hertweck, Mittwoch, 24. September 2008 20:50:
Die Frage ist, hast Du merkliche Performance-Probleme? Unter "normalen" Umstaenden ist ein Defragmentieren eines ext Filesystems naemlich nicht erforderlich. Wenn genug Platz ist, kann sich ein ext Filesystem quasi auch langsam selbst defragmentieren.
Da hat vor einiger Zeit mal die ct was dazu geschrieben. Es ging um eine Partition, auf der ein Cyrus-Imap-Server seinen Spool hatte, und die bei weitem noch nicht voll war. Ich erinnere mich nicht mehr genau, aber Quintessenz war, daß es durchaus nützlich ist zu defragmentieren, indem man die ganzen Daten runter und dann wieder draufkopiert. Das soll das IO um den Faktor 2 oder 3 gesenkt haben.
Wie gesagt IIRC, vielleicht weiß jemand hier genaueres.
Ne, Du hast schon recht. Unter gewissen Umstaenden kann es durchaus Sinn machen, zu "defragmentieren". Deswegen auch die Frage nach Performance Problemen. Im Alltag eines normalen Users bringt es erfahrungsgemaess so gut wie gar nichts. Allerdings scheinen Datenbank-Applikationen und sonstige Server-Software, die viele Daten handhaben muessen (wie IMAP Server) etwas besonderes zu sein in der Art und Weise, wie sie Dateien ablegen/adressieren. Ich erinnere mich, dass es hier auf der Liste dazu auch schon Diskussionen gab, vielleicht einfach mal im Archiv suchen. Eventuell faellt Samba eben auch in diese Kategorie von Applikationen?!?
Es liegt an Samba. Dazu gab es mal einen sehr interessanten Artikel dazu, dass Samba bei ext3 sehr stark fragmentiert. Ich habe leider den Links nicht mehr. Aber es liegt wohl daran, dass ext3 das hier nicht hat: http://en.wikipedia.org/wiki/Ext4#Delayed_allocation
Das ist ein Grund, warum ich seit über einem Jahr darauf warte, dass ext4 endlich auch als für produktive Umgebungen freigegeben erklärt wird: http://lists.opensuse.org/opensuse-de/2007-10/msg00107.html
Wie gesagt: Ich habe viele kleine Dateien, die aber größer als 1 Block sind. Außerdem habe ich - aus Performance-Gründen - die "Eigene Dateien"- Verzeichnisse aller angeschlossenen WinXP-Clients auf den Server umgelenkt. Nach dem umkopieren geht es merklich schneller. Wenn ich vorher z.B. bloß eine Datei löschen wollte, musste ich mind. eine Gedenksekunde warten. Evtl. war es auch nur eine halbe. Aber es nervte trotzdem. Ich mache mir nur Gedanken, wie ich das "Problem" zukünftig löse. Denn das mit dem Hin-Und-Her-Kopieren war eine ziemliche Aktion. Es geht immerhin um ca. 350 GB.
du solltest über XFS oder so was nachdenken! Ein Problem zur Gewschwindigkeit ist ext3 ... ext2 ist da schneller...aber eben ohne Journal! Theoretisch müsstest du jeden Tag umkopieren :-)
Ich habe fidefrag noch nicht zum Laufen bekommen. Aber das schaffe ich auch noch!!!
Defrag ist zum überwiegenden Teil die Werbebotschaft... bei FAT (unter DOS) nützt es viel.. kritischer ist eher das Pufferverhalten... Aus Sicherheitsgründen NULL Puffer... aus Zeitgründen VIEL Puffer...! Was hast du bei Samba als Puffer-Delay eingestellt ?
Gruß, Alex
Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
From: "Fred Ockert"
Alex Winzer schrieb:
From: "Thomas Hertweck" Sent: Thursday, September 25, 2008 9:23 PM>
Andre Tann wrote:
Thomas Hertweck, Mittwoch, 24. September 2008 20:50:
[...]
Ne, Du hast schon recht. Unter gewissen Umstaenden kann es durchaus Sinn machen, zu "defragmentieren". [...]
Es liegt an Samba. Dazu gab es mal einen sehr interessanten Artikel dazu, dass Samba bei ext3 sehr stark fragmentiert. Ich habe leider den Links nicht mehr. Aber es liegt wohl daran, dass ext3 das hier nicht hat: http://en.wikipedia.org/wiki/Ext4#Delayed_allocation
Das ist ein Grund, warum ich seit über einem Jahr darauf warte, dass ext4 endlich auch als für produktive Umgebungen freigegeben erklärt wird: http://lists.opensuse.org/opensuse-de/2007-10/msg00107.html
[...]
du solltest über XFS oder so was nachdenken! Ein Problem zur Gewschwindigkeit ist ext3 ... ext2 ist da schneller...aber eben ohne Journal! Theoretisch müsstest du jeden Tag umkopieren :-)
Defrag ist zum überwiegenden Teil die Werbebotschaft... bei FAT (unter DOS) nützt es viel.. kritischer ist eher das Pufferverhalten... Aus Sicherheitsgründen NULL Puffer... aus Zeitgründen VIEL Puffer...!
Was hast du bei Samba als Puffer-Delay eingestellt ?
Überhaupt nichts. -> den Standardwert. Dieser Schalter war mir nicht bekannt, werde mich mal belesen. Danke für den Tip. Eventuell kann man das Problem damit ja etwas abfedern. Gruß, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
From: "Alex Winzer"
From: "Fred Ockert"
[...]
Was hast du bei Samba als Puffer-Delay eingestellt ?
Überhaupt nichts. -> den Standardwert. Dieser Schalter war mir nicht bekannt, werde mich mal belesen. Danke für den Tip. Eventuell kann man das Problem damit ja etwas abfedern.
Habe leider nichts gefunden. Weder mit Buffer delay noch sonstwie. Kann mir mal jemand einen links schicken, in dem der Schalter beschrieben wird. Denn auch in der Samba-Doc bin ich nicht fündig geworden. Gruß und Danke, Alex -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Alex Winzer schrieb:
From: "Alex Winzer"
From: "Fred Ockert"
[...]
Was hast du bei Samba als Puffer-Delay eingestellt ?
Überhaupt nichts. -> den Standardwert. Dieser Schalter war mir nicht bekannt, werde mich mal belesen. Danke für den Tip. Eventuell kann man das Problem damit ja etwas abfedern.
Habe leider nichts gefunden. Weder mit Buffer delay noch sonstwie. Kann mir mal jemand einen links schicken, in dem der Schalter beschrieben wird. Denn auch in der Samba-Doc bin ich nicht fündig geworden.
google -> smb.conf -> Socket options zum Beispiel ...
Gruß und Danke, Alex
Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (7)
-
Alex Winzer -
Andre Tann -
Christian Brabandt -
Fred Ockert -
Manfred Kreisl -
Martin Schröder -
Thomas Hertweck