
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On 2013-05-13, at 17:22, Daniel Phillips <<a href="mailto:daniel.raymond.phillips@gmail.com">daniel.raymond.phillips@gmail.com</a>> wrote:</div><div><br></div><blockquote type="cite"><div><span>Hi Ted,</span><br><span>You said:</span><br><blockquote type="cite"><span>...any advantage of decoupling the front/back end</span><br></blockquote><blockquote type="cite"><span>is nullified, since fsync(2) requires a temporal coupling</span><br></blockquote><span></span><br><span>After after pondering it for a while, I realized that is not</span><br><span>completely accurate. The reduced delete latency will</span><br><span>allow the dbench process to proceed to the fsync point</span><br><span>faster, then if our fsync is reasonably efficient (not the</span><br><span>case today, but planned) we may still see an overall</span><br><span>speedup.</span><br></div></blockquote><div><br></div>Ages ago, before we implemented extents for ext3, we had an asynchronous unlink/truncate-to-zero thread that was handing the busywork of traversing the indirect tree and updating all of the bitmaps.<div><br></div><div>This was transactionally safe, since the blocks were moved over to a temporary inode in the main process' transaction, and the unlinked inode was on the orphan list.</div><div><br></div><div>With the extent-mapped inodes the latency of the unlink/truncate-to-zero was greatly reduced, and we dropped that code. If anyone is interested to revive this for some reason, the newest version I could find was for 2.4.24:</div><div><br></div><div><a href="http://git.whamcloud.com/?p=fs/lustre-release.git;a=blob_plain;f=lustre/kernel_patches/patches/ext3-delete_thread-2.4.24.patch;hb=21420e6d66eaaf8de0342beab266460c207c054d">http://git.whamcloud.com/?p=fs/lustre-release.git;a=blob_plain;f=lustre/kernel_patches/patches/ext3-delete_thread-2.4.24.patch;hb=21420e6d66eaaf8de0342beab266460c207c054d</a></div><div><br></div><div>IIRC, it only pushed unlink/truncate to the thread if it had indirect blocks, since the effort of allocating a separate inode and transferring over the allocated blocks wasn't worthwhile otherwise.</div><div><br></div><div>Cheers, Andreas</div></body></html>