search for: ocfs2_mount_errors_panic

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:...

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 a...

...ty 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 well to me. Finally, any feedback about this process (positive or negative) would be greatly appreciated. Aug 11 11:32:25 cvknode73 kernel: [678904.787906]...

...ty 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 well to me. Finally, any feedback about this process (positive or negative) would be greatly appreciated. Aug 11 11:32:25 cvknode73 kernel: [678904.787906]...

...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 well to me. > > Finally, any feedback about this process (positive or negative) would be greatly appreciated. > > Aug 11 11:32:25 cvknode...

...tly handle journal abnormal case. ``` fstest NO. 648 could trigger ocfs2_abort from ocfs2_start_trans(). So you could find my previous mail, I ran the fstest with parameter '-e generic/648', which means fstest excludes NO. 648. The only different between ocfs2_abort and ocfs2_error is set OCFS2_MOUNT_ERRORS_PANIC, which could trigger panic. If you think panic is brute, I suggest to use ocfs2_error. > > >> BTW, the basic rule here is, we don't want to change journal to prevent > >> other nodes corrupting the filesystem. > > > > If my memory is correct, every node has i...

...`` > > fstest NO. 648 could trigger ocfs2_abort from ocfs2_start_trans(). So you could > find my previous mail, I ran the fstest with parameter '-e generic/648', which > means fstest excludes NO. 648. > > The only different between ocfs2_abort and ocfs2_error is set > OCFS2_MOUNT_ERRORS_PANIC, which could trigger panic. If you think panic is > brute, I suggest to use ocfs2_error. > Looked back the history, it is designed to panic in cluster mode: a2f2ddbf2baf ocfs2: __ocfs2_abort() should not enable panic for local mounts >> >>>> BTW, the basic rule here is, w...

...648 could trigger ocfs2_abort from ocfs2_start_trans(). So you could > > find my previous mail, I ran the fstest with parameter '-e generic/648', which > > means fstest excludes NO. 648. > > > > The only different between ocfs2_abort and ocfs2_error is set > > OCFS2_MOUNT_ERRORS_PANIC, which could trigger panic. If you think panic is > > brute, I suggest to use ocfs2_error. > > > > Looked back the history, it is designed to panic in cluster mode: > a2f2ddbf2baf ocfs2: __ocfs2_abort() should not enable panic for local mounts About the panic action from ocf...

...ger ocfs2_abort from ocfs2_start_trans(). So you could >>> find my previous mail, I ran the fstest with parameter '-e generic/648', which >>> means fstest excludes NO. 648. >>> >>> The only different between ocfs2_abort and ocfs2_error is set >>> OCFS2_MOUNT_ERRORS_PANIC, which could trigger panic. If you think panic is >>> brute, I suggest to use ocfs2_error. >>> >> >> Looked back the history, it is designed to panic in cluster mode: >> a2f2ddbf2baf ocfs2: __ocfs2_abort() should not enable panic for local mounts > > About...

ocfs2 currently uses the Journaled Block Device (JBD) for its journaling. This is a very stable and tested codebase. However, JBD is limited by architecture to 32bit block numbers. This means an ocfs2 filesystem is limited to 2^32 blocks. With a 4K blocksize, that's 16TB. People want larger volumes. Fortunately, there is now JBD2. JBD2 adds 64bit block number support and some other

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