New filesystem overhead

[S.Jagadeesh Babu]

Hi,

I created a new filesystem of 7.3GB and after mounting i can see a free space of only 6.87GB with only lost+found in the directory. I am wondering what happened to remaining space.
The statictics shown when given bdf are:
total KBytes: 7340032
used : 2900
avail : 6878569

Its a jfs filesystem.

Can anyone clarify .

Regs,
S.J.Babu

[Shannon Petry]

In the old days, we had to deal with a 10% tolerance that was not useable with HFS. Now that we can adjust that tolerance with HFS we have all moved to JFS, which creates new overheads.
It was explained to me that this new overhead is mainly used for journaling. This is the area that the system keeps track of what it is doing, and is resetved un-adjustable space. The new tolerance is about 8% unusable space with JFS.
Perhaps someone else could give a better technical description of the space, but I think I covered enough that you get the idea.
Best Regards,
Shannon

[rajsri]

Hi
generally 5 % is the filesystem overhead.

[S.Jagadeesh Babu]

Hi,

Though i could understand there is overhead for the filesystems, i would like to know what for this space is used and how can we change that overhead space allocation.

Regs,
S.J.babu

[Bill Hassell]

Filesystems cannot exist without directories. Unix manages disk space by assigning chunks of data called filesystem blocks to an inode (which occupies space). Each inode contains specific information on this disk space. inodes by themselves are not useful until a directory (which is also a file) entry assigns a name to an inode.

So inodes occupy space and directories occupy space. When you deal with gigabyte filesystems, normal inode sizes will require a massive number of inodes when the filesystem gets full. For HFS filesystems, the inodes are all created with newfs and cannot be modified (except by extending the filesystem). For vxfs, some inodes are preallocated along with directory structures and extra space for journaling structures.

You can reduce the overhead somewhat by increasing the default blocksize (8K) to a much larger number such as 32K or 64K. This requires removing all the data, using newfs to blow away the previous filesystem and then use newfs with options to create a larger inode. This works for both HFS and VXFS.

For HFS filesystems, there is a minfree value which keeps the write performance of the filesystem fairly stable. Once an HFS filesystem reaches 90% full, the time required to locate additional space goes up geometrically. However, if the filesystem contains a database, this value can be reduced to 0% since additional space is no longer requested (databases typically preallocate their space).

Adjusting the inode size to a large number will not bring back 100% of the directory overhead and experimenting with the filesystem blocksize may result in a major difference in performance for some databases. With disks so incredibly cheap, trying to recover a few hundred megs is probably not worth the effort.

[John Palmer]

Your overhead will be almost entirely due to the number of i-nodes. bdf -i will report the number of i-nodes in the filesystem and by default will be a (very) large number for a filesystem > 7Gb.

If you intend to only create a small number of large files in this filesystem e.g. database files then consider reducing the number of i-nodes to a nore realistic number.

man mkfs_vxfs describes in full how you do it but the format is:-
mkfs -F vxfs -o ninode=
where is the number of i-nodes required.

For example if you know that there will be < 1000 files,
mkfs -F vxfs -o ninode=1000

Be aware though that this will be a hard limit for the number of i-nodes. The default for mkfs_vxfs is to create 'unlimited' i-nodes, new ones will be created as required.

Hope this helps,
John

[Andy Monks]

It's the number of inodes on the filesystem.

if you do a 'bdf -i' you'll see how many you have. And it will be lots. Each one takes up 128bytes.

When you create the filesystem you can alter the number of inodes that get created by changing the number of cylinder groups and the number of inodes per cylinder group.

Alternatively, just use jfs (vxfs).

[John Palmer]

vxfs filesystem i-nodes are in fact 256 bytes. mkfs_vxfs allows an option inosize=n
but the only allowed value for n is 256!

[Rob Mallard]

How come when I do a bdf 'available' plus 'used' does not equal 'total space'? If the overhead was inode space, would that not be recorded in used.

It seems the difference in these two numbers is vxfs management space just like in hfs.

This is contrary to what John Palmer alluted to above so can anyone else vouch for his answer.


Thanks!

[curt larson]

maybe this might help

allocated - used = unused or free space

7340032 - 2900 = 7337132

now why doesn't this equal what is available?

your free space will be used for both inodes and file blocks. So, how much space available for files is determined by how you use it. It is sort of like asking, I have 15 gallons of gas so how far can i drive? Well, it depends on how you drive.

Here your asking I have 7337132 of free space, so how much file space does that equal? Well it depends on how you use it.

vxfs dynamically allocates inodes from the pool of free blocks, so the number of free inodes and blocks is an estimate based on the number of free extents and the current ratio of allocated inodes to allocated blocks.

if you added your space available (free blocks) + number of free inodes * 256 per inode/1024 for kbytes or free inodes/4, you'll get a number close to your free space. it is just an esitmate after all.

7337132 - 6878569 = 458563
458463 * 4 = 1834252

so I'd guess you have about 1,800,000 free inodes in this file system.

So your free space is known, df -F vxfs -v filesystem_name

The space available is an esitmate of how this free space will be allocated into inodes and blocks. free space - space designated for free inodes = what is available.

[John Palmer · Accepted solution]

Details for a newly created 1Gb filesystem with unlimited inodes:-
kbytes=1024000, used=1357, available=958735, total inodes=255664.
255664 inodes at 256 bytes each = 63916kb
1024000 - 1357 - 958735 = 63908kb

Details for the same filesystem created with fixed 1000 inodes:-
kbytes=1024000, used=1357, available=1022401,
total inodes=1000.
1000 inodes at 256 bytes each = 250kb
1024000 - 1357 - 1022401 = 242kb

Thus the whole difference between allocated and avail (with an 8kb error) is inode space.

[Rob Mallard]

Thanks for clearing that up for me!