[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
File System Performance Loss in Genera 8.0 (16X slower!)
Date: Fri, 6 Jul 90 10:57 PDT
From: snicoud@atc.boeing.com (Stephen L. Nicoud)
Date: 6 Jul 90 15:34:17 GMT
From: cogen@XN.LL.MIT.EDU
What has happened to the network file system in going from Genera 7.2 to 8.0?
By one measure, it is 16 TIMES SLOWER THAN BEFORE! I would like to know if
anyone else has experienced this, or is it a problem with our local
installation?
I can confirm this.
I had a directory with 120+ files on a Sun 3 (SunOS 3.4) (Yes,
I know this is an ancient version of the OS). With 8.0 it was
taking 65 to 70 seconds just to save a file from ZMACS to this
directory. My symbolics sits in "NFS2 ReadDir" state for most
of the time.
As soon as I reaped all the hogs and deleted other files in
that directory, bring the total number of files down to under
40, the problem was significantly reduced.
I tried a similar set of tests using 7.2 and didn't have the
problem.
I thought the problem might have been because of the SunOS
version (3.4), but now that you report the problem in 4.0,
perhaps it is not.
BTW, NFS was the protocol used.
This is not the problem Cogen was reporting, since he was reading FROM
the Unix system, not writing TO the Unix server. When writing a new
version of a file to a Unix server, the Lispm must read the directory in
order to rename the old version to filename.~version~. It has to read
the entire directory in order to find all the existing
filename.~version~ files so that it can increment the version number
(NFS ReadDir doesn't return filenames sorted, and there's no
wildcard-matching operation in NFS). Not only that, but the creation of
the temporary file that is written to until the file is closed (which is
when the version number is incremented) invalidates the directory
contents cache, so you are guaranteed that you'll have to read the
directory from the server in order to increment the version.
barmar