On Wed, Apr 14, 1999 at 09:30:21AM -0400, Jim Nance wrote:
> The ram disks under Linux have several limitations that probably make
> them unsuitable for what you are trying to do. I believe that they were
> designed primarily for OS installs from floppy disk. The Linux filesystems
> do not do synchronous metadata writes and are therefor very fast. I do not
> think you need to do anything special to get tmpfs like performance from ext2.
> If you are going to put a large number of files into a directory, then there
> is an experimental filesystem called reiserfs you might want to try. You can
> get more information from:
Dont you just love people who follow up their own posts :-)
The original question is enough of an FAQ that I thought it would be good to
have real numbers rather than just my assurances that Linux has a fast FS
layer. Therefore I wrote a benchmarking program that creates/writes/destroys
files and ran it under several operating systems and on several types of
file systems. I have included that program as an attachment to this mail.
Here are the results:
OS Hardware FS Type Loops/Second
--------------------------------------------------------------------
Linux 2.2.5-ac6 1 nfs 16.33
Linux 2.2.5-ac6 1 arla 73.67
Linux 2.2.5-ac6 1 ext2 15383.32
Solaris 2.6 2 afs 71.33
Solaris 2.6 2 nfs 10.00
Solaris 2.6 2 ufs 23.67
Solaris 2.6 2 tmpfs 9162.32
Digital Unix 4.0D 3 afs 49.33
Digital Unix 4.0D 3 nfs 14.67
Digital Unix 4.0D 3 ufs 28.67
Digital Unix 4.0D 3 memfs 3062.66
Linux 2.0.33 4 afs 69.33
Linux 2.0.33 4 nfs 15.00
Linux 2.0.33 4 ext2 2218.33
Hardware:
1 -> 333 MHz PII, 512M ram, Compaq WDE4360W disk
2 -> Ultra450 class Sun server (300MHz?)
3 -> Personal Workstation 600 AU. 600 MHz alpha. 1.5G ram
4 -> 75 MHz Pentium, 32M ram, Segate ST31200N disk
Notice how Linux writting to an ext2 file system is significantly faster
than any other OS/FS combination. The next closest is Solaris writting
to tmpfs, and its still far behind ext2. Its also good to notice how
slow both Solaris and Digital Unix are on their local file systems. This
is probably why both have a ram base file system.
Please note that this benchmark is intended to measure the time it takes to
create and delete files, which is expensive on most non-linux systems. It
does not indicate anything about the data I/O rate to an existing file.
If someone would like to put this table in an FAQ, please be my guest. Also
if you have any criticisms, I would like those too. Also, I would like to
know how NT does on this test if anyone has an NT system they can test it
on.
Thanks,
Jim
--
----------------------------------------------------------------------------
Jim Nance Avant! Corporation
(919) 941-6655 Do you have sweet iced tea? jim_nance@avanticorp.com
No, but there's sugar on the table.
--5vNYLRcllDrimb99
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="files.c"
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <setjmp.h>
#include <signal.h>
#include <sys/time.h>
jmp_buf jump;
char *fname[4] = {"file_name_1", "file_name_2", "file_name_3", "file_name_4" };
void done(int x) {longjmp(jump,1); }
void cleanup(void) {int i; for(i=0; i<4; i++) {unlink(fname[i]);}}
int main(int ac, char **av)
{
static char str[] = "My dog has flees...................................\n";
static unsigned long cnt;
static struct timeval tstart, tstop;
double delt;
if(ac==2) {
if(chdir(av[1])) {
fprintf(stderr,"Can not change to directory %s\n", av[1]);
exit(-1);
}
}
cnt = 0;
signal(SIGALRM, done);
gettimeofday(&tstart, NULL);
if(setjmp(jump)==1) {
gettimeofday(&tstop, NULL);
delt = tstop.tv_sec - tstart.tv_sec;
delt += 1e-6*(tstop.tv_sec - tstart.tv_sec);
printf("Did %lu loops in %.2f seconds (%.2f loops/sec)\n",
cnt, delt, cnt/delt);
cleanup();
return 0;
}
alarm(3);
for(; 1; ++cnt) {
char *fn = fname[cnt%4];
int fd = open(fn, O_WRONLY | O_CREAT | O_TRUNC, 0660);
if(fd<0) {
fprintf(stderr,"Failed to open %s\n",fn); exit(-1);
}
write(fd, str, sizeof(str));
close(fd);
unlink(fn);
}
cleanup();
return 0;
}
--5vNYLRcllDrimb99--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/