[guardian-dev] IOCipher Status Update
hans at guardianproject.info
Fri Jan 18 10:44:47 EST 2013
Stephen, I'm online and available all day today and Monday to talk about this.
#guardianproject, skype, whatever.
David, they're working on it today and Monday. The libsqlfs and IOCipher
repos are up-to-date with all changes.
On 01/18/2013 09:24 AM, David Oliver wrote:
> 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?
> 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
>>> 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
>>> improving the lock situation so that we can have concurrent reads, or
>>> even SQLite3 3.7's WAL, if that's not too ambitious. This chunk is
>>> more complicated than the write work you just did, so it might just be
>>> 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
>>> looks like they take about 40-50% of the time of a similarly arranged
>> 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.
More information about the Guardian-dev