Weyoun schrieb:
Die Rolle zwischen "weiter benutzen" oder "nicht weiter benutzen"...
Ich installiere das aus dem
AUR: Da wird der
öffentliche Quellcode geladen und es local auf meinem Rechner kompiliert.
Da sicherlich auch Leute, die in der Lage sind das zu prüfen, die gleichen Bedenken haben, würde es schnell auffallen und gemeldet, wäre da was "böses" drin.
WulfmanGER schrieb:
Im Prinzip schon ... aber ob sämtliche Dateien mit hashes geprüft werden... ICH würde es ja einfach machen: Schritt 1: welche Dateien haben gleiche Dateigröße, Schritt 2: Dateien mit gleicher Dateigröße könnten POTENTIELL identisch sein - hier mache ich ein Hash und prüfe.
Stimmt!
WulfmanGER schrieb:
Nach Dateigröße im ersten Schritt zu prüfen ginge viel schneller. Nur treffer werden genauer geprüft. Weiß aber nicht wie RAR das löst ...
Das könntest du leicht prüfen:
Zwei identische Dateien mit unterschiedlichen Namen und eine ähnlich große mit nochmal anderen Namen.
Dann rebooten, damit nichts mehr im Datenträger-Cache ist und packen.
An der HD-LED kannst du dann abschätzen, ob nur die beiden identisch großen Dateien gescannt werden, oder auch die dritte, obwohl sie aufgrund der Dateigröße ja gar nicht identisch sein kann.
WulfmanGER schrieb:
Die 2 MKVs mit 3,5GByte waren jetzt nur ein Extremes Beispiel.
Das war mit durchaus bewusst.
WulfmanGER schrieb:
Ich hab das z.b. genutzt um meinen ARK:SA-Server zu backupen. ARK legt leider für JEDE MAP einen kompletten Server an - identische Dateien. Unterschied ist nur das Map-Ordner und die 2 Config-Dateien. Rest ist immer identisch. Jetzt hab ich 2 Maps (bald 3...9) ... Statt jetzt 30Gbyte ... obwohl die Dateien recht schlecht zu packen sind, liege ich bei einer Archivgröße von 10Gbyte (was in etwa den Server 1x +2x Map entspricht). 10Gbyte sind schneller mal eben von a nach b verschoben als 30Gbyte. Ist sicher nicht der einzige Speicherineffektive Server.
Mich würde dabei schon die Verschwendung von Plattenplatz und die unnötige Schreiblast für die SSD ziemlich gegen den Strich gehen und versuchen das schon im Ansatz zu unterbinden.
Da ich ARK (generell Server) nicht kenne, weiß ich natürlich nicht, welche Möglichkeiten ich da hätte.
Mein erster Ansatz wäre, die identischen Dateien vorab als Symlink auf den ersten Server zu erstellen (ggfs. mit Schreibschutz), damit ARK "sieht", dass die schon da sind und nicht neu erstellen will, oder es zumindest dank Schreibschutz nicht erstellen kann.
Die würden dann auch als Symlink gepackt und wiederhergestellt, so dass auch be der Wiederherstellung keine unnötige Schreiblast entsteht.
Alternativ auch per Hardlinks (mit "cp -l …"), so dass es "richtige" Dateien sind, aber wie neulich schon geschrieben, erkennen normale Packer das nicht und packen sie wieder einzeln, bzw. RAR würde sie als identische Dateien erkennen - aber dann trotzdem als eigenständige Dateien wiederherstellen und man hat wider diese unnötige Schreiblast/Platzverschwendung.
WulfmanGER schrieb:
Wer das Format CBR kennt, kann diese Funktion auch nutzen um weiße Seiten die öfters vorkommen können (aber trotzdem 2-5Mbyte groß sind), auf diese weise zu "nullen". Da kommen schnell mal paar Mbyte zusammen (und je nach Endgerät/Übertragungsweg zählt jedes Megabyte was ich einsparen kann; Hotel in der Pampa - 100Mbyte sind angenehmer als 125Mbyte... Ich kann da ein Lied von singen!). Leider ist CBR nicht so kompatible wie CBZ (Zip statt RAR; Zip kennt in der Richtung leider nichts - selbst wenn - Calibre ist bei ZIP extrem wählerlisch - sobald ich bissel mehr kompression auswähle, kann das Teil schon nicht mehr gelesen werden.... mit internen Dateiverweisen würde es noch schlechter umgehen können; CB7 (7z) kann leider mein Viewer nicht; ist bei Bildern nämlich viel effektiver als RAR/ZIP)
Ich lese nur ePub: Auch ZIP, aber andere Komprssion bringt fast nichts:
Das größte des aktuellen Zyklus (Perry Rhodan) hat 7573 kiB:
Entpacke ich es und packe es mit ZIP und höchster Kompression, ist es gerade mal 14,1 kiB kleiner und als 7zip, solide und mit höchster Kompression werden gerade mal 147,1 kiB eingespart: Das sind nicht mal ganz 2%.
WulfmanGER schrieb:
Ich hab z.b. bei meinem Webserver mehrere doppelte Dateien - da ich öfters mal ein komplettes Backup mache um mal eben schnell gravierende sachen zu ändern. Wenn ich diese 2-3-4 Ordner (schnell mal 1-2Gbyte groß) mal packe (um sie weg zu sichern), spare ich hier auch ... ein großteil der 1-2Gbyte je Ordner sind Bilder - die dann natürlich 2-3-4x existieren
Wie gesagt: Backup mache ich mehrstufig und lasse dabei identische Dateien als Hardlinks übernehmen: Das spart eine Menge Zeit und Platz ("5" statt "S", damit ich es nummerisch sortieren kann: 5001 steht sozusagen für "Sicherung 001"):
Bash:
# du -sBM {5015..5001}
82937M 5015
4630M 5014
4342M 5013
3958M 5012
3986M 5011
4346M 5010
4500M 5009
4823M 5008
2531M 5007
503M 5006
1808M 5005
2215M 5004
274M 5003
1892M 5002
714M 5001
5015 ist die älteste (Anf. Sept.) und zeigt die komplette Größe.
(das Videoarchiv habe ich nur extern, da ich nicht ständig darauf zugreifen können muss und SSDs 2015 noch ziemlich teuer waren - da sich das bewährt hat, bin ich dabei geblieben)
Alle weiteren zeigen nur die Änderungen zur vorherigen Stufe, da "du" Hardlinks berücksichtigt.
Nach einiger Zeit lösche ich alle außer eine Stufe/Mon., so dass 5008 von Anf. April ist.
Ab da habe ich noch nicht wieder ausgemistet und sichere nach jeder größeren Änderung (oder bevor ich am System "basteln" möchte): 5004 ist von Anf. Mai.
Dabei ist jede Stufe für sich vollständig und hat die komplette Größe:
Code:
# du -sBM 5010
83250M 5010
# du -sBM 5005
83773M 5005
# du -sBM 5001
84021M 5001
Da z. B. der Dateimanager mit Hardlinks nichts am Hut hat (wie eben auch normale Packer), kommt er auf eine
geringfügig höhere Gesamtgröße.
Das ist übrigens eine 500 GB 2,5" USB3-HD, es sind noch andere Sicherungen drauf (182 GiB davon einfach, also ohne Hardlinks) und das Dateisystem ist xfs, also keine Komprimierung (das meiste davon würde sich sowieso nicht komprimieren lassen):
Hier zeige ich meine
Sicherungsskripte.
WulfmanGER schrieb:
Trotzdem find ich die Funktion gut - wenn dann noch intelligent geprüft wird (Dateigröße -> dann Hash), ist der Zeitaufwand kaum relevant - dafür aber schnell der Speicherplatz.
Zweifellos: Ein eindeutiger Fall von besser haben und (ggfs.) nicht brauchen, als umgekehrt.
