BOOTMFS image too big
I tried building a "release" ISO image today, but it failed because it couldn't build the boot floppies. Tail end of the build process (with an `ls' and `du' thown in). Is this known? Kent linking BOOTMFS textdata bss dec hex filename 2650861 209180 210260 3070301 2ed95d BOOTMFS -- >>> Kernel build for BOOTMFS completed on Mon Mar 31 05:23:27 GMT 2003 -- cd /usr/obj/usr/src/sys/BOOTMFS; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.00503 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac make KERNEL=BOOTMFS reinstall install -m 555 -o root -g wheel -fschg BOOTMFS /R/stage/kernels/BOOTMFS mv /R/stage/kernels/BOOTMFS /R/stage/image.kern/kernel Setting up /boot directory for kern floppy dload=0x20 dsize=0x25000 isize=0x25000 entry=0x20 nsize=0x11ae9 /R/stage/image.kern/kernel: 53.6% -- replaced with /R/stage/image.kern/kernel.gz sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt 1440 /R/stage/image.kern 8 fd1440 Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/rvnn0c:2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) super-block backups (for fsck -b #) at: 32 cpio: write error: No space left on device *** Error code 1 Stop in /usr/src/release. *** Error code 1 . chapel-hill# ls -l R/stage/image.kern total 1330 drwxr-xr-x 2 root wheel 512 Mar 30 19:23 boot -r-xr-xr-x 1 root wheel 1339861 Mar 30 19:23 kernel.gz chapel-hill# du R/stage/image.kern 88 R/stage/image.kern/boot 1418R/stage/image.kern ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Status of ATA tagging in Stable
In article <[EMAIL PROTECTED]>, Kevin Oberman <[EMAIL PROTECTED]> wrote: >I have a P3 system running STABLE built on March 7. I installed a new >IBM DTLA disk drive and was distressed at its slowness, so I tried >turning on tagging to see if that would help. It seemed to, until... > >3 AM when my periodic tasks started running. The system lost all disk >access and logged lots of errors (a few of which I added to the end of >this message). This combination worked beautifully until the ATA MFC just after 4.5, and it has since been declared that those IBM drives don't do tagging correctly. Since I've got a semi-production server with the DTLAs in it, I gave up on tagging, just using UDMA, it's good enough. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vinum performance
On Sunday, 30 March 2003 at 18:10:07 +0200, Dag-Erling Smrgrav wrote: > Lukas Ertl <[EMAIL PROTECTED]> writes: >> I'm currently testing with prime stripe sizes, but it doesn't seem to >> help. I additionally added "options AHC_ALLOW_MEMIO" to the kernel, and it >> has raised write performance in the single-disk case (although I'm not >> happy with that one either; I expected a disk on a U160 controller to pump >> out more than ~65MB/s). > > Does the data sheet for your disk indicate that it can in fact write > much faster than that? The speed at which data is actually written > to the media is much lower than the bus speed - the bus speed *has* > to be higher to accomodate multiple devices. You're touching on one of the real issues here. For optimum transfers, a plex needs large stripes. If you're only doing one transfer at a time (like bonnie does), you'll just pick on individual disks alternately, so the performance can't be much better than a single disk. Do a large number of simultaneous transfers and it will be a different story. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: vinum performance
On Sunday, 30 March 2003 at 16:30:17 +0200, Dag-Erling Smrgrav wrote: > Anti <[EMAIL PROTECTED]> writes: >> try benchmarking ccd as well to see how it compares? and try some big stripe >> sizes (4093, 8191, 12281)? > > I believe Greg showed in his USENIX paper on Vinum that large stripe > sizes aren't preferable to small ones. I may misremember though. You misremember. I said that large stripe sizes *are* preferable. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: vinum performance
On Sunday, 30 March 2003 at 14:08:24 +0200, Dag-Erling Smrgrav wrote: > Lukas Ertl <[EMAIL PROTECTED]> writes: >> Anyone has an idea what's going wrong here? (Apart from me doing bullsh*t >> benchmarking :-) .) > > Just out of curiosity, try again with prime stripe sizes (31, 61, 127, > 257, 509) or at least odd ones (31, 63, 127, 255, 511). If you're going to do this kind of test, make sure it's a multiple of the UFS block size, but not a power of 2. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: vinum performance
Lukas Ertl <[EMAIL PROTECTED]> writes: > On Sun, 30 Mar 2003, Dag-Erling Smørgrav wrote: > > Does the data sheet for your disk indicate that it can in fact write > > much faster than that? > Well, the HP/Compaq webpages are full of marketing speech wrt that, but > since these disks are U320 disks, they should perform better I think. Check the data sheet. I *strongly* doubt your disks have an internal transfer speed much higher than 65 MB/s. The external transfer speed has nothing to do with it, it only controls how fast you can fill the disk's cache and free the bus for other transactions to other devices. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vinum performance
On Sun, 30 Mar 2003, Dag-Erling Smørgrav wrote: > Lukas Ertl <[EMAIL PROTECTED]> writes: > > I'm currently testing with prime stripe sizes, but it doesn't seem to > > help. I additionally added "options AHC_ALLOW_MEMIO" to the kernel, and it > > has raised write performance in the single-disk case (although I'm not > > happy with that one either; I expected a disk on a U160 controller to pump > > out more than ~65MB/s). > > Does the data sheet for your disk indicate that it can in fact write > much faster than that? Well, the HP/Compaq webpages are full of marketing speech wrt that, but since these disks are U320 disks, they should perform better I think. > The speed at which data is actually written to the media is much lower > than the bus speed - the bus speed *has* to be higher to accomodate > multiple devices. Ok, that's reasonable. best regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universität Wien http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vinum performance
Lukas Ertl <[EMAIL PROTECTED]> writes: > I'm currently testing with prime stripe sizes, but it doesn't seem to > help. I additionally added "options AHC_ALLOW_MEMIO" to the kernel, and it > has raised write performance in the single-disk case (although I'm not > happy with that one either; I expected a disk on a U160 controller to pump > out more than ~65MB/s). Does the data sheet for your disk indicate that it can in fact write much faster than that? The speed at which data is actually written to the media is much lower than the bus speed - the bus speed *has* to be higher to accomodate multiple devices. For instance, the "internal formatted transfer rate" for a recent 73GB Seagate Cheetah varies between 38.4 and 63.9 MB/s (depending on how far out from the spindle you're writing). You won't see higher average transfer speeds than that unless the data you're writing fits entirely within the disk's on-board cache. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vinum performance
Lukas Ertl <[EMAIL PROTECTED]> writes: > Anyone has an idea what's going wrong here? (Apart from me doing bullsh*t > benchmarking :-) .) Just out of curiosity, try again with prime stripe sizes (31, 61, 127, 257, 509) or at least odd ones (31, 63, 127, 255, 511). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
