Todo

   1 2008-09-02  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
   2
   3         * need to speed up the 02 test, it's not clever to sleep so much. Reduce
   4         the intervals!
   5
   6         * rersyncrecent, the script: default to one week. The name of the switch
   7         is --after. Other switches?
   8
   9 2008-08-30  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
  10
  11         * need a switch --skip-deletes (?)
  12
  13         * need a switch --enduser that tells us that the whole tempfile
  14         discipline is not needed when there is no downstream user. (?)
  15
  16         Without this switch we cannot have a reasonable recent.pl that just
  17         displays the recent additions. Either we accept to download everything.
  18         Or we download temporary files without the typical rsync protocol
  19         advantages.
  20
  21         Or maybe the switch is --tmpdir? If --tmpdir would mean: do not use
  22         File::Temp::tempdir, this might be a win.
  23
  24 2008-08-29  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
  25
  26         * apropos missing: we have no push, we never know the downstream
  27         servers. People who know their downstream hosts and want to ascertain
  28         something will want additional methods we have never thought about, like
  29         update or delete a certain file.
  30
  31 2008-08-26  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
  32
  33         * tempted to refactor rmirror into resolve_symlink, localize, etc.
  34         Curious if rsync_options=links equal 0 vs. 1 will make the expected
  35         difference.
  36
  37         * rsync options: it's a bit of a pain that we usually need several rsync
  38         options, like compress, links, times, checksum and that there is no
  39         reasonable default except the original rsync default. I think wee can
  40         safely assume that the rsync options are shared between all recentfile
  41         instances within one recent tree.
  42
  43 2008-08-20  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
  44
  45         * deletes: if a delete follows an add quickly enough it may happen that
  46         a downstream mirror did not see the add at all! It seems this needs to
  47         be mentioned somewhere. The point here is that even if the downstream is
  48         never missing the principal timeframe it may encounter a "delete" that
  49         has no complimentary "add" anywhere.
  50
  51 2008-08-19  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
  52
  53         * I suspect the treat of metadata is incorrect during read or something.
  54         The bug that I am watching is that between 06:08 and 06:09 the 6h file
  55         contained more than 6 hours worth of data. At 06:08 we merged into the
  56         1d file. We need to take snapshots of the 6h file over the course of an
  57         hour or maybe only between XX:08 and XX:09? Nope, the latter is not
  58         enough.
  59
  60         Much worse: watching the 1h file: right at the moment (at 06:35) it
  61         covers 1218867584-1219120397 which is 70 hours.
  62
  63         Something terribly broken. BTW, 1218867584 corresponds to Sat Aug 16
  64         08:19:44 2008, that is when I checked out last time, so it seems to be
  65         aggregating and never truncating?
  66
  67         No, correct is: it is never truncating; but wrong is: it is aggregating.
  68         It does receive a lot of events from time to time from a larger file.
  69         Somehow a large file gets merged into the small one and because the
  70         "meta/merged" attribute is missing, nobody is paying attention. I
  71         believe that I can fix this by making sure that metadata are honoured
  72         during read. DONE and test adjusted.
  73
  74 2008-08-17  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
  75
  76         * grand renaming plan
  77
  78         remotebase          => remoteroot   to fit well with localroot        DONE
  79         local_path()        => localroot    seems to me should already work   DONE
  80         recentfile_basename => rfilename    no need to stress it has no slash DONE
  81
  82         filenameroot??? Doesn't seem too bad to me today. Maybe something like
  83         kern? It would anyway need a deprecation cycle because it is an
  84         important constructor.
  85
  86         * I like the portability that Data::Serializer brings us but the price
  87         is that some day we might find out that it is slowing us a bit. We'll
  88         see.
  89
  90 2008-08-16  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
  91
  92         * should we not enter the interval of the principal (or the interval of
  93         the merging file?) in every aggregated/merged file?
  94
  95         * we should aim at a first release and give up on thinking about
  96         sanitizing stuff and zloop. Let's just admit that a full traditional
  97         rsync is the only available sanitizer ATM. Otherwise it's complicated
  98         stuff: sanitizing on the origin server, sanitizing on the slaves,
  99         sanitizing forgotten files, broken timestamps, etc. Let's delay it and
 100         get the basics out before this becomes a major cause for mess.
 101
 102 2008-08-13  Andreas Koenig  <k@andreas-koenigs-computer.local>
 103
 104         * On OSes not supporting symlinks we expect that RECENT.recent contains
 105         the contents of the principal recentfile. Actually this is identical on
 106         systems supporting symlinks. Simple, what follows from that is that we
 107         need to keep the serializer in the metadata because we cannot read it
 108         from the filename, doesn't it? Of course not. It's a chicken and egg
 109         problem. This leaves us with the problem to actually parse the
 110         serialized data to find out in which format it is. So who can do the 4
 111         or 5 magics we wanted to support? File::LibMagic?
 112
 113 2008-08-09  Andreas Koenig  <k@andreas-koenigs-computer.local>
 114
 115         * remotebase and recentfile_basename are ugly names. Now that we need a
 116         word for the shortest/principal/driving recentfile too we should do
 117         something about it.
 118
 119         localroot is good. rfile is good. local_path() is bad, local_path($path)
 120         is medium, filenameroot() is bad, remotebase is bad, recentfile is
 121         already deprecated.
 122
 123         Up to now remotebase was the string that described the remote root
 124         directory in rsync notation, like pause.perl.org::authors. And
 125         recentfile_basename was "RECENT-1h.yaml".
 126
 127 2008-08-08  Andreas Koenig  <k@andreas-koenigs-computer.local>
 128
 129         * The test that was added in today's checkin is a good start for a test
 130         of rmirror. We should have more methods in Recent.pm: verify,
 131         addmissingfiles. We should verify the current tree, then rmirror it and
 132         then verifytree the copy. We could then add some arbitrary file and let
 133         it be discovered by addmissingfiles, then rmirror again and then
 134         verifytree the copy again.
 135
 136         Then we could start stealing from csync2 sqlite database [no port to
 137         OSX!] and fill a local DB. And methods to compare the database with the
 138         recentfiles. Our strength is that in principle we could maintain state
 139         with a single float. We have synced up to 1234567890.123456. If the Z
 140         file does not add new files all we have to do is mirror the new ones and
 141         delete the goners.
 142
 143         This makes it clear that we should extend current protocol and declare
 144         that we cheat when we add files too late, just to help the other end
 145         keeping track. Ah yes, that's what was meant when zloop was mentioned
 146         earlier.
 147
 148         Maybe need to revisit File::Mirror to help me with this task.
 149
 150 2008-08-07  Andreas Koenig  <k@andreas-koenigs-computer.local>
 151
 152         * There must be an allow-me-to-truncate flag in every recentfile.
 153         Without it one could construct a sequence of updates winning the locking
 154         battle against the aggregator. Only if an aggregator has managed to
 155         merge data over to the next level, truncating can be allowed. DONE with
 156         accessor merged.
 157
 158 2008-08-06  Andreas Koenig  <k@andreas-koenigs-computer.local>
 159
 160         * We should probably guarantee that no duplicates enter the aggregator
 161         array.
 162
 163 2008-08-02  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
 164
 165         * To get merge operation faster would need a good benchmark test. What
 166         02 spits out isn't reliable enough and is dominated by many other
 167         things. Between
 168
 169         commit 10176bf6b79865d4fe9f46e3857a3b8669fa7961
 170         Author: Andreas J. Koenig <k@k75.(none)>
 171         Date:   Sat Aug 2 07:58:04 2008 +0200
 172
 173         and
 174
 175         commit 3243120a0c120aaddcd9b1f4db6689ff12ed2523
 176         Author: Andreas J. Koenig <k@k75.(none)>
 177         Date:   Sat Aug 2 11:40:29 2008 +0200
 178
 179         there was a lot of trying but the effect is hardly measurable with
 180         current tests.
 181
 182         * overhead of connecting seems high. When setting
 183         max_files_per_connection to 1 we see that.
 184
 185 2008-08-01  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
 186
 187         * 1217622571.0889 - 1217597432.86734 = 25138.2215600014
 188
 189         25138.2215600014/3600 = 6.98283932222261
 190
 191         It jumps into the eye that this is ~ 7 hours, not ~6, so there seems to
 192         be a bug in the aggregator. FIXED
 193
 194 2008-07-27  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
 195
 196         * e.g. id/Y/YE/YEWENBIN/Emacs-PDE-0.2.16.tar.gz: Do we have it, should
 197         we have it, can we mirror it, mirror it!
 198
 199         I fear this needs a new class which might be called
 200         File::Rsync::Mirror::Recent. It would collect all recentfiles of a kind
 201         and treat them as an entity. I realize that a single recentfile may be
 202         sufficient for certain tasks and that it is handy for the low level
 203         programmer but it is not nice to use. If there is a delete in the 1h
 204         file then the 6h file still contains it. Seekers of the best information
 205         need to combine at least some of the recentfiles most of the time.
 206
 207         There is the place for the Z loop!
 208
 209         But the combination is something to collect in a database, isn't it. Did
 210         csync2 just harrumph?
 211
 212 2008-07-26  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
 213
 214         * it just occurred to me that hosts in the same mirroring pool could
 215         help out each other even without rewriting the recentfile. Just fetch
 216         the stuff to mirror from several places, bingo. But that's something
 217         that should rather live in a separate package or in rsync directly.
 218
 219         * cronjobs are unsuited because with ntp they would all come at the full
 220         minute and disturb each other. Besides that I'd hate to have a backbone
 221         with more than a few seconds latency.
 222
 223 2008-07-25  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
 224
 225         * a second rsync server with access control for PAUSE. Port? 873 is the
 226         standard port, let's take 8873.
 227
 228         * if there were a filesystem based on this, it would have a slow access
 229         to inexistent files. It would probably provide wrong readdir (only based
 230         on current content) or also a slow one (based on a recentfile written
 231         after the call). But it would provide fast access to existing files. Or
 232         one would deliberately allow slightly blurred answers based on some
 233         sqlite reflection of the recentfiles.
 234
 235         * todo: write a variant of mirror() that combines two or more
 236         recentfiles and treats them like one
 237
 238         * todo: signal handler to remove the tempfile
 239
 240 2008-07-24  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
 241
 242         * now that we have the symlink I forgot how it should be used in
 243         practice.
 244
 245         * the z loop: add missing files to Z file. Just append them (instead of
 246         prepending). So one guy prepends something from the Y file from time to
 247         time and another guy appends something rather frequently. Collecting
 248         pond. When Y merges into Z, things get epoch and the collecting pond
 249         gets smaller. What exactly are "missing files"?
 250
 251         take note of current epoch of the alpha file, let's call it the
 252         recent-ts
 253
 254         find all files on disk
 255
 256         remove all files registered in the recentworld up to recent-ts
 257
 258         remove all files that have been deleted after recent-ts according to
 259         recentworld
 260
 261 2008-07-23  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
 262
 263         * rersyncrecent might be a cronjob with a (locked) state file which
 264         contains things like after and maybe last z sync or such?
 265
 266         rrr-mirror might be an alternative name but how would we justify the
 267         three Rs when there is no Re-Rsync-Recent?
 268
 269         With the --loop parameter it is an endless loop, without it is no loop.
 270         At least this is simple.
 271
 272         * todo: new accssor z-interval specifies how often the Z file is updated
 273         against the filesystem. We probably want no epoch stamp on these
 274         entries. And we want to be able to filter the entries (e.g. no
 275         by-modules and by-category tree)
 276
 277 2008-07-20  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
 278
 279         * Fill the Z file. gc or fsck or both. Somehow we must get the old files
 280         into Z. We do not need the other files filled up with filesystem
 281         contents though.
 282
 283         * need interface to query for a file in order to NOT call update on
 284         PAUSE a second time within a short time.
 285
 286 2008-07-19  Andreas J. Koenig  <andreas.koenig.7os6VVqR@franz.ak.mind.de>
 287
 288         * recommended update interval? Makes no sense, is different for
 289         different users.
 290
 291         * Moosify
 292
 293         Local Variables:
 294         mode: change-log
 295         change-log-default-name: "Todo"
 296         tab-width: 2
 297         left-margin: 2
 298         End: