Quoth Paul Vercellotti <pverce...@yahoo.com>, on 2013-06-07 01:07:35 -0700: > The current system does in-place decryption on read (no copying), which adds > almost no overhead to the operation. Now in-place decryption with a > memory-mapped file seems like it would dirty the page, which could > accidentally get flushed back to the file on close potentially corrupting the > database - I'm wondering if that's a valid concern.
Yes, you can't safely do it in-place on the mapped region; you'd have to make a copy. Since the big advantage of memory mapping is avoiding the copy, the benefit would be noticeably decreased, I'd think---though if your decryption code can do an out-of-place transformation "just as easily" then you could still elide that together with the copy and maybe be a bit easier on the cache than an explicit kernel->user copy plus an in-place transformation. If you really want, you might be able to implement xFetch to allocate a shadow buffer, decrypt from the map into that, and return that pointer. Since it's designed for accessing maps directly, though, I don't see it documented what the lifetime of that pointer has to be---it might be "until the file is closed", in which case you have to keep those shadow buffers alive the entire time, but you might still avoid taking syscalls that way. ---> Drake Wilson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
