Hello, Vlad! Tuesday, April 3, 2012, 12:44:07 PM, you wrote:
VK> Encryption must be resistent to the database shutdown\server restart and so on. VK> Therefore it must be restartable. As we going to add "encrypted" flag for each page VK> we can know pages that already encrypted. To not read whole database searching VK> for the not encrypted pages after restart i offer to store last encrypted page number VK> at header page (also, obviously, we need to store encription state on the header VK> such as "clear", "encrypted", "encryption is in progress", "decryption is in progress"). disagree, because - not all db pages need to be encrypted. for example PIP, TIP, etc. Performance effect of decrypting/encrypting these pages can be disasterous. - I suspect that pages will not be encrypted as a whole. Otherwise, engine will need to understand page type only after decryption. And, we already have checksum field in the page header, that can indicate, it is decrypted or not. - if there were reset during encryption, this is the abnormal sitiation, and it can be fixed, for example, with header page flag "encryption is in progress" and "encrypted". The mechanism can be same while engine checks TIP on "first connect". If first connect see that DB is "in progress", it just continues to encrypt (or decrypt) pages that are "not finished" yet. Pages itself does not need that flags - they are being written in atomic way, so they can't be "in progress". Yes, this way FB will read (at least) the whole database. So? It was intended to do it when encryption/decryption was started. -- Dmitry Kuzmenko, www.ibase.ru, (495) 953-13-34 ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
