Vaclav Hanzl wrote:
mount -t cachefs /dev/hdb /home -o tag=nfs_mount
echo "cachefs__" > /dev/hdb
I think the order of these two commands should be reversed, but it
likely does not matter now if you already wrote "cachefs__" once.
0.00user 1.67system 0:01.67elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+162minor)pagefaults 0swaps
du -h Inbox
645M Inbox
I am afraid this still might be just the effect of the normal NFS RAM cache?
Is the same thing quicker (even first time) after client reboot?
Is it quicker for files much bigger than client's RAM?
645MBytes in 1.67s is 389MBytes/s, I guess your /dev/hdb cannot go as fast?
I would expect the following types of speedups:
1st read over network - at network speed or server speed, whichever is
smaller (it may matter whether data are in server's RAM cache)
2nd read over network - at client's RAM speed for small files, than at
client's harddisk speed via cachefs
1st read after client's reboot - at client's harddisk speed via
cachefs
2nd read after client's reboot - at client's RAM speed for small
files, than at client's harddisk speed via cachefs
Then there is another quite hypothetical type of speed:
client_harddisk_speed + min( server_speed, network_speed )
if cachefs by some lucky accident or clever design can read
alternating data chunks from client's disk and server's disk (like a
disk mirror can).
With lightly loaded server with good disks and gigabit network and
slow disk on client, there may be no cachefs-related speedup at all.
So, could you please reboot your client and repeat your test to see
whether you can read at client's disk speed the first time after
reboot?
I'll try to unmount the NFS and the CacheFS and try the timings again.
I did this @ home over the weekend so I have to wait 'till I get home to
do it again.
I modified the file on the server, and re-read it from the client, but
the file didn't change on the client.
I think NFS mount options can influence how big this danger is,
however making the danger bigger by cachefs itself would likely mean
that something does not work the way it was designed to work.
But how can I get this "caching" to go look at the server and see if the
file has been modified, or flush the cache every so often? Would that
have to be added as a parameter? I was talking to someone over here and
they told me that old IRIX had a cachefs-type thing and it had some flag
where you told it how often to go check the server. How easy would this
be to implement?
Cheers,
-Cesar
