From: Artem Bityutskiy <dedekind@yandex.ru>
To: Tomasz Chmielewski <mangoo@wpkg.org>
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
Subject: Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)
Date: Tue, 01 Apr 2008 12:57:46 +0300 [thread overview]
Message-ID: <47F2071A.6010406@yandex.ru> (raw)
In-Reply-To: <47F202D9.20405@wpkg.org>
Tomasz Chmielewski wrote:
> Such as?
ext3 for example.
> Flash (also on block devices) is slow and expensive (when compared to
> modern hard disks) and therefore compression is *very* useful here.
Well, if you are ready to trade performance to compression, then well,
go ahead :-) May be I used too strong wording, but I wanted to say then
use raw flash then. But I'd also consider implementing compression support
for a block based FS. Reiser4 claimed to have it for example.
> Do you mean using hacks like block2mtd? It's hacky, and pretty hard to
> boot a system this way (need to build own initramfs, with a static
> block2mtd or loads of libraries - not something an average user would
> like to do; no distro supports it; updating a kernel would be a pain etc.).
Well, ok, it still sounds strange for me, but you may use JFFS2 and UBIFS
with block2mtd as well if you really want to.
> True.
> Unfortunately, there is no way to access flash directly on flash-based
> block devices (USB-sticks, IDE-flash disks, SSD disks etc.).
Yeah, that's a pity :-(
> Unfortunately, traditional filesystems were rather designed for rotating
> media / cheap disks (no transparent compression; tend to accumulate
> writes in one area of the disk - more on that - below).
Sure.
> 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. :-)
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2008-04-01 10:02 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 [this message]
2008-04-02 14:17 ` Tomasz Chmielewski
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=47F2071A.6010406@yandex.ru \
--to=dedekind@yandex.ru \
--cc=ext-adrian.hunter@nokia.com \
--cc=joern@logfs.org \
--cc=jwboyer@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mangoo@wpkg.org \
--cc=penberg@cs.helsinki.fi \
/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.