From owner-freebsd-current Sun Nov 12 08:01:14 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA12052 for current-outgoing; Sun, 12 Nov 1995 08:01:14 -0800 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA12043 for ; Sun, 12 Nov 1995 08:01:08 -0800 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA26310; Sun, 12 Nov 1995 10:00:35 -0600 From: Joe Greco Message-Id: <199511121600.KAA26310@brasil.moneng.mei.com> Subject: Re: ISP state their FreeBSD concerns To: dyson@freefall.freebsd.org (John Dyson) Date: Sun, 12 Nov 1995 10:00:34 -0600 (CST) Cc: current@freebsd.org In-Reply-To: <199511120557.VAA24917@freefall.freebsd.org> from "John Dyson" at Nov 11, 95 09:57:36 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > > 8. File creation (particularly directories) appears to be slow compared > > to other BSD-like systems. They say the stats for INN and CNEWS > > for articles processed per second are quite a bit lower than that > > on some "other" systems. They say that file deletion seems to be > > a bit slower than BSDI, but not by much. I think they are talking > > 2.0.5 on this item, although one ISP was experimenting with 1026 SNAP. > > I am working on this stuff right now. Give me benchmarks!!!! I'll > do what I can. :-( I have a little suite of programs I use for performance testing. The tests are absolutely slanted towards news server type applications. The one in particular I will quote is "small-file-write.c", a program that writes 10000 files in subdirectories, creating the subdirectories if needed (much like a news server would do). So the "first run" numbers include the time needed to make dirs: Slowaris 5.4 - SS10/30 - 64MB RAM (SCSI II, reasonable drive) 10000 files in 332 seconds - first run 10000 files in 20 !!! seconds - second run Slowaris 5.4 - SS10/30 - 64MB RAM (SCSI II, Barracuda drive) 10000 files in 249 seconds - first run 10000 files in 13 !!! seconds - second run Slowaris 5.4 - SS10/30 - 64MB RAM - PrestoServe (SCSI II, Barracuda drive) 10000 files in 76 seconds - first run 10000 files in 12 seconds - second run FreeBSD 2.0.5R - ASUS SP3G AMD 486DX2/66 + NCR810 - 8MB (SCSI II, reasonable drive) 10000 files in 620 seconds - first run :-( :-( 10000 files in 310 seconds - second run :-( :-( :-( !! FreeBSD 1026-SNAP - ASUS SP3G AMD 486DX4/100 + NCR810 - 48MB (SCSI II, SLOW drive, fs mounted -o async) 10000 files in 569 seconds - first run :-( :-( 10000 files in 207 seconds - second run :-( :-( :-( !! Now, I can't swear that by tweaking newfs options, etc., it isn't able to improve this - I simply haven't tried because I didn't realize until just now how abominable this performance was. Does anybody have advice about what might be tweakable to help this? This is really sad. The program itself: #include #include #include #include #include #include char *pathn(int x) { static char *buffer[1024]; int d1, d2, d3; d1 = x; x /= 10; d1 -= x * 10; d2 = x; x /= 10; d2 -= x * 10; d3 = x; x /= 10; d3 -= x * 10; sprintf(buffer, "%d/%d/%d/%d", d1, d2, d3, x); return(buffer); } int writef(char *name) { int fd; char *ptr; if ((fd = open(name, O_CREAT|O_RDWR, 0644)) < 0) { if (errno == ENOENT) { ptr = name; while (ptr = strchr(ptr, '/')) { *ptr = '\0'; if (mkdir(name, 0755) < 0) { if (errno != EEXIST) { perror(name); exit(1); } } *ptr++ = '/'; } return(writef(name)); } else { perror(name); exit(1); } } else { close(fd); } } int main() { int i, n; time_t tm = time(NULL); n = 10000; for (i = 0; i < n; i++) { writef(pathn(i)); if (! (i % 100)) { printf("%d..", i); fflush(stdout); } } printf("\n%d files in %d seconds\n", n, time(NULL) - tm); exit(0); }