Re: refuse to update certain files upon extraction

--===============1661394470==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ"
Content-Disposition: inline


--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Message by -Joerg Schilling- from Wed 2008-03-19:
> Lasse Kliemann <[email protected]> wrote:
>=20
> > At first, I could not see how sleep(1) could prevent the same file to g=
et=20
> > archived twice. It will in fact not make any difference when using snap=
shots=20
> > of live filesystems. But if there is a cycle: change files, dump, chang=
e=20
> > files, dump, ..., then it will prevent files to be archived multiple ti=
mes.
>=20
> I am no longer sure how to do the sleep(1) correctly..... I'll fall back =
to
> the >=3D solution that has the disadvantage of a probability to archive a=
 file
> when it is not really needed.=20
=20
I have no objection to this.

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

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

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


By the way, this three-step-method (touch file, take fs snapshot, dump) can=
=20
in fact lead to a significant amount of data archived twice, at least on=20
Linux and under extreme conditions. I did tests once with blogbench running=
=20
in parallel to such a dump.  Touching the timestamp file and taking the fs=
=20
snapshot took ages, and obviously a large portion of that delay was between=
=20
the touch and the snapshot. These are, however, extreme conditions, since=
=20
blogbench really puts a lot of load on the system and generates huge amount=
s=20
of data on the disk at the same time. Maybe it's also due to a bad schedule=
r.=20
The Linux kernel offers at least three different schedulers.  In case I'll=
=20
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=
=20
the filesystem via rsync, use star on the mirror) this no longer is an issu=
e. =20
For rsync works without timestamps, and star, in that case, can work withou=
t=20
dumpdate=3D..., because star can rely on the ctimes on the mirror; they are=
=20
updated by rsync. But since this method itself brings a significant space a=
nd=20
time overhead, it should be rarely prefered.

Lasse

--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)

iQIcBAEBAgAGBQJH4UfoAAoJEFYll6N4nhdv1a4QAJmdPn7DUmSSAEcUOwe+PZQr
1HG9BORKR1oYH9VXTjhpDsl2fOeFuyl8e1OtcT+Y1qU9Ql1YKE7lC6zOdQd5+/y2
Vx7V/VpeFLpKAxxbc/iD+ISgRPhk8x5XOkQyGr0FLPUqzG4da6LVnFT5Mgmo0nBV
uvRPqZoalXcHj1ghRVQL1Z7rwnFrXHnRz/x2wuAza2DhVdReX52p4u70jqMijZJf
Bj2UQeyznfw+XLqXBcvJO4bO/ke6EbSjWQTsJjPQecbeEVwONt/Z2l3o+aQTCL7B
sNkCdJTALxdQP9XKphXvVuiSfo2uz85gChMv77L7+dEoesN+xhAssfudpzJUkY1K
HrHHaiJ84OeZxRupyWoNErk/624PP+ymnrKClES6g1bc62tSfatSkLqaV8r0hsAE
bXbRmdSNuYdWDWDmlNsJBz6QWxoZKdP2GNguZ2e60ljkX5q9o7ewpprYF/4qCRRO
LaoshFajmn2Otmlb904RBdnppGYsGkZx5Gk737rWGkG91MVzYLKqXgR/5ujKivEM
6bNRQUw+fnEg3a91XQqqgcdxLH/6KddmEFUD+m0I6yEI2ZtWYwqaM8eNh9BhIGgK
ytXAwG8vRtIwULqSkGg91fMQ5ngVmSa+aH2ZI6Frb77pDWDOybTC1tyJ8bn01ZlM
ixnBtmW1SQsAFU5GoSOa
=6Wtn
-----END PGP SIGNATURE-----

--rwEMma7ioTxnRzrJ--

--===============1661394470==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Star-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/star-users

--===============1661394470==--