Gelegentlich kommt es vor, dass ich als Linuxer Mac OS X-Benutzer
beneide. Zuletzt um Time Machine, das effizient und unaufdringlich
regelmäßig Backups anlegt. Der Trick daran ist, soweit ich das
verstehe, dass ein Daemon alle relevanten FS-Ereignisse protokolliert
und das eigentliche Time Machine-Programm nur stündlich die geänderten
Objekte mit dem Backup synchronisiert. Hinzu kommt, dass das
MOSX-Filesystem auch Hardlinks von Verzeichnissen erlaubt, sodass
Kopien von gleich gebliebenen Teilbäumen einfach und schnell angelegt
werden können.

Ich verwende auf Linux rsnapshot, das für die Backups rsync und cp -al
verwendet. Da rsync beim Kopieren Quelle und Ziel komplett abgleichen
muss, ist das eine vergleichsweise aufwändige und langwierige
Angelegenheit.

Meine Überlegung ist nun, ob es möglich ist, rsync auf die Sprünge zu
helfen, indem nur die Teilbäume von Quelle und Ziel abgeglichen werden,
wo es nötig ist. Linux hat seit 2.6.12 inotify, mit dem Änderungen in
einem Verzeichnis nicht-rekursiv beobachtet werden können. Ich kann mir
aber nur schwer vorstellen, dass es praktikabel ist auf jedes einzelne
Verzeichnis ein inotify watch zu setzen.

Gibt es vielleicht einen Weg, den ich übersehen habe?

Michael

-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

私の記憶が確かならば, Michael Schuerig  wrote:
> Gelegentlich kommt es vor, dass ich als Linuxer Mac OS X-Benutzer
> beneide.

du darfst gerne einen Mac benutzen und mußt ihn dazu auch nicht mit
Pinguin-Kot beschmutzen... 8-)

> Zuletzt um Time Machine, das effizient und unaufdringlich regelmäßig
> Backups anlegt.

Um das gar so effizient hinzubekommen, benutzt man da einige böse Tricks
(inklusive hard links auf Verzeichnisse - nicht wirklich die strahlendste
Idee).

Genaugenommen habe ich noch immer nicht verstanden, warum man nicht einfach
hingegangen ist und die FS-Snapshots von FreeBSD portiert hat, wenn man dort
eh schon alles mitnimmt, was nicht niet- und nagelfest ist.

> Gibt es vielleicht einen Weg, den ich übersehen habe?

FreeBSD (oder etwas ähnliches) installieren und UFS mit Snapshots verwenden?


Noses.

Michael Schuerig  writes:
> Gelegentlich kommt es vor, dass ich als Linuxer Mac OS X-Benutzer
> beneide.

Dann solltest Du Dir einfach ein Mac OS X organisieren. Das bekommt
man auch auf einem 'normalen' PC zum Laufen und somit ermoeglicht es
der 'eye candy'-Zielgruppe, ohne groesseren Geldaufwand nonchalant
ueber alle Apple-typischen Funktionsstoerungen hinwegzusehen, aka
'laesst man es fuenf Minuten alleine, darf man es rebooten'. Das ist
eine schoene Tradition, die wenigstens seit OS 9 existiert und man
darf einen betraechtlichen 'engineering'-Aufwand dahinter vermuten,
dieses feature trotz mittlerweile vollstaendig ausgetauschter
Software- und Hardwareplattform immer noch anzubieten.

[...]

> Ich verwende auf Linux rsnapshot, das für die Backups rsync und cp -al
> verwendet. Da rsync beim Kopieren Quelle und Ziel komplett abgleichen
> muss, ist das eine vergleichsweise aufwändige und langwierige
> Angelegenheit.
>
> Meine Überlegung ist nun, ob es möglich ist, rsync auf die Sprünge zu
> helfen, indem nur die Teilbäume von Quelle und Ziel abgeglichen werden,
> wo es nötig ist.

Das ist, unhoeflich ausgedrueckt, totaler bullshit, denn rsync kopiert
ja bereits nur die Aenderungen, und ob Du einmal im Block ermittelst,
was 'die Aenderungen' nun eigentlich sind, oder den ganzen Tag im
Hintergrund Rechenzeit darauf verwendest, sie alle mitzuprotokollieren
nimmt sich, objektiv gesehen, fast nichts, zumal rsnapshot ja bereits
im Hintergrund laeufen soll, es also etwas unklar scheint, was Dich
eigentlich daran stoert, ob es ein paar Sekunden laenger oder kuerzer
arbeitet.

Davon ab: Das, was Du haben moechtest (und was uebrigens tatsaechlich
urspruenglich eine BSD-Entwicklung war) heisst 'unionfs'.

Michael Schuerig  wrote:

> Gibt es vielleicht einen Weg, den ich übersehen habe?

Für das Dateisystem meiner Wahl gibt es das hier:

NAME
       xfsdump - XFS filesystem incremental dump utility

Gruss

Sven

-- 
"If you don't make lower-resolution mapping data publicly
available, there will be people with their cars and GPS
devices, driving around with their laptops" (Tim Berners-Lee)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

