hi Ted: thanks for the suggest. finally added O_SYNC to open solved the issue. we are checking the storage setting. Br kassey On Fri, Aug 3, 2018 at 11:09 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > On Fri, Aug 03, 2018 at 06:15:48PM +0800, Kassey wrote: >> hi linux-ext4 team: >> >> we got a easy reproduced issue that during OTA, the storage is Samsung UFS. >> we will extract the updated file to DDR firstly(buffer_from_ddr)... >> >> but we found some of the files is corrupted sometimes. >> we compared the success and failure found that below pattern f30a >> EXT4_EXT_MAGIC >> were in the failure file data block. >> >> which should be expected to in inode table extent info. >> > > The way OTA (Over the air) update works is that it "patches" the file > system. Specifically, userspace (a program in the recovery partition) > is directly updating the file system at the block level. > > The OTA data file is calculated by looking at the starting file system > image, and the destination file system image, comparing the two, and > then creating a "delta" file which is what is actually sent over the > air. > > What you are seeing could be caused by: > > *) A bug in the program which generates the OTA file > > *) A bug in the program which uses the OTA file to update file systems > > *) The OTA file getting corrupted > > *) The starting file system image is different from what is expected; > that is, it is different from the starting file system image used > when generating the OTA file. > >> do you have some debug suggest to check how a extent looks like >> info write to a ext4 file data block ? > > A file data block can look like *anything*, including the header of > extent data block. For example, if you create a file system image, > e.g: > > mke2fs -t ext4 test.img 8M > > The file system that contains test.img will, by *definition* contain > blocks that look like extent data blocks; in fact, they *are* extent > data blocks, but not for the file system where test.img is stored, but > in the test.img file system itself. > > Furthermore, the program which applies the OTA update has no idea > whether a particular block it is updating is file data block. It > simply doesn't have that context. The OTA update system is also not > something which is maintained by the upstream ext4 developers (which > is who you have contacted when you e-mailed linux-ext4@xxxxxxxxxxxxxxx). > > So I'm afraid we can't help you behind giving you a general > explanation of how OTA works (and this is only something I know > because I've worked with the Android team). I would check to see > whether you are properly configuring and creating OTA updates, as well > as checking whether Samsung made many local changes to the OTA update > system. > > Best regards, > > - Ted -- Best regards Kassey
