From: David Woodhouse <dwmw2@infradead.org>
To: phillip@lougher.demon.co.uk
Cc: "Jörn Engel" <joern@wohnheim.fh-wedel.de>,
kbiswas@neoscale.com, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: partially encrypted filesystem
Date: Mon, 08 Dec 2003 14:07:33 +0000 [thread overview]
Message-ID: <1070892449.31993.97.camel@hades.cambridge.redhat.com> (raw)
In-Reply-To: <E1ATLgF-0003XX-0V@anchor-post-31.mail.demon.net>
On Mon, 2003-12-08 at 13:44 +0000, phillip@lougher.demon.co.uk wrote:
> dwmw2@infradead.org wrote:
> > 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.
>
> Curiously, I am aware of how flash and log structured filesystems work.
This I assumed. The explanation was more for the benefit of the peanut
gallery than yourself.
> > 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_.
>
> Maybe okay for a flash filesystem which is slow anyway, but many
> filesystem designers *are* concerned about physical locality of
> blocks, for example video filesystems.
Oh, absolutely.
> Or maybe 'not in(to)-place' :-)
:)
> I don't think I was saying compression is difficult, it is not
> difficult if you've designed the filesystem correctly.
My point was that it's trivial in JFFS2 not because I designed the file
system 'correctly', but mostly because of other factors which just
happened to lead to a design which, by coincidence, made compression
trivial.
--
dwmw2
next prev parent reply other threads:[~2003-12-08 14:07 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-03 21:07 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 [this message]
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=1070892449.31993.97.camel@hades.cambridge.redhat.com \
--to=dwmw2@infradead.org \
--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 \
/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
all inboxes | Powered by JetHome®