Number of inodes in formatting?

lucmove · 12-19-2008, 03:38 AM

Can someone please tell me what I did wrong here. I have this 135 Gb partition:

Code:

dumpe2fs 1.39 (29-May-2006)
Filesystem volume name:   home
Last mounted on:          <not available>
Filesystem UUID:          07c5bffc-1b27-4d4e-be65-10ba0abc8a02
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              8265728
Block count:              66110960
Reserved block count:     661109
Free blocks:              1198392
Free inodes:              7863693
First block:              0
Block size:               2048
Fragment size:            2048
Reserved GDT blocks:      512
Blocks per group:         16384
Fragments per group:      16384
Inodes per group:         2048
Inode blocks per group:   256
Filesystem created:       Wed Sep 17 22:07:12 2008
Last mount time:          Wed Dec 17 18:15:59 2008
Last write time:          Wed Dec 17 18:15:59 2008
Mount count:              10
Maximum mount count:      39
Last checked:             Sat Dec  6 17:22:04 2008
Check interval:           15552000 (6 months)
Next check after:         Thu Jun  4 16:22:04 2009
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      0b8f62a1-d669-478d-99e3-1562b1f38a1a
Journal backup:           inode blocks
Journal size:             64M

Then I wanted to copy everything over to another partition (160 Gb) in another disk. I formatted it like this:

Code:

# mkfs.ext3 -m 1 -b 2048 -O has_journal -O dir_index -L new /dev/sda6

I am 99% sure I formatted the new partition exactly the same way I had formatted the old one. It's like a formula/recipe I keep for that.

After the copy, I realized the data was taking quite a few more Gb in the new partition than in the old one. So I ran dumpe2fs on the new one and got this:

Code:

dumpe2fs 1.39 (29-May-2006)
Filesystem volume name:   new
Last mounted on:          <not available>
Filesystem UUID:          fc22d661-2e52-40b8-8218-31e622f1b35b
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              19537920
Block count:              78143646
Reserved block count:     781436
Free blocks:              72802354
Free inodes:              19537903
First block:              0
Block size:               2048
Fragment size:            2048
Reserved GDT blocks:      512
Blocks per group:         16384
Fragments per group:      16384
Inodes per group:         4096
Inode blocks per group:   256
Filesystem created:       Fri Dec 19 00:13:18 2008
Last mount time:          Fri Dec 19 01:35:37 2008
Last write time:          Fri Dec 19 01:35:37 2008
Mount count:              2
Maximum mount count:      31
Last checked:             Fri Dec 19 00:13:18 2008
Check interval:           15552000 (6 months)
Next check after:         Tue Jun 16 23:13:18 2009
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      3c25861c-bc45-4002-b93c-acedc8c878db
Journal backup:           inode blocks
Journal size:             64M

Here is the obvious difference to me:
old one:
Inodes per group: 2048
new one:
Inodes per group: 4096

Why did that happen? The data was supposed to take the same amount of disk space in both partitions. What exactly was my mistake?

TIA

Tuttle · 12-19-2008, 04:08 AM

Have you tried using dd for this operation?
It might make a good experiment!
Then see if you can still manipulate the free space using cfdisk or hdparm!

lucmove · 12-19-2008, 07:20 AM

I don't understand how dd is relevant in this case. I just want to understand why the exact same command line formats one partition with 2048 inodes per group and another partition with 4096 inodes per group.

tredegar · 12-19-2008, 12:06 PM

Quote:

What exactly was my mistake?... [SNIP] ...I just want to understand why the exact same command line formats one partition with 2048 inodes per group and another partition with 4096 inodes per group.

You did not make a mistake.
Your new partition is 160GB, your old one 135GB.
So the new partition is larger.
So when you formatted it to ext3, linux decided that as it was larger, it would be appropriate to allocate more inodes for the (increased number of) files likely to be stored there.

