In-Reply-To:ubifs, ubiblk(formatted with vfat) and yaffs2 test

[Nancy]

Hi,
    Thank you for sharing your test report!
    For ubiblk,  cp; sync;  is not enough, cause ubiblk hold back a LEB
in ram until another logical block number LEB wants to use the
writecache(in ubiblk) or an block device layer "release" call will
drive the LEB in writecache to be written on Nand Flash.
    For FAT, when it write some files, usually, it modify FAT table
first, then goes the file contends, finally still need to change
something in FAT table or whatever it is which belongs to the
Filesystem meta data. That means, the last LEB hold back in ram
contains the most important data (filesystem meta data). If there
comes unclean reboot. That may lost lots of data. Though UBI tolerant
unclean reboot. In this case, you should use tool "dosfsck
/dev/ubiblockN -a" before you mount ubiblock again. And see what you
have lost!
    To be safe, you should do : cp...; sync; flushcache /dev/ubiblockN
    I'm not sure block device layer's Ioctl "BLKFLSBUF" use in this
way. Is there any command like sync, not just sync the buffer cache,
but also the buffer in dirver layer( call that ioctl :-)

/* flushcache.c  */
#include <sys/ioctl.h>
#include <linux/fs.h>
#include <fcntl.h>
#include <stdio.h>

int main(int argc,char **argv)
{
       int fd;

       if( argc != 2 ){
               printf( "Usage:%s device name(full path)\n", argv[0] );
               return -1;
       }

       if( (fd = open( argv[1], O_RDONLY ) ) == -1) {
               printf( "Open %s failed\n", argv[1] );
               return -1;
       }

       if( ioctl( fd, BLKFLSBUF) == -1)
               printf("flush catche failed\n");

       close(fd);
       return 0;
}

-- 
Best wishes,
Nancy