From: Charles Manning <manningc2@actrix.gen.nz>
To: Pavel Machek <pavel@ucw.cz>, David Woodhouse <dwmw2@infradead.org>
Cc: "Phillip Lougher" <phillip@lougher.demon.co.uk>,
"Matthew Wilcox" <willy@debian.org>,
"Erez Zadok" <ezk@cs.sunysb.edu>,
"Jörn Engel" <joern@wohnheim.fh-wedel.de>,
"Kallol Biswas" <kbiswas@neoscale.com>,
linux-kernel@vger.kernel.org,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: partially encrypted filesystem
Date: Wed, 10 Dec 2003 15:13:04 +1300 [thread overview]
Message-ID: <20031210020607.500755679@blood.actrix.co.nz> (raw)
In-Reply-To: <20031210000759.GA618@elf.ucw.cz>
On Wednesday 10 December 2003 13:07, Pavel Machek wrote:
>
> > Even if you were going to admit to having a block size of 64KiB to the
> > layers above you, you just can't _do_ atomic replacement of blocks,
> > which is required for normal file systems to operate correctly.
>
> Are those assumptions needed for something else than recovery after
> crash/powerdown? [i.e., afaics 64K ext2 should work on flash, but fsck
> might have some troubles...]
The main reason for this in JFFSx and YAFFS (but particularly JFFSx on NOR)
is that flash memory cannot be arbitrarily overwritten without an erase and
an erase takes a long time.
Eg: NOR flash typically takes around 1 second to erase a block (typically
64kB in size) and approx 10usec or so per byte/word to program. So to change
a single byte in a block in place would typically require something like:
1. Read into buffer
2. Erase block [1 second].
3. Reprogram [0.6 seconds]
+ do that all over again for the update to the file info.
On NAND flash, where erase is far faster, the cost is far less. Still in a
comparison of YAFFS (which uses log structuring for the same reasons as
JFFS2) and FAT + block driver for NAND, YAFFS could sustain a write speed of
approx 10 times the FAT + block driver solution on the same hardware.
Then there are issues like wear levelling (because flash has a limited
lifetime) and bad block handling etc... but performance (and crash recovery)
are the main issues.
-- Charles
next prev parent reply other threads:[~2003-12-10 2:06 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-03 21:07 partially encrypted filesystem Kallol Biswas
2003-12-03 21:44 ` Richard B. Johnson
2003-12-03 23:20 ` bill davidsen
2003-12-03 21:44 ` Jörn Engel
2003-12-04 0:08 ` Linus Torvalds
2003-12-04 1:25 ` Jeff Garzik
2003-12-04 2:08 ` Linus Torvalds
2003-12-04 3:59 ` H. Peter Anvin
2003-12-04 2:37 ` Charles Manning
2003-12-04 14:17 ` Jörn Engel
2003-12-04 15:20 ` Linus Torvalds
2003-12-04 16:07 ` Phillip Lougher
2003-12-04 17:26 ` Jörn Engel
2003-12-04 18:20 ` Phillip Lougher
2003-12-04 18:40 ` Jörn Engel
2003-12-04 19:41 ` Erez Zadok
2003-12-05 11:20 ` Jörn Engel
2003-12-05 16:16 ` Erez Zadok
2003-12-05 19:14 ` Matthew Wilcox
2003-12-05 19:47 ` Erez Zadok
2003-12-05 20:28 ` Matthew Wilcox
2003-12-05 21:38 ` Pat LaVarre
2003-12-06 0:15 ` Maciej Zenczykowski
2003-12-06 1:35 ` Pat LaVarre
2003-12-06 2:39 ` Valdis.Kletnieks
2003-12-06 11:43 ` Maciej Zenczykowski
2003-12-07 0:04 ` Shaya Potter
2003-12-08 14:08 ` Jörn Engel
2003-12-06 0:50 ` Phillip Lougher
2003-12-08 11:37 ` David Woodhouse
2003-12-08 13:44 ` phillip
2003-12-08 14:07 ` David Woodhouse
2003-12-10 1:16 ` [OT?]Re: " Charles Manning
2003-12-10 17:45 ` Phillip Lougher
2003-12-09 23:40 ` Pat LaVarre
2003-12-10 0:07 ` Pavel Machek
2003-12-10 1:28 ` Pat LaVarre
2003-12-10 2:13 ` Charles Manning [this message]
2003-12-05 19:58 ` Pat LaVarre
2003-12-08 11:28 ` David Woodhouse
2003-12-08 13:49 ` phillip
2003-12-04 19:18 ` David Wagner
2003-12-05 13:02 ` Jörn Engel
2003-12-05 17:28 ` Frank v Waveren
2003-12-05 23:59 ` David Wagner
2003-12-19 15:01 ` Rik van Riel
2003-12-04 3:10 ` Valdis.Kletnieks
2003-12-04 18:16 ` Hans Reiser
2003-12-06 19:56 Pat LaVarre
2003-12-06 22:07 ` Maciej Zenczykowski
2003-12-10 3:22 Valient Gough
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=20031210020607.500755679@blood.actrix.co.nz \
--to=manningc2@actrix.gen.nz \
--cc=dwmw2@infradead.org \
--cc=ezk@cs.sunysb.edu \
--cc=joern@wohnheim.fh-wedel.de \
--cc=kbiswas@neoscale.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=phillip@lougher.demon.co.uk \
--cc=willy@debian.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;
as well as URLs for NNTP newsgroup(s).