Re: [mirrorbrain] ToDo for upcoming 2.13.0 release

Agreed on the hashes cleanup. This should be done before any stable
release that implements hashes in the db to eliminate the need for too
much backwards thinking, as most will be starting from a clean slate.
Perhaps you could eliminate all previous stale hash logic completely,
and simply suggest that users clear the table first. Or maybe I'm
overthinking since non-existent files would be cleared anyway.

As for on-disk hashes, is there any valid reason to leave them on? Imo
it makes sense to deprecate the option (off by default, stored in the
db instead) for a few releases and see if anyone screams.

Cory

On Wed, May 5, 2010 at 1:03 PM, Peter Poeml <peter_at_poeml.de> wrote:
> Hi,
>
> 2.13.0 release is around the corner - and here's a little the list of
> things that I'd like to see fixed beforehand:
>
>
> - implement database cleanup for "mb makehashes". So far, it only
>  creates hashes, but never deletes them. It should delete hashes for
>  non-existing files (per directory), as it was done (and is still done)
>  for hashes stored on disk.
>
> - what's the strategy for Torrent files and hashes (.md5 & friends) that
>  already exist on-disk? Should generated torrents/hashes replace them?
>  Or should existing files take precedence?
> - make creation of Zsync hashes configurable (in order to save
>  resources). Eventually, it should be configurable if zsync hashes are
>  created only for certain directories/files. Zsync hashes can get quite
>  large (roughly 10 times larger than torrent hashes). For the upcoming
>  release, it is sufficient to have these hashes switched off in the
>  default configuration; the rest can happen later.
> - make creation of Torrent hashes configurable (same as zsync)
>
> - http://mirrorbrain.org/issues/issue54 - the hasher used to ignore
>  unreadable files, but doesn't anymore
>
> - check for correct handling of empty files by mb hashes (just to make
>  sure it doesn't do something utterly stupid)
>
> - ponder if we can already switch off creation of on-disk hashes in "mb
>  makehashes" (with hashes being saved in the database now)
>
> - critically eye DBD memory management once again (probably fine, since
>  2.13.0 code runs stable in production since weeks now, and the initial
>  memory consumption has been tracked down to be caused by large zsync
>  hashes)
>
> - quick & easy: include an sha1 top hash into torrents
>
> - torrents: nodes key (http://mirrorbrain.org/issues/issue49)
>
>
> The top two issues are the most important ones IMO.
> Peter
>

_______________________________________________
mirrorbrain mailing list
Archive: http://mirrorbrain.org/archive/mirrorbrain/

Note: To remove yourself from this mailing list, send a mail with the content
 	unsubscribe
to the address mirrorbrain-request_at_mirrorbrain.org