linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Fedyk <mfedyk@matchmail.com>
To: Oleg Drokin <green@namesys.com>
Cc: Rogier Wolff <R.E.Wolff@BitWizard.nl>,
	Hans Reiser <reiser@namesys.com>,
	linux-kernel@vger.kernel.org, Nikita Danilov <god@namesys.com>
Subject: Re: First impressions of reiserfs4
Date: Mon, 8 Sep 2003 15:24:57 -0700	[thread overview]
Message-ID: <20030908222457.GB17441@matchmail.com> (raw)
In-Reply-To: <20030908101704.GE10487@namesys.com>

On Mon, Sep 08, 2003 at 02:17:04PM +0400, Oleg Drokin wrote:
> You only can have as many inodes as number of blocks on the fs (at least that's the limit imposed on you
> by mke2fs).

True, but not exactly.  Each file will need one block to store even one byte
on ext2/3.  But your inode tables have about 1/4-1/2 the number of inode entries to
blocks.  This can be changed at mkfs time though.

# mke2fs -n -b 1024 -m0 /dev/md0
mke2fs 1.34-WIP (21-May-2003)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
39923712 inodes, 319388032 blocks
0 blocks (0.00%) reserved for the super user
First data block=1
38988 block groups
8192 blocks per group, 8192 fragments per group
1024 inodes per group

40M inodes and 319M blocks with a 1k block ext2/3 filesystem.

# mke2fs -n -b 4096 -m0 /dev/md0
mke2fs 1.34-WIP (21-May-2003)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
39927808 inodes, 79847008 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
2437 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group

40M inodes and 80M blocks on a 4k block ext2/3 filesystem.

So with the defaults, you'd have to have 40M files each between 4.1 - 7.9Kb
to run out of inodes, and fill the filesystem.

k# mke2fs -n -b 1024 -m0 -T news /dev/md0
mke2fs 1.34-WIP (21-May-2003)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
79847424 inodes, 319388032 blocks
0 blocks (0.00%) reserved for the super user
First data block=1
38988 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group

80M inodes and 319M blocks on a 1k block ext2/3 filesystem.

Now one question I have...

Is that 32k blocks per group + 32k fragments per group = 64k blocks per
group (since fragments aren't[1] implemented)?

[1] For those interested, the space allocated for fragments was a perfect
fit for tail merging support.  There is a patch in alpha stages floating
around for that...

Hmm, take ext3 with htree, reiser3 & reiser4 (choose the block size 1k, 2k or 4k) with
tail merging off, 1k files per directory and all files the same size as
block size with 40M files.  How would the table look as far as space effency
look comparing them?  For that matter, how do JFS & XFS compare?

Mike

  parent reply	other threads:[~2003-09-08 22:24 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-30 11:33 First impressions of reiserfs4 Erik Hensema
2003-08-30 17:06 ` Hans Reiser
2003-08-31 17:14   ` Rogier Wolff
2003-09-08  8:12     ` Oleg Drokin
2003-09-08  8:56       ` Rogier Wolff
2003-09-08  9:08         ` Oleg Drokin
2003-09-08  9:33           ` Rogier Wolff
2003-09-08  9:48             ` Oleg Drokin
2003-09-08 10:05               ` Rogier Wolff
2003-09-08 10:17                 ` Oleg Drokin
2003-09-08 12:59                   ` Herbert Poetzl
2003-09-08 22:24                   ` Mike Fedyk [this message]
2003-09-09  7:04                     ` Oleg Drokin
2003-09-09 19:10                       ` Mike Fedyk
2003-09-11 10:29                         ` Oleg Drokin
2003-09-11 17:15                           ` Reiser3/4 & Ext2/3 was: " Mike Fedyk
2003-09-11 17:27                             ` Oleg Drokin
2003-09-11 22:50                               ` Rogier Wolff
2003-09-12  1:20                                 ` Bernd Eckenfels
2003-09-12  4:48                                   ` Mike Fedyk
2003-10-01 21:06                                     ` Bernd Eckenfels
2003-10-02  6:36                                       ` Hans Reiser
2003-09-12  1:17                             ` Bernd Eckenfels
2003-09-08 20:11       ` Andreas Dilger

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=20030908222457.GB17441@matchmail.com \
    --to=mfedyk@matchmail.com \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=god@namesys.com \
    --cc=green@namesys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiser@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).