Re: Umgang mit Dubletten

[Werner Holtfreter <Holtfreter@xxxxxx>]

Hallo Raphael,

am Donnerstag, 2009-08-20 23:24:49 schrieben Sie:

> On Thu, Aug 20, 2009 at 06:47:19PM +0200, Werner Holtfreter wrote:

> > Also Softlinks! Aber wie? Vielleicht sollte man mehrfach
> > benoetigte Dateien grundsaetzlich in ein Verzeichnis "SHARED"
> > auslagern, um unbedachter Loeschung vorzubeugen?
>
> Wie waere es mit folgender Idee:
>
> Jede Datei, die als "schuetzenswert" gilt wird anhand ihres
> Contents indexiert, dabei bieten sich  Hashverfahren wie md5 oder
> sha256 an.
>
> Dateien bleiben grundsaetzlich da liegen, wo sie logisch
> hingehoeren, also in eine wie-auch-immer thematische
> Verzeichnisstruktur, z.B. im Homeverzeichnis.
>
> Ein regelmaessig laufender Job durchsucht regelmaeÃ?ig alle
> relevanten Dateien und speichert dabei je einen Datensatz
>
> <hashwert>|<timestamp>|<timestamp>|/pfad/datei
>
> in einem Index ab, wobei die Timestamps den Zeitpunkt der
> Indexierung und den Timestamp der Datei selbst sind. Dieser Index
> wird z.B. taeglich erneuert und fortgeschrieben.
>
> Ein zweiter Job ermittelt nun - pro filesystem - alle Dateien,
> die noch nicht im Repository liegen. Das Repository besteht aus
> Dateien, die als Dateiname nur den Wert der Checksumme des
> Dateiinhalts haben, sortiert in eine Verzeichnishierachie
> basierend auf den ersten 3 Stellen des Hashwertes.
>
>
> Beispiel:
>
> e55d56d38035824cf1e2ead96e7688a72f3dac068d97e98d25fa819349a0cfae
> /home/rabe/UUGRN/Aufnahmeantrag_UUGRN.pdf
>
> Das Basisverzeichnis dieses Repositorys sei ./.repo relativ zu
> jedem Mointpoint, also zB /.repo /usr/.repo /home/.repo
>
> Unterhalb sei das repo nach den ersten 3 Stellen der Checksummen
> untergliedert, damit nicht zu viele Dateien in einem Verzeichnis
> liegen, ueber den Daumen gepeilt sind (bei Gleichverteilung) 256
> Files pro Hierachieebene sinnvoll.

Warum ist das sinnvoll? Warum nicht alle Dateien in ein Verzeichnis?

