On Monday, Oct 7, 2002, at 18:49 Europe/Vienna, John Leonard wrote: > I'm having the following problems- > > 1) File modification time changes 60 seconds after file is created. > > cd to a sharity mounted directory > Create a new file e.g. echo some stuff > newfile > stat newfile > wait a minute of two > stat newfile again - and the modify/change time is exactly 60 seconds > later than the original stat shows. I first noticed this when I would > edit a newly created file (using nedit) and the editor complained that > the file had been changed.
The 60 seconds look very much like the close delay in the Sharity configuration (as you have found out in your next posting). The server is obviously setting the modification date to the date when the file is closed, not when it was last modified. You can reduce the closeDelay* settings to improve the modification date issue. I would recommend at least 1 millisecond since "0" often has a special meaning. Reducing the close delay may have a negative impact on read/write performance. > 2) During a compile using absoft f90 for linux, output files from a > previous step are not ready in time for subsequent steps. > > f90 file1 # result OK > f90 file2 # result OK > f90 file3 # depends on output of file1 and file2 compiles, fails as if > output from file1 and file2 do not exist. > If I put a sleep 3s before each of the f90 commands the compile will > succeed. That's interesting. Since all files are created, written AND read through Sharity, it can't be a caching issue. What's the exact error message? And have you tried to add an 'ls' or 'cp' between the compiles to verify whether the files are there? > We're using sharity 2.7, RH linux 7.3, W2K pro SP2 as servers. Sharity > is mounting the servers using nfs3. I've tried setting > Microsecondfiletimes=yes (by itself) and also datacachetimenolock=0 > and requestoplock=no, but none of those settings seemed to improve the > behaviour. Also tried setting NFSkernelattributecachetime to 0 > (default=2) but that didn't help either. You can only change the AMOUNT of modification time deviation with Sharity settings, not the fact that there IS a deviation. The deviation is caused by a changed behavior of Windows 2k (compared to previous Windows versions). The settings you have tried affect caching. I really doubt that the other problem is caused by caching since all data goes through Sharity and there is no known bug in Sharity's cache updating. To analyze this further, please try to find out whether it's just the fortran compiler which can't see the files or if other tools (like 'ls' or 'cp') can't see them, too. Regards, Christian. -- Dipl.-Ing. Christian Starkjohann Objective Development mailto:[EMAIL PROTECTED] | http://www.obdev.at/ _______________________________________________ Sharity-talk mailing list [EMAIL PROTECTED] To unsubscribe see http://at.obdev.at/mailman/listinfo/sharity-talk
