Ren wrote:
> Hi Joseph,
>
> Is the following patch for this issue?
> ```
> commit 3bb8b653c86f6b1d2cc05aa1744fed4b18f99485
> Author: Joseph Qi <joseph...@huawei.com>
> Date: Mon Sep 19 14:44:33 2016 -0700
>
> ocfs2: fix double unlock i
ould be a design error from Suse.
>
>
> Bernd
>
> ----- On Oct 25, 2016, at 11:44 AM, Joseph Qi joseph...@huawei.com wrote:
>
>> Hi Bernd,
>> The error message shows that connection between node 1 and 2 cannot be
>> set up. So you should make sure networ
Sorry for the late response since I was out of office.
Just run configure and prepare the build dependence and then make & make
install.
On 2016/6/23 23:50, He, Xuebin wrote:
> Hi Joseph,
>
> I saw you are contributing to ocfs2-tools repo. I'm currently using that tool
> with older version.
out what you have explained so I can refer
> to?
>
> Thanks.
>
> 2016-05-16 17:07 GMT+08:00 Joseph Qi <joseph...@huawei.com>:
>> Hi,
>> It depends on the user scenario. I suggest choose the approximate
>> cluster size with the most files. And you shoul
Hi,
It depends on the user scenario. I suggest choose the approximate
cluster size with the most files. And you should also consider the
volume size support, for example, 4K cluster will only support 16TB
volume, while 1M cluster can support 4PB.
BTW, no matter 4kb or 20kb files, they are always
I don't think so.
I haven't ever encountered this. So I am wandering if these volumes are
not newly created. In other words, they are copied using LUN copy.
Another possibility is, they are the same device with different name in
multipath environment.
Thanks,
Joseph
On 2016/5/4 13:43, Eric Ren
> All the best ... Michael
>
> On 03/25/2016 01:36 AM, Joseph Qi wrote:
>> Hi Michael,
>>
>> On 2016/3/24 21:47, Michael Ulbrich wrote:
>>> Hi Joseph,
>>>
>>> thanks for this information although this does not sound too optimistic ...
>>&g
d, you have already upgraded to version 1.8.4. So I'm sorry
currently I don't have a better idea.
Thanks,
Joseph
>
> Thanks a lot for your help ... Michael
>
> On 03/24/2016 02:10 PM, Joseph Qi wrote:
>> Hi Michael,
>> So I think the block of record #153 goes wrong,
ns at record #154 and spans 135 records, right?
>
> Will backup fs metadata as soon as I have some external storage at hand.
>
> Thanks a lot so far ... Michael
>
> On 03/24/2016 10:41 AM, Joseph Qi wrote:
>> Hi Michael,
>> It seems that dead loop happens in chain
059656 428442419215872100525820 5119 1984
> 2059657 4277123072158727383 8489 5120 1984
> 2059658 42734725121587214 158585655 1984
> 2059659 4269821952158722637 132357060 1984
> 205966
Hi Michael,
Could you please use debugfs to check the output?
# debugfs.ocfs2 -R 'stat //global_bitmap'
Thanks,
Joseph
On 2016/3/24 6:38, Michael Ulbrich wrote:
> Hi ocfs2-users,
>
> my first post to this list from yesterday probably didn't get through.
>
> Anyway, I've made some progress in
Hi Nguyen,
If the problem can be resolved by enlarging O2CB_HEARTBEAT_THRESHOLD,
it may be caused by heavy load in your fio performance test.
Ocfs2 should do disk heartbeat to indicate "I'm alive". Once heartbeat
timeout it will fence the node, which default behavior is restarting.
Thanks,
Joseph
5:44 integ-hm5 kernel: (nvfs,91539,0):dlm_get_lock_resource:789 no
> lockres found, allocated our own: 880717e38780
> Dec 27 21:45:44 integ-hm5 kernel: (nvfs,91539,0):__dlm_insert_lockres:187
> A895BC216BE641A8A7E20AA89D57E051: Hash res O0084782204
> Dec 27 21:45:
:05:08 integ-hm8 kernel: gran_size: 128K chunk_size: 256M
> num_reg: 10 lose cover RAM: 0G
> Dec 27 23:05:08 integ-hm8 kernel: gran_size: 128K chunk_size: 512M
> num_reg: 10 lose cover RAM: 0G
> Dec 27 23:05:08 integ-hm8 kernel: gran_size:
> DLM_RECOVERY off
> HEARTBEAT off
> CLUSTER off
>
> Regards
> Prabu
> **
>
>
>
> On Wed, 23 Dec 2015 07:30:54 +0530 *Joseph Qi
> <joseph...@huawei.com>*wrote
>
> So you mean the four nodes are manually rebooted? If so you must
> analyze messages befor
node. After reboot everything is come to
> normal, this behavior happend many times. Do we have any debug and fix for
> this issue.
>
> Regards
> Prabu
>
>
> On Tue, 22 Dec 2015 16:30:52 +0530 *Joseph Qi
> <joseph...@huawei.com>*wrote
>
> Hi Pra
> QUORUM off
> SOCKET off
> DLM_GLUE off
> DLM_THREAD off
> DLM_RECOVERY allow
> HEARTBEAT off
> CLUSTER off
>
> Regards
> Prabu
>
>
> On Wed, 23 Dec 2015 07:51:38 +0530 *Joseph Qi
> <joseph...@huawei.com>*wrote
>
> Please also switch
Hi Prabu,
>From the log you provided, I can only see that node 5 disconnected with
node 2, 3, 1 and 4. It seemed that something wrong happened on the four
nodes, and node 5 did recovery for them. After that, the four nodes
joined again.
On 2015/12/22 16:23, gjprabu wrote:
> Hi,
>
>
Hi Jon,
>From the information you provided, I can see:
Your ocfs2 cluster has 3 nodes configured, which are node 0, 1, 2.
And the network of node 1 (host name is server1) has been down and then
result in the -ENOTCONN(-107) and -EHOSTDOWN(-112) errors when sending
dlm messages.
On 2015/10/29
-
> zh
On 2015/10/14 15:49, Zhangguanghui wrote:
> OCFS2 is often used in high-availaibility systems, This patch enhances
> robustness for the filesystem.
> but storage network is unstable，it still triggers a panic， such as
> ocfs2_start_trans -> __ocfs2_abort ->panic.
> The 's_mount_opt' should depend
ST: Input/output error
> ls: cannot access MICKEYLITE_3_0_M4_1_OLD: Input/output error
> total 0
> d? ? ? ? ? ? MICKEYLITE_3_0_M4_1_TEST
> d? ? ? ? ? ? MICKEYLITE_3_0_M4_1_OLD
> Regards
> G.J
> **
>
Could you please show me the umount process stack?
cat /proc
kernel/config//node/).
I haven't used ocfs2 along with ceph rbd. So I am not sure if it has
relations with rbd.
>
>
>
> Regards
> G.J
> **
>
>
>
> On Fri, 25 Sep 2015 06:26:57 +0530 *Joseph Qi <joseph...@huawei.com>*
> wrote
>
> On 2015/9/2
[264464.605542] o2dlm: Node 7 leaves domain A895BC216BE641A8A7E20AA89D57E051
> ( 1 2 3 4 ) 4 nodes
> [275619.497198] o2dlm: Node 7 joins domain A895BC216BE641A8A7E20AA89D57E051 (
> 1 2 3 4 7 ) 5 nodes
> [426628.076148] o2cb: o2dlm has evicted node 1 from domain
> A895BC216BE641A8A7E20AA89D57E051
> [
Please check the node config in configfs in each node:
/sys/kernel/config/cluster/your_cluster_name/node/
If it is not the same, try to offline the cluster and then online, which
will reload the config from the cluster.conf.
On 2015/8/6 0:38, Jonathan Ramsay wrote:
Hello ,
Have four node
Hi All,
We have encountered a case that extent alloc gd has been abnormally
cleared.
In our environment, the volume has been formatted with 128 slots but
actually has 64 slots in use. Since extent alloc is allocated when
formatting, and extent_alloc:0107 (inode 259) hasn't been use in our
26 matches
Mail list logo
