Thomas Anders wrote:
>> The "missing file" problem is most likely a consequence of different
>> semantics between Unix and Windows. On Unix, the modification date of a
>> directory is changed when a file is created (or deleted or renamed). On
>> Windows, the date stays unchanged.
>
> As experienced here, this problem only exists for FAT and friends, not
> Windows in general. NTFS obviously has proper time stamps and Sharity
> correctly passes them, so there's no caching problem with it.
There are proper time stamps and they can be read, but they are not updated
when a file is created. Sharity can't notice the difference between NTFS and
FAT except for minor semantic differences. One of the maybe relevant
differences is that Sharity can't SET the timestamps on FAT file systems.
Sharity tries to emulate Unix semantics as good as possible and therefore
updates directory timestamps when files are created/deleted/renamed. If this
fails, it may cause the behavior you saw.
However, the problem persists on ANY Windows file system if the file is
created directly on the server. Sharity has no way to know and to update the
directory timestamp accordingly.
>> Unix applications (and sometimes even the
>> kernel) base caching strategies on these semantics. If the modification date
>> of a directory has not changed, cached contents can be used and there is no
>> need to re-request the data.
>> You can enable a "workaround" for this, turning off the kernel's cache all
>> together. Sharity can change the modification date slightly on each read.
>> The option which enables this feature in sharity.cfg is
>> "changeMicrosecondFileTimes".
>
> I enabled this for both nfs2 and nfs3 frontends and restarted Sharity,
> but don't see a change in timestamps on subsequent reads on a directory:
>
> - --- snip ---
> foo# grep changeMicrosecondFileTimes sharity.cfg
> changeMicrosecondFileTimes = yes;
> changeMicrosecondFileTimes = yes;
> foo# truss -t lstat -v lstat ls -ld
> /netdoc/www/server/data/Solar/DATA/Juni_2002
> lstat64("/netdoc/www/server/data/Solar/DATA/Juni_2002", 0xFFBEFB50) = 0
> d=0x03B83257 i=3 m=0040777 l=2 u=765 g=765 sz=131072
> at = Jun 1 00:00:00 MEST 2002 [ 1022882400 ]
> mt = Jun 1 00:10:00 MEST 2002 [ 1022883000 ]
> ct = Jun 1 00:10:00 MEST 2002 [ 1022883000 ]
> bsz=8192 blks=1 fs=nfs
> drwxrwxrwx 2 httpd httpd 131072 Jun 1 00:10
> /netdoc/www/server/data/So
> lar/DATA/Juni_2002
> [...]
> What am I missing?
The timestamps you see here are in 1 second resolution. As the name
indicates, 'changeMicrosecondFileTimes' changes the timestamps only by a
couple of microseconds. You won't notice this at the application level, but
the kernel cache should be circumvented (unless newer operating systems
ignore deviations of a couple of microseconds, this feature has been
introduced and tested about two years ago).
>> Please note that turning off kernel caching for Sharity may have a negative
>> impact on performance.
>
> Strongly agreed. As this problem is only experienced with some (older|broken)
> filesystems (see above), it would be nice to enable the workaround for
> a specific mount point rather than globally. Is this feasible?
You CAN set this option on a per server basis, but not on a per mount basis.
Simply move the setting into a server specific section (see the .default
entry in the "servers" section for an example).
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
