I&#x27;m going to guess that the Pi uses ext3&#x2F;4 which I&#x27;m assuming does pretty well with appending files on a spinning disk.<p>Yes, we need something tailored for flash and the advent of SSDs have put some effort into that. However, the controller of a SD-card is for understandable reasons not as advanced as one on an SSD. One of the issues that seemed prevalent of the Pi was that SD-cards, when issuing a TRIM command, just erases the flash - immediately. Which of course kind of defeats the purpose and leads to bad performance (trying to optimize for future writes by sacrificing current writes).<p>The recommendation that I saw was to schedule a pass clearing free space for when the Pi wasn&#x27;t in active use.<p>Problem with the controller doing some of the stuff (which I guess is inevitable due to different design needs) and the file system doing some other stuff is that when the filesystem is paired with a bad controller (but one that still does some kind of wear leveling) you are kind of screwed anyway, because either implementation can not rely on the other. 
So, just use an SSD instead?<p>I guess it&#x27;s worse on the Pi since it&#x27;s somewhat trying to be a workstation on mobile hardware. And sometimes I get the impression that even phone makers can&#x27;t tailor it well anyway (samsungs android filesystem for the older phones were apparently pretty awful for instance). And android only got TRIM support in, I believe, Kitkat? But only if the whole chain of device hardware and drivers supported it (so god knows which current devices actually support it)... Learning that was quite shocking to me and probably a large source of &quot;my phone just keeps getting slower&quot; problems. But who cares if it just accelerates sales of new phones?