Messages in this thread | | | Date | Thu, 11 Sep 2003 10:15:13 -0700 | From | Mike Fedyk <> | Subject | Reiser3/4 & Ext2/3 was: First impressions of reiserfs4 |
| |
On Thu, Sep 11, 2003 at 02:29:38PM +0400, Oleg Drokin wrote: > 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. >
True. Do you know if ext2/3 allocates the block even for empty files? So if you create the file, it should be sparse until you write something to it, right? Does the touch command do this?
> > > > 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). >
Hmm, any experiments with more files per dir (maybe 500 or 1000)? I'm not sure if you're going to use a directory full block with 100 files per dir in ext2/3.
> > 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))
Are these indirects stored in the tree, or do you have many partially filled indirect blocks?
> Also bitmaps are static (1 block per 128M of space in case of 4k blocksize) > as are superblock, journal and journal header. >
How many superblocks are there in reiser3? Also, the bitmap locations are static, and allocated at mkfs time? How is that done so fast for large filesystems?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |