Moin Ich habe ca 70.000 Emails in zwei Konten, die ich gerne gescheit archivieren würde. Gesammelt wurden die Mails mit Thunderbird, daher in mbox Dateien (30GB). Was jetzt gemacht werden soll: - beide Ordner zusammenführen - Duplikate löschen - Anhänge in einem Ordner auslagern Ich bin davon ausgegangen, dass dies alles mit Thunderbird zu machen ist. Leider nicht. Schon das Zusammenführen der Konten lässt TB immer einfrieren (i5 mit 8GB RAM, SSD) Duplikate kann ich finden (sind viele), aber nicht löschen Anhänge in Ordner geht gar nicht, weil alle AddOns völlig veraltet sind Was ist also ein Client, der mit all diesen Dingen keine Probleme hat und die mbox Dateine lesen kann? Sollte Freeware sein, kann aber auch ein bisschen was kosten. Gruß Kolja
Ich benutze MailStore Home, vielleicht ist das was für Dich? Geht in gratis Home-Version nicht über Netzlaufwerke. Gruss Chregu
Ich würde das scripten, Perl oder Python, ggf. auch eine Datenbank als Zwischenspeicher. Bei letzterer hättest du die Ent-Duplikatisierung einfach, indem du die Message-ID als primary key benutzt. Das ist sicher auch bisschen Arbeit, aber hätte eine gute Chance, dass man die Anforderungen wirklich wunschgemäß umsetzen kann.
Zum Archivieren, Suchen, Migrieren und Konvertieren nutze ich MailStore Home. Es gibt nix besseres. Für de Duplikate weiß ich allerdings nichts. Es gibt viel Pröddel (ich nutze Outlook), nichts funktioniert wirklich. Da bin ich auch für Ideen offen ;)
Der einzige Client, den ich kenne, der wirklich gut mit vielen Mails zurecht kommt, ist Roundcube. Ist aber kein lokales Mailprogramm in dem sinne, sondern eine Webanwendung, die bei mir zuhause auf meinem eigenen Mailserver läuft. Zum speichern der Mails verwende ich aber nicht mbox, sondern Maildir. Damit lässt es sich auch viel einfacher arbeiten, auch ohne spezielle Tools, sind ja nur ein paar Ordner mit Mails drin. Vermutlich ist der Zugriff auf viele Mails mit Maildir auch besser. Verzeichnis/Postfach mit 457124 Mails, beliebige Seite mit einem Ausschnitt von 100 Mails drauf in nur 2-3 Sekunden geladen. Kleinere Verzeichnisse in 1-2 Sekunden. Lokal hab ich momentan auch Thunderbird, aber ob ich dort mbox oder was anderes habe weiss ich gerade nicht, da darf ich nicht auf die Verzeichnisse mit vielen Mails klicken, sonst hängt das ein paar ein zwei Minuten. Eventuell sollte ich da auch mal was machen.
MailStore klingt ganz gut, will sich aber nicht installieren lassen. Es kommt immer die Fehlermeldung "Verzeichnis nicht leer". Habe es aber gerade erst erstellt. RoundCube kenne ich, aber ich möchte jetzt nicht extra ne Webserver dafür aufsetzten müssen. Ich bleib auf der Suche
Wenn es local installiert wird (nicht portabel) dann gehts, aber das Auswählen einer mbox Datei ergibt: "Die durchgeführte Aktion hat mehr Zeit in Anspruch genommen als erwartet" Und das war die kleinere Datei. edit: Auch der Import über Mozilla geht nicht. Mein Profil wird zwar gefunden, aber "Es ist ein Fehler aufgetreten"
:
Bearbeitet durch User
Ich hatte das bei Outlookfiles auch, ich hab es dann auf Outlook zugreifen lassen, da gings. Evtl. geht das mit TB auch? Mein Rekord waren allerdings nur ~25GB. Mag sein, das es größer auch Probleme bekommt.
Christian M. schrieb: > Ich benutze MailStore Home, Vers 4. nutze ich bereits über 10 Jahre. Die neueren Versionen habe ich auch getestet, sind noch nicht notwendig. Die Einarbeitungszeit ist gering. Es erkennt Duplikate. Alle 2 bis 3 Jahre lagere ich aus. Je 3 POP- und 3 IMAP-Konten kann man einrichten. Die werden zeitgesteuert automatisch abgeholt. Momentan speichert es ca. 150.000 eMails.
Nochmal installiert und jetzt liest er die Mais ein! Das wird dauern :-)
Kolja L. schrieb: > Was ist also ein Client, der mit all diesen Dingen keine Probleme hat > und die mbox Dateine lesen kann? Hallo, evtl. hilft Dir diese Seite: https://unix.stackexchange.com/questions/131977/imap-folders-how-big-is-too-big
Mhh, es sind alles IMAP Folder, aber die sind ja schon lokal gespeichert. Für die 2GB Grenze ist es wohl zu spät... MailStore hat in einer Stunde nicht ganz 3.000 Mail eingelesen. Dauert also noch etwas länger...
So, ist durchgelaufen. Leider sind von dem großen Konto (gmail) keine Mails importiert worden...
Ich habe für diesen Fall ein paar Zeilen Xojo (ehem. RealBasic/RealStudio) benutzt. Im Sprachumfang gibt es eine Klasse "Email". In Verbindung mit einem Socket (TCP-Klasse mit wahlweise POP3 oder IMAP-Protokoll obendrauf) hole ich mir die einzelnen Mails jeweils komplett als RAW-Datenblock vom Server und speichere diese als Text-Dateien. Das geht deshalb, weil Mail ein rein textbasiertes Medium ist und alle Inhalte jeweils als ein einziger langer, strukturierter Text vorliegen: Header, HTML, Plaintext inkl. scheinbar binärer Bestandteile u. Anhänge. Die sind in Base64 (also auch nur Text). Ich bin sicher, das geht in anderen Sprachen/Scripten ganz genau so zu machen. Gibt man diesen Dateien noch die Endung ".eml" hat man genau das, was MS und zahlreiche andere Mailserver bzw. -Clients und Archivprogramme auch nur machen. Das ist nämlich ein verbreiteter Standard, den man dann mit eigenem Code oder anderer fertiger Software beliebeig weiterverarbeiten kann.
DPA schrieb: > Der einzige Client, den ich kenne, der wirklich gut mit vielen Mails > zurecht kommt, ist Roundcube. Ist aber kein lokales Mailprogramm in dem > sinne, sondern eine Webanwendung, die bei mir zuhause auf meinem eigenen > Mailserver läuft. Zum speichern der Mails verwende ich aber nicht mbox, > sondern Maildir. Damit lässt es sich auch viel einfacher arbeiten, auch > ohne spezielle Tools, sind ja nur ein paar Ordner mit Mails drin. > Vermutlich ist der Zugriff auf viele Mails mit Maildir auch besser. Maildir ist bei > 70k Mails keine gute Idee, denn: " Jede E-Mail wird dabei als eigene Datei in fest definierten Verzeichnissen repräsentiert." Quelle: https://de.wikipedia.org/wiki/Maildir D.h. da belegt schon eine einzige Mail mit vielleicht 30 Zeichen Text einen ganzen Cluster des Dateisystems. Also anstatt ein paar Bytes gleich 4048 Bytes oder, je nach Clustergröße, noch mehr. Es hat schon seinen Grund, warum E-Mail Programme nicht alle Maildir verwenden und stattdessen andere, kompaktere Lösungen wählen.
Jörg W. schrieb: > Ich würde das scripten, Perl oder Python, Wenn das gewerbliche Mails sind, die er 10 Jahre aufbewahren muss, würde ich lieber etwas nehmen, dass auch erprobt ist. Da reicht ein Fehler im Parser und schon hat man Datensalat. > ggf. auch eine Datenbank als > Zwischenspeicher. Bei letzterer hättest du die Ent-Duplikatisierung > einfach, indem du die Message-ID als primary key benutzt. Ein E-Mailprogramm das die Mails von Thunderbird importieren kann und selbst ein ausgereiftes Datenbankmanagementsystem zum Speichern verwendet, wäre wohl die sinnvollste Lösung. @TS Schau dir mal diese Liste an, vielleicht findest du etwas passendes: https://en.wikipedia.org/wiki/Comparison_of_email_clients#Database,_folders_and_customization Und mach vor allem von den bestehenden Daten ein Backup für die Daueraufbewahrung. Sichere auch die dazu passende Thunderbird Version. Verlasse dich nicht darauf, dass der Import in ein anderes E-Mail Programm und das finden der Duplikate fehlerfrei funktioniert. Solange du ein Backup der Originaldaten hast, hast du zumindest die Möglichkeit immer wieder dran zu kommen. Zumindest gilt das, wenn die Daten für dich wichtig sind. Wenn Speicherplatz keine Rolle spielt, dann kann Maildir in der Tat ein Vorteil sein. Einzelne Dateien pro Mail sind in dieser Hinsicht nämlich sehr unproblematisch, auch wenn sie jede Menge Speicherplatz verschwenden.
Kolja L. schrieb: > Moin > > Ich habe ca 70.000 Emails in zwei Konten, die ich gerne gescheit > archivieren würde. > Gesammelt wurden die Mails mit Thunderbird, daher in mbox Dateien > (30GB). > > Was jetzt gemacht werden soll: > - beide Ordner zusammenführen > - Duplikate löschen > - Anhänge in einem Ordner auslagern > Was ist also ein Client, der mit all diesen Dingen keine Probleme hat > und die mbox Dateine lesen kann? > The Bat kann mit Mbox importieren. Mein Hauptmailaccount hat in Summe ca - 63k Mails (gesendete und empfangene), in Summe muß the Bat 70k Mails in 7 "Konten" managen. Mails werden durch Filter automatisch in die entsprechenden "Ordner" (auch Kontoübergreifend) verschoben. Ob die Filter vorher oder später aktiviert werden ist egal, das geht alles ziemlich schnell. Duplikate löschen, Komprimieren oder auf Integrität prüfen geht ratzfatz, selbst mit einer magnetischen Platte, Anhänge werden dort gespeichert wo Du sie gespeichert haben willst und zusammenführen unterschiedlicher Accounts ist auch kein Problem - Mails aus dem einen Account markieren, kopieren und im anderen Account einfügen. Fertig. Allerdings arbeite ich nach wie vor mit Pop3/SMTP, also nix mit IMAP (ist hier nicht sinnvoll, da die Mails lokal und nicht auf irgendeinem fremden Server liegen sollen). Suchen und Finden von Mails geht sehr gut und schnell wenn ein halbwegs brauchbarer Suchbegriff bekannt ist, es kann Ordner und Kontoübergreifend oder auch nur in einem Ordner gesucht werden.... Das Programm kostet ein bischen was doch ich komme weder mit Outlook noch mit Thunderbird klar (Outook muß ich bei einem Kunden verwenden, Thunderbird sehe ich bei anderen... Nein Danke...) Und Abstürze? Mit der Version die ich habe sind mit bisher keine passiert (auf 5 verschiedenen Rechnern) hth
Nano schrieb: > D.h. da belegt schon eine einzige Mail mit vielleicht 30 Zeichen Text > einen ganzen Cluster des Dateisystems. Man sollte es ja vielleicht auch nicht auf FAT-Dateisystemen mit ihren berüchtigten Clustern benutzen. ;-) Bessere Filesysteme haben dafür bessere Konzepte … Allerdings einen Plattenblock wird jede Datei natürlich schon minimal belegen, das können auf neueren Platten dann auch 4 KiB sein. Mails mit nur 30 Zeichen gibt es jedoch praktisch nicht. Gerade mal nachgesehen, die kleinste Mail, die ich so auf die Schnelle in meiner Inbox sehe (zwei zitierte Zeilen, zwei eigene Zeilen Text) hat schon mal knapp 4 KiB – dank DKIM, "Received" und was da noch so alles drin steht in Header und Signatur. Wenn die Mails von einem Exchange-Server kamen, kannst du dich vor Metadaten im Header gar nicht retten, unter 10 … 12 KiB läuft da gar nichts. Nano schrieb: >> Ich würde das scripten, Perl oder Python, > > Wenn das gewerbliche Mails sind, die er 10 Jahre aufbewahren muss, würde > ich lieber etwas nehmen, dass auch erprobt ist. > Da reicht ein Fehler im Parser und schon hat man Datensalat. Dass man solch eine Aktion grundsätzlich nur auf einer Kopie der Daten laufen lässt, sollte klar sein. Außerdem würde ich schon aus Gründen der Verarbeitungszeit so einen Script erstmal auf einem kleinen Extrakt der originalen Maildaten laufen lassen, bis ich das Vertrauen habe, dass er das tut, was ich mir vorstelle.
Nano schrieb: > Maildir ist bei > 70k Mails keine gute Idee, denn: > > " Jede E-Mail wird dabei als eigene Datei in fest definierten > Verzeichnissen repräsentiert." > Quelle: https://de.wikipedia.org/wiki/Maildir > > D.h. da belegt schon eine einzige Mail mit vielleicht 30 Zeichen Text > einen ganzen Cluster des Dateisystems. > > Also anstatt ein paar Bytes gleich 4048 Bytes oder, je nach > Clustergröße, noch mehr. Das ist nicht viel. Ausserdem enthalten Mails immer auch noch Header. Auch ohne Inhalt können da schon mal 2000 bis 3000 Bytes zusammenkommen. Zudem sind bei derart vielen Mails die meisten sicher nicht leer. Gerade mal bei mir auf dem Server nachgesehen:
1 | root@pelican:/home/daniel# ls -1 Maildir/.*/{cur,new}/ | wc -l
|
2 | 664434 |
3 | root@pelican:/home/daniel# du -hs Maildir/ |
4 | 8.3G Maildir/ |
5 | root@pelican:/home/daniel# du -hs --apparent-size Maildir/ |
6 | 7.0G Maildir/ |
Also rund 664434 bei mir insgesamt, zusätzlicher Speicherverbrauch bei rund 18.57%. Das ist nicht viel. Und seien wir mal ehrlich, 664434 Mails sind nur 8.3G, im Vergleich zu was ich sonst so auf meinem System habe ist das nichts. Zudem gibt es weitere Nachteile, so viele Mails stattdessen in eine Datei zu packen. Löscht man z.B. eine, muss ja das ganze File neu geschrieben werden. Je nach Dateiformat und anderen Faktoren ist auch das Abrufen einer Mail ineffizienter. (Edit: Dateisystem ist ext4.)
:
Bearbeitet durch User
Kolja L. schrieb: > Was ist also ein Client, der mit all diesen Dingen keine Probleme hat > und die mbox Dateine lesen kann? neomutt? (siehe auch https://mailman.neomutt.org/pipermail/neomutt-users-neomutt.org/2018-August/000392.html)
Jörg W. schrieb: > Man sollte es ja vielleicht auch nicht auf FAT-Dateisystemen mit ihren > berüchtigten Clustern benutzen. ;-) Bessere Filesysteme haben dafür > bessere Konzepte … Allerdings einen Plattenblock wird jede Datei > natürlich schon minimal belegen, das können auf neueren Platten dann > auch 4 KiB sein. Es gibt Filesysteme, die mehrere kleine Files in einen Block packen. Früher wäre für so einen Fall ReiserFS empfohlen worden. https://en.wikipedia.org/wiki/Block_suballocation Welches verwendest du denn? UFS2 gehört mit dazu.
A. K. schrieb: > Welches verwendest du denn? UFS2 gehört mit dazu. UFS (exakter: Berkeley FFS) konnte das schon länger (Stichwort: fragments, 1/8 eines normalen Blocks). Mittlerweile bin ich bei ZFS, habe aber leider von der Architektur dieses Dateisystems keine Ahnung. :) Benutze selbst auch kein Maildir (sondern nach wie vor Mbox), aber bei mir sind die Mailboxen auch nicht so riesig.
Jörg W. schrieb: > Nano schrieb: >> D.h. da belegt schon eine einzige Mail mit vielleicht 30 Zeichen Text >> einen ganzen Cluster des Dateisystems. > > Man sollte es ja vielleicht auch nicht auf FAT-Dateisystemen mit ihren > berüchtigten Clustern benutzen. ;-) Bessere Filesysteme haben dafür > bessere Konzepte … Allerdings einen Plattenblock wird jede Datei > natürlich schon minimal belegen, das können auf neueren Platten dann > auch 4 KiB sein. Ja, ich meinte eigentlich die Block Size. Cluster size ist eigentlich eine unter Windows übliche Terminology und wird dort synonym mit Block size und Allocation unit verwendet. Die Blocksize ist bei den meisten modernen Dateisystemen oftmals in Schritten von 512 Byte, 1k, 2k, 4k, 8k usw. frei wählbar, aber aufgrund der Größe moderner Datenträger nimmt man meist 4096 Bytes als Block size oder größer. Weiter oben hat sich übrigens ein Fehler eingeschlichen, ich habe 4048 Bytes geschrieben, meinte aber 4096 Bytes. > Mails mit nur 30 Zeichen gibt es jedoch praktisch nicht. Gerade mal > nachgesehen, die kleinste Mail, die ich so auf die Schnelle in meiner > Inbox sehe (zwei zitierte Zeilen, zwei eigene Zeilen Text) hat schon mal > knapp 4 KiB – dank DKIM, "Received" und was da noch so alles drin steht > in Header und Signatur. Wenn die Mails von einem Exchange-Server kamen, > kannst du dich vor Metadaten im Header gar nicht retten, unter 10 … 12 > KiB läuft da gar nichts. Das ist natürlich richtig, allerdings reicht bei einer Speicherung von 1 Datei pro Mail schon eine Größe von "Blocksize + 1 Byte" um einen ganzen "Block - 1 Byte" zu verschwenden. Man hat also auch Verluste, wenn die Dateien ein bisschen größer sind. Bei großen Mails fällt das natürlich nicht mehr so stark ins Gewicht, aber Mails haben dummerweise die Angewohnheit, dass sie eher klein sind und sich im Rahmen von wenigen kByte bewegen, also hat man am Ende der Datei immer Verschnitt. Speicherungsarten, die die Mails aneinander hängen und aus vielen Mails eine oder mehrere große Dateien machen sind da bezüglich dem Speicherplatzverbrauch effizienter. Der Nachteil ist dann allerdings die Fehleranfälligkeit. Dem Problem kann man aber etwas abmildern, in dem man ausgereifte Datenbankmanagementsysteme verwendet. Bei kaputtem Speicher können deren Datenbanken allerdings auch kaputt gehen. Bei einzelnen Dateien pro Mail kann das zwar auch passieren, aber der Schaden ist dann nicht so groß. Bei Dateisystemen wie ext3 und ext4 sollte man noch im Hinterkopf behalten, dass die Anzahl der verfügbaren Inodes begrenzt ist. Bei vielen kleinen Dateien besteht theoretisch die Gefahr, dass die einem also ausgehen bevor einem der Speicherplatz auf der Partition aus geht. Die Anzahl der freien inodes und inodes insgesamt kann man übrigens mit dem Befehl: sudo tune2fs -l /dev/{PARTITION} | grep -i inode anzeigen. Die Blocksize erhält man mit dem Befehl: sudo tune2fs -l /dev/mapper/vgubuntu-home | grep -i "Block size" Unter Windows geht das bei den für Windows bekannten Dateisystemen in der Powershell mit dem Befehl: Get-WmiObject -Class Win32_Volume | Select-Object Label, Blocksize | Format-Table -AutoSize > Nano schrieb: >>> Ich würde das scripten, Perl oder Python, >> >> Wenn das gewerbliche Mails sind, die er 10 Jahre aufbewahren muss, würde >> ich lieber etwas nehmen, dass auch erprobt ist. >> Da reicht ein Fehler im Parser und schon hat man Datensalat. > > Dass man solch eine Aktion grundsätzlich nur auf einer Kopie der Daten > laufen lässt, sollte klar sein. Schon klar, aber es ist möglich, dass sich Fehler einschleichen, die man bei einer kleinen Menge an Testdaten gar nicht merkt und man sich dann beim sichern vieler tausender Mails in falscher Sicherheit wiegt. Ausgereifte Import- und Exportfunktionen von E-Mail Programmen haben hier den Vorteil, dass die von tausenden von Benutzer schon benutzt wurden und der ein oder andere Fehler da dann sicher schon aufgefallen und behoben wurde. Eine Alternative dazu wäre, auf ausgereifte Bibliotheken zu setzen, die so etwas auch können. > Außerdem würde ich schon aus Gründen der > Verarbeitungszeit so einen Script erstmal auf einem kleinen Extrakt der > originalen Maildaten laufen lassen, bis ich das Vertrauen habe, dass er > das tut, was ich mir vorstelle. Das Skript kann nur so gut sein, wie du auch die verschiedenen Fälle von unterschiedlichen Testdaten abdeckst. Fehlt da ein Testszenario, dann könnte das unten durchschlüpfen und zu Problemen führen. Deswegen würde ich bei so kritischem Sachen, wie den geschäftlichen E-Mail Verkehr, zu etwas ausgereiftem greifen und die Originaldaten trotzdem noch als Backup irgendwo sichern.
Daniel A. schrieb: > Also rund 664434 bei mir insgesamt, zusätzlicher Speicherverbrauch bei > rund 18.57%. Das ist nicht viel. Und seien wir mal ehrlich, 664434 Mails > sind nur 8.3G, im Vergleich zu was ich sonst so auf meinem System habe > ist das nichts. Ich habe hier eine kleine ca. 14 GB große Partition für /var, die hat nur 960992 inodes. Bei 664434 Mails wäre das mittelfristig betrachtet schon recht knapp. Vor allem wenn man Geschäftsmails für AFAIK 10 Jahre vorrätig halten muss, könnte das noch zu einem Problem werden. Auf jeden Fall sollte man beim Anlegen der Partition darauf achte, dass der Vorrat an inodes groß genug ist, wenn man vor hat, sehr viele kleine Dateien auf der Partition zu speichern. Noch eine kleine Ergänzung: Mit dem Befehl "df -i" geht das mit dem Anzeigen der freien inodes übrigens besser, als das was ich zuvor geschrieben habe. > > Zudem gibt es weitere Nachteile, so viele Mails stattdessen in eine > Datei zu packen. Löscht man z.B. eine, muss ja das ganze File neu > geschrieben werden. Je nach Dateiformat und anderen Faktoren ist auch > das Abrufen einer Mail ineffizienter. Ja, das ist möglich. Anderseits könnte ein cleveres E-Mailprogramm auch 1 Datei für die Mails pro Monat, Quartal oder Jahr anlegen und die neueste Datei in den Speicher laden, dann geht der Zugriff recht schnell. Da gibt's schon einige Optimierungen und DBMS beachten so etwas auch.
Nano schrieb: > Das ist natürlich richtig, allerdings reicht bei einer Speicherung von 1 > Datei pro Mail schon eine Größe von "Blocksize + 1 Byte" um einen ganzen > "Block - 1 Byte" zu verschwenden. Im Mittel verschwendet man mit jeder Datei die Größe einer halben (kleinsten) Zuordnungseinheit. An i-nodes hätte ich wohl keinen Mangel:
1 | $ df -ih /home |
2 | Filesystem Size Used Avail Capacity iused ifree %iused Mounted on |
3 | zroot/home 365G 32G 334G 9% 334k 700M 0% /home |
Relativ zur Belegung des Speichers ist da praktisch noch gar nichts an i-nodes belegt. :-) Dass der Missbrauch des Dateisystems als Datenbank nicht unproblematisch ist, ist schon klar, aber selbst Usenet-Newsserver sind damit jahrelang problemlos klar gekommen. Sie haben dort lediglich eine Zwischenebene eingefügt, damit die Anzahl der Dateien pro Verzeichnis nicht ausufert.
Jörg W. schrieb: > zroot/home 365G 32G 334G 9% 334k 700M 0% /home Wie gut dass ZFS diese i-nodes nicht reserviert. Bei einer i-node pro 512 Bytes bliebe sonst nicht viel Raum für Daten. ;-)
:
Bearbeitet durch User
DPA schrieb: > A. K. schrieb: >> Bei einer i-node pro 512 Bytes > > Normalerweise gibt es eine inode Nummer pro Datei. Ja. Und solch eine ZFS dnode ist 512 Bytes gross. Mit 700M Nodes ist sein Filesystem also voll mit Verwaltungsinformation, völlig ohne Daten. Daher stammt dieses Pseudo-Limit. Mehr geht nicht.
:
Bearbeitet durch User
Jörg W. schrieb: > Dass der Missbrauch des Dateisystems als Datenbank nicht unproblematisch > ist, ist schon klar, So klar ist das nicht. Einige Filesysteme sind robuster als MySQLs Oldtimer Engine MyISAM.
A. K. schrieb: > Wie gut dass ZFS diese i-nodes nicht reserviert. :-) Ich habe auch Dateisysteme, die mehr i-node-Auslastung anzeigen, aber die sind insgesamt voller. Offenbar wird mit stärkerem Füllstand auch automatisch die maximal mögliche Anzahl an i-nodes reduziert. Yep, mal einen kurzen Test gemacht, kleines ZFS-Dateisystem angelegt und gefüllt, dabei immer ein df -ih mitlaufen lassen:
1 | Filesystem Size Used Avail Capacity iused ifree %iused Mounted on |
2 | zspool/foo 100M 90M 10M 90% 13k 21k 38% /var/spool/foo |
3 | zspool/foo 100M 92M 8.1M 92% 13k 17k 43% /var/spool/foo |
4 | zspool/foo 100M 94M 5.9M 94% 13k 12k 51% /var/spool/foo |
5 | zspool/foo 100M 96M 3.9M 96% 13k 8.0k 61% /var/spool/foo |
6 | zspool/foo 100M 98M 1.9M 98% 13k 3.9k 77% /var/spool/foo |
7 | zspool/foo 100M 100M 0B 100% 13k 0 100% /var/spool/foo |
Interessant …
Jörg W. schrieb: > Ich habe auch Dateisysteme, die mehr i-node-Auslastung anzeigen, aber > die sind insgesamt voller. Offenbar wird mit stärkerem Füllstand auch > automatisch die maximal mögliche Anzahl an i-nodes reduziert. Nein, die Anzahl der inodes wird von Anfang an bei der Erstellung der Partition festgelegt. Es scheint eher so, dass die Partitionsprogramme bei kleinen Partitionsgrößen eine kleinere Anzahl an inodes vorschlägt. Oben habe ich meine /var Partition genannt, die ist sehr klein und hat recht wenige inodes. Bei meinem /home Verzeichnis, das deutlich größer ist, sieht es deutlich besser aus. Bei beiden habe ich als Dateisystem ext4 gewählt.
Jörg W. schrieb: > Offenbar wird mit stärkerem Füllstand auch > automatisch die maximal mögliche Anzahl an i-nodes reduziert. Logisch. Die maximale Anzahl freier dnodes kann nicht grösser sein als die Anzahl freier Bytes / 512. Der in df angezeigte Wert freier i-nodes dürfte im API ad-hoc aus der freien Kapazität berechnet werden.
Nano schrieb: > Nein, die Anzahl der inodes wird von Anfang an bei der Erstellung der > Partition festgelegt. Du hast leider nicht zugehört ("zugelesen" klingt komisch ;-): es geht um ZFS hier. Da ist das tatsächlich völlig dynamisch, wie du meinem Trace entnehmen kannst. Die Zahl der freien i-nodes wird dort einfach immer so hinreichend groß angezeigt, dass die Situation "alle i-nodes belegt, obwohl noch Platz im Dateisystem ist" nie eintreten kann. Dass 40 Jahre alte Dateisysteme (extXfs ist in dieser Hinsicht ja nach wie vor der alte FFS-Rewrite, mit dem ext2fs angefangen hat) das anders handhaben, ist klar und unbestritten.
Nano schrieb: > Nein, die Anzahl der inodes wird von Anfang an bei der Erstellung der > Partition festgelegt. Nur bei Filesystemstrukturen mit fester Anzahl i-nodes. Filesysteme wie ZFS, JFS2 und btrfs allozieren i-nodes dynamisch, ein bei mkfs definiertes Limit existiert also nicht.
:
Bearbeitet durch User
Jörg W. schrieb: > Nano schrieb: >> Nein, die Anzahl der inodes wird von Anfang an bei der Erstellung der >> Partition festgelegt. > > Du hast leider nicht zugehört ("zugelesen" klingt komisch ;-): es geht > um ZFS hier. > > Da ist das tatsächlich völlig dynamisch, wie du meinem Trace entnehmen > kannst. Die Zahl der freien i-nodes wird dort einfach immer so > hinreichend groß angezeigt, dass die Situation "alle i-nodes belegt, > obwohl noch Platz im Dateisystem ist" nie eintreten kann. > > Dass 40 Jahre alte Dateisysteme (extXfs ist in dieser Hinsicht ja nach > wie vor der alte FFS-Rewrite, mit dem ext2fs angefangen hat) das anders > handhaben, ist klar und unbestritten. Ach so, okay. Mein Fehler.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.