1 2008-08-02 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
3 * To get merge operation faster would need a good benchmark test. What
4 02 spits out isn't reliable enough and is dominated by many other
7 commit 10176bf6b79865d4fe9f46e3857a3b8669fa7961
8 Author: Andreas J. Koenig <k@k75.(none)>
9 Date: Sat Aug 2 07:58:04 2008 +0200
13 commit 3243120a0c120aaddcd9b1f4db6689ff12ed2523
14 Author: Andreas J. Koenig <k@k75.(none)>
15 Date: Sat Aug 2 11:40:29 2008 +0200
17 there was a lot of trying but the effect is hardly measurable with
20 * overhead of connecting seems high. When setting
21 max_files_per_connection to 1 we see that.
23 2008-08-01 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
25 * 1217622571.0889 - 1217597432.86734 = 25138.2215600014
27 25138.2215600014/3600 = 6.98283932222261
29 It jumps into the eye that this is ~ 7 hours, not ~6, so there seems to
30 be a bug in the aggregator. FIXED
32 2008-07-27 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
34 * e.g. id/Y/YE/YEWENBIN/Emacs-PDE-0.2.16.tar.gz: Do we have it, should
35 we have it, can we mirror it, mirror it!
37 I fear this needs a new class which might be called
38 File::Rsync::Mirror::Recent. It would collect all recentfiles of a kind
39 and treat them as an entity. I realize that a single recentfile may be
40 sufficient for certain tasks and that it is handy for the low level
41 programmer but it is not nice to use. If there is a delete in the 1h
42 file then the 6h file still contains it. Seekers of the best information
43 need to combine at least some of the recentfiles most of the time.
45 There is the place for the Z loop!
47 But the combination is something to collect in a database, isn't it. Did
50 2008-07-26 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
52 * it just occurred to me that hosts in the same mirroring pool could
53 help out each other even without rewriting the recentfile. Just fetch
54 the stuff to mirror from several places, bingo. But that's something
55 that should rather live in a separate package or in rsync directly.
57 * cronjobs are unsuited because with ntp they would all come at the full
58 minute and disturb each other. Besides that I'd hate to have a backbone
59 with more than a few seconds latency.
61 2008-07-25 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
63 * a second rsync server with access control for PAUSE. Port? 873 is the
64 standard port, let's take 8873.
66 * if there were a filesystem based on this, it would have a slow access
67 to inexistent files. It would probably provide wrong readdir (only based
68 on current content) or also a slow one (based on a recentfile written
69 after the call). But it would provide fast access to existing files. Or
70 one would deliberately allow slightly blurred answers based on some
71 sqlite reflection of the recentfiles.
73 * todo: write a variant of mirror() that combines two or more
74 recentfiles and treats them like one
76 * todo: signal handler to remove the tempfile
78 2008-07-24 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
80 * now that we have the symlink I forgot how it should be used in
83 * the z loop: add missing files to Z file. Just append them (instead of
84 prepending). So one guy prepends something from the Y file from time to
85 time and another guy appends something rather frequently. Collecting
86 pond. When Y merges into Z, things get epoch and the collecting pond
87 gets smaller. What exactly are "missing files"?
89 take note of current epoch of the alpha file, let's call it the
92 find all files on disk
94 remove all files registered in the recentworld up to recent-ts
96 remove all files that have been deleted after recent-ts according to
99 2008-07-23 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
101 * rersyncrecent might be a cronjob with a (locked) state file which
102 contains things like after and maybe last z sync or such?
104 rrr-mirror might be an alternative name but how would we justify the
105 three Rs when there is no Re-Rsync-Recent?
107 With the --loop parameter it is an endless loop, without it is no loop.
108 At least this is simple.
110 * todo: new accssor z-interval specifies how often the Z file is updated
111 against the filesystem. We probably want no epoch stamp on these
112 entries. And we want to be able to filter the entries (e.g. no
113 by-modules and by-category tree)
115 2008-07-20 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
117 * Fill the Z file. gc or fsck or both. Somehow we must get the old files
118 into Z. We do not need the other files filled up with filesystem
121 * need interface to query for a file in order to NOT call update on
122 PAUSE a second time within a short time.
124 2008-07-19 Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de>
126 * recommended update interval? Makes no sense, is different for
133 change-log-default-name: "Todo"