[guardian-dev] IOCipher Status Update

[David Oliver]

Thanks Stephen for this.  It seems like we're closing in on completion here
with the final step being Stephen's team looking at the lock issue and to
advise Guardian as to fixes/changes/etc that we (Guardian) would implement.

Stephen - can you provide a timeframe for your locking review?

HC, Abel - please advise if this is correct.  Also, do we have work to do
bringing to the repository up-to-date?


Dave

David M. Oliver | david at olivercoady.com | http://olivercoady.com |
http://dmo.tel | @davidmoliver | +1 970 368 2366


On Thu, Jan 17, 2013 at 10:58 PM, Stephen Lombardo
<sjlombardo at zetetic.net>wrote:

> Hello Hans,
>
> On 2013-01-15, Hans-Christoph Steiner wrote:
> > I'm integrating the IOCipher patch now, did you have any tests written
> up for
> > that already?  I renamed begin() and complete() to beginTransaction() and
> > completeTransaction() since the words 'begin' and 'complete' seemed too
> vague
> > in the context of the VirtualFileSystem class.  We'll work to document
> that so
> > people can make good use of it.
>
> We made several changes to the VfsTest project to add timings etc. to
> facilitate testing. The performance testing was still a bit manual, since
> we had to change the settings in libsqlfs, build a libiocipher.so, and then
> re-deploy the app, but it might be useful in the future. We'll commit it
> all up to a github repo tomorrow.
>
> > It would great if you could spend the remaining time (~10 hours) working
> on
> > improving the lock situation so that we can have concurrent reads, or
> maybe
> > even SQLite3 3.7's WAL, if that's not too ambitious.  This chunk is
> probably
> > more complicated than the write work you just did, so it might just be
> that
> > you end up giving us direction for how to implement it.
>
> This sounds good, we should have some time to look into the lockign,
> threading, and WAL setup tomorrow and Monday.
>
> > FYI, I added read
> > speed tests to tests/c_perf.c and they are already a lot faster than
> writes,
> > looks like they take about 40-50% of the time of a similarly arranged
> write.
>
> Ah, read tests are an excellent idea. That sounds consistent with what I
> would expect, there is a lot of extra overhead on the write side for each
> block read, update, write and commit. That should speed up a bit with WAL
> due to the way the writes occur as it cuts down on the number of pages that
> have to be written in each transaction by omitting the rollback journal.
>
> Cheers,
> Stephen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20130118/911a40a4/attachment-0001.html>