Hi,
I am afraid that doing so might introduce a compatible risk into exited
systems which reply ocfs2/dlmfs.
We can't guarantee that no system management tools is using the
information reported from this file.
Basically, ocfs2-tools works of top of it. But after a quick glance at
the sourc
i
Also looks sane to me
Reviewed-by: Changwei Ge
>> ---
>> fs/ocfs2/file.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
>> index 2e982db3e1ae..53939bf9d7d2 100644
>> --- a/fs/ocfs2/file.c
>>
Hi Jia-Ju,
Please checkout my comments inline.
On 2019/7/27 8:49 上午, Joseph Qi wrote:
On 19/7/26 18:14, Jia-Ju Bai wrote:
In ocfs2_xa_prepare_entry(), there is an if statement on line 2136 to
check whether loc->xl_entry is NULL:
if (loc->xl_entry)
When loc->xl_entry is NULL, it is use
Hi Jia-ju,
Could you please point out how ->w_handle can be NULL if we are changing
disk inode?
I just checked the ocfs2 code but can't find any clue ...
In my opinion, it's impossible to change disk inode without an existed
journal transaction. If truly so, it's a another problem.
Thank
Hi Gang,
It looks good to me.
On 2019/1/15 16:23, Gang He wrote:
> Hello ChangWei,
>
>>>> On 2019/1/15 at 16:00, in message
> <63adc13fd55d6546b7dece290d39e3730127826...@h3cmlb12-ex.srv.huawei-3com.com>,
> Changwei Ge wrote:
>> On 2019/1/15 13:49
On 2019/1/15 13:49, Gang He wrote:
> Hello Changewei,
>
>>>> On 2019/1/15 at 11:50, in message
> <63adc13fd55d6546b7dece290d39e3730127825...@h3cmlb12-ex.srv.huawei-3com.com>,
> Changwei Ge wrote:
>> Hi Gang,
>>
>> Most parts of this patch look san
Hi Gang,
Most parts of this patch look sane to me, just a tiny question...
On 2019/1/11 17:01, Gang He wrote:
> The user reported this problem, the upper application IO was
> timeout when fstrim was running on this ocfs2 partition. the
> application monitoring resource agent considered that this
Hi Gang,
On 2019/1/11 17:01, Gang He wrote:
> The user reported this problem, the upper application IO was
> timeout when fstrim was running on this ocfs2 partition. the
> application monitoring resource agent considered that this
> application did not work, then this node was fenced by the cluste
qT6Fo7Y&m=K8aRgOiMescamJW-IuHq-cW4mWedGQv2JTT-2KPy1RI&s=PQOJREyeElsg_1IlINdSGefNqA6w_cUrI1ezdVxyi7o&e=
> Signed-off-by: Larry Chen
> Cc: Mark Fasheh
> Cc: Joel Becker
> Cc: Junxiao Bi
> Cc: Joseph Qi
> Cc: Changwei Ge
> Signed-off-by: Andrew Morton
> ---
Hi Jun,
On 2018/3/2 10:16, piaojun wrote:
> Hi Changwei,
>
> On 2018/3/2 9:59, Changwei Ge wrote:
>> Hi Jun,
>> I think the comments for both two functions are OK.
>> No need to rework them.
>> As we know, ocfs2 lock name(lock id) are composed of several par
Hi Jun,
I think the comments for both two functions are OK.
No need to rework them.
As we know, ocfs2 lock name(lock id) are composed of several parts including
block number.
Thanks,
Changw2ei
On 2018/3/1 20:58, piaojun wrote:
> Hi Larry,
>
> There is the same mistake in ocfs2_reflink_inodes_lo
Hi Larry,
On 2018/2/28 18:18, Larry Chen wrote:
> The function ocfs2_double_lock tries to lock the inode with lower
> blockid first, not lockid.
As ocfs2's lock name includes block number, so I think the comment you want to
rework is all right.
So nack.
Thanks,
Changwei
>
> Signed-off-by: Lar
It looks good to me.
Reviewed-by: Changwei Ge
On 2017/12/14 13:16, Gang He wrote:
> As you know, ocfs2 has support trim the underlying disk via
> fstrim command. But there is a problem, ocfs2 is a shared disk
> cluster file system, if the user configures a scheduled fstrim
> job
It looks good to me.
Reviewed-by: Changwei Ge
On 2017/12/14 13:16, Gang He wrote:
> Introduce a new dlm lock resource, which will be used to
> communicate during fstrim a ocfs2 device from cluster nodes.
>
> Signed-off-by: Gang He
> ---
> fs/ocfs2/d
On 2018/1/11 15:57, Gang He wrote:
>
>
>
>> On 2018/1/11 15:19, Gang He wrote:
>>>
>>>
>>>
>>
On 2018/1/11 12:31, Gang He wrote:
> Hi Changwei,
>
>
>> On 2018/1/11 11:33, Gang He wrote:
>>> Hi Changwei,
>>>
>>>
>>
On 2018/1/11 1
On 2018/1/11 15:19, Gang He wrote:
>
>
>
>> On 2018/1/11 12:31, Gang He wrote:
>>> Hi Changwei,
>>>
>>>
>>
On 2018/1/11 11:33, Gang He wrote:
> Hi Changwei,
>
>
>> On 2018/1/11 10:07, Gang He wrote:
>>> Hi Changwei,
>>>
>>>
>>
O
On 2018/1/11 12:31, Gang He wrote:
> Hi Changwei,
>
>
>> On 2018/1/11 11:33, Gang He wrote:
>>> Hi Changwei,
>>>
>>>
>>
On 2018/1/11 10:07, Gang He wrote:
> Hi Changwei,
>
>
>> On 2018/1/10 18:14, Gang He wrote:
>>> Hi Changwei,
>>>
>>>
>
On 2018/1/11 11:33, Gang He wrote:
> Hi Changwei,
>
>
>> On 2018/1/11 10:07, Gang He wrote:
>>> Hi Changwei,
>>>
>>>
>>
On 2018/1/10 18:14, Gang He wrote:
> Hi Changwei,
>
>
>> On 2018/1/10 17:05, Gang He wrote:
>>> Hi Changwei,
>>>
>>>
>
On 2018/1/11 10:07, Gang He wrote:
> Hi Changwei,
>
>
>> On 2018/1/10 18:14, Gang He wrote:
>>> Hi Changwei,
>>>
>>>
>>
On 2018/1/10 17:05, Gang He wrote:
> Hi Changwei,
>
>
>> Hi Gang,
>>
>> On 2017/12/14 13:16, Gang He wrote:
>>> As you know, o
On 2018/1/10 18:14, Gang He wrote:
> Hi Changwei,
>
>
>> On 2018/1/10 17:05, Gang He wrote:
>>> Hi Changwei,
>>>
>>>
>>
Hi Gang,
On 2017/12/14 13:16, Gang He wrote:
> As you know, ocfs2 has support trim the underlying disk via
> fstrim command. But there is a probl
Hi Gang,
On 2018/1/10 18:14, Gang He wrote:
> Hi Changwei,
>
>
>> On 2018/1/10 17:05, Gang He wrote:
>>> Hi Changwei,
>>>
>>>
>>
Hi Gang,
On 2017/12/14 13:16, Gang He wrote:
> As you know, ocfs2 has support trim the underlying disk via
> fstrim command. But there
On 2018/1/4 10:09, Gang He wrote:
> Hi Alex,
>
>
>> Hi Gang,
>>
>> On 2017/12/14 13:14, Gang He wrote:
>>> As you know, ocfs2 has support trim the underlying disk via
>>> fstrim command. But there is a problem, ocfs2 is a shared disk
>>> cluster file system, if the user configures a schedule
On 2018/1/10 17:05, Gang He wrote:
> Hi Changwei,
>
>
>> Hi Gang,
>>
>> On 2017/12/14 13:16, Gang He wrote:
>>> As you know, ocfs2 has support trim the underlying disk via
>>> fstrim command. But there is a problem, ocfs2 is a shared disk
>>> cluster file system, if the user configures a sch
Hi Gang,
On 2017/12/14 13:16, Gang He wrote:
> Introduce a new dlm lock resource, which will be used to
> communicate during fstrim a ocfs2 device from cluster nodes.
>
> Signed-off-by: Gang He
> ---
> fs/ocfs2/dlmglue.c | 86
> +
> fs/ocf
Hi Gang,
On 2017/12/14 13:16, Gang He wrote:
> As you know, ocfs2 has support trim the underlying disk via
> fstrim command. But there is a problem, ocfs2 is a shared disk
> cluster file system, if the user configures a scheduled fstrim
> job on each file system node, this will trigger multiple no
123108 97224 S 0.333 6.017 0:01.33 corosync
>
> ocfs2test@tb-node2:~>multiple_run.sh -i ens3 -k ~/linux-4.4.21-69.tar.gz -o
> ~/ocfs2mullog -C hacluster -s pcmk -n tb-node2,tb-node1,tb-node3 -d
> /dev/sda1 -b 4096 -c 32768 -t multi_mmap /mnt/shared
> Tests with "-b
0
> RBP: 0003 R08: 000e R09:
> R10: 0483 R11: 7fa75ded61b0 R12: 7fa75e90a770
> R13: 000e R14: 00001770 R15:
>
> Fixes: 1cce4df04f37 ("ocfs2: do not lock/unlock() inode
On 2017/12/8 14:21, alex chen wrote:
>
>
> On 2017/12/8 13:36, Ben Hutchings wrote:
>> On Fri, 2017-12-08 at 12:03 +0800, alex chen wrote:
>>>
>>> On 2017/12/8 10:26, Ben Hutchings wrote:
On Fri, 2017-12-08 at 08:39 +0800, alex chen wrote:
>
> On 2017/12/8 2:25, Ben Hutchings wrote:
Hi Gang,
On 2017/11/30 10:45, Gang He wrote:
> Hello Changwei,
>
>
>> On 2017/11/29 16:38, Gang He wrote:
>>> Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which
>>> will be used in non-block IO scenarios.
>>>
>>> Signed-off-by: Gang He
>>> ---
>>>fs/ocfs2/dlmglue.c | 21 ++
It looks fine to me.
On 2017/11/29 16:39, Gang He wrote:
> Add ocfs2_overwrite_io function, which is used to judge if
> overwrite allocated blocks, otherwise, the write will bring extra
> block allocation overhead.
>
> Signed-off-by: Gang He
Reviewed-by: Changwei Ge
>
On 2017/11/29 16:38, Gang He wrote:
> Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which
> will be used in non-block IO scenarios.
>
> Signed-off-by: Gang He
> ---
> fs/ocfs2/dlmglue.c | 21 +
> fs/ocfs2/dlmglue.h | 4
> 2 files changed, 25 insertions(+)
On 2017/11/28 13:44, Gang He wrote:
> Hi Changwei,
>
>
>> Hi,
>> Gang
>>
>> On 2017/11/27 17:48, Gang He wrote:
>>> Add ocfs2_overwrite_io function, which is used to judge if
>>> overwrite allocated blocks, otherwise, the write will bring extra
>>> block allocation overhead.
>>>
>>
>> Can yo
Hi,
Gang
On 2017/11/27 17:48, Gang He wrote:
> Add ocfs2_overwrite_io function, which is used to judge if
> overwrite allocated blocks, otherwise, the write will bring extra
> block allocation overhead.
>
Can you elaborate how this overhead is introduced?
Forgive me, I don't figure it.
Thanks,
On 2017/11/28 9:52, piaojun wrote:
> Hi Gang,
>
> If ocfs2_overwrite_io is only called in 'nowait' scenarios, I wonder if
> we can discard 'int wait' just as ext4 does:
>
> static bool ext4_overwrite_io(struct inode *inode, loff_t pos, loff_t len);
Yes, Jun has a point.
It seems that ocfs2_overw
Hi Gang,
On 2017/11/27 17:48, Gang He wrote:
> Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which
> will be used in non-block IO scenarios.
>
> Signed-off-by: Gang He
> ---
> fs/ocfs2/dlmglue.c | 22 ++
> fs/ocfs2/dlmglue.h | 4
> 2 files changed, 26 in
Hi Andrew and Vitaly,
I do agree that patch ee8f7fcbe638 ("ocfs2/dlm: continue to purge
recovery lockres when recovery master goes down", 2016-08-02) introduced
an issue. It makes DLM recovery can't pick up a new master for an
existed lock resource whose owner died seconds ago.
But this patch
Hi Andrew,
On 2017/8/26 5:24, Andrew Morton wrote:
> On Thu, 24 Aug 2017 08:15:30 +0000 Changwei Ge wrote:
>
>> Hi Andrew,
>>
>> On 2017/8/24 15:42, Stephen Rothwell wrote:
>>> Hi Andrew, After merging the akpm-current tree, today's linux-next
>>
Hi Andrew,
On 2017/8/24 15:42, Stephen Rothwell wrote:
> Hi Andrew, After merging the akpm-current tree, today's linux-next
> build (x86_64 allmodconfig) produced these warnings:
> fs/ocfs2/dlm/dlmrecovery.c: In function 'dlm_free_dead_locks':
> fs/ocfs2/dlm/dlmrecovery.c:2306:6: warning: unused v
Hi Gang,
More log before crash is pasted.
Also, I gathered some structure's content, which may be useful to
analyze this issue.
Paste them here too.
struct dio_submit {
bio = 0x88035690b800,
blkbits = 0x9,
blkfactor = 0x3,
start_zero_done = 0x1,
pages_in_io = 0x34,
block_in_file
Hi,
We encountered a crash issue days ago.
The call trace follows as below:
>From the call trace, we can see that a direct read request caused this
crash issue, which triggered a BUG_ON check point.
With the help of debugfs.ocfs2 tool, I can see that clusters owned by
the target file are extrem
2001
From: Changwei Ge
Date: Wed, 11 Jan 2017 09:05:35 +0800
Subject: [PATCH] fix umount hang after journal flushing failure
Signed-off-by: Changwei Ge
---
fs/ocfs2/journal.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/fs/ocfs2/journal.c b/fs/ocfs2/journal.c
index a244f1
41 matches
Mail list logo