Jacek Konieczny:
> /sys/kernel/debug/aufs/si_142e1bbf/xi0: 1, 112x4096 118608
> /sys/kernel/debug/aufs/si_142e1bbf/xi1: 1, 32x4096 37516
> /sys/kernel/debug/aufs/si_142e1bbf/xib: 8x4096 4096
>
> > .B trunc_xib
> > Truncate the external inode number bitmap file. The truncation is done
> > automatically when you delete a branch unless you do not specify
>
> Doesn't seem to affect the behaviour.
The XIB file is allocated 8 blocks, which means it supports the inode
number up to
8 blocks (including pre-allocated) x 4096 bytes x 8 bits
= 262144
If the maxmum inode number on your tmpfs doesn't exceeds 262144, then
the XIB file size will not change.
> So I have made a script which creates and removes lots of files and
> reports the file system usage every 100 files added/remove.
>
> What is interesting =E2=80=93 the usage increased only each few seconds, =
> not
> with every file created as I would expect. I guess this behaviour
> depends on a way tmpfs allocates inodes.
Agreed.
Additionally the XINO file block allocation is done by its
block-size. Generally one block (4096 bytes) support the 1024 inode
numbers (assuming each number is 4 bytes). So when the change of the
maximum inode number is less than 1024, the blocks of the XINO file will
not change.
> Tests show this should solve my problem.
>
> Thanks a lot for the hints!
Glad to hear that.
J. R. Okajima
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
