The Problem was the use of vfs.ioopt=2 !
As long as vfs.ioopt is 1 or 2 the CDs are broken and with
vfs.ioopt=0 the CDs are o.k.
I didn't see any other problems with the use of vfs.ioopt=2,
especially no Filesystem corruption :-). Are there other known
problems withs vfs.ioopt != 0 ?
Ciao
On Mon, 26 Nov 2001, Kenneth D. Merry wrote:
So did you try the statically linked -stable binary on -current?
Yes, I used the newest version from the ports (compiled on -CURRENT) and
the staticly linked from -STABLE both on -CURRENT, and the CDs are
identical.
Is it completely static?
On Mon, 26 Nov 2001, Joerg Wunsch wrote:
Kenneth D. Merry [EMAIL PROTECTED] wrote:
Are there any areas with good data on the CD? i.e. can you see any
pattern to the corruption? If you compare the same CD burned from
-current and -stable you might begin to see a patern.
I tried a
Hi,
Due to vinum it is no problem to add disks and grow your volumes but up to
now you couldn't easily make use of that new space for a file system, except
using sequence of ufsdump/newfs/ufsrestore or something similar.
Thomas ([EMAIL PROTECTED]) and me ([EMAIL PROTECTED]) have written a
