cdrecord produces broken CDs on -CURRENT: The Answer !
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 Christoph :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord produces broken CDs on -CURRENT
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.e. ldd cdrecord should report that it isn't a dynamic executable) Yes it is. That may help narrow the problem down somewhat. I'm not sure, though, whether the -stable binary will work with the pass interface on -current. It doesn't matter wether I take cdrecord from -CURRENT or from -STABLE, the CDs (I burn on -CURRENT) are identical. 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. Yes, about half of the CD is correct, and the rest is filled up with binary zero. If there are data other then zero on the CD, then they are correct. Is the table of contents correct? I don't know, but I don't think so. The first 60kB (exact 60kB!) of the broken CD are zeros, and I can't mount it. Ken -- Kenneth Merry [EMAIL PROTECTED] Ciao Christoph :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord produces broken CDs on -CURRENT
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 test-burn with a FreeBSD-current from yesterday, on a YAMAHA CRW2100S 1.0H writer (writing a CD-RW), and can't see any failure. It's only a small directory tree, but MD5-comparing the tree on the CD-RW with the original on UFS only reveals the added TRANS.TBL files, no other differences. # cdrecord -version Cdrecord 1.9 (i386-unknown-freebsd5.0) Copyright (C) 1995-2000 Jörg Schilling # ls -l `which cdrecord` -r-xr-xr-x 1 root wheel - 163392 Apr 4 2001 /usr/local/bin/cdrecord* # ldd `which cdrecord` /usr/local/bin/cdrecord: libcam.so.2 = /usr/lib/libcam.so.2 (0x2808a000) libc.so.5 = /usr/lib/libc.so.5 (0x2809a000) libsbuf.so.2 = /usr/lib/libsbuf.so.2 (0x2814e000) (I haven't rebuilt the binary after upgrading -current, for months as you can see.) Maybe there are other problems. But I had no problems (burning CDs on -CURRENT) until the beginning of october. (I run make world about once a week). And with -STABLE everything is fine until now. It is the same box, I (try to) burn the same image, the only difference is the FreeBSD version. So it can't be only a hardware problem. Ciao Christoph :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
growfs(8) for FreeBSD
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(8) for FreeBSD. Currently we can only grow unmounted file systems (in a clean state) without any active snapshots inside. It is foreseen to enhance growfs to grow mounted file systems as well, and handle active snapshots correctly. This requires some infrastructure which is then only available in FreeBSD-5, whilst the current design runs also happily on FreeBSD-4 and FreeBSD-3 (tested) and possibly even on FreeBSD-2 (untested). To help us gathering the needed data for fixing bugs in growfs we additionally wrote ffsinfo(8), a (very) extended version of dumpfs. We've sent a couple of snapshots of our code to Kirk McKusick and to Greg Lehey. Greg also volunteered :-) for reviewing the code. We also maintain some sort of (for some contractual reasons unilaterally) contact with Don Coleman who is doing the same thing for BSD/OS. -- Ciao Christoph :-) M$: Where do you want to go today? Linux:Where do you want to go tomorrow? FreeBSD: Are you guys comming, or what? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
