Am 24.03.2016 um 09:10 schrieb Stefan Priebe - Profihost AG: > > Am 23.03.2016 um 15:07 schrieb Brian Foster: >> On Wed, Mar 23, 2016 at 02:28:03PM +0100, Stefan Priebe - Profihost AG wrote: >>> sorry new one the last one got mangled. Comments inside. >>> >>> Am 05.03.2016 um 23:48 schrieb Dave Chinner: >>>> On Fri, Mar 04, 2016 at 04:03:42PM -0500, Brian Foster wrote: >>>>> On Fri, Mar 04, 2016 at 09:02:06PM +0100, Stefan Priebe wrote: >>>>>> Am 04.03.2016 um 20:13 schrieb Brian Foster: >>>>>>> On Fri, Mar 04, 2016 at 07:47:16PM +0100, Stefan Priebe wrote: >>>>>>>> Am 20.02.2016 um 19:02 schrieb Stefan Priebe - Profihost AG: >>>>>>>>> >>>>>>>>>> Am 20.02.2016 um 15:45 schrieb Brian Foster <bfoster@xxxxxxxxxx>: >>>>>>>>>> >>>>>>>>>>> On Sat, Feb 20, 2016 at 09:02:28AM +0100, Stefan Priebe wrote: >> ... >>> >>> This has happened again on 8 different hosts in the last 24 hours >>> running 4.4.6. >>> >>> All of those are KVM / Qemu hosts and are doing NO I/O except the normal >>> OS stuff as the VMs have remote storage. So no database, no rsync on >>> those hosts - just the OS doing nearly nothing. >>> >>> All those show: >>> [153360.287040] WARNING: CPU: 0 PID: 109 at fs/xfs/xfs_aops.c:1234 >>> xfs_vm_releasepage+0xe2/0xf0() >>> >> >> Ok, well at this point the warning isn't telling us anything beyond >> you're reproducing the problem. We can't really make progress without >> more information. We don't necessarily know what application or >> operations caused this by the time it occurs, but perhaps knowing what >> file is affected could give us a hint. >> >> We have the xfs_releasepage tracepoint, but that's unconditional and so >> might generate a lot of noise by default. Could you enable the >> xfs_releasepage tracepoint and hunt for instances where delalloc != 0? >> E.g., we could leave a long running 'trace-cmd record -e >> "xfs:xfs_releasepage" <cmd>' command on several boxes and wait for the >> problem to occur. Alternatively (and maybe easier), run 'trace-cmd start >> -e "xfs:xfs_releasepage"' and leave something like 'cat >> /sys/kernel/debug/tracing/trace_pipe | grep -v "delalloc 0" > >> ~/trace.out' running to capture instances. Isn't the trace a WARN_ONCE? So it does not reoccur or can i check the it in the trace.out even the WARN_ONCE was already triggered? Stefan > > Stefan > >> >> Brian >> >>> Stefan >>> >>>> >>>> -Dave. >>>> >>> >>> _______________________________________________ >>> xfs mailing list >>> xfs@xxxxxxxxxxx >>> http://oss.sgi.com/mailman/listinfo/xfs -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
