FUD about CGD and GBDE

[ALeine]

phk at phk.freebsd.dk wrote: 

> In message <20050303120421.GW86348 at cicely12.cicely.de>, Bernd
> Walter writes:
>
> >And how would you know that a restore from backup is required
> >for a damaged file?
> 
> 100% true.
> 
> The trouble is that it would cost a lot in performance and a
> doubling in metadata to protect yourself against this.

Not necessarily, if one were to implement the ideas I proposed
I believe the performance could be kept at the same level as now.

To summarize my ideas:

1. Introduction of journaling

I described this idea in detail here:
http://docs.FreeBSD.org/cgi/mid.cgi?200502282202.j1SM21qs042751

The user would decide how many key sectors would be using a single
key shadow sector, for example, 1 key shadow sector for every 8 key
sectors. That would add only 1/8th (12.5%) in metadata size and
1/264th (0.38%) overall. On a 400 Gb disk this would be 1.5 Gb.

264 = 8 * (32 data sectors + 1 key sector)

Then a kernel sysctl variable would control whether journaling is
enabled or not (kern.geom.bde.atomic_writes_enabled). Now there are
two possibilities: either make journaling a volume initialization
option: if you specify it the key shadow sectors are allocated,
otherwise not (kern.geom.bde.atomic_writes_enabled is ignored,
which might make someone falsely believe that they have journaling
on a volume that was not initialized for it) or make it possible to
turn journaling on later by allocating key shadow sectors by default
(so they are used according to kern.geom.bde.atomic_writes_enabled).

One could even implement a totally automatic fsck(8) recovery of
incomplete writes by storing the HMAC of the last written data
sector inside the shadow key sector,  there is plenty of room for
it there. This way one would get data integrity and automatically
recoverable volumes without having to store the HMAC for every
data sector, in the example I stated above there would be one
HMAC (shadow key sector) place holder protecting 256 data sectors.

2. Introduction of per-key sector grouping

This would be set at volume initialization, the user would set the
number of sectors that are to be encrypted with the same key.

Based on this one could also increase the key size as long as all
the keys for a zone fit inside one sector (for example, by having
two sectors encrypted with the same key one could already use AES256).

3. Introduction of control over key regeneration cycle

There would be a sysctl variable to control after how many writes
the key is regenerated (kern.geom.bde.key_regeneration_on_write_cycle).
This would speed things up quite a bit and users would be allowed to
decide what is more important to them in terms of speed and assumed
security.

If all this were implemented I believe the performance on volumes
initialized to take advantage of the possible speedups would not
be worse than with the current implementation of GBDE. Comments?

ALeine
___________________________________________________________________
WebMail FREE http://mail.austrosearch.net