All of lore.kernel.org
 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: Tue, 9 Sep 2003 12:10:44 -0700	[thread overview]
Message-ID: <20030909191044.GB28279@matchmail.com> (raw)
In-Reply-To: <20030909070421.GJ10487@namesys.com>

On Tue, Sep 09, 2003 at 11:04:21AM +0400, Oleg Drokin wrote:
> Hello!
> 
> On Mon, Sep 08, 2003 at 03:24:57PM -0700, Mike Fedyk 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.
> 
> Yes, I know this. 

I figured you did, as the explanation was mostly for people who don't.

> But my experiments quickly shown that if you ask mkfs to create inode tables with
> free inodes that exceed blocks count for the device, then mkfs will only create as much free inodes
> as there are free blocks on the device (I was needing that when I experimented with 60 millions files
> on ext2/reiserfs/xfs and stuff and I only had 20G partition.)
> 

Hmm, didn't know this, but it makes sence for ext2/3 since they use 1 block
per file/directory.  It wouldn't do much good to waste more space for inode
tables than you could even theoretically use.

> > Hmm, take ext3 with htree, reiser3 & reiser4 (choose the block size 1k, 2k or 4k) with
> 
> reiser4 does not have support for blocksize different from page size for now (sigh, same old problems
> we finally solved for reiser3 recently).
> 

Interesting, somewhere I think I saw that it was using 512 byte blocks, but
don't ask me where I saw that or who said it.

> > 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
> 
> Hm. I will probably try this once.
> For reiserfs:
> I can tell you that 60M+ empty files (cannot remember exact number, but I still have the script to create those)
> took ~5.5G of space. 

With how many directories?  Do you run into drive speed limitations with
that much meta-data, or are there still bottlenecks in the
journaling/hashing to deal with? How big are the reiser3/4 equivalents to
inodes?  In ext2/3 they're currently 128 bytes I believe plus some static
bitmaps in the block groups.  The only thing variable in ext2/3 are the
directory sizes (and they don't shrink... :( )

> Then 60M * 4k is 240G, all these blocks are referenced by leafnodes, ~1000 pointers fits into one node,
> so we will spend ~245M for block pointers (extra 5 because there are more layers of indirections).
> 
> > look comparing them?  For that matter, how do JFS & XFS compare?
> 
> Unfortunatelly I never had the patience to wait until XFS creates 60M files. Have not tried jfs.
> 

Hmm, isn't XFS slower than ext2/3 in that regard?

  reply	other threads:[~2003-09-09 19:10 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
2003-09-09  7:04                     ` Oleg Drokin
2003-09-09 19:10                       ` Mike Fedyk [this message]
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=20030909191044.GB28279@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.