luiz_siam

Hi Bruna,
 
I'm using EXT4. According to my research (but I'm not an expert to be completely sure) good quality cards already do wear leveling internally and so it is kind of hard to wear out the memory. 
 
See this topic, for example: http://electronics.stackexchange.com/questions/27619/is-it-true-that-a-sd-mmc-card-does-wear-levelling-with-its-own-controller
 
The hard part is to make sure you're buying authentic SD cards... here in Brazil I'm having some difficulties - the last approach we took was to contact Sandisk directly in order to have supplier references and increase our chances to get original Sandisk or Kingstom ones. I've checked few we bought on Brazilian's ebay like site and they were not original (I could corrupt them in the first power loss try or even before!) This page helped me a lot on testing SD cards: http://www.bunniestudios.com/blog/?page_id=1022(but there is no 100% method).
 
Regards
Luiz

Hello Luiz!
 
Thank you for sharing, we were facing the same problems here and recently we decide to change to SD card. Our idea is to create 3 partitions: 1 read only, 1 "data" partition and 1 backup partition, but we are concern about the maximum write cycles. So we thought about using a different filesystem, like JFFS2 or UBIFS rather than EXT2/3/4, even we knowing that they aren't meant for block devices. Did you try somenthing like this ? What do you think about it ?
 
Thanks
 
Bruna

Hello guys,
 
This is not a question, but a feedback I think may be useful for some.
 
I have a cubieboard 2 server application using Igor's armbian running for 8 months in several places (~40 installations). In my application:
 
The OS in installed on NAND Armbian 3.8 + wheezy + kernel 3.4.107 There is a postgresql instance running, writing approx. 25kB/s average (not constant) Ordered data mode journaling on From time to time I've problems on clients with system corruption (not only the database, but the whole filesystem - sometimes I couldn't event boot the cubieboard anymore, had several kernel panics and more weird stuff like thousands of filesystem errors at once on fsck). Problems usually (but not always) appear after unclean shutdowns, due to power loss.
 
Recently I've decided to give a try and test the system running on the SD card. For my surprise, it is working smoothly without corruptions!. I've now created a read-only partition for the system and isolated the database, logs and other stuff (tomcat, /var/*, among others) on a "data" partition. I've conducted a test here with "pseudo-aleatory" automatic power downs during the system regular operation - I could turn it down (uncleanly) more than 200 times on different moments without problems, even on the database.
 
I'm not sure if moving to the SD card is the key point here (or the ro only partition + armbian 4.7 + jessie + kernel 3.4.110), but as I've seen other threads in other forums questioning the NAND drivers and physical bus routing on cubieboard2, I think it will be nice to share my experience and recommend users with heavier read-write requirements not to use the cubieboard 2 NAND!
 
If any of you had similar (or completely different) experiences, please share - I'm curious to have feedback and maybe reach a definitive answer about the problems I've been experiencing here (which costs a lot of money to us on tech support calls). Now, on SD card, it is rock solid - I couldn't break the system, even trying it hard!
 
Thanks
Luiz
 
 
 
 

Hello, I agree with you folks. My NAND also on cubieboard2 is not reliable. I had so many file corruptions and re-installed so many times so many debian on it without being able to have a stable OS. I will never install any OS again on NAND.
SD Card or SATA is a much better choice.

My experience with cubietruck is that after 6 months of fulltime use with the OS installed into nand resulting in wrong file's md5, continuous db corruption and filesystem corruption (continuous = everyday) without any crash or cold reset that could explain those errors.... after the 4th complete OS install from scratch, for me the nand is a DEAD END.
Since that choice, my CT is running perfectly using only the sd card since a year.

I'm not saying that there are no problems in NAND kernel driver, but when I used rootfs on NAND on cubietruck, I don't remember any major filesystem problems even after unclean shutdowns.

I don't know what mounting options for rootfs were used in Armbian 3.8, but if they were data=writeback,commit=600, then it may be the main cause for the issues - these are performance optimizations that can cause FS corruption on unclean shutdowns.
From ext4 kernel doc
 

Hello,
 
I'm running armbian on the cubieboard 2 and have noticed something that might be an unexpected behavior: when running on NAND, the nand2 partition is mounted with ordered data mode (despite the fstab configuration)! It looks like the system tries to remount the partition in writeback data mode, but it is not allowed to, according to the following messages:
 
root@siamserver:~# dmesg | grep EXT4 [   12.504386] EXT4-fs (nand2): mounted filesystem with ordered data mode. Opts: (null) [   17.557900] EXT4-fs (nand2): Cannot change data mode on remount [   17.604119] EXT4-fs (nand2): Cannot change data mode on remount   As the official cubieboard 2 download page states the writeback mode as a performance tweak and the fstab states that the /dev/nand2 partition should be mounted with writeback mode, I'm not sure if this is the default behavior or if this is happening only here.   Another important thing I've noticed: if running on SD card, the partition is really running on writeback mode! And the same fstab is used (the script just changes the mmc string to nand2)   As my intention is to have the system safe after unexpected power failures I'm good with this option (despite some corruptions from time to time), however I just want to make sure that everything is fine here and, most importantly, that my partition is really being mounted in ordered data mode (as obvious as it may sound)     Regards