similar to: (no subject)

Using fsdlm/ocfs2_controld.cman, I've rerun the test I've been having problems with on 2.6.30-rc1. After running for several minutes in the same directory on three nodes, the test hangs, and I collect the following information: bull-01 ------- 3053 S< [ocfs2dc] ocfs2_downconvert_thread 3054 S< [dlm_astd] dlm_astd 3055 S< [dlm_scand]

We got a remote Oracle 10g R2 standby running on OCFS2. Initial when we started the standby, read I/O was < 5MB/sec on average. Since then it has grown to over 40MB/sec (longer average, it peaks much higher). Here is a graph showing this: http://www.alameda.net/~ulf/dbphx01.png We also have a local standby running (on EXT3) which is not showing the same symptom. I am trying to find where all

Hi, all, As we use OCFS2, the network is not good. When the converting request message can?t send to the another node, there will be a node hangs up which will still waiting for the dlm. CAS2/logdir/var/log/syslog.1-6778-Sep 16 20:57:16 CAS2 kernel: [516366.623623] o2net: Connection to node CAS1 (num 1) at 10.172.254.1:7100 has been idle for 30.87 secs, shutting it down.

Found 15 patches (out of 162) that appeared relevant to ocfs2 1.4. Please review. Sunil

Remove redundant BUG_ON() Signed-off-by: Goldwyn Rodrigues <rgoldwyn at suse.de> --- diff --git a/fs/ocfs2/dlm/dlmast.c b/fs/ocfs2/dlm/dlmast.c index d07ddbe..81eff8e 100644 --- a/fs/ocfs2/dlm/dlmast.c +++ b/fs/ocfs2/dlm/dlmast.c @@ -103,7 +103,6 @@ static void __dlm_queue_ast(struct dlm_ctxt *dlm, struct dlm_lock *lock) lock->ast_pending, lock->ml.type); BUG(); } -

Hi All, we have installed the below ocfs2 version and exported the ocfs2 FS over nfs to some other nfs clients. rpm -qa | grep -i ocfs ocfs2-tools-1.4.4-1.el5 ocfs2-2.6.18-164.10.1.el5-1.4.7-1.el5 ocfs2console-1.4.4-1.el5 after some time or some day, we can't access the monted FS in nfs client. Below are process which we see issue on the nfs server when we have problem access the shares

The following series of patches comprises the bulk of our outstanding changes for Ocfs2. Aside from the usual set of cleanups and fixes that were inappropriate for 2.6.25, there are a few highlights: The '/sys/o2cb' directory has been moved to '/sys/fs/o2cb'. The new location meshes better with modern sysfs layout. A symbolic link has been placed in the old location so as to

The Lock Value Block (LVB) of a DLM lock can be lost when nodes die and the DLM cannot reconstruct its state. Clients of the DLM need to know this. ocfs2's internal DLM, o2dlm, explicitly zeroes out the LVB when it loses track of the state. This is not a standard behavior, but ocfs2 has always relied on it. Thus, an o2dlm LVB is always "valid". ocfs2 now supports both o2dlm and

Mainline commit d4f7e650e55af6b235871126f747da88600e8040 attempts to delay the dlm_thread from sending the drop ref message if the lockres is being migrated. The problem is that we make the dlm_thread wait for the migration to complete. This causes a deadlock as dlm_thread also participates in the lockres migration process. A better fix for the original oss bugzilla#1012 is in testing.

Hi All: As we test with two node in one OCFS2 cluster. The cluster is hang up may be for dead lock. We use the debugfs.ocfs tool founding that one resource is holding by one node who has it for long time and another node can still wait for the resource. So the cluster is hang up. debugfs.ocfs2 -R "fs_locks -B" /dev/dm-0 debugfs.ocfs2 -R "dlm_locks LOCKID_XXX" /dev/dm-0 How

Hi All: As we test with two node in one OCFS2 cluster. The cluster is hang up may be for dead lock. We use the debugfs.ocfs tool founding that one resource is holding by one node who has it for long time and another node can still wait for the resource. So the cluster is hang up. debugfs.ocfs2 -R "fs_locks -B" /dev/dm-0 debugfs.ocfs2 -R "dlm_locks LOCKID_XXX" /dev/dm-0 How

All, This is hopefully the final drop of the patches for adding global heartbeat to the o2cb stack. The diff from the previous set is here: http://oss.oracle.com/~smushran/global-hb-diff-2010-10-07 Implemented most of the suggestions provided by Joel and Wengang. The most important one was to activate the feature only at the end, Also, got mostly a clean run with checkpatch.pl. Sunil

The changes from the last drop are: 1. Patch 11 removes struct dlm_lock_name. 2. Patch 12 is an unrelated bugfix. Actually is related to a bugfix that we are retracting in mainline currently. The patch may need more testing. While I did hit the condition in my testing, Marcos hasn't. I am sending it because it can be queued for 2.6.30. Give us more time to test. 3. Patch 13 will be useful

These patches convert the mle list to a hash. The same patches apply on ocfs2 1.4 too. Currently, we use the same number of hash pages for mles and lockres'. This will be addressed in a future patch that will make both of them configurable. Sunil

Please review the list of patches being applied to the ocfs2 1.4 tree. All patches list the mainline commit hash. Thanks Sunil

Hi! Seems we're facing some memory leak here. This is vanilla 2.6.19-rc6 on a x86_64 box, 4GB RAM. A simple `ls -Rn' on a filesystem with lots of files makes the box leak so much RAM that the OOM killer starts to kick in. With slab alloc debugging turned on, we see this: # mount; ls -Rn; wait some seconds; Ctrl-C [root@lnxp-1038:/backend1]$ cat /proc/slab_allocators | egrep

Hi, we are using a SLES10 Patchlevel 3 with 12 Nodes hosting tomcat application servers. The cluster was running some time (about 200 days) without problems. Recently we needed to shutdown the cluster for maintenance and experianced very long times for the umount of the filesystem. It took something like 45 minutes each node and filesystem (12 x 45 minutes shutdown time). As a result the planned

Hi everyone. Does anyone know why the user-space heartbeat (linux-ha) patches from SuSE / Novell are not commited to the mainline ocfs2 source tree? Or are they? Is there an easy way (which does not break the distros package management) to apply these? Thanks, Christian

Does anyone have any idea what to try next? Here are the steps I have taken and the problem: (I wanted to post my question on the first line before I explained the problem and what I have tried) ---------- Node 0 has the file system mounted just fine and works great. When trying to mount on Node 1: `mount.ocfs2 /dev/mapper/data /cluster/ data` I get this error after about 30 seconds:

Hi, The following patches comprise the bulk of Ocfs2 updates for the 2.6.30 merge window. Aside from larger, more involved fixes, we're adding the following features, which I will describe in the order their patches are mailed. Sunil's exported some more state to our debugfs files, and consolidated some other aspects of our debugfs infrastructure. This will further aid us in debugging