Re: gbde data corruption?

Heiko Schaefer wrote:
> > While you are at it, consider "man tunefs", and read about the
> > "-m" option to see why "-m 0" is a terrible thing to do; in
> > particular, read the first and last paragraphs.
> 
> i believe i'm aware of the issues with "tunefs -m 0". i only use it as a
> temporary means of cramming data onto disks. with 60GB drives it sometimes
> comes in handy to temporarily use those 8% (4.6GB in that case).
> of course i leave minfree at 8% on filesystems to which i write regularly.

I mentioned it because you complained about a problem that
was obviously related to using that option.  The problem is
that you can't string non-adjacent frags together to get full
disk blocks, and you were wondering why the files were appearing
trashed when you thought you had free space left, but you didn't,
because you told the OS ("tunefs -m 0") that fragmentation was
OK, and you didn't care about it.

FWIW, the fragmentation you end up with doing this is persistant,
unless you delete *every file* you created after tuning it this
way, to return the system back to a reasonable state.


> my comments on speed were unrelated to tunefs-related slowness, but i
> suppose it is reasonable to expect a "tunefs -m 0"'d filesystem to be
> reliable, albeit slow. that was what concerned me. but as it turned out, i
> just used a broken version of the gbde code.

The only problem between 1.12 and 1.13 is MD5_KEY was defined.
This wouldn't break you the way you were breaking.  Unless you
are talking about the recent 1.14 checkin?  The major code there
is:

	if (wp->so + wp->length > kp->media_width)
		wp->length = kp->media_width - wp->so;

I'm pretty sure this won't trigger for a 60GB drive, at least not
with the MD5_KEY defined, which seems to disable the problem, which
requires a specific random number, sector size, and media size that
wouldn't be applicable in your case.


> initial fiddling points that poul's hint of using "-i" when gdbe initing
> and setting the sector_size improves speed greatly for me.

Yeah; without setting, it though, you should not have been able
to trigger the bug that 1.14 fixes.


> anyway, thanks for pointing it out - there are certainly enough other
> obvious things that i'm not aware of :)

No problem; but you will probably want to avoid "-m 0", if at
all possible.  My own recommendation, as far as speed goes, is
"-m 15", which is at the 85% fill for efficiency of a perfect
hash, at which point performance is expected to drop off.  8-).

-- Terry