mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: Daniel Phillips <phillips@bonn-fries.net>,
	Andrew Morton <akpm@zip.com.au>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch] delayed disk block allocation
Date: Sun, 3 Mar 2002 22:31:03 -0700	[thread overview]
Message-ID: <20020303223103.J4188@lynx.adilger.int> (raw)
In-Reply-To: <3C7F3B4A.41DB7754@zip.com.au> <E16hhuI-0000S6-00@starship.berlin> <20020304050450.GF353@matchmail.com>
In-Reply-To: <20020304050450.GF353@matchmail.com>; from mfedyk@matchmail.com on Sun, Mar 03, 2002 at 09:04:50PM -0800

On Mar 03, 2002  21:04 -0800, Mike Fedyk wrote:
> On Mon, Mar 04, 2002 at 03:08:54AM +0100, Daniel Phillips wrote:
> > The main disconnect there is sub-page sized writes, you will bundle together
> > young and old 1K buffers.  Since it's getting harder to find a 1K blocksize
> > filesystem, we might not care.  
> 
> Please don't do that.
> 
> Hopefully, once this is in, 1k blocks will work much better.  There are many
> cases where people work with lots of small files, and using 1k blocks is bad
> enough, 4k would be worse.
> 
> Also, with dhash going into ext2/3 lots of tiny files in one dir will be
> feasible and comparible with reiserfs.

Actually, there are a whole bunch of performance issues with 1kB block
ext2 filesystems.  For very small files, you are probably better off
to have tails in EAs stored with the inode, or with other tails/EAs in
a shared block.  We discussed this on ext2-devel a few months ago, and
while the current ext2 EA design is totally unsuitable for that, it
isn't impossible to fix.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/


  reply	other threads:[~2002-03-04  5:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-01  8:26 Andrew Morton
2002-03-04  2:08 ` Daniel Phillips
2002-03-04  3:10   ` Jeff Garzik
2002-03-04  7:27     ` Andrew Morton
2002-03-04  5:04   ` Mike Fedyk
2002-03-04  5:31     ` Andreas Dilger [this message]
2002-03-04  5:40       ` Mike Fedyk
2002-03-04  6:14         ` Andreas Dilger
2002-03-04  5:41       ` Jeff Garzik
2002-03-04  6:18         ` Andreas Dilger
2002-03-04 15:02           ` Hans Reiser
2002-03-06 12:59             ` Pavel Machek
2002-03-04  7:53       ` Andrew Morton
2002-03-04  8:06         ` Daniel Phillips
2002-03-04  8:34           ` Andrew Morton
2002-03-04  7:20   ` Andrew Morton
2002-03-04  9:23     ` Daniel Phillips
2002-03-04 14:54 rwhron
2002-03-04 15:10 ` Jeff Garzik
2002-03-07 12:06 Etienne Lorrain
2002-03-07 14:47 ` Steve Lord
2002-03-07 17:30   ` Mike Fedyk

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=20020303223103.J4188@lynx.adilger.int \
    --to=adilger@clusterfs.com \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@bonn-fries.net \
    /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®