[guardian-dev] IOCipher Status Update

[Hans-Christoph Steiner]

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.

.hc


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?
> 
> 
> 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
>>
>