> As a caveat, desktop distros can be rough on flash (re: SD) cards.
i wouldn't call fedora for arm a desktop distro, it's pretty sparse;
(but not busybox sparse). the feature is you have the ability of
installing
whatever rpms you want.
That's definitely a benefit. Buildroot offers RPM support but I haven't
tried it yet.
i also haven't seen hard evidence for the 'flash is delicate' idea.
i suspect urban myth. wear leveling alorithms are many years mature now.
I got it from a number of places when writing a proposal for an SD/SSD
based system for the government. One place that spells it out plainly
(without backup references, however) is on D. Woodhouse's site for the
Linux-MTD support:
Last entry discusses the differences between block and flash devices
with respect to wear out times. Information appears to be from early
2009. Not sure if things have changed much since then.
> Swapping is likely to happen often
this applies to any bb/distro where you need more memory than you have;
not
just fedora.
Not picking on Fedora (it's the only distro I use on desktops - really
don't like Ubuntu as a developer). But desktop distros are general
purpose and have lots of utilities running that are not required for
most embedded products.
whatever your application, if you have insufficient memory
then you have to consider swap. same for all distros.
True, but only to a point. An embedded distro is (at least to this
point in history) more likely to run without swap because it doesn't
have long term storage (the SD card is a relatively recent feature in
the grand scheme of things). If you build a system that has but one
purpose - an alarm system, a set top box, a mobile recorder, etc. - you
can avoid swap. Also, swap is slower than running from memory.
Embedded systems tend to lean toward snappy response by intent. General
purpose distros lean toward full user experience, and can trade off
responsiveness if needed.
Note that one of the first thing CONFIG_PREEMPT_RT suggests is to avoid
swapping in applications by calling mlocakall() (see
RT PREEMPT HOWTO - RTwiki). If you want snappy response in your RT embedded box, you don't swap.
we could set up a little contest to see if fedora writes more than
other distros. that would be fun...
Doubt there is much difference. Many of them provide common system
features running as daemons, such as system logging (which generates
lots of writes). System logging might be different between distros and
that could affect the number of writes each does, I suppose.
> and excessive writes will wear the SD
> card faster than it would a hard disk.
i would love to see some hard numbers.
Again, start with David Woodhouse's info. He gives a rough estimate of
10^3 writes for MLC NAND and 10^5 writes for SLC NAND. Don't know which
type SD's use but I think it's SLC.
> You can disable swap and use a
> tmpfs filesystem for temporary writes (like /tmp, /etc/resolv.conf,
> and /var) to reduce wear on the flash card.
i still think this is distro independent. it depends on what apps/rpms
are installed. and those tend to be identical between distros.
Identical between desktop distros. Not between general purpose distros
and embedded platform distros.
resolv.conf?
DHCP on boot of an embedded device updates resolv.conf. A single write
to the SD card that can update far more of the card (due to erase/write
sizes in flash) than is necessary considering what is being updated.
Not to mention that resolv.conf doesn't need to be stored between boots
since DHCP will just update it the next time the board boots.
If you have a static network configuration then this isn't an issue.
i would need some hard data before i worried about this. the specs for
the cards say otherwise.
Maybe they've gotten better recently. Still, given they way they
function, they have a shelf life that is measurable and significantly
less than what is measurable for hard drives. And it's not particularly
hard to work around that in the boot sequence.
here's a test someone did 2 years ago.
http://www.bress.net/blog/archives/114-How-Long-Does-a-Flash-Drive-Last.html
Nicely done.
doesn't go far enough though.
he didn't try to repair the filesystem (or didn't report it).
i wonder if fsck and badblocks would resurrect writability for the
drive?
As Woodhouse says: Bad eraseblocks are not hidden and should be dealt
with in software
There is nothing the flash device does to help with bad blocks. That
support comes from higher level chip and/or software support.
i also don't think TRIM support was in the extfs code back then.
(trim tells the flash device that certain blocks no longer have
useful data on them so it is free to use them as destinations for
wear leveling).
Wear leveling helps, but it is a mitigator of the issue, not a
resolution. The fact remains that NAND flash operates differently than
a hard disk and in such a way that the lifespan of the flash is less
than the disk.
i have a small pile of class 2 2G flash cards now. i should try to
destroy one.
I do so many rootfs dd's to mine right now I keep expecting it to puke.
They last longer than I expected. If it lasts longer than 6 months I'll
be pleasantly surprised. But 6 months is not sufficient for an embedded
consumer device. It needs to run for years without failure and excess
writing to an SD card may make that problematic. Since it's an easy
issue to work around in the distro, there is no reason not to do so.
Of course all this is dependent on the target application of the device.
If you're building the world's tiniest, lowest power, mobile desktop,
then a desktop distro is probably what you want. If you're building an
application specific device like a set top box, then you probably want a
custom distro.
