Date: Fri, 20 Apr 2001 05:54:26 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: niek@bergboer.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UFS block size vs. write speed Message-ID: <20010420055426.Q1790@fw.wintelcom.net> In-Reply-To: <20010420144543.F30241@wit379119.student.utwente.nl>; from niek@wit379119.student.utwente.nl on Fri, Apr 20, 2001 at 02:45:43PM %2B0200 References: <20010420144543.F30241@wit379119.student.utwente.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
ugh, dude, please wrap lines at 70 characters. :( * Niek Bergboer <niek@wit379119.student.utwente.nl> [010420 05:43] wrote: > Hello, > > I've got a machine connected to a 100 MBit/FDX network and I > would like to store largish (~20 MB or bigger) files on it that > are downloaded from the network over a dc card. The only consideration > here is speed since the files are all temporary. I'm running FreeBSD > 4.3-RC1. > > > The dc card is fine and does 9.2 MB/s. The problem arises when > writing to the UFS filesystem, which makes the transfer rate drop > down to 5.6 MB/s using the standard 8 kb blocksize. The problem > here seems to be the combined network and disk interrupt load since > writing to the filesystem from /dev/zero results in 13 MB/s rates. > The issue is that -- and I'm not feeding trolls here -- that Linux > 2.2 smashed up to 8.5 MB/s through... > > Reading from the filesystem and uploading to the network puts > 8.6 MB/s through, so that's no problem. > > I tried to increase block-sizes on said filesystem to 64 kb, > which increased the throughput to around 7 MB/s. When trying to > make blocksizes 128 of 256 kb, newfs segfaults (...). > > So my questions: > > a.) Is it possible to create larger blocksizes, and would that > increase write speed? Not sure. > b.) Are there other newfs options that I can use to increase throughput? Have you tried softupdates? > c.) Does FreeBSD support filesystem other than UFS/FFS that allow > for faster transfer rates? Not afaik. > PS: The tests were already done with the fs mounted async. The > drive in question communicates at UDMA/33 on a PIIX4 controller in > an AMD K6/2 233 system. There's a couple things here. a) what version of freebsd are you using? recent versions turn of IDE write caching, you may want to turn this on, see the ata(4) manpage, remeber that it can only be set at boot time. b) how are you writing these files? perhaps we can figure a faster way to do the io? did you write the program yourself? What size writes are you doing? It's funny, but you have the ideal system for an interesting optimization I've always wanted to try. Since you seem to be reading over the network, have you tried doing this, creating the file and then using ftruncate on it to extend it, then use mmap() and read directly from the socket into the mmap'd area. You may have to experiment with several different madvise() flags to get optimal performance. Or you may discover that doing this "trick" actually makes performance worse because of the way the trick screws with what the vm system expects. I think a combination of MADV_SEQUENTIAL and/or MADV_WILLNEED could do the trick. -- -Alfred Perlstein - [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010420055426.Q1790>