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 23:14:42 -0700 [thread overview]
Message-ID: <20020303231442.M4188@lynx.adilger.int> (raw)
In-Reply-To: <3C7F3B4A.41DB7754@zip.com.au> <E16hhuI-0000S6-00@starship.berlin> <20020304050450.GF353@matchmail.com> <20020303223103.J4188@lynx.adilger.int> <20020304054025.GH353@matchmail.com>
In-Reply-To: <20020304054025.GH353@matchmail.com>; from mfedyk@matchmail.com on Sun, Mar 03, 2002 at 09:40:25PM -0800
On Mar 03, 2002 21:40 -0800, Mike Fedyk wrote:
> On Sun, Mar 03, 2002 at 10:31:03PM -0700, Andreas Dilger wrote:
> > 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.
>
> Do you think it'll look like block tails (like ffs?) or will it be more like
> tail packing in reiserfs?
It will be like tail packing in reiserfs, I believe. FFS has fixed-sized
'fragments' while reiserfs has arbitrary-sized 'tails'. The ext2 tail
packing will be arbitrary-sized tails, stored as an extended attribute
(along with any other EAs that this inode has. With proper EA design,
you can share multiple inode's EAs in the same block. We also discussed
for very small files that you could store the tail (or other EA data)
within the inode itself.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
next prev parent reply other threads:[~2002-03-04 6:16 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
2002-03-04 5:40 ` Mike Fedyk
2002-03-04 6:14 ` Andreas Dilger [this message]
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=20020303231442.M4188@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®