All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Chmielewski <mangoo@wpkg.org>
To: Artem Bityutskiy <dedekind@yandex.ru>
Cc: LKML <linux-kernel@vger.kernel.org>,
	penberg@cs.helsinki.fi, "Jörn Engel" <joern@logfs.org>,
	ext-adrian.hunter@nokia.com, jwboyer@gmail.com, w@1wt.eu,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)
Date: Wed, 02 Apr 2008 16:17:25 +0200	[thread overview]
Message-ID: <47F39575.40006@wpkg.org> (raw)
In-Reply-To: <47F2071A.6010406@yandex.ru>

Artem Bityutskiy schrieb:
> Tomasz Chmielewski wrote:

(...)

>> Performance is only one factor in the equation. Other factors are: 
>> cost and reliability.
>>
>> I speak from experience: flash-based block devices tend to have poor 
>> wear-levelling (at least Transcend IDE-flash disks).
>> To reproduce:
>> - format a 2 GB Transcend IDE-flash disk with ext3
>> - write a small file (50-100 kB)
>> - update that file ~several hundred thousand times - as you finish, 
>> IDE-flash disk will have 200-300 badblocks
> Yeah, that's bad. But if you have a bad FTL, surely there is not guarantee
> a flash FS will help? Isn't it better to use better hardware?
> 
> We did some experiments with MMC cards and we were unable to wear them
> out with re-writing the same sectors again and again. This suggests there
> _is_ better FTL hardware then that USB stick you was using.
> 
> Anyway, your original mail said Logfs can work with block devices. My 
> answer -
> UBIFS too, but this is very strange to do this IMO. But OK, it might is not
> senseless, sorry for the wording. :-)

I was thinking why my IDE-flash disk died so soon[1] and how efficient 
can an internal wear-levelling be in devices which hide its "flashiness" 
(USB-sticks, IDE-flash disks etc.).

Internal wear-levelling mechanism doesn't have a clue about free space 
on the filesystem - it that case, how can it do any efficient 
wear-levelling?



[1] Well, it didn't die, really. Once I removed the file which was 
showing I/O errors and did "dd if=/dev/zero of=bigfile", there are no 
badblocks anymore - probably remapped.



-- 
Tomasz Chmielewski
http://wpkg.org

  reply	other threads:[~2008-04-02 14:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-01  8:02 UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system) Tomasz Chmielewski
2008-04-01  8:45 ` Artem Bityutskiy
2008-04-01  9:03   ` Jörn Engel
2008-04-01  9:09     ` Artem Bityutskiy
2008-04-01  9:31       ` Jörn Engel
2008-04-01  9:39   ` Tomasz Chmielewski
2008-04-01  9:57     ` Artem Bityutskiy
2008-04-02 14:17       ` Tomasz Chmielewski [this message]
2008-04-02 14:22         ` Jörn Engel
2008-04-01 11:06   ` Andi Kleen
2008-04-01 11:23     ` Artem Bityutskiy
2008-04-01 16:27       ` H. Peter Anvin
2008-04-01 21:26         ` Willy Tarreau
2008-04-02  4:47           ` Artem Bityutskiy
2008-04-02  6:25             ` Willy Tarreau
2008-04-02  7:17               ` Artem Bityutskiy
2008-04-09 21:09 ` Pavel Machek
2008-04-09 21:32   ` Jörn Engel
  -- strict thread matches above, loose matches on Subject: below --
2008-03-27 14:55 [RFC PATCH] UBIFS - new flash file system Artem Bityutskiy
2008-03-31 12:29 ` Jan Engelhardt
2008-03-31 12:47   ` Adrian Hunter
2008-03-31 13:20     ` Jörn Engel
2008-04-01  5:26       ` UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system) Artem Bityutskiy
2008-04-01  5:28         ` Artem Bityutskiy
2008-04-01  5:56         ` Artem Bityutskiy
2008-04-01  9:25           ` Jörn Engel
2008-04-01  9:39             ` Artem Bityutskiy
2008-04-01 10:51               ` Jörn Engel
2008-04-01 11:17                 ` Artem Bityutskiy
2008-04-01  9:19         ` Jörn Engel
2008-04-01  9:46           ` Artem Bityutskiy
2008-04-01 11:16             ` Jörn Engel

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=47F39575.40006@wpkg.org \
    --to=mangoo@wpkg.org \
    --cc=dedekind@yandex.ru \
    --cc=ext-adrian.hunter@nokia.com \
    --cc=hpa@zytor.com \
    --cc=joern@logfs.org \
    --cc=jwboyer@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=w@1wt.eu \
    /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.