similar to: user-space heartbeat ptaches from suse

Hi, When attempting to restore to LINUX RHEL5 - OCFS2 filesystem received the following error during RMAN restore for nearly all of the datafiles attempted to restore with exception of a couple of smaller datafiles which were smaller < 2GB. ORA-19870: error reading backup piece /db/dumps/TR1_1/rmanbackup/TR1_88_1 ORA-19502: write error on file "/db/devices/db1/PR2/pr2_1/pr2.data1",

Does anybody knows if is there a certified procedure in to backup a RAC DB 10.2.0.3 based on OCFS2 , via split mirror or snaphots technology ? Using Linux LVM and OCFS2, does anybody knows if is possible to dinamically extend an OCFS filesystem, once the underlying LVM Volume has been extended ? Thanks in advance Riccardo Paganini

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

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

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

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

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

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.

After some parallel mount/umount test on ocfs2, we got this: slab error in kmem_cache_destroy(): cache `o2dlm_mle': Can't free all objects. Then we found a memleak situation in dlm_add_migration_mle(). When a mle found, it will be removed from dlm->hlist. If there is no pointer to it at that moment, the mle will become an ?orphan mle? that no process can find and release.

#backporting the 3 patches at http://kernel.us.oracle.com/~smushran/srini/ to 1.2. enlarge hash_table capacity to fasten hash_table lookups. Signed-off-by: Wengang wang <wen.gang.wang at oracle.com> -- diff -up ./svnocfs2-1.2/fs/ocfs2/dlm/dlmdebug.c.orig ./svnocfs2-1.2/fs/ocfs2/dlm/dlmdebug.c --- ./svnocfs2-1.2/fs/ocfs2/dlm/dlmdebug.c.orig 2009-04-22 11:00:37.000000000 +0800 +++

Wether the dlm_lock needs to access lvb or not depends on dlm_lock_resource it belongs to. So a new parameter "struct dlm_lock_resource *res" is added to dlm_new_lock() so that we can know if we need to allocate lvb for the dlm_lock. And we have to make the lockres availale for calling dlm_new_lock(). Signed-off-by: Wengang Wang <wen.gang.wang at oracle.com> ---

Currently the process of dlm join contains 2 steps: query join and assert join. After query join, the joined node will set its joining_node. So if the joining node happens to panic before the 2nd step, the joined node will fail to clear its joining_node flag because that node isn't in the domain map. It at least cause 2 problems. 1. All the new join request will fail. So no new node can mount

I've read fs/ocfs2/dlm/dlmcommon.h to study the structure of dlm_migratable_lockres. However, I may find a typo for the DLM_MIG_LOCKRES_MAX_LEN, the NET_MAX_PAYLOAD_BYTES should be O2NET_MAX_PAYLOAD_BYTES, I think. In comments, the sizeof(net_msg) should be sizeof(o2net_msg) by referring to fs/ocfs2/cluster/tcp.h. Signed-off-by: Jeff Liu <jeff.liu at oracle.com> ---

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

We should check dlm->dlm_state under dlm->spinlock though maybe in this case it doesn't hurt. Signed-off-by: Wengang Wang <wen.gang.wang at oracle.com> --- fs/ocfs2/dlm/dlmdomain.c | 13 ++++++------- 1 files changed, 6 insertions(+), 7 deletions(-) diff --git a/fs/ocfs2/dlm/dlmdomain.c b/fs/ocfs2/dlm/dlmdomain.c index 6b5a492..ab82add 100644 --- a/fs/ocfs2/dlm/dlmdomain.c +++

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

We are in the process of upgrading to OCFS2. We have recently restored our Production Database to a Development platform configured with OCFS2 with RMAN. No problems. As for the Production migration, we understand that you cannot mount an OCFS volume (our current configuration) with OCFS2. We are interested in mounting an EXT3 file system, performing a cold RMAN backup, copying the datafiles

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

The versioning information is confusing for end-users. The numbers are stuck at 1.5.0 when the tools have moved to 1.8.3. I suggest removing the versioning system in the kernel altogether and let the kernel version be the guide to debug issues. However, if you think versioning is still required, please state the reason and modify the version string in the ver.* files to reflect the uptodate

Now the discussion moves to kernel space, I move the email from ocfs2-tools-devel to ocfs2-devel. The original discussion can be found from http://oss.oracle.com/pipermail/ocfs2-tools-devel/2009-June/001891.html Joel Becker Wrote: > On Sat, Jun 27, 2009 at 03:46:04AM +0800, Coly Li wrote: >> Joel Becker Wrote: >>> On Sat, Jun 27, 2009 at 03:00:05AM +0800, Coly Li wrote: >>