Thanks for the update. Could it be something local to your environment ?<div id="yMail_cursorElementTracker_1623764676763"><br></div><div id="yMail_cursorElementTracker_1623764677672">Have you checked mounting the OCFS2 on a vanilla system ?</div><div id="yMail_cursorElementTracker_1623764693838"><br></div><div id="yMail_cursorElementTracker_1623764694053">Best Regards,</div><div id="yMail_cursorElementTracker_1623764711850">Strahil Nikolov<br> <br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Tue, Jun 15, 2021 at 12:01, Ulrich Windl</div><div><Ulrich.Windl@rz.uni-regensburg.de> wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> Hi Guys!<br clear="none"><br clear="none">Just to keep you informed on the issue:<br clear="none">I was informed that I'm not the only one seeing this problem, and there seems<br clear="none">to be some "negative interference" between BtrFS reorganizing its extents<br clear="none">periodically and OCFS2 making reflink snapshots (a local cron job here) in<br clear="none">current SUSE SLES kernels. It seems that happens almost exactly at 0:00 o'<br clear="none">clock.<br clear="none"><br clear="none">The only thing that BtrFS and OCFS2 have in common here is that BtrFS provides<br clear="none">the mount point for OCFS2.<br clear="none"><br clear="none">Regards,<br clear="none">Ulrich<br clear="none"><br clear="none">>>> Ulrich Windl schrieb am 02.06.2021 um 11:00 in Nachricht <60B748A4.E0C :<br clear="none">161 :<br clear="none">60728>:<div class="yqt9720639786" id="yqtfd22691"><br clear="none">>>>> Gang He <<a shape="rect" ymailto="mailto:GHe@suse.com" href="mailto:GHe@suse.com">GHe@suse.com</a>> schrieb am 02.06.2021 um 08:34 in Nachricht<br clear="none">><br clear="none"><<a shape="rect" ymailto="mailto:AM6PR04MB6488DE7D2DA906BAD73FA3A1CF3D9@AM6PR04MB6488.eurprd04.prod.outlook.c" href="mailto:AM6PR04MB6488DE7D2DA906BAD73FA3A1CF3D9@AM6PR04MB6488.eurprd04.prod.outlook.c">AM6PR04MB6488DE7D2DA906BAD73FA3A1CF3D9@AM6PR04MB6488.eurprd04.prod.outlook.c</a><br clear="none"><br clear="none">> om><br clear="none">> <br clear="none">> > Hi Ulrich,<br clear="none">> > <br clear="none">> > The hang problem looks like a fix<br clear="none">(90bd070aae6c4fb5d302f9c4b9c88be60c8197ec <br clear="none">> > ocfs2: fix deadlock between setattr and dio_end_io_write), but it is not <br clear="none">> 100% <br clear="none">> > sure.<br clear="none">> > If possible, could you help to report a bug to SUSE, then we can work on <br clear="none">> > that further.<br clear="none">> <br clear="none">> Hi!<br clear="none">> <br clear="none">> Actually a service request for the issue is open at SUSE. However I don't <br clear="none">> know which L3 engineer is working on it.<br clear="none">> I have some "funny" effects, like these:<br clear="none">> On one node "ls" hangs, but can be interrupted with ^C; on another node "ls"<br clear="none"><br clear="none">> also hangs, but cannot be stopped with ^C or ^Z<br clear="none">> (Most processes cannot even be killed with "kill -9")<br clear="none">> "ls" on the directory also hangs, just as an "rm" for a non-existent file<br clear="none">> <br clear="none">> What I really wonder is what triggered the effect, and more importantly  how<br clear="none"><br clear="none">> to recover from it.<br clear="none">> Initially I had suspected a rather full (95%) flesystem, but that means <br clear="none">> there are still 24GB available.<br clear="none">> The other suspect was concurrent creation of reflink snapshots while the <br clear="none">> file being snapshot did change (e.g. allocate a hole in a sparse file)<br clear="none">> <br clear="none">> Regards,<br clear="none">> Ulrich<br clear="none">> <br clear="none">> > <br clear="none">> > Thanks<br clear="none">> > Gang<br clear="none">> > <br clear="none">> > ________________________________________<br clear="none">> > From: Users <users‑<a shape="rect" ymailto="mailto:bounces@clusterlabs.org" href="mailto:bounces@clusterlabs.org">bounces@clusterlabs.org</a>> on behalf of Ulrich Windl <br clear="none">> > <<a shape="rect" ymailto="mailto:Ulrich.Windl@rz.uni" href="mailto:Ulrich.Windl@rz.uni">Ulrich.Windl@rz.uni</a>‑regensburg.de><br clear="none">> > Sent: Tuesday, June 1, 2021 15:14<br clear="none">> > To: <a shape="rect" ymailto="mailto:users@clusterlabs.org" href="mailto:users@clusterlabs.org">users@clusterlabs.org</a> <br clear="none">> > Subject: [ClusterLabs] Antw: Hanging OCFS2 Filesystem any one else?<br clear="none">> > <br clear="none">> >>>> Ulrich Windl schrieb am 31.05.2021 um 12:11 in Nachricht <60B4B65A.A8F<br clear="none">: 161 <br clear="none">> <br clear="none">> > :<br clear="none">> > 60728>:<br clear="none">> >> Hi!<br clear="none">> >><br clear="none">> >> We have an OCFS2 filesystem shared between three cluster nodes (SLES 15<br clear="none">SP2,<br clear="none">> >> Kernel 5.3.18‑24.64‑default). The filesystem is filled up to about 95%,<br clear="none">and<br clear="none">> >> we have an odd effect:<br clear="none">> >> A stat() systemcall to some of the files hangs indefinitely (state "D").<br clear="none">> >> ("ls ‑l" and "rm" also hang, but I suspect those are calling state()<br clear="none">> >> internally, too).<br clear="none">> >> My only suspect is that the effect might be related to the 95% being<br clear="none">used.<br clear="none">> >> The other suspect is that concurrent reflink calls may trigger the<br clear="none">effect.<br clear="none">> >><br clear="none">> >> Did anyone else experience something similar?<br clear="none">> > <br clear="none">> > Hi!<br clear="none">> > <br clear="none">> > I have some details:<br clear="none">> > It seems there is a reader/writer deadlock trying to allocate additional <br clear="none">> > blocks for a file.<br clear="none">> > The stacktrace looks like this:<br clear="none">> > Jun 01 07:56:31 h16 kernel:  rwsem_down_write_slowpath+0x251/0x620<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ? __ocfs2_change_file_space+0xb3/0x620<br clear="none">[ocfs2]<br clear="none">> > Jun 01 07:56:31 h16 kernel:  __ocfs2_change_file_space+0xb3/0x620 [ocfs2]<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ocfs2_fallocate+0x82/0xa0 [ocfs2]<br clear="none">> > Jun 01 07:56:31 h16 kernel:  vfs_fallocate+0x13f/0x2a0<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ksys_fallocate+0x3c/0x70<br clear="none">> > Jun 01 07:56:31 h16 kernel:  __x64_sys_fallocate+0x1a/0x20<br clear="none">> > Jun 01 07:56:31 h16 kernel:  do_syscall_64+0x5b/0x1e0<br clear="none">> > <br clear="none">> > That is the only writer (on that host), bit there are multiple readers<br clear="none">like <br clear="none">> > this:<br clear="none">> > Jun 01 07:56:31 h16 kernel:  rwsem_down_read_slowpath+0x172/0x300<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ? dput+0x2c/0x2f0<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ? lookup_slow+0x27/0x50<br clear="none">> > Jun 01 07:56:31 h16 kernel:  lookup_slow+0x27/0x50<br clear="none">> > Jun 01 07:56:31 h16 kernel:  walk_component+0x1c4/0x300<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ? path_init+0x192/0x320<br clear="none">> > Jun 01 07:56:31 h16 kernel:  path_lookupat+0x6e/0x210<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ? __put_lkb+0x45/0xd0 [dlm]<br clear="none">> > Jun 01 07:56:31 h16 kernel:  filename_lookup+0xb6/0x190<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ? kmem_cache_alloc+0x3d/0x250<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ? getname_flags+0x66/0x1d0<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ? vfs_statx+0x73/0xe0<br clear="none">> > Jun 01 07:56:31 h16 kernel:  vfs_statx+0x73/0xe0<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ? fsnotify_grab_connector+0x46/0x80<br clear="none">> > Jun 01 07:56:31 h16 kernel:  __do_sys_newstat+0x39/0x70<br clear="none">> > Jun 01 07:56:31 h16 kernel:  ? do_unlinkat+0x92/0x320<br clear="none">> > Jun 01 07:56:31 h16 kernel:  do_syscall_64+0x5b/0x1e0<br clear="none">> > <br clear="none">> > So that will match the hanging stat() quite nicely!<br clear="none">> > <br clear="none">> > However the PID displayed as holding the writer does not exist in the<br clear="none">system <br clear="none">> <br clear="none">> > (on that node).<br clear="none">> > <br clear="none">> > Regards,<br clear="none">> > Ulrich<br clear="none">> > <br clear="none">> > <br clear="none">> >><br clear="none">> >> Regards,<br clear="none">> >> Ulrich<br clear="none">> >><br clear="none">> >><br clear="none">> >><br clear="none">> >><br clear="none">> > <br clear="none">> > <br clear="none">> > <br clear="none">> > <br clear="none">> > _______________________________________________<br clear="none">> > Manage your subscription:<br clear="none">> > <a shape="rect" href="https://lists.clusterlabs.org/mailman/listinfo/users " target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users </a><br clear="none">> > <br clear="none">> > ClusterLabs home: <a shape="rect" href="https://www.clusterlabs.org/ " target="_blank">https://www.clusterlabs.org/ </a><br clear="none">> > <br clear="none">> > <br clear="none">> > _______________________________________________<br clear="none">> > Manage your subscription:<br clear="none">> > <a shape="rect" href="https://lists.clusterlabs.org/mailman/listinfo/users " target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users </a><br clear="none">> > <br clear="none">> > ClusterLabs home: <a shape="rect" href="https://www.clusterlabs.org/ " target="_blank">https://www.clusterlabs.org/ </a><br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> <br clear="none"><br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none">Manage your subscription:<br clear="none"><a shape="rect" href="https://lists.clusterlabs.org/mailman/listinfo/users" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br clear="none"><br clear="none">ClusterLabs home: <a shape="rect" href="https://www.clusterlabs.org/" target="_blank">https://www.clusterlabs.org/</a><br clear="none"></div> </div> </blockquote></div>