Hi, Fredrik, On Wed, 2012-11-14 at 11:41 +0100, Ohlsson, Fredrik (GE Healthcare, consultant) wrote: > 2. Empty files, size 0. Well, this is expected in some cases. If create a file, start appending data, and have a power cut, you may end up with zero-sized files. This is a Linux feature - the data is cached in RAM until write-back happens or something like fsync() happens. Ext4 has a feature that if you write to a file, then close it, ext4 will initiate write-back for you right away. It was added a couple of years ago to make it more user-friendly. You really should investigate what are those files and what was happening to them just before the power cut. Zero-length files may be normal, in general. However, strictly _all_ files you care about should be explicitly synced. This is just safer. If you write serious medical software, you should take data integrity seriously in your apps. I wrote this section for UBIFS users long time ago, and it is the same (modulo UBIFS-specific details) for other Linux file-systems, including ext4: http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writeback http://www.linux-mtd.infradead.org/doc/ubifs.html#L_sync_exceptions > Is ext4 a bad choice for an embedded system with I 1Gb IDE Flash Disk and Debian 2.6.32-5-686? Should we change filesystem? I do not know for sure, but I doubt there is serious power-cut testing regularly conducted for ext4, but people may correct me. So if power-cut tolerance is important for you, you should conduct good power-cut tests. And remember, the disk quality is very important for power-cut-tolerance. If you uses something like bad managed flash (bad SSD, eMMC), it may lose recently written data on power-cut. So testing is important. Of course you should have barriers on as well. We conducted some 3 years ago. Results were quite good for ext4 - in many cases it could recover without a need to run ckfs.ext4, sometimes it was not mountable, but ckfs.ext4 helped. On the opposite, ext3 constantly required ckfs.ext3, and sometimes died so badly that even ckfs.ext3 could not recover it. -- Best Regards, Artem Bityutskiy
Attachment:
signature.asc
Description: This is a digitally signed message part