Bug reported to upstream maintainer.

Looks like /tmp should be a tmpfs filesystem too to save flash writes.

Sorry correction to previous comment. Bug amended to show problem of writing to
flash rather than tmpfs, looks to apply to /var/run only. 

Suggestion to solve, either link /var/run to /tmp using tmpfs filesystem or
create a tmpfs mountpoint for /var/run, like used on Ubuntu 6.06, varrun on
/var/run type tmpfs (rw)

Upsteream maintainer has reported that this is intentional in order to save
system RAM.
For now, this isn't considered as a bug, so marking as INVALID.
Thanks for your feedback!

Comment 5 Frantisek Dufka 2006-08-05 14:31:13 UTC

Is there some specific system software that makes relatively big files in
/var/run  when compared to /tmp which is mounted as tmpfs too and contains more
files than /var/run? Otherwise it is a bit strange to have /tmp as tmpfs and
/var/run not. IMO /tmp is more typical to have big temporary files as many unix
commands create files there via mk*temp family of standard libc routines. 

There is a lot of .pid files in /tmp. Maybe it is a bug to have some pid files
in /tmp and some in /var/run? If /var/run remains in flash can at least all
those 4 byte pid files and other temporary stuff go from /var/run to /tmp?

Anyway, it really looks intentional and there is easy 'fix' for those who want
to have /var/run as tmpfs - uncomment one line in /etc/init.d/minircS. Do not
symlink /var/run to /tmp as it was in IT2005 unless you first remove 'rm -rf
/var/run/*' from minircS near the commented /var/run tmpfs mount.

BTW as for flash wear there is another file - /etc/mtab which gets rewritten
frequently - each boot and each mount command (card insert/eject) any way how to
solve this?

I reopened this bug to get answer to first question but feel free to close it again.

(In reply to comment #5)
> There is a lot of .pid files in /tmp. Maybe it is a bug to have some pid files
> in /tmp and some in /var/run? If /var/run remains in flash can at least all
> those 4 byte pid files and other temporary stuff go from /var/run to /tmp?

While AF_PID_DIR etc. should not point to /tmp, this is really a minor issue 

> BTW as for flash wear there is another file - /etc/mtab which gets rewritten
> frequently - each boot and each mount command (card insert/eject) any way how to
> solve this?

jffs2 distributes the write cycles quite well. Each tmpfs mount consumes atleast
100K RAM and symlinking /var/tmp to /tmp has it's own problems. Flash wearing
has been considered as a smaller problem than chronic lack of memory.

Thank you for your attention on this. I've re-opened as I'd like to comment on 
the point of tmpfs and flash wearing. Apologies, but not knowing who at Nokia 
is involved, I figured this is the best way to feedback.  
 
I can fully understand Nokia not using tmpfs for /var reduces RAM and this 
technically solves one problem, but isn't this creating a new  problem? I 
question it because other embedded Linux using jffs2 felt it necessary to 
reduce flash wear and have both /tmp and /var in ram, for example OpenZaurus. 
 
I would be interested to know, for peace of mind, what kind of wear would occur 
if you assume no user writes, and simply using the 770 daily with the OS 
writing to flash. Does this seriously limit the 770 life, how many years?  
 
I'm being cynical here, but I can imagine Nokia are not worried about it, 
because the flash might wear out after the warranty. Though for me as a 
consumer this issue is as important as having sufficient RAM, probably more so, 
if the product doesn't last.  
 
Although clunky, maybe using a swap file on the MMC could also 
adapt /etc/init.d/minircS to use ram for certain directories like /var and 
minimise this issue for those users with a MMC? 
 
Anyway I hope you don't mind, I hope in some way this is useful feedback! Thank 
you for reading. 
 
Kind regards 
Richard

(In reply to comment #7)
> Thank you for your attention on this. I've re-opened as I'd like to comment on 
> the point of tmpfs and flash wearing. Apologies, but not knowing who at Nokia 
> is involved, I figured this is the best way to feedback.  

No problem. I will forward these questions to the developers. According to
hardware people, the memory is specified for 100k write/erase cycles. Quote from
the memory chip specification;

"The on-chip write controller automates all program and erase functions
including pulse repetition, where required, and internal verification and
margining of data. Even the write-intensive systems can take advantage of the
K9F1G08R0A′s extended reliability of 100K program/erase cycles by providing
ECC(Error Correcting Code) with real time mapping-out algorithm."

http://www.samsung.com/products/semiconductor/NANDFlash/SLC_LargeBlock/1Gbit/K9F1G08R0A/K9F1G08R0A.htm

> I would be interested to know, for peace of mind, what kind of wear would occur 
> if you assume no user writes, and simply using the 770 daily with the OS 
> writing to flash. Does this seriously limit the 770 life, how many years?  

It is difficult to give estimate on this. It would require to find out the use
cases, then take jffs2 wear leveling into account.

I received additional information about this. Quote;

JFFS2 uses wear leveling which makes the whole flash partition to wear
out uniformly. The garbage collector rotates also those erase blocks
which contain static data like libraries and binaries.

Each erase block can be written and erased 100 000 times.  It is not
a hard limit after which the erase block breaks, but rather a point after 
which the erase blocks will start to show correctable single bit errors. 
With error check and correction, the erase blocks are likely to last
1 million write-erase cycles.

Root partition size is 129499136 bytes. If you write this much of random
(uncompressible) data 100 000 times, it would be about 12 terabytes.
With wear leveling, each erase block on the root partition would then be 
written and erased 100k times and flash driver might start seeing 
correctable single bit flips here and there.

The write speed of uncompressible random data is not constant on
JFFS2 but varies because to garbage collection. Without the
garbage collection, about 1.2MB/s write speed is seen. In continuos 
writing (like overwriting the same file over and over again) the write
speed is roughly halved. It would take about 200 days of continous 
uninterrubtale writing at 700kB/s (or 56GB/day) to achieve 12TB.

In the normal usage the device is not written all the time and daily
data amounts are several orders of magnitudes smaller than in the
maximume wear speed.  Even if one would write 1GB per day, the device 
would last over 30 years.

Comment 10 Eero Tamminen 2007-08-10 16:46:36 UTC

In latest N800 release /var/run is linked to /tmp/.run to improve
bootup time (when jffs2 has lot of GCing to do in bootup, it's
bad to write to it).

Comment 11 Eero Tamminen 2007-09-26 14:02:06 UTC

This should have been set fixed when the latest release got out...

https://garage.maemo.org/tracker/index.php?func=detail&aid=1214&group_id=164&atid=681