mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [rfc] Near-constant time directory index for Ext2
Date: Thu, 22 Feb 2001 12:31:37 +0100	[thread overview]
Message-ID: <20010222123137.T724@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <200102220203.f1M237Z20870@webber.adilger.net> <3A947C54.E4750E74@transmeta.com> <3A948ACB.7B55BEAE@innominate.de> <97230a$16k$1@penguin.transmeta.com> <9727hh$1e7$1@penguin.transmeta.com>
In-Reply-To: <9727hh$1e7$1@penguin.transmeta.com>; from torvalds@transmeta.com on Wed, Feb 21, 2001 at 09:19:45PM -0800

Hi Linus,
Hi LKML people,

On Wed, Feb 21, 2001 at 09:19:45PM -0800, Linus Torvalds wrote:
> In article <97230a$16k$1@penguin.transmeta.com>,
> Linus Torvalds <torvalds@transmeta.com> wrote:
> >allocate blocks one at a time. Make the blocksize something nice and
> >big, not just 4kB or 8kB or something.
> 
> Btw, this is also going to be a VM and performance issue some time in
> the future.  Tgere are already CPU's that would _love_ to have 64kB
> pages etc, and as such a filesystem that doesn't play with the old silly
> "everthing is a block" rules would be much appreciated with the kind of
> people who have multi-gigabyte files and want to read in big chunks at a
> time. 
 
For this we need a block remapper layer that can map any
blocksize n to any blocksize m with only the following constraints:

   - n and m are powers of 2
   - n is a multiple of m

Both should use the page cache ( of size p) of course, so it
becomes 2 layers, if n > p.

   -  translating a buffer of n into some pages
   -  translating a page into buffers of m (current buffercache)

We could limit the translation to 5 powers of 2 obove and 5 powers of 2
below PAGE_CACHE_SIZE so that we can maintain a validity bitmap
(2^5 = 32 bits) for each layer if access is too expensive[1].

Some subsystems could certainly benefit from it.

   -  loop device (with all the crypto stuff)
   -  LVM
   -  FSes that support block sizes != PAGE_CACHE_SIZE
   -  Devices with blocksize != 512 (they don't have to care
      being special anymore). There are even some rumors
      about very pervert blocksizes of 1M and the like.

Since these remapped buffers will look like merged requests, I
see even no problems with the elevator any more.

The question is, where we implement this infrastructure, esp. if
we consider the last user (devices with blocksize != 512).

This has to be answered by the main architects of Linux before
anyone could start.

> So either you have a simple block-based filesystem (current ext2, no
> extents, no crapola), or you decide to do it over.  Don't do some
> half-way thing, please. 

Daniel (and others) uses ext2 as as a playground, because it is
implemented, tested and not that hard to understand and verify.

Hope they will switch to some own design later, once they
sufficiently played around with^W^W^Wtested their ideas.

Regards

Ingo Oeser

[1] In buffer cache we use read-modify-write for partial pages,
   which hurts performance for them and is annoying for media
   with limited write cycles like flash and CD-RW[2].

