ariz Posted May 9, 2016 Posted May 9, 2016 Hi, What do you do to avoid the problem with zero size files or zeroes at the end after unclean reboot on cubie or another device with nand flash on extx filesystem ? Why do everyone use extx filesystems when its generate these problems ? a little description ... http://www.linux-mtd.infradead.org/faq/ubifs.html#L_empty_file http://www.linux-mtd.infradead.org/faq/ubifs.html#L_end_hole Thanks, ariz
zador.blood.stained Posted May 9, 2016 Posted May 9, 2016 Armbian by default mounts ext4 rootfs with "commit=600,data=writeback" options, which is optimized for performance and minimizing writes on flash media, but in the event of crash or unclean shutdown this may cause data loss. To shifs settings towards data integrity you may want to use "commit=5,data=ordered" mount options (you may have to also use tune2fs to remove "journal_data_writeback" option from default FS mount options depending on "age" of your image). Why do everyone use extx filesystems when its generate these problems ? And what FS should be used by default then? F2FS? Not an option for older kernels + no resize capabilities. BTRFS? Again, mainline is recommended for stability. And another thing - NAND implementation on allwinner devices sometimes can cause troubles by itself, regardless of filesystem it's formatted to.
tkaiser Posted May 9, 2016 Posted May 9, 2016 What do you do to avoid the problem with zero size files or zeroes at the end after unclean reboot Do clean reboots only? What's the purpose of unclean reboots if this causes troubles? If your board has stability issues why not thinking about fixing the problems first instead of exploring workarounds?
ariz Posted May 9, 2016 Author Posted May 9, 2016 And what FS should be used by default then? F2FS? Not an option for older kernels + no resize capabilities. BTRFS? Again, mainline is recommended for stability. And another thing - NAND implementation on allwinner devices sometimes can cause troubles by itself, regardless of filesystem it's formatted to. I know, its a big problem. I wonder it its possible to use jffs2 or ubifs?
ariz Posted May 9, 2016 Author Posted May 9, 2016 Do clean reboots only? What's the purpose of unclean reboots if this causes troubles? If your board has stability issues why not thinking about fixing the problems first instead of exploring workarounds? Sometimes You do not know when you will have no power, sometimes its not depend on You. Especially if you give your device to someone who does not understand any electronic devices. I give users cubie a20 and sometimes they don't have any UPS or another power backup.
tkaiser Posted May 9, 2016 Posted May 9, 2016 Sometimes You do not know when you will have no power, sometimes its not depend on You. Especially if you give your device to someone who does not understand any electronic devices. I give users cubie a20 and sometimes they don't have any UPS or another power backup. Well, then I would start with these measures: If it's Cubieboard2 then decrease DRAM clockspeed (for whatever reasons CB2 uses the highest speed possible and it's known that almost no A20 board works really reliable with 480MHz -- most reported problems are related to DRAM clock being too high --> bit flips will lead to all sorts of trouble). @Igor/@Zador: AFAIK something like DRAM reliability testing for Cubieboards has never happened. Decreasing DRAM clock in both fex and Cubieboard2_defconfig from 480MHz to eg. 400MHz might be an idea for future releases Don't use NAND but eMMC where possible Avoid boards that features AXP209 PMU but lack a battery connector If all of the above is no option then think about tweaking ext4 parameters as outlined by Zador Ext4 is a requirement for general purpose OS images (due to necessary filesystem resizing on 1st/2nd boot), it's really realible for most use cases (see page 3 here) and surprisingly it's also faster than alternatives that tried to address performance problems on flash media (F2FS for example).
ariz Posted May 13, 2016 Author Posted May 13, 2016 I did some research and some tests... I can confirm that f2fs is not stable, after mounting I had kernel oops. My friend successfully using btrfs but on ssd drives (no nand). I think I'll try it in near future. Also had some good news! Tests... After system start script generate 300 files in one new directory filled with some text and then restart after short sleep and sync. System was restarted over 50 times (over 15k files was generated). 1. After clean reboot all files where fine (no zero size files) 2. After unclean reboot (echo b >/proc/sysrq-trigger) there was different results depend on ext mount options a. commit=600,data=writeback and journal_data_writeback enebled zero size files was ~8-10% b. commit=5,data=ordered and journal_data_writeback disabled zero size files was ~3% 3. SOLUTION! after writing have to give echo 3 >/proc/sys/vm/drop_caches Of course it take same time to save all data (depends on the amount of data to write) but on that system it was less then one second. So, I my case I can use drop_caches after each write (I do not have them too many) or simply execute periodically.
zador.blood.stained Posted May 13, 2016 Posted May 13, 2016 3. SOLUTION! after writing have to give echo 3 >/proc/sys/vm/drop_caches In this case you can also try adding "sync" to mount options
ariz Posted May 13, 2016 Author Posted May 13, 2016 In this case you can also try adding "sync" to mount options Why didn't you said it before ? I think it works pretty well too. Regards.
Recommended Posts