[Voyage-linux] LEDs, APT repository, MySQL in RAM questions

[Andreas Delleske]

Dear Jordi,

thank you for your friendly reply!

> We use adjtimex + ntpd in order to have a ALIX3D2 synchronized. I
> wrote how we configured it in
> http://code.google.com/p/wfrog/wiki/InstallOn_Alix3D2_voyageLinux0_6_2#Clock_sync

Thanks, I've found that page already.. :-)

I found out that I could install adjtimex package as soon as I changed
the apt-sources to the german server..

Now the only buggy package that I need is ssmtp (smtp forwarder to a
smarthost), but i works when ignoring errors when installing.

> I set up a read-write partition for the database and write a record
> each 5 min. So far the ALIX 3 D 2 with a 1Gb SLC Compact Flash has
> been working for half a year perfectly. We'll have to wait a couple of
> years to know how long the CF last!!!

Yes..

If we think about wear leveling, there is a lot of options:

Here, we will have only tens to hundreds of write updates per day, not
thousands, and I have 4 GByte Flash memory, only 400 MB of which are
used so far. The part where the changes appear (the database) is only
3 MB now and will 10 MB in some years.

If we assume that every change rewrites 100 kByte (much less in the
database's data, but with every update one or three flash blocks have
to be rewritten..) we rewrite max. 10 MB per day = 3,65 GBytes per
year - within one year, the free space on that disk is rewritten only
once (statistically)  that is, if we have a proper wear-leveling
algorithm.  If every flash block can be rewritten only 10.000 times,
can we think of 10.000 years? I think that would be enough. :-) Or did
I go wrong?

Does th CF card "know" which blocks are free and use them
automatically with a round-robin-method? If the CF knows nothing about
filesystems, it would be much less: Assume we write always in the same
10 MB, the CF will last 10.000 days = 27,3 years. Shouldnt even that
be enough?

I see that if we have one small table in the DB which gets rewritten
always in the same spot, things get worse: 10.000 operations would be
accomplished after only a hundred days... maybe it is crucial to put
only that table in RAM and let the rest of the database grow slowly
without any concern?

However, it would be great to be able to check the "sanity" of the
CF-disk like with the smartmontools and in some years just swap the
disk (they are inexpensive anyway).

Or we could move that table from time to time to another location on
the flash ("Manual" wear-leveling)? Lets say we create a copy of the
full database every day and leave to old copy unattended until the
free space is filled up so with every update a new spot is used? Then,
with 3,5 GByte free space divided by 10 MByte a day we'd fill the disk
within a year - but could we redo that 10.000 times? That would be
enough as well.

-- 
Kind regards
Andreas