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?
next prev parent 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 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).