linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Yury Umanets <umka@namesys.com>
Cc: Bill Davidsen <davidsen@tmr.com>, Daniel Egger <degger@fhm.edu>,
	Hans Reiser <reiser@namesys.com>,
	Nikita Danilov <Nikita@namesys.com>,
	Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>,
	reiserfs mailing list <reiserfs-list@namesys.com>
Subject: Re: Reiser4 status: benchmarked vs. V3 (and ext3)
Date: Thu, 14 Aug 2003 15:10:55 +0100	[thread overview]
Message-ID: <1060870255.4803.49.camel@passion.cambridge.redhat.com> (raw)
In-Reply-To: <1060837469.17622.6.camel@haron.namesys.com>

On Thu, 2003-08-14 at 06:04, Yury Umanets wrote:
> Yes, you are right. Device driver cannot take care about leveling.

The hardware device driver doesn't. The 'translation layer' does, in the
case where you are using a traditional block-based file system. 

If you consider the translation layer and the underlying raw hardware
driver together to form the 'device driver' from the filesystem's
perspective and in the context of the above sentence, then you're
incorrect -- it can, and in general it _does_ take care of wear
levelling.

> It is able only to take care about simple caching (one erase block) in 
> order to make wear out smaller and do not read/write whole block if one 
> sector should be written.

Whatever meaning of 'device driver' you meant to use -- no.

The raw hardware driver provides only raw read/write/erase
functionality; no caching is appropriate. 

The optional translation layer which simulates a block device provides
far more than simple caching -- it provides wear levelling, bad block
management, etc. All using a standard layout on the flash hardware for
portability.

(Except in the special case of the 'mtdblock' translation layer, which
is not suitable for anything but read-only operation on devices without
any bad blocks to be worked around.)

> Part of a filesystem called "block allocator" should take care about 
> leveling.

That's insufficient. In a traditional file system, blocks get
overwritten without being freed and reallocated -- the allocator isn't
always involved. 

If you want to teach a file system about flash and wear levelling, you
end up ditching the pretence that it's a block device entirely and
working directly with the flash hardware driver. 

Either that or use a translation layer which does it _all_ for the file
system and then just use a standard file system on that simulated block
device.

Between those two extremes, very little actually makes sense.

If you introduce the gratuitous extra 'block device' abstraction layer
which doesn't really fit the reality of flash hardware very well at all,
you end up wanting to violate the layering in so many ways that you
realise you really shouldn't have been pretending to be a block device
in the first place.

-- 
dwmw2


  reply	other threads:[~2003-08-14 14:11 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-23 21:02 Reiser4 status: benchmarked vs. V3 (and ext3) Hans Reiser
2003-07-24  4:26 ` Tupshin Harper
2003-07-24  4:31   ` Shawn
2003-07-24  4:56     ` Tupshin Harper
2003-07-24  5:21       ` Shawn
2003-07-24  5:33         ` Shawn
2003-07-24 11:10         ` Nikita Danilov
2003-07-24 15:10           ` Tupshin Harper
2003-07-24 15:26             ` Larry McVoy
2003-07-24 15:32               ` Tupshin Harper
2003-07-24 15:54                 ` Larry McVoy
2003-07-24 15:32               ` Shawn
2003-07-27 12:28           ` Hans Reiser
2003-07-27 12:45             ` Tomas Szepe
2003-07-27 14:01               ` Hans Reiser
2003-07-27 15:04               ` Gene Heskett
2003-07-24 15:59 ` Daniel Egger
2003-07-24 17:07   ` Nikita Danilov
2003-07-24 21:10     ` Tupshin Harper
2003-07-25 12:57       ` Nikita Danilov
2003-07-25  0:39     ` Daniel Egger
2003-07-25 13:02       ` Nikita Danilov
2003-07-25 14:20         ` Daniel Egger
2003-07-25 14:39           ` Yury Umanets
2003-07-26  1:08             ` Daniel Egger
2003-07-26  7:19               ` Yury Umanets
2003-07-26 14:13                 ` Daniel Egger
2003-07-26 14:54                   ` Yury Umanets
2003-07-26 15:21                     ` Daniel Egger
2003-07-27  3:28                       ` Valdis.Kletnieks
2003-07-27 10:30                       ` Yury Umanets
2003-07-27 11:05                         ` Daniel Egger
2003-07-27 11:46                           ` Yury Umanets
2003-08-08 14:01                         ` David Woodhouse
2003-08-08 14:28                           ` Bernd Eckenfels
2003-08-08 23:58                             ` David Woodhouse
2003-08-09  0:29                               ` Bernd Eckenfels
2003-08-09  0:38                                 ` David Woodhouse
2003-07-27 13:31                     ` Hans Reiser
2003-07-27 14:13                       ` Yury Umanets
2003-07-27 13:28                   ` Hans Reiser
2003-07-27 14:10                     ` Daniel Egger
2003-07-27 14:15                       ` Yury Umanets
2003-08-13 20:12                         ` Bill Davidsen
2003-08-14  5:04                           ` Yury Umanets
2003-08-14 14:10                             ` David Woodhouse [this message]
2003-08-15 11:15                               ` Yury Umanets
2003-08-15 15:28                               ` Bill Davidsen
2003-08-15 15:53                                 ` David Woodhouse
2003-08-14 13:58                           ` David Woodhouse
2003-07-27 15:30                       ` Bernd Eckenfels
2003-07-27 15:49                         ` Alan Cox
2003-08-08 13:23                           ` David Woodhouse
2003-07-28 11:30                       ` Hans Reiser
2003-07-26 17:14                 ` Jussi Laako
2003-07-27 13:35                   ` Hans Reiser
2003-08-08 14:08                   ` David Woodhouse
2003-07-27 12:59           ` Hans Reiser
2003-07-27 14:16             ` Daniel Egger
2003-07-27 15:32               ` Bernd Eckenfels
2003-08-08 14:29                 ` David Woodhouse
2003-07-28 12:44               ` Hans Reiser
2003-07-28 13:06                 ` Daniel Egger
2003-07-28 13:29                   ` Hans Reiser
2003-07-28 13:48                   ` Hans Reiser
2003-07-27 12:38   ` Hans Reiser
2003-07-26  8:33 ` Andrew Morton
2003-07-27 13:24   ` Hans Reiser

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=1060870255.4803.49.camel@passion.cambridge.redhat.com \
    --to=dwmw2@infradead.org \
    --cc=Nikita@namesys.com \
    --cc=davidsen@tmr.com \
    --cc=degger@fhm.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiser@namesys.com \
    --cc=reiserfs-list@namesys.com \
    --cc=umka@namesys.com \
    /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).