It looks like the HowManyInodesDoIAllocate algorithm of mkfs just doubles the previous number when some threshold is crossed (I'm guessing, it may be cleverer).

If you'd like finer control of this you can do it: See man mkfs.ext3

Tuttle · 12-19-2008, 05:15 PM

Quote:

Originally Posted by lucmove

I don't understand how dd is relevant in this case. I just want to understand why the exact same command line formats one partition with 2048 inodes per group and another partition with 4096 inodes per group.

dd has no relevance here... I am just Mr. Irrelevant today :P

GazL · 12-19-2008, 05:39 PM

Quote:

Originally Posted by lucmove

Code:

dumpe2fs 1.39 (29-May-2006)
Inode count:              19537920
Inode size:               128

I'll assume that inode size is in bytes.
19537920 * 128
= 2500853760

~2.5GB of space taken up with inodes!

Unless you're planning on having somewhere in the region of 19.5 million files in that partition, you might want to cut that down a little.

lucmove · 12-19-2008, 11:47 PM

OK. So inode size is the problem. Or is it because the partitions are different sizes?

I discovered that I can set the inode-size option with the -I (capital i) parameter. My man mkfs.ext3 in Slackware 12 does not say that. I tried it and it worked although there is a mysterious message about which Google seems to know nothing:

Code:

Warning: 256-byte inodes not usable on most systems

It worked, but it still doesn't help. Check this out: now with two partitions the exact same size:

OLD:

Code:

dumpe2fs 1.39 (29-May-2006)
Filesystem volume name:   home
Last mounted on:          <not available>
Filesystem UUID:          07c5bffc-1b27-4d4e-be65-10ba0abc8a02
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              8265728
Block count:              66110960
Reserved block count:     661109
Free blocks:              1198392
Free inodes:              7863693
First block:              0
Block size:               2048
Fragment size:            2048
Reserved GDT blocks:      512
Blocks per group:         16384
Fragments per group:      16384
Inodes per group:         2048
Inode blocks per group:   256
Filesystem created:       Wed Sep 17 22:07:12 2008
Last mount time:          Wed Dec 17 18:15:59 2008
Last write time:          Wed Dec 17 18:15:59 2008
Mount count:              10
Maximum mount count:      39
Last checked:             Sat Dec  6 17:22:04 2008
Check interval:           15552000 (6 months)
Next check after:         Thu Jun  4 16:22:04 2009
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      0b8f62a1-d669-478d-99e3-1562b1f38a1a
Journal backup:           inode blocks
Journal size:             64M

NEW:

Code:

dumpe2fs 1.39 (29-May-2006)
Filesystem volume name:   chomesam
Last mounted on:          <not available>
Filesystem UUID:          4ecd9fb8-785b-4014-beb8-5ba48a6f933e
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              15581184
Block count:              62315604
Reserved block count:     623156
Free blocks:              60317190
Free inodes:              15581173
First block:              0
Block size:               2048
Fragment size:            2048
Reserved GDT blocks:      512
Blocks per group:         16384
Fragments per group:      16384
Inodes per group:         4096
Inode blocks per group:   512
Filesystem created:       Sat Dec 20 03:11:39 2008
Last mount time:          Sat Dec 20 03:18:38 2008
Last write time:          Sat Dec 20 03:18:38 2008
Mount count:              1
Maximum mount count:      28
Last checked:             Sat Dec 20 03:11:39 2008
Check interval:           15552000 (6 months)
Next check after:         Thu Jun 18 02:11:39 2009
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      e3b92941-fa12-4674-9af1-49d36f6f92ef
Journal backup:           inode blocks
Journal size:             64M

Now the inode size is the same, but the data still takes up more space in the new partition:

Part. Size Used Avail Use% Mounted on
old: 125G 122G 891M 100% /home
new: 116G 83M 114G 1% /mnt/sda

The two partitions are the same size! Why does the new one become smaller after formatting?

Note that this difference remains in the output of dumpe2fs:

OLD:
Inodes per group: 2048
Inode blocks per group: 256

NEW:
Inodes per group: 4096
Inode blocks per group: 512

I discovered that, in theory, I can add the -g parameter to specify the number of blocks in a block group. But that parameter gives me an error:

Code:

mkfs.ext3: Could not allocate block in ext2 filesystem while trying to allocate filesystem tables

Why, oh, why can't the use of space in the new partition be as efficient as in the old one?

GazL · 12-20-2008, 08:27 AM

You're missing something. Your old filesystem has ~ 8 million inodes, your new one has ~ 15 million!

Here....

Block size * Blocks per group / Inodes per group = Bytes per inode

OLD:

Code:

Block size:               2048
Blocks per group:         16384
Inodes per group:         2048
Inode size:               256

16384 * 2048 / 2048 = 16384 bytes per inode

NEW:

Code:

Block size:               2048
Blocks per group:         16384
Inodes per group:         4096
Inode size:               256

16384 * 2048 / 4096 = 8192 bytes per inode.

If you want them the same, try creating your new filesystem with '-i 16384' (lower case 'i' bytes per inode option) to specify the correct bytes per inode. That'll result in half as many inodes being created. Infact, if you're sure you'll never have more than 4 million files in that filesystem, you could even go upto "-i 32768" and save even more space.