From: Artem Bityutskiy <dedekind@infradead.org>
To: Nancy <nancydreaming@gmail.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: ubifs, ubiblk(formatted with vfat) and yaffs2 test
Date: Mon, 02 Jun 2008 09:18:17 +0300 [thread overview]
Message-ID: <1212387497.31023.172.camel@sauron> (raw)
In-Reply-To: <bae050c10806012229n78668cf3rf71c44bd396a7fba@mail.gmail.com>
[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.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2008-06-02 6:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-02 5:29 References:ubifs, ubiblk(formatted with vfat) and yaffs2 test Nancy
2008-06-02 6:18 ` Artem Bityutskiy [this message]
2008-06-02 6:47 ` ubifs, " Nancy
[not found] <bae050c10806012138p6167f30eu9450563efa5429ab@mail.gmail.com>
2008-06-02 5:55 ` KeunO Park
2008-06-02 6:06 ` Nancy
[not found] <5ed5c4730805291914h187e0b0et2de31d595b52f125@mail.gmail.com>
2008-05-30 15:17 ` KeunO Park
-- strict thread matches above, loose matches on Subject: below --
2008-05-30 6:01 KeunO Park
2008-05-30 6:33 ` Artem Bityutskiy
2008-05-30 7:15 ` KeunO Park
2008-05-30 11:34 ` Josh Boyer
2008-05-30 12:51 ` KeunO Park
2008-05-30 12:02 ` Artem Bityutskiy
2008-05-30 12:05 ` Artem Bityutskiy
2008-05-30 13:00 ` KeunO Park
2008-05-30 13:49 ` Artem Bityutskiy
2008-05-30 15:08 ` KeunO Park
2008-06-02 6:10 ` Artem Bityutskiy
2008-06-04 4:06 ` KeunO Park
2008-06-04 8:05 ` Artem Bityutskiy
2008-10-24 11:41 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1212387497.31023.172.camel@sauron \
--to=dedekind@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=nancydreaming@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.