Re: code 11: files changed during backup

Lasse Kliemann <lasse-list-dar-discussions-2007-vHKVnW1TcfEx7OB5OnRqRA@public.gmane.org> Thu, 15 Mar 2007 21:50:54 +0100
Newsgroups gmane.comp.sysutils.backup.dar.general
Message-ID <[email protected]>
* Denis Corbin writes:
 
> I agree, this is acceptable that dar appends several copies of a
> 'unclean' files up to the time it can:
> - either properly save the file (which is no more recorded as 'unclean')
> - reach the maximum retry count specified by the user.
> 
> This feature should not be activated by default (a command line option
> is required for that), file are still marked as 'unclean' but no retry
> is performed by default.
> 
> At restoration, unclean files are restored with a warning (for backward
> compatibility this is better than not restoring them at all).
> If a file has been saved several times (may the last copy be also an
> unclean or a clean version of this file) only the last occurence is
> "visible" and accessible to the user. The other copies (thus except the
> last one) of a given file (clean or not) are just garbage in the archive.
> 
> For testing or diffing, only the last copy of an unclean file is
> considered (the diffing will most probably fail on such unclean files as
> they were changing at the time of the backup).
> 
> With theses restrictions, it seems possible to have this feature in dar.
 
I agree with all of this.


> > It should, of course, be user-configurable, whether retries should take place 
> > and how many of them at most per file. Maybe one could also allow the user to 
> > make the number of retries dependent on the size of the file.
> 
> maybe it would be better to have a user definable amount of byte that
> can be afforded to be wasted by file or by archive. If this amount is
> not exhausted, a new try could take place. In addition the retry per
> file could also be used.

This would make three numbers:

- an upper bound for the total waste,
- an upper bound for the waste per file,
- and an upper bound on the number of retries.

For a retry to take place, each of the actual values at that time must be 
below its upper bound. The upper bounds may be infinity, but at least a 
warning should be displayed when they are all three set to infinity.


> > So, for 
> > example, the user could say that for files above a certain size, no retries 
> > should be made. One could also allow the user to limit the total size that is 
> > spent on retries.
> 
> Note that a file can be detected as 'unclean' only once it has been
> saved completely.
> 
> > There are a lot of possibilities. For my purposes, it would 
> > be enough if I could say: 'give every file at most n retries and do not retry 
> > on files larger than x bytes.'
> >
> 
> Of course, it would not be much more complicated to have user definable
> "and" and "or" operation between different type of criterium, like what
> is done for EA or file selection. So far here I see several atomic tests:
> - max number of retry per file
> - max amount of already wasted bytes by unclean files in the archive
> - max amount of byte to waste by unclean data for each file
> 
> Theses could be "ANDed" or "ORed" to make something more complex like:
> "(retry file at most n times) and ((do not waste more than 20MB for
> unclean files) or (do not waste more than 500KB per file))"
> 
> thus an unclean file of 1GB could be tried at most n times if there is
> not yet more than 20MB of unclean data in the archive so far.

Would this not mean, it is tried at most once, because after one failure 
there is already more than 20MB wasted on unclean data? (This would not 
contradict what you wrote, I just want to make sure I understand correct.)

> ... While
> smaller files than 500KB could be tried at least n times even if already
> more than 20MB of unclean data is present in the archive so far.

Yes. Having these "AND"-"OR"-Feature would be near to an ultimate solution. I 
am unsure whether this is really necessary, however. If I were you, it would 
very much depend on the effort necessary to implement this. I presume that 
the simple solution (three upper bounds) will be sufficient most of the time. 
Maybe others on this list might want to express their views on this.


Regards, Lasse

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Dar-discussions mailing list
Dar-discussions-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/dar-discussions
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFF+bGu1gObwed86AkRAtA8AKCgMOj+NjBBHujcdOjlvp6t3VINugCg0L48
XskBxo5XYjmWLGC0gRIHP90=
=JqjY
-----END PGP SIGNATURE-----