Messages in this thread | | | Date | Wed, 02 Jun 1999 12:54:20 -0400 | From | Peter Rival <> | Subject | Re: ext2fs corruption under heavy load? |
| |
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> I really hate replying to my own posts, but... It appears that (with help from Henry Hall) the blame for this has been taken away from ext2 and placed squarely on the shoulders of the QLogic drivers. The ISP1020 cards were particularly bad, so I replaced them with ISP1040B cards. I am now seeing the same, _SILENT_ corruption I was before, only now it's at a somewhat higher load (~80 users instead of 60). <p>The reason I accented the word "silent" is that there are no errors, no warnings, no SCSI complaints either on the console or in the logs, and files just end up "disappearing". At least until the time I can unmount the disk and fsck the filesystem. Is this just an Alpha bug, or has anyone else tried to really push their system like this (configuration below) and gotten it to work? Or should I just chuck the QLogic cards and go try to beg out some BusLogic/Symbios Logic cards? <p> - Pete (who's going to go back to testing the shared workloads to relieve the stress ;) <p>Peter Rival wrote: <blockquote TYPE=CITE>Hi, <p> I've been attempting to benchmark linux (2.2.9+AXP SMP patches) on a 2-CPU AS4100. Everything runs fine, and the numbers are quite good, until somewhere in the (simulated) 50-60 user range. I'm running AIM VII on a system with 26 disks attached (does this sound familiar again? ;) so while IO isn't the problem, we are still beating on the filesystem (fserver benchmark). Anyway, once I get into this user range, I will start seeing errors in this code path: <p> <tt> if ((fd = creat(flist[CREAT][index],S_IRWXU | S_IRWXG | S_IRWXO)) < 0) { /* try create */</tt> <br><tt> perror("creat() in dsearch()"); /* handle error */</tt> <br><tt> sprintf(errbuf,"dsearch():can't creat '%s'\n", /* build error message */</tt> <br><tt> flist[CREAT][index]);</tt> <br><tt> chdir(cwd); /* change directories */</tt> <br><tt> cl_list(flist); /* clear list *</tt> <br><tt> return(-1); /* return error */</tt> <br><tt> } /* end of error */</tt> <br><tt> close(fd); /* close the file */</tt> <br><tt> if (unlink(flist[CREAT][index])) { /* unlink it */</tt> <br><tt> perror("unlink() in dsearch()"); /* handle error */</tt> <br><tt> getcwd(ncwd,256);</tt> <br><tt> chdir(cwd); /* change directories */</tt> <br><tt> cl_list(flist); /* clear list *</tt> <br><tt> return(-1); /* return error */</tt> <br><tt> } /* end of error */</tt> <br> <p>It complains about not being able to unlink a file with an "unlink() in dsearch(): No such file or directory". Well, that's true enough...the file doesn't actually exist. The strange part is that in some of the filesystems, I wind up with unattached inodes at the next fsck (one, every time...). As I have said, this has happened on almost all of the 26 work disks at one time or another, and on all 4 of the SCSI controllers (QLogic ISP 1020 (3) and 1040(1)). I can reproduce this problem every time I run the benchmark. <p> I have looked through the sys_creat (or really, sys_open) sys_unlink paths and don't see anything that should be wrong with it. Does anyone have any ideas? The system is running a stock RH6.0 install with the 2.2.9 kernel plus the AXP SMP patches that Richard Henderson posted. <p>Thanks! <p> - Pete</blockquote> </html>
| |