Re: still: Re: gbde data corruption?

In message <20030430141207.L27116_at_daneel.foundation.hs>, Heiko Schaefer writes:

>hmm, i am now on cvs as of yesterday evening, including all your changes
>in sys/geom/ up to just now (just looked in cvsweb, nothing newer than
>what i use there).
>
>but i still get corruption of data, judging by checksum testing.
>again, the corrupted file i see is much more compressible than the
>uncorrupted original.

That is really strange, the problems I've seen until now have all
resulted in data coming back scrambled beyond recognition, and therefore
practically incompressible, this sounds like they're filled with identical
bytes or sectors of some kind.

Can you try to run "cmp -l oldfile newfile" and study the output
for a bit ?  Any observations you can make will be helpful.

>(potentially this could also be an nfs-issue, as i am copying onto the
>gbde partition via nfs from a 4.6-rc machine. but i can't really imagine
>that, never had anything like that in all of my non-gbde freebsd nfs
>experience. if it is an nfs issue, then it would probably be fbsd-5
>specific - is there any such known issue ?!)

I doubt it is NFS, but it would be nice if you could verify the checksum
on both the client and server side, just to see that they agree.

>the partition in question now looks like this:
>e: 117231392       16    4.2BSD     4096 16384    64  # (Cyl.    0*- 7297*)

What does diskinfo(8) say about the encrypted (ad0e.bde) and unencrypted
(ad0e) devices (for some value of "ad0") ?

>this time i inited gbde's sectorsize to "4096". last time i reported
>corruption, gbde's sectorsize was at its default (i presume 512). the
>corruption then 'felt' just the same. very sporadic - and somewhat
>non-deterministic from my point of view.

The sectorsize is mainly a performance issue, it should not affect operation

I currently have no bugs showing up in my test-cases, but of course
that has always been the "stable state", I add testcases when I
manage to reproduce a bug, and then I fix it :-)

-- 
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.