Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 15:50:57 +0200	[thread overview]
Message-ID: <1204811457.23706.49.camel@sauron> (raw)
In-Reply-To: <bae050c10803060539y16c65e26o181ef7b26ce008cf@mail.gmail.com>

On Thu, 2008-03-06 at 21:39 +0800, Nancy wrote:
>    Yes, but in FTL layer, it don't know whether the old mapped LEB is
> useful or not until
> the new mapped LEB which data stored in a write_cache have to be write
> to PEB. The
> write_cache maybe full filled with new data or just a little new data,
> others have to be read from the old mapped PEB

Ok, probably I understand what you are talking about. If you have a huge
file, and you remove it, the file-system does few changes in meta-data,
and that's it. Right, FTL does not know that the FS blocks the contents
of the file are stored at, are now in fact obsolete.

But UBI in now way can help you to solve this problem. How could it?
Invent an interface which would help.

The only way to go is to teach the FS which sits on top of you to inform
you about all blocks which become free when something is deleted. But
the existing FSes do not do this. An yes, this means you'll move garbage
all over the place, which is slow.

This is why we started UBIFS instead of doing FTL - because we assumed a
native FS should be significantly more efficient then FTL.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

  reply	other threads:[~2008-03-06 13: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
2008-03-06 13:39   ` Nancy
2008-03-06 13:50     ` Artem Bityutskiy [this message]
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=1204811457.23706.49.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