[2] Yes I know about packet writing mode ;-)
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<       come and join the fun       >>>>>>>>>>>>

  reply	other threads:[~2001-02-22 11:32 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-20 15:04 Daniel Phillips
2001-02-20 20:03 ` Linus Torvalds
2001-02-20 21:08   ` Jeremy Jackson
2001-02-20 21:20     ` Mike Dresser
2001-02-20 22:36       ` Jeremy Jackson
2001-02-20 23:08         ` Daniel Phillips
2001-02-21  1:04           ` Bernd Eckenfels
2001-02-21 16:38             ` Daniel Phillips
2001-02-20 22:58       ` Jonathan Morton
2001-02-20 21:41   ` Daniel Phillips
2001-02-21  0:22     ` Linus Torvalds
2001-02-21  0:30       ` Alan Cox
2001-02-21  2:35         ` Ed Tomlinson
2001-02-21 23:13           ` Linus Torvalds
2001-02-21 23:34             ` Davide Libenzi
2001-02-21 23:59               ` Linus Torvalds
2001-02-21 23:57             ` H. Peter Anvin
2001-02-22  0:35             ` Ed Tomlinson
2001-02-21  1:01       ` Andreas Dilger
2001-02-22  2:28       ` Daniel Phillips
2001-02-22  3:30         ` Linus Torvalds
2001-02-22 16:33           ` Chris Mason
2001-02-22 22:30           ` Daniel Phillips
2001-02-21 17:21 ` Davide Libenzi
2001-02-21 21:08   ` Martin Mares
2001-02-21 21:29     ` Davide Libenzi
2001-02-21 21:32       ` Martin Mares
2001-02-21 21:59         ` Davide Libenzi
2001-02-21 22:26           ` Martin Mares
2001-02-21 22:43             ` Davide Libenzi
2001-02-21 22:14         ` H. Peter Anvin
2001-02-21 22:32           ` Martin Mares
2001-02-21 22:38             ` H. Peter Anvin
2001-02-21 22:50               ` Martin Mares
2001-02-21 22:54                 ` H. Peter Anvin
2001-02-21 23:07                   ` Martin Mares
2001-02-21 23:15                     ` H. Peter Anvin
2001-02-21 23:42                       ` Daniel Phillips
2001-02-21 23:52                         ` Davide Libenzi
     [not found]                       ` <3A945081.E6EB78F4@innominate.de>
2001-02-21 23:48                         ` H. Peter Anvin
2001-02-22  1:22                           ` Daniel Phillips
2001-02-22  1:42                             ` H. Peter Anvin
2001-02-22  2:03                             ` Andreas Dilger
2001-02-22  2:41                               ` H. Peter Anvin
2001-02-22  3:43                                 ` Daniel Phillips
2001-02-22  4:02                                   ` Linus Torvalds
2001-02-22  5:19                                     ` Linus Torvalds
2001-02-22 11:31                                       ` Ingo Oeser [this message]
2001-02-22 18:20                                         ` Linus Torvalds
2001-02-22  4:02                                   ` H. Peter Anvin
2001-02-22  7:03                                     ` Andreas Dilger
2001-02-22  4:03                                   ` H. Peter Anvin
2001-02-22 10:35                                     ` Alan Cox
2001-02-23  0:59                                       ` Felix von Leitner
2001-02-22  3:08                               ` Daniel Phillips
2001-02-22  8:06                                 ` [rfc] [LONG] " Andreas Dilger
2001-02-22  7:20                       ` [rfc] " Bill Wendling
2001-02-22  8:34                       ` Rogier Wolff
2001-02-21 23:26                     ` Jamie Lokier
2001-02-22 19:04                 ` Kai Henningsen
2001-02-22  6:23 ` [Ext2-devel] " tytso
2001-02-22  7:24   ` Daniel Phillips
2001-02-22 13:20   ` tytso
2001-02-22 18:16     ` Andreas Dilger
2001-02-22 23:04       ` Daniel Phillips
2001-02-22 23:40       ` tytso
2001-02-23 20:11       ` tytso
2001-02-24  0:32         ` Andreas Dilger
2001-02-22 18:38 ` Kai Henningsen
     [not found] <Pine.LNX.4.10.10102211740550.1933-100000@coffee.psychology.mcmaster.ca>
2001-02-21 22:47 ` H. Peter Anvin
2001-02-23  1:52 Andries.Brouwer
2001-02-23 21:43 ` Ralph Loader
2001-02-23 22:37   ` Guest section DW
2001-02-24  2:47   ` Ralph Loader
2001-02-24  5:34   ` Ralph Loader
2001-02-23  2:49 Andries.Brouwer
2001-02-23  3:42 ` Daniel Phillips
2001-02-23 12:20 ` Jonathan Morton
2001-02-23 18:57   ` Andreas Dilger
2001-02-23 12:38 Andries.Brouwer

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=20010222123137.T724@nightmaster.csn.tu-chemnitz.de \
    --to=ingo.oeser@informatik.tu-chemnitz.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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

all inboxes | Powered by JetHome®