Hello Jason,
Jason Lunz:
> I've run into a problem where log rotation (repeated delete/recreate of
> a single path) causes unbounded disk usage for the xino file. I'm using
> aufs cvs 20070709 on mostly-vanilla kernel.org linux 2.6.22.13 i386.
:::
> Is this normal? Is there any limit to the amount of space used? If not,
> this is a disk space leak. I found this problem because I ran into
> systems that were using 10 times as much space for xino as for the
> actual files in the rw branch.
>
> Does it even make sense to use xino when the writable branch is tmpfs?
I guess it is a known issue, and fixed already.
It was a problem of reclaiming/re-using inode-numbers.
I'd like to suggest you to try the latest aufs.
Additionary, there is a limitation or specification in tmpfs.
It does not reclaim the inode number, and this behaviour MAY make aufs
to do the same behaviour too. In this case, the file size of xino grows.
Try 'df -i' and 'ls -i' for your tmpfs, and watch how inode-number will
be assigned and how the number of free inodes is decremented with your
test script.
Specifying the total number of inode for tmpfs may be worth, but I am
afraid that you need to use other filesystem for your writable branch,
since even if your link(2) two files, tmpfs decrements the number of
free inode and aufs will follow it.
Junjiro Okajima
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
