[guardian-dev] IOCipher Status Update

[Abel Luck]

+1 from me.

As Hans said, our repos have merged all the Zetetic changes.

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