refuse to update certain files upon extraction

headers Lasse Kliemann | 19 Mar 2008 18:05

* Message by -Joerg Schilling- from Wed 2008-03-19:
> Lasse Kliemann <lasse-list-star-users <at> mail.plastictree.net> wrote:
> 
> > At first, I could not see how sleep(1) could prevent the same file to get 
> > archived twice. It will in fact not make any difference when using snapshots 
> > of live filesystems. But if there is a cycle: change files, dump, change 
> > files, dump, ..., then it will prevent files to be archived multiple times.
> 
> I am no longer sure how to do the sleep(1) correctly..... I'll fall back to
> the >= solution that has the disadvantage of a probability to archive a file
> when it is not really needed. 

I have no objection to this.

Users can always put a sleep in their scripts if they wish.

> My example from the man page
> 
> 
>      echo > /tmp/snapstamp
> 
>      mount -r `fssnap -F ufs -o \
>          backing-store=/var/tmp/EXPORT-NFS.snap /export/nfs` /mnt
> 
>      star -c -xdev -sparse -acl -link-dirs level=0 -wtardumps \
>          f=archive-name dumpdate=/tmp/snapstamp \
> 
> 
> will also archive some files twice although not needed because  /tmp/snapstamp is
> older than the snapshot itself.

Yes, and a sleep would have no effect here (save for the whole procedure 
taking one second longer then necessary .

By the way, this three-step-method (touch file, take fs snapshot, dump) can 
in fact lead to a significant amount of data archived twice, at least on 
Linux and under extreme conditions. I did tests once with blogbench running 
in parallel to such a dump.  Touching the timestamp file and taking the fs 
snapshot took ages, and obviously a large portion of that delay was between 
the touch and the snapshot. These are, however, extreme conditions, since 
blogbench really puts a lot of load on the system and generates huge amounts 
of data on the disk at the same time. Maybe it's also due to a bad scheduler. 
The Linux kernel offers at least three different schedulers.  In case I'll 
get bored some day, I'll do some benchmarks with them.

If one does that rsync-mirror-method I described earlier (keep a mirror of 
the filesystem via rsync, use star on the mirror) this no longer is an issue.  
For rsync works without timestamps, and star, in that case, can work without 
dumpdate=..., because star can rely on the ctimes on the mirror; they are 
updated by rsync. But since this method itself brings a significant space and 
time overhead, it should be rarely prefered.

Lasse

Re: refuse to update certain files upon extraction