From: "Artem B. Bityutskiy" <dedekind@yandex.ru>
To: Ferenc Havasi <havasi@inf.u-szeged.hu>
Cc: linux-mtd@lists.infradead.org, "Zhao, Forrest" <forrest.zhao@intel.com>
Subject: Re: The problem that I didn't think out
Date: Sun, 27 Nov 2005 16:20:19 +0300 [thread overview]
Message-ID: <4389B293.3020507@yandex.ru> (raw)
In-Reply-To: <4389AE3D.8000807@inf.u-szeged.hu>
Ferenc, Greetings!
> We had some time, so we read the plan of JFFS3 (with RaiserFS
> documentation).
Oh, what a delightful news! :-)
> The key compression is the only one in the plan that I think that is
> better if we don't use. I think to make key management as simple and
> fast as possible is more important than some percent in flash usage. (if
> I am right the bottleneck of real products is not the flash usage but
> the speed) But it is small techniqual question.
Well, I would not agree, compression Guru Ferenc though you be :-) When
you start thinking about GC, you'll notice that Indexing nodes are to be
rewritten *a great deal* of times. So, the smaller is the index, the
faster is JFFS3. The main idea of key compression is *not* to save flash
space, but to lessen the (index size)/(data size) ratio.
Nonetheless, tests should show the worthiness of keys compression. There
is obviously a (CPU time) vs. (amount of flash IO) trade-off. Thus, I
offer to wait for a JFFS3 prototype and evaluate this. Let's mark this
stuff as "to be evaluated".
> The big questions are that questions you already thinging on: garbage
> collection and wear leveling. Without solving them JFFS3 have no nice
> future. I only would like to say that now we are also thinking on these
> important problems... and we will write if anything usable found. (I may
> be better feeling to thinking on someting not alone... :) )
Great! :-)
Thank you for this feedback.
--
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.
next prev parent reply other threads:[~2005-11-27 13:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-25 8:36 The problem that I didn't think out Zhao, Forrest
2005-11-25 11:58 ` Artem B. Bityutskiy
2005-11-27 13:01 ` Ferenc Havasi
2005-11-27 13:20 ` Artem B. Bityutskiy [this message]
2005-11-28 0:32 ` Ferenc Havasi
2005-11-28 10:15 ` Artem B. Bityutskiy
2005-11-28 2:20 ` zhao, forrest
2005-11-28 10:24 ` Artem B. 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=4389B293.3020507@yandex.ru \
--to=dedekind@yandex.ru \
--cc=forrest.zhao@intel.com \
--cc=havasi@inf.u-szeged.hu \
--cc=linux-mtd@lists.infradead.org \
/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.