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, 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.
>
>
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? (i.
Hi,
Im running -STABLE and -CURRENT from different disks on the same box.
And with -STABLE there are no problems burning CDs with a YAMAHA CRW6416S
on an Adaptec 2940.
But withs -CURRENT all CDs are broken. Cdrecord produces no Error messages
and exits normaly, but there are areas with binary zer
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 growfs
