Evgeniy Polyakov wrote: >> So now I'll patiently await your solution to the find / problem. Once >> that's in I will swap my NFS mounts for POHMELFS :) > > Cold cache issues with this test are related to the stat(2) performance > on the server. It takes about 30-35 seconds to stat all objects in the > linux kernel source tree, and this stat is performed for directory > reading to get information about the object. > NFS does not have this basically because its server is in the kernel and > it should not copy a not-that-small chunk of the data from kernel to the > userspace.
I see. Is there any other way besides running fserver in kernel space to get access to this? Perhaps just a small (optional) kernel module for the fserver process that would give POHMELFS the same advantage? > Test with the stat will show the same issues for the NFS and POHMELFS, > namely cold cache run will take about 1m8sec for POHMELFS and about > 33-35 seconds for NFS, since POHMELFS will do two stats - on the server > and client, while NFS will do it on the client only (its in-kernel > server has access to the data directly). Hot cache run will show the > same 33-35 seconds both for POHMELFS and NFS, since there will be only > single stat on the client. So from what I gather, when i start fserver, then mount it on the client, then start the find - the cache needs to get populated on both client and server. Following that logic - a commandline option to pre-populate the cache for fserver would help, assuming that the stat(2) performance penalty on a fresh client is NULL or close to zero? Its less ideal than the first option, but as long as fserver retains the cache throughout its process lifetime, this could be an acceptable solution as an optional feature at fserver startup. _______________________________________________ Pohmelfs mailing list [email protected] http://www.ioremap.net/cgi-bin/mailman/listinfo/pohmelfs
