@roswellgrey Thank you for contributing some concrete information to the discussion.
Your test file has prompted me to revisit this issue and I spent a few hours reading up on the current situation and checking it out on a long running Pi here.
I now have two large text files filled with commands and data, but I suspect this would be far too technical to post here.
So ... for those of you who are not Linux experts, I will try to formulate a short version.
On a RasPi the Operating System and all the user files and log files are stored on a small, cheap SD Flash memory card plugged into the mmc controller.
Flash memory is written in blocks of 512 bytes
SSD Flash drives are fast, expensive and use 'dynamic wear levelling' to spread the writes out evenly and maximise the useful life of the flash cells.
SD cards are cheap, slow and some have no wear Levelling at all, most implement 'static wear levelling' via proprietary algorithms embedded in the controller on the card.
This Flash Translation Layer is opaque and cannot be directly observed or interacted with.
They have a 'write pool' of writable blocks and _if_ the OS can tell the controller that a block is no longer needed, it can be added back to the pool of available blocks, and thus be recirculated to help share out writes among flash blocks.
The Linux mmc driver can issue a TRIM command which tells the flash controller to erase a block, and thus add it back to the free pool.
Unfortunately this functionality of the mmc controller on the RasPi has been broken for years.
see: 'FStrim does not work on RPI'
http://www.raspberrypi.org/forums/viewtopic.php?f=71&t=47484root@raspberrypi:~# sudo fstrim -v /
fstrim: /: FITRIM ioctl failed: Operation not supported
TL;DR
1) Buy a (genuine) SanDisk Ultra SDHC card much bigger than you need.
2) DO NOT write a huge image file that fills up the whole partition, because every block that is written to is removed from the wear levelling pool.
INSTEAD copy the minimal OS image onto it, THEN expand the filesystem.
e.g. DD the <4 Gig image onto the card, then expand it to 8Gig.
If you bought a 16 Gig card that 'unused' space is not 'wasted' as it should be contributing to the wear levelling pool.
3) update to the latest kernel ('sudo aptitude update kernel')
root@raspberrypi:~# uname -a
Linux raspberrypi 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l GNU/Linux
And Broadcom binary blob. ('sudo aptitude update firmware-brcm80211')
root@raspberrypi:~# /opt/vc/bin/vcgencmd version
Sep 8 2014 19:02:48
Copyright (c) 2012 Broadcom
version 3f2f2607186be72e4945cfa8edc77872dfc73195 (clean) (release)
Enable the Newly Fixed TRIM
'The latest rpi-update kernel now includes a new MMC driver. This driver is completely rewritten'
http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=85061#root@raspberrypi:~# sudo fstrim -v /
/: 4681015296 bytes were trimmed
Automate the running of trim occasionally.
e.g.
Add this to your /etc/crontab
00 00 * * * root ionice -c 3 fstrim -v / | logger -t fstrim
For bonus points you could also reduce the wear from services which continually append to their log files -such as web server by e.g. installing ramlog:
http://www.tremende.com/ramlog/I also came across this handy service called backup2mail where you can have your Pi email a backup of your database:
http://www.backup2mail.com/So due to the magic of the Open Source development model, everything now should 'just work' as it is supposed to, and you didn't have to pay for the upgrade.