On 2007-02-15T14:23:30, John Lange <john.lange@open-it.ca> wrote:
> As a quick follow up to my own posting; I have the
> 2.6.16.37-SLES10_SP1_BRANCH_20070213192756-smp kernel running and I also
> found:
>
> ocfs2-tools-1.2.2-20.i586.rpm
>
> a package from OpenSUSE factory (10.3).
please don't run 10.3 packages on SLE10. They are compiled against
different libraries.
> Neither of these things has solved the problem as memory continues to
> climb out of control as soon as the nfs clients start accessing the
> ocfs2 file system.
Please open a support incident with NTS.
> As a work around, I'm wondering if anyone has an opinion on if its safe
> to do this:
>
> sync ; echo 3 > /proc/sys/vm/drop_caches
> sync ; echo 0 > /proc/sys/vm/drop_caches
>
> on a cron every 15 minutes?
It's safe, but probably a performance penalty.
> This might keep this thing alive until we can figure out how to patch
> ocfs to 1.2.4. The alternative is to stop nfs and remount ocfs2 every 15
> minutes but that causes us major grief as it knocks the clients offline.
SLE10-SP1 _is_ updated to 1.2.4 already. The kernel-of-the-day has all
the recent fixes.
However, I'm not perfectly sure whether reexporting OCFS2 via NFS(v3 or
v4?) is already working perfectly. I would not be surprised if it
doesn't yet. For sure, file locking doesn't work (yet).
Sincerely,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar
Wilde