Re: gbde data corruption?

In message <20030429171204.W20908_at_daneel.foundation.hs>, Heiko Schaefer writes:

>i'll stress-test it some more after i get to reboot that machine
>physically this evening. mounting the filesystems that used to make some
>sense with 1.12 after upgrading to 1.13 apparently hanged the machine
>after some short time.
>
>my hope is to eventually have an nfs server (200gb data is waiting to live
>on it) that can saturize 100mbit - and is also reliable :)

That will take some hardware.  I'm very interested in hearing how it goes.

>how much (incompatible) change in the format of the gbde data do you
>expect ? can i hope for something stable in 5.1, for example ?!

There is no change of format, it was only 1.12 which got børked.

>> Much worse than that:  They get cut into smaller I/O requests and the
>> cpu has to chew on them a lot.  While GBDE is not directly slow, it
>> will never be as fast as an unencrypted partitition.
>
>hm... cpu seems to be not the limiting factor at all - that machine has an
>athlon 1800+ and is idle >>50% most of the time. without understanding the
>technical details, it seems to me that working on bigger chunks of the
>disc at a time would result in much more throughput.

Yes.

Remember to set the sectorsize in gbde (gbde init -i) to the fragment
size of your filesystem (typically 2048 for ufs), this is critical
for performance.

>in general, as long as the cpu is not maxed out, shouldn't only latency -
>but not throughput - be impacted by using gbde?

CPU will limit your throughput, disk-seeks latency.

>in absolute terms: getting approximately 1,5MB/s for writing access on a
>relatively modern harddisk seems quite low to me. does the data get
>scattered on the physical disc, or what could cause this ?
>
>read access is less tragic - approx 10MB/s (compared to slightly over
>20MB/s on the same drive with a non-gbde mount) - but i also don't quite
>understand what leads to that.

GBDE encrypts each sector with an individual key, and both the encrypted
data, and the encrypted key needs to be stored on disk, so the number
of disk-IO is effectively doubled.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.