ubifs, ubiblk(formatted with vfat) and yaffs2 test
dedekind at infradead.org
Mon Jun 2 02:18:17 EDT 2008
[Fixed abused mail subject]
On Mon, 2008-06-02 at 13:29 +0800, Nancy wrote:
> 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 :-)
Sorry, but these things are absolutely unacceptable and mean your
implementation is broken.
Artem Bityutskiy (Битюцкий Артём)
More information about the linux-mtd