search for: __ocfs2_abort

Hi, "status = -30" means it has encountered EROFS when start transaction. And system panic is because s_mount_opt is set to OCFS2_MOUNT_ERRORS_PANIC in __ocfs2_abort, ideal with OCFS2_MOUNT_ERRORS_PANIC first in ocfs2_handle_error. so I think that it is not reasonable, Therefore, this setting shall be canceled in __ocfs2_abort. thanks ________________________________ zhangguanghui From: Joseph Qi<mailto:joseph.qi at huawei.com> Date: 2015-10-14 16:13...

On 10/14/2015 03:57 AM, Joseph Qi wrote: > On 2015/10/14 16:45, Zhangguanghui wrote: >> Hi, >> "status = -30" means it has encountered EROFS when start transaction. >> And system panic is because s_mount_opt is set to OCFS2_MOUNT_ERRORS_PANIC in __ocfs2_abort, >> ideal with OCFS2_MOUNT_ERRORS_PANIC first in ocfs2_handle_error. >> so I think that it is not reasonable, Therefore, this setting shall be canceled in __ocfs2_abort. >> thanks >> > The option is set when mounting and __ocfs2_abort does the check and > then perfo...

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 on the mount option set, If errors=continue is set, > mark as a EIO error, change OCFS2_MOUNT_ERRORS_PANIC to OCFS2_MOUNT_ERRORS_CONT in __ocfs2_abort; > it's better than forcing a panic without decreasing availability,errors=conti...

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 on the mount option set, If errors=continue is set, mark as a EIO error, change OCFS2_MOUNT_ERRORS_PANIC to OCFS2_MOUNT_ERRORS_CONT in __ocfs2_abort; it's better than forcing a panic without decreasing availability,errors=continue seems be wel...

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 on the mount option set, If errors=continue is set, mark as a EIO error, change OCFS2_MOUNT_ERRORS_PANIC to OCFS2_MOUNT_ERRORS_CONT in __ocfs2_abort; it's better than forcing a panic without decreasing availability,errors=continue seems be wel...

...abort() then got panic. :) > So I changed to ocfs2_error(). I also sent two mails in 2023-4-30 (the first > mail has mess format by thunderbird). I copy the mail content here: > ``` > More info for this patch, maybe I should write below info in commit log. > > From the comment of __ocfs2_abort(), there is another way to handle > journal ABORT: panic. > And fstest generic test NO. 648 will trigger ocfs2_abort then make > kernel panic. I don't like the panic style, ocfs2 should elegantly > handle journal abnormal case. > ``` > > fstest NO. 648 could trigger ocfs2_...

...; > So I changed to ocfs2_error(). I also sent two mails in 2023-4-30 (the first > > mail has mess format by thunderbird). I copy the mail content here: > > ``` > > More info for this patch, maybe I should write below info in commit log. > > > > From the comment of __ocfs2_abort(), there is another way to handle > > journal ABORT: panic. > > And fstest generic test NO. 648 will trigger ocfs2_abort then make > > kernel panic. I don't like the panic style, ocfs2 should elegantly > > handle journal abnormal case. > > ``` > > > >...

...anged to ocfs2_error(). I also sent two mails in 2023-4-30 (the first >>> mail has mess format by thunderbird). I copy the mail content here: >>> ``` >>> More info for this patch, maybe I should write below info in commit log. >>> >>> From the comment of __ocfs2_abort(), there is another way to handle >>> journal ABORT: panic. >>> And fstest generic test NO. 648 will trigger ocfs2_abort then make >>> kernel panic. I don't like the panic style, ocfs2 should elegantly >>> handle journal abnormal case. >>> ``` >&g...

...right. I ever used ocfs2_abort() then got panic. :) So I changed to ocfs2_error(). I also sent two mails in 2023-4-30 (the first mail has mess format by thunderbird). I copy the mail content here: ``` More info for this patch, maybe I should write below info in commit log. >From the comment of __ocfs2_abort(), there is another way to handle journal ABORT: panic. And fstest generic test NO. 648 will trigger ocfs2_abort then make kernel panic. I don't like the panic style, ocfs2 should elegantly handle journal abnormal case. ``` fstest NO. 648 could trigger ocfs2_abort from ocfs2_start_trans(). So...

fstest generic cases 347 361 628 629 trigger a same issue: When jbd2 enter ABORT status, ocfs2 ignores it and keep going to commit journal. This commit gives ocfs2 ability to handle jbd2 ABORT case. Signed-off-by: Heming Zhao <heming.zhao at suse.com> --- fs/ocfs2/alloc.c | 10 ++++++---- fs/ocfs2/journal.c | 5 +++++ fs/ocfs2/localalloc.c | 3 +++ 3 files changed, 14

...rk, ocfs2_drop_dl_inodes); osb->dentry_lock_list = NULL; + INIT_WORK(&osb->osb_freeze_work, ocfs2_freeze_worker); + /* get some pseudo constants for clustersize bits */ osb->s_clustersize_bits = le32_to_cpu(di->id2.i_super.s_clustersize_bits); @@ -2529,5 +2551,110 @@ void __ocfs2_abort(struct super_block* sb, ocfs2_handle_error(sb); } +static inline int is_kernel_thread() +{ + return (current->flags & PF_KTHREAD); +} + +/* ocfs2_freeze_fs()/ocfs2_unfreeze_fs() are always called by freeze_bdev()/ + * thaw_bdev(). bdev->bd_fsfreeze_mutex is used for synchronization....