Sven Geggus wrote: 
> Michael Schuerig  wrote:
>
>> Gibt es vielleicht einen Weg, den ich übersehen habe?
>
> Für das Dateisystem meiner Wahl gibt es das hier:
>
> NAME
>        xfsdump - XFS filesystem incremental dump utility

Solaris: ufsdump. BSD und abgeleitete: dump.

Die durchsuchen nicht den Dateisystembaum, sondern die linear die
Liste der inodes, um Änderungen zu finden.

	-is

Ignatios Souvatzis  wrote:

> Die durchsuchen nicht den Dateisystembaum, sondern die linear die
> Liste der inodes, um Änderungen zu finden.

OS-X macht das anders?

Sven

-- 
"In my opinion MS is a lot better at making money than it is at making good
operating systems" (Linus Torvalds, August 1997)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

Sven Geggus  writes:
> Ignatios Souvatzis  wrote:
>
>> Die durchsuchen nicht den Dateisystembaum, sondern die linear die
>> Liste der inodes, um Änderungen zu finden.
>
> OS-X macht das anders?

Es wird wohl fortlaufend eine 'Datenbank' aller seit dem letzten
backup geaenderten Dateien vom System selber angelegt und das
eigentliche Backup-Programm muss nicht erst nach den Aenderungen
suchen. Wie bereits geschrieben: Etwas aehnliches sollte sich mit
unionfs realisieren lassen, in dem man in geeigneten Zeitintervallen
einen neuen snapshot anlegt und ein backup des darunterliegenden, alten
'top-levels' macht (der jetzt read-only ist). Im 'live'-Dateisystem
wuerde man sinnvollerweise (wenn man time machine kopieren will) nach
diesem backup noch den alten top-level branch mit dem
darunterliegenden verschmelzen, waehrend man im 'backup'-Dateisystem
die snapshot-Strukture beibehalten wuerde, um jeweils eine 'Ansicht'
des Dateisystem zu einen bestimmten Zeitpunkt bieten zu koennen.

Inwiefern das gegenueber einen konventionellen backup eine
Verbesserung jenseits gewissen Wow!-Effekts ergaebe, waere eine gute
Frage. Ich wuerde mir die Muehe jedenfalls nicht deswegen machen
wollen, denn eigentlich moechte ich bloss ein backup und Wow!-Effekte
lassen mich vollkommen kalt[*].

	[*] Zb habe ich seit mehr als zehn Jahren ein

        	exec xsetroot -solid grey36

	in meiner fvwm2-Konfiguration, weil mir der Gedanke,
        auch nur irgendeinen Bruchteil der Rechenzeit eines
        von mir benutzten Computers fuer so etwas nutzloses
        wie das 'Berechnen' von Ausschnitten eines Hintergrundbildes
        zu verwenden einfach gegen den Strich geht.

Michael Schuerig wrote:

> Meine Überlegung ist nun, ob es möglich ist, rsync auf die Sprünge zu
> helfen, indem nur die Teilbäume von Quelle und Ziel abgeglichen werden,
> wo es nötig ist. Linux hat seit 2.6.12 inotify, mit dem Änderungen in
> einem Verzeichnis nicht-rekursiv beobachtet werden können. Ich kann mir
> aber nur schwer vorstellen, dass es praktikabel ist auf jedes einzelne
> Verzeichnis ein inotify watch zu setzen.

Es ist schon möglich es auch rekursiv zu machen (inotifywatch -r) was dann
aber für jedes Verzeichnis eine Watch platziert (die Default Anzahl von
8192 kann man mit /proc/sys/fs/inotify/max_user_watches erhöhen).

Für 1 Gigabyte und ein paar tausend Files (mein /home/markus/) funktioniert
das Watch noch recht praktikabel, für 600 gig (mein /home) ist er nach 10
min wegen des Überschreiten von Limit 20000, bzw. wg. segmentation fault
bei out-of memory (bei noch wesentlich höhereren Limit) beendet worden. Ist
also wahrscheinlich noch nicht so einsetzbar.

Man könnte sich aber mal anschauen wie es z.b. beagle macht, es gibt sicher
klügere Ansätze wie man viele Directories beobachtet. In Kombination mit
hooks in apt für das Backup könnte man dann sicher einen aktives Backup
Verfahren entwickeln. Obwohl man es vielleicht nicht Backup nennen sollte,
wäre ja eher ein inkrementelles Raid ;)

mfg Markus

私の記憶が確かならば, Sven Geggus  wrote:
>> Die durchsuchen nicht den Dateisystembaum, sondern die linear die Liste
>> der inodes, um Änderungen zu finden.
> OS-X macht das anders?

Ja, da sowieso jede Operation auf einem Dateisystem überwacht wird, um sie
der Metadaten-Datenbank zum Kauen vorzulegen, kann man sich die notwendigen
Informationen mit wenig Aufwand gleich aus diesem Verzeichnis greifen. Nur
so als Beispiel, was der lokale Schäuble-Klon hier weiß:

noses@wasabi:~/ 176-%mdls ~/bmctl.log 
kMDItemContentCreationDate     = 2008-04-21 19:39:56 +0200
kMDItemContentModificationDate = 2008-05-01 21:13:53 +0200
kMDItemContentType             = "com.apple.log"
kMDItemContentTypeTree         = (
    "com.apple.log",
    "public.plain-text",
    "public.text",
    "public.data",
    "public.item",
    "public.content",
    "public.log"
)
kMDItemDisplayName             = "bmctl.log"
kMDItemFSContentChangeDate     = 2008-05-01 21:13:53 +0200
kMDItemFSCreationDate          = 2008-04-21 19:39:56 +0200
kMDItemFSCreatorCode           = ""
kMDItemFSFinderFlags           = 0
kMDItemFSHasCustomIcon         = 0
kMDItemFSInvisible             = 0
kMDItemFSIsExtensionHidden     = 0
kMDItemFSIsStationery          = 0
kMDItemFSLabel                 = 0
kMDItemFSName                  = "bmctl.log"
kMDItemFSNodeCount             = 0
kMDItemFSOwnerGroupID          = 801
kMDItemFSOwnerUserID           = 1000
kMDItemFSSize                  = 13472
kMDItemFSTypeCode              = ""
kMDItemKind                    = "Log File"
kMDItemLastUsedDate            = 2008-05-01 21:13:53 +0200
kMDItemUsedDates               = (
    2008-04-21 00:00:00 +0200,
    2008-04-23 00:00:00 +0200,
    2008-04-24 00:00:00 +0200,
    2008-04-27 00:00:00 +0200,
    2008-05-01 00:00:00 +0200
)