> Virtuell sei angenommen, dass /a/bc/abcdef.... eine sinnvolle
> Verteilung ergaebe, dann wuerde obige Datei als Hardlink unter
>
> ./.repo/e/55/e55d56d38035824cf1e2ead96e7688a72f3dac068d97e98d25fa
>819349a0cfae
> zum liegen kommen 
> (16*256 = 4096 Verzeichnisse * ca 256 "Dateien pro Verzeichnis"
> =  ca 1 Mio Dateien)
>
> Der Pruefjob wuerde nun also den aktuellen Index vergleichen mit
> dem Inhalt des Repositorys und im Repository noch fehlende
> Checksummen durch Hardlink auf (eine/die) entsprechende Datei
> "fixieren".
>
> Ein vom Index vollkommen unabhaengiger Konsistenzcheck koennte
> regelmaessig das Repository durchlaufen und fuer alle dort hart
> verlinkten Dateien deren Content-Checksumme mit dem Dateiname
> vergleichen und somit modifizierte Dateien im Repository passend
> umbenennen oder verschieben.
>
> Zudem braeuchte man fuer das Backup nur hinzugekommene Dateien im
> Repository sichern.
>
> Wird eine Datei zB aus dem Homeverzeichnis irrtuemlich geloescht
> oder modifiziert, kann man anhand des aufgezeichneten Index den
> Hashwert eines Dateinamens zu einem bestimmten Zeitpunkt (oder
> Zeitraum) ermitteln und kann die fehlende Datei durch einfaches
> Kopieren aus dem Repository wieder herstellen.
>
> Abwandlung: Kommt es auf den Platz nicht an und/oder soll ein
> zentrales Repository ueber Filesystem- oder Rechnergrenzen hinweg
> angelegt werden, zB als "ewiges Archiv", kann anstelle der
> Hardlinks auch eine Kopie angelegt werden. Anhand des Indexes
> wuerde man dann fehlende Dateien im Repo nicht per Hardlink
> "sichern", sondern einfach als Kopie. Das haette ausserdem den
> Effekt, dass das Repository nicht inkonsistent werden *kann* weil
> die Dateien im Homeverzeichnis ja beim ueberschreiben das
> Repository nicht direkt beeinflussen, der Pruefjob waere also
> obsolet.
>
> Nebeneffekt: Zeichnet man die Checksummen der Dateien als
> Dateiname auf, kann man beim Lesen (Recoverytest) des Backups
> auch unmittelbar pruefen, dass die Daten im Backup fehlerfrei vom
> Medium gelesen werden koennen bzw. beim Schreiben des Backups
> vollstaendig und fehlerfrei geschrieben wurden.
>
> Denkbar waere, fuer das Backup die einzelnen Dateien mit bzip2 zu
> packen und entsprechend umzubenennen, etwa
> e55d56d38035824cf1e2ead96e7688a72f3dac068d97e98d25fa819349a0cfae.
>bz2 Der Konsistenzcheck muesste hier allerdings die Dateien jeweils
> entpacken, was natuerlich wesentlich CPU-intensiver ist.
>
> Wichtig dafuer ist, dass man fuer die Wiederherstellung einer Datei
> aus dem Backup den aufgezeichneten Index benoetigt. Denkbar waere,
> einen (abgeschlossenen) Index selbst als Checksumme in das
> Repository zu kopieren und das im (aktuellen) Index entsprechend
> festzuhalten.
>
> Zusaetzlich koennte man diese "speziellen" Sicherungen des Indexes
> durch immutable-Flags ("chattr +r foo"  oder "chflags noschg
> foo") gegen Ueberschreiben, Loeschen etc zu schuetzen und zugleich
> als Erkennungsmerkmal fuer "diese Datei enthaelt einen Index" zu
> verwenden.
>
> Weitere Methoden zur Signierung oder Verschluesselung von Dateien
> im Repository seien hier nur erwaehnt aber nicht weiter
> ausgefuehrt.
>
> Zusammengefasst zielt das Ganze darauf ab, dass jede Form von
> Archiv oder Sicherung auf eine thematische Sortierung verzichten
> sollte und stattdessen streng anhand von eindeutigen Merkmalen
> wie Checksummen operieren sollte, wenn moeglich *ausserhalb* der
> Umgebung, auf der aktiv gearbeitet wird.
>
> Nur eine Idee.
>
> Achso, Thema Doubletten: Die Treten im Repo nicht auf, koennen
> aber im Homeverzeichnis entstehen.

Aber mein Ziel war doch, Dubletten im Home durch Links zu ersetzen!

Du hast zusaetzlich einen Index und ein Repository eingefuehrt. Das  
Repository braucht nahezu keinen zusaetzlichen Platz, wenn es aus 
Hardlinks auf die Dateien in Home besteht. Soweit gut. Aber wie 
kann man mit diesem Konzept irgendwo Platz sparen und/oder 
Uebersicht gewinnen?

> Aber automatisch darf man sie nicht einfach durch Hardlinks
> de-duplizieren wenn nicht sicher gestellt ist, dass die Datei
> Read-Only ist, sonst aendert sich der Inhalt der Datei ungewollt
> auch fuer andere Stellen (bei Hardlinks).   

Sehr richtig. Wenn man inhaltsgleiche Dateien mit Hardlinks *blind* 
verbinden wuerde, duerfte man darauf nur noch Lesezugriff zulassen 
bzw. muesste beim Schreiben den Link loesen. Uebrigens werden durch 
Hardlinks auch die Dateirechte vereinheitlicht, das nur am Rande.
-- 
Viele Gruesse
Werner Holtfreter
--
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/