Ocfs2 devel - Dec 2018 - About ocfs2 inode/extent meta file allocation problem

Hello Guys,

When you read ocfs2 kernel code, you can find that ocfs2 uses inode_alloc:N /
extent_alloc:N meta files to manage inode block/extent block allocation.
The meta file per node will be increased via getting some blocks from
global_bitmap meta file when the user create new files(inodes).
But the meta files ( inode_alloc:N or extent_alloc:N) will not shrink back when
these inode/extent blocks are deleted (e.g. these files are removed by the
user).
Then, if the user creates lots of files until the file system is full, next, the
user deletes all the files.
At this moment, the inode_alloc:N file is very big and occupy the whole file
system, since this meta file can not shrink back.
The user can not create a file with some data clusters, since the global_bitmap
meta file has not more available cluster bits.
I did not do this testing in my machine, but from the code logic, I feel my idea
should be true.
Do you have any ideas for this problem? 
My suggestion is, 
we should return some blocks to global_bitmap meta file from inode_alloc:N /
extent_alloc:N meta files when there are enough free blocks.

Thanks
Gang

On 2018/12/19 13:47, Gang He wrote:
> Hello Guys,
> 
> When you read ocfs2 kernel code, you can find that ocfs2 uses inode_alloc:N
/ extent_alloc:N meta files to manage inode block/extent block allocation.
> The meta file per node will be increased via getting some blocks from
global_bitmap meta file when the user create new files(inodes).
> But the meta files ( inode_alloc:N or extent_alloc:N) will not shrink back
when these inode/extent blocks are deleted (e.g. these files are removed by the
user).
> Then, if the user creates lots of files until the file system is full,
next, the user deletes all the files.
> At this moment, the inode_alloc:N file is very big and occupy the whole
file system, since this meta file can not shrink back.
> The user can not create a file with some data clusters, since the
global_bitmap meta file has not more available cluster bits.
> I did not do this testing in my machine, but from the code logic, I feel my
idea should be true.
> Do you have any ideas for this problem? 
> My suggestion is, 
> we should return some blocks to global_bitmap meta file from inode_alloc:N
/ extent_alloc:N meta files when there are enough free blocks.
> 
> Thanks
> Gang      
> 
> 
> 
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
> 
> 
Hi Gang,

I feel the problem what you described will be exist. When there
are a lot of small files in the ocfs2 volume, it will use plentiful
enough space as inode/extent allocs' group descriptors.
I agree your idea, in addition, I think we need to fix it use
two steps as follows:
- Online fix, start a delayed work to check inode/extent alloc if
  exceeding a certain percentage, then return spaces to global_bitmap.
- Offline fix, to some extreme scenario, inode/extent alloc occupy
  enough spaces but none of gd can be freed, metadata should be
  moved in this case.

Thanks,
Yiwen.