> 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.
Where it conflicts with my proposition ?
> - 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.
a) There is no checksum field in ODS12, but it doesn't matter here because
even if will return checksums it should be calculated for encrypted image
*stored on disk* (because checksums are guard against disk errors).
b) Page header sooner af all will not be encrypted.
c) Where it conflicts with my proposition ?
> - 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.
How do you going to detect still not encrypted pages if you against
"encrypted" flag ?
> Pages itself does not need that flags - they are being written
> in atomic way, so they can't be "in progress".
This flag is *required* to distinguish encrypted pages. I don't understand
why do you object it.
> Yes, this way FB will read (at least) the whole database.
> So? It was intended to do it when encryption/decryption was started.
Why do we need to do a dumb work ?
Sorry, but i see no arguments in your disagreement ;)
Regards,
Vlad
------------------------------------------------------------------------------
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
