Comment 15 for bug 1430620

After 1 week of usage, my gnome-terminals have written a total of 48 MB. Out of this, about 40 MB was cating my favorite test file 4 times for speed measurement purposes, and the remaining about 8 MB was the normal tasks I performed, including management of several remote servers via ssh, compilation of several applications over and over again, and a complete dist-upgrade to Vivid alpha (not in screen as it's done by default, but actually writing to the terminal's scrollback) and dist-upgrading again a few times.

Assuming 75 TB lifetime as mentioned in comment 3 (which is about 1/10 of the actual lifetime measured in this stress-test: http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead), I would have to keep this usage pattern for 30 years and then it'd cause 0.1% of the SSD wear-out.

Of course your usage patterns might differ significantly and result in magnitudes higher numbers; let me know if that's the case.

Note: resizing with rewrapping is an issue, if you do it with a large scrollback then it produces a lot of output, it writes quicker than upon normal operation. This might be a concern; a workaround could be to disable rewrapping on resize, using a relatively small scrollback buffer, or disabling opaque resize in the WM. (The data is in the ballpark of 5–10 bytes per line on each resize, i.e. probably less than 1 MB if you have 100.000 lines. The real problem is that most WMs send many resize events during a manual resize.)

In the mean time, I've done a proof of concept in the upstream bug to store the scrollback in memory, and I'm planning to make it a mainstream feature.