<div dir="ltr"><div class="gmail_extra"><span style="font-size:14px">Hi Brain,</span></div><div class="gmail_extra"><span style="font-size:14px"><br></span></div><div class="gmail_extra"><span style="font-size:14px">>The original stacktrace shows the crash in a readdir request. I'm sure</span><br style="font-size:14px"><span style="font-size:14px">>there are multiple things going on here (and there are a couple rename</span><br style="font-size:14px"><span style="font-size:14px">>traces in the vmcore sitting on locks), of course, but where does the</span><br style="font-size:14px"><span style="font-size:14px">>information about the rename come from?</span><br></div><div class="gmail_extra"><span style="font-size:14px"><br></span></div><div class="gmail_extra"><span style="font-size:14px">I tracked source code of the application. It moves data to a quarantined area(another folder on same disk) under some conditions. In the bug report, it indicates a condition that DELETE(create empty file in a directory) object + list the directory will cause data MOVE (os.rename) to quarantined area(another folder). The os.rename function call is the only function of the application to touch quarantined folder. </span></div><div class="gmail_extra"><span style="font-size:14px"><br></span></div><div class="gmail_extra"><span style="font-size:14px">>I'm not quite following here because I don't have enough context about</span><br style="font-size:14px"><span style="font-size:14px">>what the application server is doing. So far, it sounds like we somehow</span><br style="font-size:14px"><span style="font-size:14px">>have multiple threads competing to rename the same file..? Is there</span><br style="font-size:14px"><span style="font-size:14px">>anything else in this directory at the time this sequence executes</span><br style="font-size:14px"><span style="font-size:14px">>(e.g., a file with object data that also gets quarantined)?</span><br style="font-size:14px"><br>The previous behavior (a bug in the application) should not trigger Kernel panic. Yes, there's multiple threads competing to DELETE(create a empty file) in the same directory also move the existing one to the quarantined area. I think this is the root cause of kernel panic. The scenario is 10 application workers raise 10 thread to do same thing in the same moment. <br><br style="font-size:14px"><span style="font-size:14px">>Ideally, we'd ultimately like to translate this into a sequence of</span><br style="font-size:14px"><span style="font-size:14px">>operations as seen by the fs that hopefully trigger the problem. We</span><br style="font-size:14px"><span style="font-size:14px">>might have to start by reproducing through the application server.</span><br style="font-size:14px"><span style="font-size:14px">>Looking back at that bug report, it sounds like a 'DELETE' is a</span><br style="font-size:14px"><span style="font-size:14px">>high-level server operation that can consist of multiple sub-operations</span><br style="font-size:14px"><span style="font-size:14px">>at the filesystem level (e.g., list, conditional rename if *.ts file</span><br style="font-size:14px"><span style="font-size:14px">>exists, etc.). Do you have enough information through any of the above</span><br style="font-size:14px"><span style="font-size:14px">>to try and run something against Swift that might explicitly reproduce</span><br style="font-size:14px"><span style="font-size:14px">>the problem? For example, have one thread that creates and recreates the</span><br style="font-size:14px"><span style="font-size:14px">>same object repeatedly and many more competing threads that try to</span><br style="font-size:14px"><span style="font-size:14px">>remove (or whatever results in the quarantine) it? Note that I'm just</span><br style="font-size:14px"><span style="font-size:14px">>grasping at straws here, you might be able to design a more accurate</span><br style="font-size:14px"><span style="font-size:14px">>reproducer based on what it looks like is happening within Swift.</span><span style="font-size:14px"><br></span></div><div class="gmail_extra"><span style="font-size:14px"><br></span></div><div class="gmail_extra"><span style="font-size:14px">We observe this issue on production cluster. It's hard to have a free gear with 100% same HW to test it currently. </span></div><div class="gmail_extra"><span style="font-size:14px">I'll try to figure out an approach to reproduce it. I'll update this mail thread if I can make it. </span></div><div class="gmail_extra"><span style="font-size:14px"><br></span></div><div class="gmail_extra"><span style="font-size:14px">Thanks // Hugo</span></div><div class="gmail_extra"><span style="font-size:14px"><br></span></div></div>