linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: "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: Mon, 08 Dec 2003 11:37:05 +0000	[thread overview]
Message-ID: <1070883425.31993.80.camel@hades.cambridge.redhat.com> (raw)
In-Reply-To: <3FD127D4.9030007@lougher.demon.co.uk>

On Sat, 2003-12-06 at 00:50 +0000, Phillip Lougher wrote:
> Of course, all this is at the logical file level, and ignores the 
> physical blocks on disk.  All filesystems assume physical data blocks 
> can be updated in place.  With compression it is possible a new physical 
> block has to be found, especially if blocks are highly packed and not 
> aligned to block boundaries.  I expect this is at least partially why 
> JFFS2 is a log structured filesystem.

Not really. JFFS2 is a log structured file system because it's designed
to work on _flash_, not on block devices. You have an eraseblock size of
typically 64KiB, you can clear bits in that 'block' all you like till
they're all gone or you're bored, then you have to erase it back to all
0xFF again and start over.

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.

These characteristics of flash have often been dealt with by
implementing a 'translation layer' -- a kind of pseudo-filesystem --
which pretends to be a block device with the normal 512-byte
atomic-overwrite behaviour. You then use a traditional file system on
top of that emulated block device. 

JFFS2 was designed to avoid that inefficient extra layer, and work
directly on the flash. Since overwriting stuff in-place is so difficult,
or requires a whole new translation layer to map 'logical' addresses to
physical addresses, it was decided just to ditch the idea that physical
locality actually means _anything_.

Given that design, compression just dropped into place; it was trivial.

-- 
dwmw2


  reply	other threads:[~2003-12-08 11:38 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 [this message]
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
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=1070883425.31993.80.camel@hades.cambridge.redhat.com \
    --to=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=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).