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

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.

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?

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?

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.

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). 

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.

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

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.