Einige dieser Informationen sind mehr oder weniger gewagte Schlüsse ("das
Teil endet in .log, ist ganz offensichtlich eine reine Unix-Textdatei - das
wird wohl tatsächlich eine Log-Datei sein"). Zusätzlich dazu wurde auch noch
ein Index gebildet, so daß in ihr vorkommende von white space
eingeschlossene "Worte" auch noch von Spotlight gefunden werden können.

TimeMachine greift sich einfach alles mit kMDItemFSContentChangeDate >
"letzte Sicherung".


Noses.

Markus Raab wrote:

> Für 1 Gigabyte und ein paar tausend Files (mein /home/markus/)
> funktioniert das Watch noch recht praktikabel, für 600 gig (mein
> /home) ist er nach 10 min wegen des Überschreiten von Limit 20000,
> bzw. wg. segmentation fault bei out-of memory (bei noch wesentlich
> höhereren Limit) beendet worden. Ist also wahrscheinlich noch nicht so
> einsetzbar.

Etwas in der Art hatte ich erwartet, aber es ist gut, dass es jemand
tatsächlich ausprobiert hat.

Michael

-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

Michael Schuerig  writes:
> Markus Raab wrote:
>
>> Für 1 Gigabyte und ein paar tausend Files (mein /home/markus/)
>> funktioniert das Watch noch recht praktikabel, für 600 gig (mein
>> /home) ist er nach 10 min wegen des Überschreiten von Limit 20000,
>> bzw. wg. segmentation fault bei out-of memory (bei noch wesentlich
>> höhereren Limit) beendet worden. Ist also wahrscheinlich noch nicht so
>> einsetzbar.
>
> Etwas in der Art hatte ich erwartet, aber es ist gut, dass es jemand
> tatsächlich ausprobiert hat.

Warum denn? Die Idee ist hirntot. Es gibt ein VFS-layer im Kernel und
durch dieses laufen bereits alle Dateimanipulationen. Wenn man jetzt
an allen Dateimanipulation 'ein bisschen was' aendern moechte,
ueberlaedt man die entsprechenden Methoden, dann dafuer gibt es die
schliesslich.

Rainer Weikusat wrote:

> Es gibt ein VFS-layer im Kernel und
> durch dieses laufen bereits alle Dateimanipulationen. Wenn man jetzt
> an allen Dateimanipulation 'ein bisschen was' aendern moechte,
> ueberlaedt man die entsprechenden Methoden, dann dafuer gibt es die
> schliesslich.

Ich würde erwarten dass inotify genau das macht. (bzw. hooks oder
Interceptoren an entsprechenden Stellen verwendet)
Bitte um Aufklärung.

mfg Markus

Michael Schuerig wrote:

> Gibt es vielleicht einen Weg, den ich übersehen habe?

Noch ergänzend, es gibt ein Dateisystem welches dich vielleicht in dem
Zusammenhang interessieren dürfte:
http://www.complang.tuwien.ac.at/czezatke/lfs.html

Neueste Arbeiten in dem Zusammenhang siehe:
http://www.complang.tuwien.ac.at/projects/linux.html
oben bei Projects.

Wieviel Undoing jetzt tatsächlich funktioniert weiß ich nicht.

mfg Markus

Markus Raab wrote:

> Michael Schuerig wrote:
> 
>> Gibt es vielleicht einen Weg, den ich übersehen habe?
> 
> Noch ergänzend, es gibt ein Dateisystem welches dich vielleicht in dem
> Zusammenhang interessieren dürfte:
> http://www.complang.tuwien.ac.at/czezatke/lfs.html

Ja, danke, im Prinzip. Aber mir ging es um einen Ansatz zu einer
praktikablen Lösung und das ist das Log Structured-FS wohl nicht mehr
ganz aktuell.

Michael

-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

Am Thu, 12 Jun 2008 22:59:18 +0200 schrieb Michael Schuerig:
>
> Gibt es vielleicht einen Weg, den ich übersehen habe?

Wie wär's mit lvm2, das behauptet von sich snapshots zu können, ich
hab's aber noch nie verwendet.

    MfG
    bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“          | berberic@fmi.uni-passau.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | www.fmi.uni-passau.de/~berberic

M G Berberich wrote:

> Am Thu, 12 Jun 2008 22:59:18 +0200 schrieb Michael Schuerig:
>>
>> Gibt es vielleicht einen Weg, den ich übersehen habe?
> 
> Wie wär's mit lvm2, das behauptet von sich snapshots zu können, ich
> hab's aber noch nie verwendet.

Ich habe mir gerade das HOWTO (http://www.tldp.org/HOWTO/LVM-HOWTO)
angesehen und LVM 2 ist zweifellos sehr interessant. Der Kontext meiner
Frage war, dass ich Backups dadurch beschleunigen wollte, dass nicht
mehr Original-FS und Backup-FS komplett miteinander verglichen werden
müssen, weil Änderungen, sobald sie entstehen, protokolliert werden. 

Ich sehe nicht, dass LVM-Snapshots dies ermöglichen. Die benötigte
Information wäre grundsätzlich vorhanden, wenn jeweils für den Stand
des letzten und aktuelles Backups ein Snapshot des Originals existiert.
Dann müssten die blockweisen Unterschiede ermittelt und auf das Backup
angewendet werden. Ob diese Daten allerdings zugänglich sind, konnte
ich aus dem HOWTO nicht erkennen. Ein gravierender Nachteil wäre auch,
dass durch die Snapshots nicht nur festgehalten würde, dass sich an
bestimmten Stellen im FS etwas geändert hat, sondern die Änderungen
selbst gespeichert würden, sie würden also ohne großen Nutzen Platz
belegen.

Michael

-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

Michael Schuerig  writes:
> M G Berberich wrote:
>> Am Thu, 12 Jun 2008 22:59:18 +0200 schrieb Michael Schuerig:
>>>
>>> Gibt es vielleicht einen Weg, den ich übersehen habe?
>> 
>> Wie wär's mit lvm2, das behauptet von sich snapshots zu können, ich
>> hab's aber noch nie verwendet.
>
> Ich habe mir gerade das HOWTO (http://www.tldp.org/HOWTO/LVM-HOWTO)
> angesehen und LVM 2 ist zweifellos sehr interessant. Der Kontext meiner
> Frage war, dass ich Backups dadurch beschleunigen wollte, dass nicht
> mehr Original-FS und Backup-FS komplett miteinander verglichen werden
> müssen, weil Änderungen, sobald sie entstehen, protokolliert werden.

Dadurch kann man ein backup aber gar nicht (wesentlich) beschleunigen,
weil hauptsaechlich das Kopieren der Dateien selber Zeit
benoetigt. Vor allem, falls dieses zB, was vorkommen soll, ueber
irgendein Netz hinweg stattfindet.

Wer das nicht glaubt, der moege es mal ausprobieren. Ein

	find linux-2.4.35 -ls >/dev/null

dauert hier ca 1.6s (cache cold) bzw 0.16s (alle folgenden). Diese
13367 Dateien zu kopieren (auf einer Platte) braucht 15-20s (das
entspricht einem reinen Datendurchsatz von 76 - 101 MBit).

Rainer Weikusat wrote:

> Michael Schuerig  writes:
>> M G Berberich wrote:
>>> Am Thu, 12 Jun 2008 22:59:18 +0200 schrieb Michael Schuerig:
>>>>
>>>> Gibt es vielleicht einen Weg, den ich übersehen habe?
>>> 
>>> Wie wär's mit lvm2, das behauptet von sich snapshots zu können, ich
>>> hab's aber noch nie verwendet.
>>
>> Ich habe mir gerade das HOWTO (http://www.tldp.org/HOWTO/LVM-HOWTO)
>> angesehen und LVM 2 ist zweiflellos sehr interessant. Der Kontext
>> meiner Frage war, dass ich Backups dadurch beschleunigen wollte, dass
>> nicht mehr Original-FS und Backup-FS komplett miteinander verglichen
>> werden müssen, weil Änderungen, sobald sie entstehen, protokolliert
>> werden.
> 
> Dadurch kann man ein backup aber gar nicht (wesentlich) beschleunigen,
> weil hauptsaechlich das Kopieren der Dateien selber Zeit
> benoetigt. 

Bist du sicher? Allein

$ find /home > /dev/null

dauert bei mir 4m4.867s auf einem verschlüsselten Dateisystem das mit
35GB zu ~50% gefüllt ist. Rsync wird nicht mit weniger auskommen, egal,
ob sich etwas geändert hat oder nicht. Wenn dann tatsächlich nur wenige
kleine Dateien ins Backup kopiert werden müssen, liegt eben doch der
Hauptaufwand beim Finden der Änderungen.

Ich vermute, dass deine Aussage zutrifft, solange es um vergleichsweise
wenige Dateien geht, aber dann nicht mehr, wenn es um ganze
Dateisysteme geht, wo die Anzahl der geänderten Dateien im Verhältnis
zur Gesamtzahl sehr klein ist.

Michael

-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

Michael Schuerig  writes:
> Rainer Weikusat wrote:
>> Michael Schuerig  writes:
>>> M G Berberich wrote:
>>>> Am Thu, 12 Jun 2008 22:59:18 +0200 schrieb Michael Schuerig:
>>>>>
>>>>> Gibt es vielleicht einen Weg, den ich übersehen habe?
>>>> 
>>>> Wie wär's mit lvm2, das behauptet von sich snapshots zu können, ich
>>>> hab's aber noch nie verwendet.
>>>
>>> Ich habe mir gerade das HOWTO (http://www.tldp.org/HOWTO/LVM-HOWTO)
>>> angesehen und LVM 2 ist zweiflellos sehr interessant. Der Kontext
>>> meiner Frage war, dass ich Backups dadurch beschleunigen wollte, dass
>>> nicht mehr Original-FS und Backup-FS komplett miteinander verglichen
>>> werden müssen, weil Änderungen, sobald sie entstehen, protokolliert
>>> werden.
>> 
>> Dadurch kann man ein backup aber gar nicht (wesentlich) beschleunigen,
>> weil hauptsaechlich das Kopieren der Dateien selber Zeit
>> benoetigt. 
>
> Bist du sicher? Allein
>
> $ find /home > /dev/null
>
> dauert bei mir 4m4.867s auf einem verschlüsselten Dateisystem das mit
> 35GB zu ~50% gefüllt ist. Rsync wird nicht mit weniger auskommen, egal,
> ob sich etwas geändert hat oder nicht. Wenn dann tatsächlich nur wenige
> kleine Dateien ins Backup kopiert werden müssen, liegt eben doch der
> Hauptaufwand beim Finden der Änderungen.

Der Gedanke war mir mittlerweile auch gekommen. Aber sinnvollerweise
wuerde muesste man eine solche Aenderungsdatenbank als 'stacked
filesystem' implementieren, dass jeweils beim ersten 'write'-Aufruf
fuer eine bestimmte Datei deren Pfad (und vermutlich auch die
i-node-Nummer) irgendwo hinterlegt. Damit wuerde man aber alle writes
wenigstens ein bisschen langsamer machen und einen, der eine
'Datenbankaktivitaet' nach sich zoege, vermutlich um ein gehoeriges
bisschen. Das erscheint mir fuer einen Hintergrundjob, der einmal am
Tag ausgefuehrt wird, immer noch kein guter tradeoff zu sein.

Rainer Weikusat wrote:

> Michael Schuerig  writes:

>> Bist du sicher? Allein
>>
>> $ find /home > /dev/null
>>
>> dauert bei mir 4m4.867s auf einem verschlüsselten Dateisystem das mit
>> 35GB zu ~50% gefüllt ist. Rsync wird nicht mit weniger auskommen,
>> egal, ob sich etwas geändert hat oder nicht. Wenn dann tatsächlich
>> nur wenige kleine Dateien ins Backup kopiert werden müssen, liegt
>> eben doch der Hauptaufwand beim Finden der Änderungen.
> 
> Der Gedanke war mir mittlerweile auch gekommen. Aber sinnvollerweise
> wuerde muesste man eine solche Aenderungsdatenbank als 'stacked
> filesystem' implementieren, dass jeweils beim ersten 'write'-Aufruf
> fuer eine bestimmte Datei deren Pfad (und vermutlich auch die
> i-node-Nummer) irgendwo hinterlegt.

So tief hinein wollte ich ja gar nicht. Mir ging es darum, ob es mit
(Linux-)Bordmitteln derzeit erreichbar ist.

> Damit wuerde man aber alle writes 
> wenigstens ein bisschen langsamer machen und einen, der eine
> 'Datenbankaktivitaet' nach sich zoege, vermutlich um ein gehoeriges
> bisschen. Das erscheint mir fuer einen Hintergrundjob, der einmal am
> Tag ausgefuehrt wird, immer noch kein guter tradeoff zu sein.

Ja, die Kosten würden anders verteilt. Ob das für einen bestimmten
Einsatzzweck akzeptabel ist, muss man natürlich individuell
entscheiden. Für einen Server, der irgendwo im Rechenzentrum steht, und
auf dem sich vorhersehbar nur bestimmte Daten ändern (dürfen), wäre das
sicher unsinnig.

Aber nimm einen Endanwender mit Notebook (mich). Bei entsprechender
Bastelneigung können Änderungen praktisch überall auftreten. Bei mir
kann ein Backup mit rsnapshot (rsync + cp -al) durchaus 1 Stunde
dauern. Ein stündliches Backup wäre damit also gar nicht möglich, ob
nun sinnvoll oder nicht. Und natürlich könnte ich während des laufenden
Backups das Notebook nicht spontan abkoppeln und mich damit nach
draussen setzen. In diesem Fall würde der Gewinn die zusätzlichen
Kosten bei Schreiboperationen ohne weiteres aufwiegen.

Michael

-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

Rainer Weikusat wrote:
> Michael Schuerig  writes:
>>dauert bei mir 4m4.867s auf einem verschlüsselten Dateisystem das mit
>>35GB zu ~50% gefüllt ist. Rsync wird nicht mit weniger auskommen, egal,
>>ob sich etwas geändert hat oder nicht. Wenn dann tatsächlich nur wenige
>>kleine Dateien ins Backup kopiert werden müssen, liegt eben doch der
>>Hauptaufwand beim Finden der Änderungen.
> 
> Der Gedanke war mir mittlerweile auch gekommen. Aber sinnvollerweise
> wuerde muesste man eine solche Aenderungsdatenbank als 'stacked
> filesystem' implementieren, dass jeweils beim ersten 'write'-Aufruf
> fuer eine bestimmte Datei deren Pfad (und vermutlich auch die
> i-node-Nummer) irgendwo hinterlegt. Damit wuerde man aber alle writes
> wenigstens ein bisschen langsamer machen und einen, der eine
> 'Datenbankaktivitaet' nach sich zoege, vermutlich um ein gehoeriges
> bisschen.

Es würde ausreichen, diese Aktion an das Rausschreiben des inodes mit
der geänderten mtime zu koppeln, was das ganze schon ein ganzes Stück
entschärft. Den Dateinamen hat Linux eh vorrätig, sonst würde /proc/fd
nicht funktionieren (wobei ich mir nicht sicher bin, ob die Dateinamen
in /proc/fd immer stehen oder ob die bloß aus dem dentry-Cache zusammen-
geklaubt werden und somit bei Speichermangel fehlen).


  Stefan

Stefan Reuther  writes:
> Rainer Weikusat wrote:
>> Michael Schuerig  writes:
>>>dauert bei mir 4m4.867s auf einem verschlüsselten Dateisystem das mit
>>>35GB zu ~50% gefüllt ist. Rsync wird nicht mit weniger auskommen, egal,
>>>ob sich etwas geändert hat oder nicht. Wenn dann tatsächlich nur wenige
>>>kleine Dateien ins Backup kopiert werden müssen, liegt eben doch der
>>>Hauptaufwand beim Finden der Änderungen.
>> 
>> Der Gedanke war mir mittlerweile auch gekommen. Aber sinnvollerweise
>> wuerde muesste man eine solche Aenderungsdatenbank als 'stacked
>> filesystem' implementieren, dass jeweils beim ersten 'write'-Aufruf
>> fuer eine bestimmte Datei deren Pfad (und vermutlich auch die
>> i-node-Nummer) irgendwo hinterlegt. Damit wuerde man aber alle writes
>> wenigstens ein bisschen langsamer machen und einen, der eine
>> 'Datenbankaktivitaet' nach sich zoege, vermutlich um ein gehoeriges
>> bisschen.
>
> Es würde ausreichen, diese Aktion an das Rausschreiben des inodes mit
> der geänderten mtime zu koppeln, was das ganze schon ein ganzes Stück
> entschärft.

Nicht wirklich. Schliesslich kann man die Daten nicht in die i-nodes
schreiben, sonst muesste man die ja wieder absuchen. In unguenstigen
Faellen (ein zweiter i-node muss aktualisiert werden und man benutzt
ein entsprechendes Dateisystem, zB [UF]FS) haette man dadurch die
Anzahl der synchronen Schreiboperationen fuer solche updates
verdoppelt. Dazu kaemen noch die fuer die eigentliche Datenbank.
k

Michael Schuerig  writes:
> Rainer Weikusat wrote:

[update log]

>> Damit wuerde man aber alle writes 
>> wenigstens ein bisschen langsamer machen und einen, der eine
>> 'Datenbankaktivitaet' nach sich zoege, vermutlich um ein gehoeriges
>> bisschen. Das erscheint mir fuer einen Hintergrundjob, der einmal am
>> Tag ausgefuehrt wird, immer noch kein guter tradeoff zu sein.
>
> Ja, die Kosten würden anders verteilt. Ob das für einen bestimmten
> Einsatzzweck akzeptabel ist, muss man natürlich individuell
> entscheiden.

Mal ein ganz anderer Gedanke: Es sollte doch eigentlich moeglich sein,
das 'journal' eines 'journalling'-Dateisystems als Aenderungsdatenbank
entweder zweckzuentfremden oder direkt zu benutzen.

Rainer Weikusat wrote:

> Michael Schuerig  writes:
>> Rainer Weikusat wrote:
> 
> [update log]
> 
>>> Damit wuerde man aber alle writes
>>> wenigstens ein bisschen langsamer machen und einen, der eine
>>> 'Datenbankaktivitaet' nach sich zoege, vermutlich um ein gehoeriges
>>> bisschen. Das erscheint mir fuer einen Hintergrundjob, der einmal am
>>> Tag ausgefuehrt wird, immer noch kein guter tradeoff zu sein.
>>
>> Ja, die Kosten würden anders verteilt. Ob das für einen bestimmten
>> Einsatzzweck akzeptabel ist, muss man natürlich individuell
>> entscheiden.
> 
> Mal ein ganz anderer Gedanke: Es sollte doch eigentlich moeglich sein,
> das 'journal' eines 'journalling'-Dateisystems als Aenderungsdatenbank
> entweder zweckzuentfremden oder direkt zu benutzen.

Hmm, ohne es genau zu wissen, denke ich doch, dass das Journal nur bis zum
nächsten erfolgreichen Daten-commit die Informationen hat. Michael möchte
aber die Informationen seit dem letzten Backup haben.

Gruß,
Bernd

Michael Schuerig wrote:

> Rainer Weikusat wrote:
> 
>> Michael Schuerig  writes:
> 
>>> Bist du sicher? Allein
>>>
>>> $ find /home > /dev/null
>>>
>>> dauert bei mir 4m4.867s auf einem verschlüsselten Dateisystem das mit
>>> 35GB zu ~50% gefüllt ist. Rsync wird nicht mit weniger auskommen,
>>> egal, ob sich etwas geändert hat oder nicht. Wenn dann tatsächlich
>>> nur wenige kleine Dateien ins Backup kopiert werden müssen, liegt
>>> eben doch der Hauptaufwand beim Finden der Änderungen.
>> 
>> Der Gedanke war mir mittlerweile auch gekommen. Aber sinnvollerweise
>> wuerde muesste man eine solche Aenderungsdatenbank als 'stacked
>> filesystem' implementieren, dass jeweils beim ersten 'write'-Aufruf
>> fuer eine bestimmte Datei deren Pfad (und vermutlich auch die
>> i-node-Nummer) irgendwo hinterlegt.
> 
> So tief hinein wollte ich ja gar nicht. Mir ging es darum, ob es mit
> (Linux-)Bordmitteln derzeit erreichbar ist.
> 
>> Damit wuerde man aber alle writes
>> wenigstens ein bisschen langsamer machen und einen, der eine
>> 'Datenbankaktivitaet' nach sich zoege, vermutlich um ein gehoeriges
>> bisschen. Das erscheint mir fuer einen Hintergrundjob, der einmal am
>> Tag ausgefuehrt wird, immer noch kein guter tradeoff zu sein.
> 
> Ja, die Kosten würden anders verteilt. Ob das für einen bestimmten
> Einsatzzweck akzeptabel ist, muss man natürlich individuell
> entscheiden. Für einen Server, der irgendwo im Rechenzentrum steht, und
> auf dem sich vorhersehbar nur bestimmte Daten ändern (dürfen), wäre das
> sicher unsinnig.
> 
> Aber nimm einen Endanwender mit Notebook (mich). Bei entsprechender
> Bastelneigung können Änderungen praktisch überall auftreten. Bei mir
> kann ein Backup mit rsnapshot (rsync + cp -al) durchaus 1 Stunde
> dauern. Ein stündliches Backup wäre damit also gar nicht möglich, ob
> nun sinnvoll oder nicht. Und natürlich könnte ich während des laufenden
> Backups das Notebook nicht spontan abkoppeln und mich damit nach
> draussen setzen. In diesem Fall würde der Gewinn die zusätzlichen
> Kosten bei Schreiboperationen ohne weiteres aufwiegen.

Das was Du möchtest lässt sich ziemlich einfach mit dem fuse implementieren.
Wenn wir vom fusexmp.c ausgehen, ist es nur noch das hinzufügen einer
Log-Datei für die open-Methode und 
flags & (O_WRONLY | O_RDWR).

Gruß,
Bernd

Bernd Schubert  writes:
> Rainer Weikusat wrote:
>> Michael Schuerig  writes:
>>> Rainer Weikusat wrote:
>> 
>> [update log]
>> 
>>>> Damit wuerde man aber alle writes
>>>> wenigstens ein bisschen langsamer machen und einen, der eine
>>>> 'Datenbankaktivitaet' nach sich zoege, vermutlich um ein gehoeriges
>>>> bisschen. Das erscheint mir fuer einen Hintergrundjob, der einmal am
>>>> Tag ausgefuehrt wird, immer noch kein guter tradeoff zu sein.
>>>
>>> Ja, die Kosten würden anders verteilt. Ob das für einen bestimmten
>>> Einsatzzweck akzeptabel ist, muss man natürlich individuell
>>> entscheiden.
>> 
>> Mal ein ganz anderer Gedanke: Es sollte doch eigentlich moeglich sein,
>> das 'journal' eines 'journalling'-Dateisystems als Aenderungsdatenbank
>> entweder zweckzuentfremden oder direkt zu benutzen.
>
> Hmm, ohne es genau zu wissen, denke ich doch, dass das Journal nur bis zum
> nächsten erfolgreichen Daten-commit die Informationen hat. Michael möchte
> aber die Informationen seit dem letzten Backup haben.

Auf Deutsch heisst obiger Satz ungefaehr: Ich (also Du) habe zwar auch
keine Ahnung davon, aber ich glaube Dein (also mein) Problem ist, das
Du (also ich) zu bloed bist, um die Frage zu verstehen.

Tip fuer Blitzmerker: Deswegen hatte ich 'zweckentfremden'
geschrieben.

Bernd Schubert wrote:

> Das was Du möchtest lässt sich ziemlich einfach mit dem fuse
> implementieren. Wenn wir vom fusexmp.c ausgehen, ist es nur noch das
> hinzufügen einer Log-Datei für die open-Methode und
> flags & (O_WRONLY | O_RDWR).

Das klingt gut. Machen werde ich es trotzdem nicht, weil mir dazu bisher
die Erfahrung in Kernel-naher Programmierung fehlt und mir für ein
erstes Projekt hier das Risiko zu groß ist.

Michael

-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/

Rainer Weikusat wrote:

> Bernd Schubert  writes:
>> Rainer Weikusat wrote:
>>> Michael Schuerig  writes:
>>>> Rainer Weikusat wrote:
>>> 
>>> [update log]
>>> 
>>>>> Damit wuerde man aber alle writes
>>>>> wenigstens ein bisschen langsamer machen und einen, der eine
>>>>> 'Datenbankaktivitaet' nach sich zoege, vermutlich um ein gehoeriges
>>>>> bisschen. Das erscheint mir fuer einen Hintergrundjob, der einmal am
>>>>> Tag ausgefuehrt wird, immer noch kein guter tradeoff zu sein.
>>>>
>>>> Ja, die Kosten würden anders verteilt. Ob das für einen bestimmten
>>>> Einsatzzweck akzeptabel ist, muss man natürlich individuell
>>>> entscheiden.
>>> 
>>> Mal ein ganz anderer Gedanke: Es sollte doch eigentlich moeglich sein,
>>> das 'journal' eines 'journalling'-Dateisystems als Aenderungsdatenbank
>>> entweder zweckzuentfremden oder direkt zu benutzen.
>>
>> Hmm, ohne es genau zu wissen, denke ich doch, dass das Journal nur bis
>> zum nächsten erfolgreichen Daten-commit die Informationen hat. Michael
>> möchte aber die Informationen seit dem letzten Backup haben.
> 
> Auf Deutsch heisst obiger Satz ungefaehr: Ich (also Du) habe zwar auch
> keine Ahnung davon, aber ich glaube Dein (also mein) Problem ist, das
> Du (also ich) zu bloed bist, um die Frage zu verstehen.

Nein, was ich eigentlich meinte, ist, dass das normale Dateisystem Journal
nicht mal Ansatzweise dafür ausgelegt ist. Dateisystem-Journale arbeiten
auf Block-Ebene, da ist im Prinzip auch der Dateiname völlig unwichtig.
Sicherlich lässt sich das ändern, aber der Aufwand ist dann eher so groß,
wie gleich ein geeignetes Journal für diesen Zweck zu schreiben.

Gruß,
Bernd

Michael Schuerig wrote:

> Bernd Schubert wrote:
> 
>> Das was Du möchtest lässt sich ziemlich einfach mit dem fuse
>> implementieren. Wenn wir vom fusexmp.c ausgehen, ist es nur noch das
>> hinzufügen einer Log-Datei für die open-Methode und
>> flags & (O_WRONLY | O_RDWR).
> 
> Das klingt gut. Machen werde ich es trotzdem nicht, weil mir dazu bisher
> die Erfahrung in Kernel-naher Programmierung fehlt und mir für ein
> erstes Projekt hier das Risiko zu groß ist.

Mit dem fuse ist ja gerade __keine__ Kernel-Programmierung, sondern normaler
Userspace. Der größte Aufwand dürfte es sein, die Information zu speichern. 
Einfache Textdatei - z.B. eine Datei pro Zeile, Problem dann Dateien nur
einmal zu erfassen (das dafür notwendige Parsen wird das Dateisystem zu
langsam machen). Besser ist also eine richtige Datenbank. Oder wie wir es
im unionfs-fuse machen, für whiteout-Dateien das Dateisystem als Datenbank
nutzen. 


Gruß,
Bernd

Bernd Schubert wrote:

> Michael Schuerig wrote:
> 
>> Bernd Schubert wrote:
>> 
>>> Das was Du möchtest lässt sich ziemlich einfach mit dem fuse
>>> implementieren. Wenn wir vom fusexmp.c ausgehen, ist es nur noch das
>>> hinzufügen einer Log-Datei für die open-Methode und
>>> flags & (O_WRONLY | O_RDWR).
>> 
>> Das klingt gut. Machen werde ich es trotzdem nicht, weil mir dazu
>> bisher die Erfahrung in Kernel-naher Programmierung fehlt und mir für
>> ein erstes Projekt hier das Risiko zu groß ist.
> 
> Mit dem fuse ist ja gerade __keine__ Kernel-Programmierung, sondern
> normaler Userspace.

Ja, sicher, aber noch immer sehr systemnah, wie immer man das nun
korrekt bezeichnet. Ich möchte meine Daten nicht meinen fehlenden
FUSE-Programmierkünsten anvertrauen.

Michael

-- 
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/