From: Artem Bityutskiy <dedekind@infradead.org>
To: Nancy <nancydreaming@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI: question about ubi_leb_change
Date: Thu, 06 Mar 2008 14:50:35 +0200 [thread overview]
Message-ID: <1204807835.23706.38.camel@sauron> (raw)
In-Reply-To: <bae050c10803060426l2b90f9e2n4a0cd3e0dd1c4d19@mail.gmail.com>
Hi,
On Thu, 2008-03-06 at 20:26 +0800, Nancy wrote:
> Hi,
> As I know, ubi_leb_change only accept a whole LEB data as one of
> its parameter.
Correct.
> If file system modify a little data which in a old mapped LEB, it
> needs to read the whole old mapped LEB data in its buffer first, then
> do the little modification, finally deliver to ubi_leb_change? Is
> that right?
This is what can be done. But file systems should not normally do this,
because it is inefficient. It is more efficient to do out-of-place
updates, which means writing data to somewhere else (a free LEB), and
treat the older data as obsolete. This is what JFFS2 and UBIFS do.
UBIFS does use the in-place update method you have described, but very
rarely. It uses it only when the FS is nearly full, and only as
last-resort method of updating the FS index, when out-of-place updates
are impossible.
> when remove files, there's only inodes .....some file system meta
> data changed,
> but the real file data still exist which means the LEB still mapped.
> Then when you write new data to this very LEB( but contains only
> trash), maybe this time, your new data is a whole LEB size. Still
> goes the process: read the mapped LEB old data to buffer, replace
> the old data with the new one in buffer, deliver to ubi_leb_change?
> Really like that?
If you have an LEB, and the contents of LEB is not needed, you should
just unmap it and write your new data. No need to read it.
> If the answer is yes, in this situation, waste a
> whole block reading time. Maybe UBIFS does not do this.
Of course UBIFS does not do it - it would be slow if it did :-)
> But FTL on UBI will face this problem. And there's no suitable
> UBI API for that needs.
> It need : old_pnum = ubi_leb_unmap( ); but do not erase the mapped PEB
> new_pnum = ubi_leb_map( );
> ubi_read_peb( old_pnum,.....) just like
> ubi_read_leb function
> ubi_srub_peb( old_pnum ,....)
>
> the write_cache in FTL layer only store changed data, when flush it to
> Nand flash
> it call " flush_write_cache" function
> void flush_write_cache(.......){
> fill_write_cache(......);
> ubi_leb_change(......);
> .....
> }
> fill_write_cache() will call ubi_read_peb() to fill write_cache with
> needed pages which come from the PEB(old_pnum)
I do not really get it what you meant. There are many ways to create an
FTL, and I do not know which one you choose. I suggested a simple one
here:
http://lists.infradead.org/pipermail/linux-mtd/2008-January/020381.html
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2008-03-06 12:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-06 12:26 UBI: question about ubi_leb_change Nancy
2008-03-06 12:50 ` Artem Bityutskiy [this message]
2008-03-06 13:39 ` Nancy
2008-03-06 13:50 ` Artem Bityutskiy
2008-03-06 14:14 ` Nancy
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=1204807835.23706.38.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox