Christian Starkjohann 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.
> 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
foo# ls /netdoc/www/server/data/Solar/DATA/Juni_2002/
Messfile_Di_11_Jun_2002.txt Messfile_Mi_5_Jun_2002.txt
Messfile_Di_18_Jun_2002.txt Messfile_Mo_10_Jun_2002.txt
Messfile_Di_4_Jun_2002.txt Messfile_Mo_17_Jun_2002.txt
Messfile_Do_13_Jun_2002.txt Messfile_Mo_3_Jun_2002.txt
Messfile_Do_20_Jun_2002.txt Messfile_Sa_15_Jun_2002.txt
Messfile_Do_6_Jun_2002.txt Messfile_Sa_1_Jun_2002.txt
Messfile_Fr_14_Jun_2002.txt Messfile_Sa_8_Jun_2002.txt
Messfile_Fr_21_Jun_2002.txt Messfile_So_16_Jun_2002.txt
Messfile_Fr_7_Jun_2002.txt Messfile_So_2_Jun_2002.txt
Messfile_Mi_12_Jun_2002.txt Messfile_So_9_Jun_2002.txt
Messfile_Mi_19_Jun_2002.txt
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
foo#
- --- snap ---
What am I missing?
> 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?
Kind regards,
Thomas
--
Thomas Anders <[EMAIL PROTECTED]>
Hahn-Meitner-Institut Berlin, Germany
_______________________________________________
Sharity-talk mailing list
[EMAIL PROTECTED]
To unsubscribe see http://at.obdev.at/mailman/listinfo/sharity-talk
