From: "Jörn Engel" <joern@logfs.org>
To: Alexey Korolev <akorolev@infradead.org>
Cc: dwmw2@infradead.org, "Jörn Engel" <joern@logfs.org>,
linux-mtd@lists.infradead.org
Subject: Re: Limited support of NAND features in MTD.
Date: Tue, 18 Dec 2007 16:18:01 +0100 [thread overview]
Message-ID: <20071218151800.GG1741@lazybastard.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0712181450540.31218@pentafluge.infradead.org>
On Tue, 18 December 2007 15:06:50 +0000, Alexey Korolev wrote:
> >
> > What does cached read do?
> >
> Performs cached read operations :)
Who would have thought? :)
> It is a feature of NAND devices. It increases performance if we have
> request to read sequentally large amount of data from NAND.
Do you have a little more information on this? Where does the cache
reside? How big is it? Who controls it? How does it interact with
writes? ...
Possibly the best answer would be a link to a datasheet.
> > Another feature that could become useful would be the on-chip copying.
> > With JFFS2 this is rare, but when doing GC or wear leveling in a fashion
> > that keeps certain alignments intact, it could improve performance.
> >
> Yeah. I know this feature. If I properly understand the real purpose of
> it is mostly related for FTL but could be used for FS as well.
> You are right it make sense to try it. But I do not know when it will be possible to do
> this. Usually this feature is called as Internal data move in NAND specs.
At least I would like to know what the conditions are. Can the command
copy whole blocks only? If it can copy single pages, can it copy any
pages or just the Nth page of one block to the Nth page of another?
If any page can be copied to any other page, it should be quite useful
for any non-compressed filesystem. YAFFS, old LogFS, anything that does
XIP, possibly UBI,...
Jörn
--
Joern's library part 7:
http://www.usenix.org/publications/library/proceedings/neworl/full_papers/mckusick.a
next prev parent reply other threads:[~2007-12-18 15:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-12 11:51 Limited support of NAND features in MTD Alexey Korolev
2007-12-12 13:54 ` Artem Bityutskiy
2007-12-12 14:36 ` Josh Boyer
2007-12-13 17:47 ` Alexey Korolev
2007-12-18 14:23 ` Jörn Engel
2007-12-18 15:06 ` Alexey Korolev
2007-12-18 15:18 ` Jörn Engel [this message]
2007-12-18 15:46 ` Alexey Korolev
2007-12-18 16:07 ` Alexey Korolev
2007-12-18 16:57 ` David Brown
2007-12-18 16:56 ` Jörn Engel
2007-12-18 18:14 ` David Woodhouse
2007-12-19 10:49 ` Alexey Korolev
2007-12-19 10:52 ` David Woodhouse
2007-12-19 11:55 ` Alexey Korolev
2007-12-19 11:57 ` Artem Bityutskiy
2007-12-19 12:47 ` David Woodhouse
2007-12-18 15:48 ` Alexander Belyakov
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=20071218151800.GG1741@lazybastard.org \
--to=joern@logfs.org \
--cc=akorolev@infradead.org \
--cc=dwmw2@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox