<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Analyzing IO Amplification in Linux File Systems · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1707.08514/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/1707.08514/feed.xml" rel="self" type="application/rss+xml" /><item><title>Analyzing IO Amplification in Linux File Systems — mentioned by kasabali</title><link>https://news.ycombinator.com/item?id=22854585</link><guid isPermaLink="false">urn:hackerpapers:mention:1707.08514:22854585</guid><pubDate>Mon, 13 Apr 2020 10:32:59 GMT</pubDate><description>&lt;p&gt;Have a look at this paper [0] While there are big gaps of write amplification for metadata writes, on macro benchmarks all filesystems have similar results. btrfs has the biggest WAF, but you can enable compression globally and I suspect that difference alone will make it come ahead of others. [0] Analyzing IO Amplification in Linux File Systems https://arxiv.org/abs/1707.08514&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1707.08514/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.OS</category></item><item><title>Analyzing IO Amplification in Linux File Systems — mentioned by cmurf</title><link>https://news.ycombinator.com/item?id=22773187</link><guid isPermaLink="false">urn:hackerpapers:mention:1707.08514:22773187</guid><pubDate>Fri, 03 Apr 2020 19:35:31 GMT</pubDate><description>&lt;p&gt;Ext3, ext4, and XFS have a journal that&amp;#x27;s constantly being overwritten. On Btrfs, the file system is the journal. It does have a bit of a wandering trees problem [1], where F2FS expressly intends to reduce the wandering tree problem.[2] There&amp;#x27;s also different approaches that don&amp;#x27;t involve filesystems [3]. But I think you have to assess the crash resistance and repairability of filesystems, not just worry about write amplification. I think there&amp;#x27;s too much made about SSD wear. The exception are the consumer class of SD Card and USB flash, those are junk to depend on for persistent usage, best…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1707.08514/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.OS</category></item><item><title>Analyzing IO Amplification in Linux File Systems — HN submission</title><link>https://news.ycombinator.com/item?id=19539630</link><guid isPermaLink="false">urn:hackerpapers:submission:1707.08514:19539630</guid><pubDate>Mon, 01 Apr 2019 01:16:46 GMT</pubDate><description>&lt;p&gt;Analyzing IO Amplification in Linux File Systems&lt;/p&gt;&lt;p&gt;&lt;/p&gt;&lt;p&gt;3 points; 0 discussion replies on HN. &lt;a href="https://hackerpaper.kaipfister.de/p/1707.08514/"&gt;Paper and source history&lt;/a&gt;. A submission is not an endorsement.&lt;/p&gt;</description><category>cs.OS</category></item></channel></rss>
