[EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, 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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
