Re: First impressions of reiserfs4

[Oleg Drokin <green@namesys.com>]

[-- Attachment #1: Type: text/plain, Size: 3504 bytes --]

Hello!

On Tue, Sep 09, 2003 at 12:10:44PM -0700, Mike Fedyk wrote:

> > 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.

Well, in fact empty files do not need this block.

> > > 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

Ok. I looked at the script. There should be 182900000 files created. (182.9M)
100 files per dir.
the dir structure was like this (in number of dirs per level):
31/59/25/40
Files were only created at the end of hierarchy.
See the script at the end if you are interested or want to try it yourself.
(script was donated to us by somebody, only it was shell script,
also I changed variable-names to hide identity).

> that much meta-data, or are there still bottlenecks in the
> journaling/hashing to deal with? How big are the reiser3/4 equivalents to

I do not remember what was major limitation.
Creation took something like one hour on my dual athlon box. This suggests
most overhead was still CPU. (I used perl script to create stuff)
Removing those files took even longer.

> 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... :( )

Well in reiserfs we have statdata (each object should have one), this is sort of
like ext2 inode, only not static. It's size is 44 bytes (plus 24 bytes item
header overhead). Each metadata block has header of 24 bytes.
If you write to file (not looking at tail case yet), you create "indirect"
items in which block pointers are stored.
(4 bytes per pointer, when you use all space in metadata block, next block is
allocated (24 bytes of overhead + pointer in higher level block) plus
new indirect item (24 bytes of overhead again))
Also bitmaps are static (1 block per 128M of space in case of 4k blocksize)
as are superblock, journal and journal header.

> > 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?

Probably it is. I was unable to find blockdevice big enough to hold
all the inode stuff for ext2/3 so I do not have comparable number.
XFS was very slow at creation (like 3 hours only gave ~ 10% of progress
and testing was stopped at this point.
Deletion of those created files also took forever)

Bye,
    Oleg

[-- Attachment #2: createdirs.pl --]
[-- Type: application/x-perl, Size: 1661 bytes --]