-------- Weitergeleitete Nachricht -------- Von: Jean-Peer Lorenz <peer....@gmx.net> An: Anton Feenstra <feens...@few.vu.nl> Betreff: Re: Logarithmic purge disabled Datum: Mon, 23 Aug 2010 10:54:16 +0200
Good morning Anton, Thank you for looking into SBackup and your bug tracking. Another maintainer able to fix minor flaws would be great. Software maintenance is really time consuming. I'm sorry to tell you, that I've already fixed the purge issue. I'll prepare an updated release within the next days. I've re-implemented it similar to the simple purge: only freestanding snapshots are removed and the removal process is repeated until no freestanding snapshot or at least 1 snapshot remain (within a certain period). The more I think about rebasing of snapshots, the more I dislike the whole idea. It is always dangerous to modify backuped data, even more if it stored in 'foreign' formats (here tar). Moreover, the current implementation of writing TAR snapshot files (snar files) contains errors and updating tarballs in only possible for uncompressed tars. So, I consider to cut rebasing completely. But that's another story... > I don't get why it becomes so expensive? Because of the current implementation. Each path that is processed is compared to every stored path in sequential manner. Regards, Jean-Peer Am Montag, den 23.08.2010, 09:37 +0200 schrieb Anton Feenstra: > Hi Jean-Peer, > > I'm considering what & how to implement. It seems the rebase operations, > although a nice idea, quickly become too costly. > > As an alternative, I'm considering changing the purge logic to purge > incremental snapshots only when their base (full) snapshot is scheduled > to purge as well. This is the easy part. More tricky is that we do not > want to purge a full (base) snapshot when any of its incremental (child) > snapshots should be retained (though I'm not sure when exactly this > condition could apply). I'm thinking now on how to implement this (will > come back on that). > > I think it would be best to add a config option for this, like: > - purge incremental snapshots individually by re-basing (may be slow) > *or* > - purge incremental shapshots together with their base (full) snapshot > > As a sidenote, I think I understand the basic logic of the rebasing, > however I don't get why it becomes so expensive? >
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Mailing list: https://launchpad.net/~nssbackup-team Post to : nssbackup-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~nssbackup-team More help : https://help.launchpad.net/ListHelp
