similar to: Bug in inode deletion code leading to stale inodes

Anyone else seen this? (25736,1):ocfs2_query_inode_wipe:882 ERROR: Inode 129047 (on-disk 129047) not orphaned! Disk flags 0x1, inode flags 0x80 (25736,1):ocfs2_delete_inode:1010 ERROR: status = -17 Test case is my patched version of ocfs2-test/programs/dirop_file_racer that allows long filename prefixes. I ran it on two nodes in separate directories. Filesystem has a 512B blocksize, and I

For nfs exporting, ocfs2_get_dentry() returns the dentry for fh. ocfs2_get_dentry() may read from disk(when inode not in memory) without any cross cluster lock. this leads to load a stale inode. this patch fixes above problem. solution is that in case of inode is not in memory, we get the cluster lock(PR) of alloc inode where the inode in question is allocated from(this causes node on which

Back porting from mainline. For nfs exporting, ocfs2_get_dentry() returns the dentry for fh. ocfs2_get_dentry() may read from disk(when inode not in memory) without any cross cluster lock. this leads to load a stale inode. this patch fixes above problem. solution is that in case of inode is not in memory, we get the cluster lock(PR) of alloc inode where the inode in question is allocated

Currently, default behavior of O_DIRECT writes was allowing concurrent writing among nodes, no cluster coherency guaranteed (no EX locks was taken), it hurts buffered reads on other nodes by reading stale data from cache. The new mount option introduce a chance to choose two different behaviors for O_DIRECT writes: * coherency=full, as the default value, will disallow concurrent

Hi list, Something went wrong this morning and we have a node ( #0 ) reboot. Something blocked the NFS access from both nodes, one rebooted and the another we restarted the nfsd and it brought him back. Looking at node #0 - the one that rebooted - logs everything seems normal, but looking at the othere node dmesg's we saw this messages: First the o2net detected that node #0 was dead: (It

changes from v3: 1, move codes that checks inode allocation bit to subfunction ocfs2_test_inode_bit(). 2, release the suballoc lock just after we get it. we should release it asap and doing so doesn't affect functionility. 3, add inode alloc slot validation. Signed-off-by: Wengang Wang <wen.gang.wang at oracle.com> -- dlmglue.c | 45 +++++++++++++++++ dlmglue.h | 2

#against V6, corrects some format problem pointed out by checkpatch.pl. For nfs exporting, ocfs2_get_dentry() returns the dentry for fh. ocfs2_get_dentry() may read from disk(when inode not in memory) without any cross cluster lock. this leads to load a stale inode. this patch fixes above problem. solution is that in case of inode is not in memory, we get the cluster lock(PR) of alloc inode

#against V6.2, add indentation. For nfs exporting, ocfs2_get_dentry() returns the dentry for fh. ocfs2_get_dentry() may read from disk(when inode not in memory) without any cross cluster lock. this leads to load a stale inode. this patch fixes above problem. solution is that in case of inode is not in memory, we get the cluster lock(PR) of alloc inode where the inode in question is allocated

For nfs exporting, ocfs2_get_dentry() returns the dentry for fh. ocfs2_get_dentry() may read from disk(when inode not in memory) without any cross cluster lock. this leads to load a stale inode. this patch fixes above problem. solution is that in case of inode is not in memory, we get the cluster lock(PR) of alloc inode where the inode in question is allocated from(this causes node on which

Ocfs2 supports exporting. PROBLEM: There are 2 problems (1) Current version of ocfs2_get_dentry() may read from disk the inode WITHOUT any cross cluster lock. This may lead to load a stale inode. (2) for deleting an inode, ocfs2_remove_inode() doesn't sync/checkpoint to disk. This also may lead ocfs2_get_dentry() from other node read out stale inode. PROBLEM DETAIL: for problem (1), For

Generally, orphan scan run in ocfs2_wq and is used to replay orphan dir. So for some low end iscsi device, the delete_inode may take a long time(In some devices, I have seen that delete 500 files will take about 15 secs). This will eventually cause umount to livelock(umount has to flush ocfs2_wq which will wait until orphan scan to finish). So this patch just try to finish the orphan scan

changes from v4: 1, let suballoc lock covers the checking of the group. 2, add/correct some log messages. 3, use ocfs2_read_group_descriptor() instead of diry reading the group. Signed-off-by: Wengang Wang <wen.gang.wang at oracle.com> -- dlmglue.c | 45 ++++++++++++++++ dlmglue.h | 2 export.c | 77 +++++++++++++++++++++++++-- inode.c | 24 ++++++++

Hi List, i'd like to share with you what happened yesterday. Kernel 2.6.36.1 ocfs2-tools 1.6.3 (latest). I had an old OCFS2 partition created with a 2.6.32 kernel and ocfs2 tools 1.4.5. I unmounted all partitions on all nodes in order to enable discontig-bg. I then used tunefs to add discontig-bg, inline-data and indexed-dirs. During indexed-dirs tunefs segfaulted and since then, fsck

The ocfs2 directory index updates two blocks when we remove an entry - the dx root and the dx leaf. OCFS2_DELETE_INODE_CREDITS was only accounting for the dx leaf. This shows up when ocfs2_delete_inode() runs out of credits in jbd2_journal_dirty_metadata() at "J_ASSERT_JH(jh, handle->h_buffer_credits > 0);". The test that caught this was running dirop_file_racer from the

This patch plugs a race between the downconvert thread and an unlock ast message. Specifically, after the downconvert worker has done its task, the dc thread needs to check whether an unlock ast made the downconvert moot. Reported-by: David Teigland <teigland at redhat.com> Signed-off-by: Sunil Mushran <sunil.mushran at oracle.com> Acked-by: Mark Fasheh <mfasheh at sus.com> ---

Hi, Since upgrading to "2.6.18-194" I am getting odd messages in the logs. Such as; sraid3 kernel INFO task pdflush 259 blocked for more than 120 seconds. The output from > grep '120 seconds' /var/log/messages | tr : ' ' | awk '{print $10}' | sort | uniq -c 6 nfsd 4 pdflush This is from an NFS server that since the upgrade has been

Resending after implementing review comments.

Hello, today I noticed the following on *only* one node: ----- cut here ----- Apr 29 11:01:18 node06 kernel: [2569440.616036] INFO: task ocfs2_wq:5214 blocked for more than 120 seconds. Apr 29 11:01:18 node06 kernel: [2569440.616056] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 29 11:01:18 node06 kernel: [2569440.616080] ocfs2_wq D

In commit ea455f8ab68338ba69f5d3362b342c115bea8e13, we move the dentry lock put process into ocfs2_wq. This is OK for most case, but as for umount, it lead to at least 2 bugs. See http://oss.oracle.com/bugzilla/show_bug.cgi?id=1133 and http://oss.oracle.com/bugzilla/show_bug.cgi?id=1135. And it happens easily if we have opened a lot of inodes. For 1135, the reason is that during umount will call

Hello. I am experimenting with OCFS2 on Suse Linux Enterprise Server 11 Service Pack 1. I am performing various stress tests. My current exercise involves writing to files using a shared-writable mmap() from two nodes. (Each node mmaps and writes to different files; I am not trying to access the same file from multiple nodes.) Both nodes are logging messages like these: [94355.116255]