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 _______________________________________________ Voyage-linux mailing list [email protected] http://list.voyage.hk/mailman/listinfo/voyage-linux
