Hello Jacek and Tomas,
Tomas M:
> > So, it seems aufs allocates some 'invisible' data on the tmpfs and never
> > frees it.
>
> That may be the xino file, which is stored on the first writable
> branch as a deleted file. But then it would probably report its size
> on tmpfs alone as well, strange.
Maybe you are right.
But the XINO files don't fully explain Jacek's situation, since aufs
shrinkes (truncates) the XINO files automatically when it is
possible. If it never be able to be shrinked, then something wrong will
happen but I don't think it can happen often. It should be rare.
Jacek, if you have debugfs mounted somewhere in your system, then you
can confirm the size and the consumed blocks of the XINO files via
<debugfs>/aufs/<si_id>/{xib,xi[0-9]*,xigen}. I'd suggest you to check
them first.
(from the aufs manual)
----------------------------------------------------------------------
The xino files are always hidden, i.e. removed. So you cannot
do `ls \-l xino_file'.
If you enable CONFIG_DEBUG_FS, you can check these information through
<debugfs>/aufs/<si_id>/{xib,xi[0-9]*,xigen}. xib is for the bitmap file,
xi0 ix for the first branch, and xi1 is for the next. xigen is for the
generation table.
xib and xigen are in the format of,
.nf
<blocks>x<block size> <file size>
.fi
Note that a filesystem usually has a
feature called pre-allocation, which means a number of
blocks are allocated automatically, and then deallocated
silently when the filesystem thinks they are unnecessary.
You do not have to be surprised the sudden changes of the number of
blocks, when your filesystem which xino files are placed supports the
pre-allocation feature.
The rests are hidden xino file information in the format of,
.nf
<file count>, <blocks>x<block size> <file size>
.fi
If the file count is larger than 1, it means some of your branches are
on the same filesystem and the xino file is shared by them.
Note that the file size may not be equal to the actual consuming blocks
since xino file is a sparse file, i.e. a hole in a file which does not
consume any disk blocks.
Once you unmount aufs, the xino files for that aufs are totally gone.
It means that the inode number is not permanent across umount or
shutdown.
----------------------------------------------------------------------
And here are the mount options and the description related to truncate
XINO files.
(from the aufs manual)
----------------------------------------------------------------------
.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
`notrunc_xib' option.
(cf. External Inode Number Bitmap, Translation Table and Generation Table).
.
.TP
.B notrunc_xib
Stop truncating the external inode number bitmap file when you delete
a branch.
(cf. External Inode Number Bitmap, Translation Table and Generation Table).
.
.TP
.B trunc_xino_path=BRANCH | itrunc_xino=INDEX
Truncate the external inode number translation table per branch. The
branch can be specified by path or index (its origin is 0).
Sometimes the size of a xino file for tmpfs branch grows very big. If
you don't like such situation, try "mount -o
remount,trunc_xino_path=BRANCH /your/aufs" (or itrunc_xino=INDEX). It
will shrink the xino file for BRANCH. These options are one time
actions. So the size may grow again. In order to make it work
automatically when necessary, try trunc_xino option.
These options are already implemented, but its design is not fixed
(cf. External Inode Number Bitmap, Translation Table and Generation Table).
.
.TP
.B trunc_xino | notrunc_xino
Enable (or disable) the automatic truncation of xino files.
The truncation is done by discarding the internal "hole" (unused blocks).
When the number of blocks by the xino file for the branch exceeds
the predefined upper limit, the automatic truncation begins. If the xino
files contain few holes and the result size is still exceeds the upper
limit, then the upper limit is added by \*[AUFS_XINO_TRUNC_STEP] blocks. The
initial upper limit is \*[AUFS_XINO_TRUNC_INIT] blocks.
Currently the type of branch fs supported by this automatic truncation
is tmpfs or ramfs only.
The default is notrunc_xino.
These options are already implemented, but its design is not fixed
(cf. External Inode Number Bitmap, Translation Table and Generation Table).
:::
The bitmap file and the table can be truncated.
For example, if you delete a branch which has huge number of files,
many inode numbers will be recycled and the bitmap will be truncated
to smaller size. Aufs does this automatically when a branch is
deleted.
You can truncate it anytime you like if you specify `trunc_xib' mount
option. But when the accessed inode number was not deleted, nothing
will be truncated.
If you do not want to truncate it (it may be slow) when you delete a
branch, specify `notrunc_xib' after `del' mount option.
For the table, see trunc_xino_path=BRANCH, itrunc_xino=INDEX, trunc_xino
and notrunc_xino option.
----------------------------------------------------------------------
And here is the description related to the size of XINO.
(from the aufs manual)
----------------------------------------------------------------------
The
maximum file size of the bitmap is, basically, the amount of the
number of all the files on all branches divided by 8 (the number of
bits in a byte).
For example, on a 4KB page size system, if you have 32,768 (or
2,599,968) files in aufs world,
then the maximum file size of the bitmap is 4KB (or 320KB).
The
maximum file size of the table will
be `max inode number on the branch x size of an inode number'.
For example in 32bit environment,
.nf
$ df -i /branch_fs
/dev/hda14 2599968 203127 2396841 8% /branch_fs
.fi
and /branch_fs is an branch of the aufs. When the inode number is
assigned contiguously (without `hole'), the maximum xino file size for
/branch_fs will be 2,599,968 x 4 bytes = about 10 MB. But it might not be
allocated all of disk blocks.
When the inode number is assigned discontinuously, the maximum size of
xino file will be the largest inode number on a branch x 4 bytes.
Additionally, the file size is limited to LLONG_MAX or the s_maxbytes
in filesystem's superblock (s_maxbytes may be smaller than
LLONG_MAX). So the
support-able largest inode number on a branch is less than
2305843009213693950 (LLONG_MAX/4\-1).
This is the current limitation of aufs.
On 64bit environment, this limitation becomes more strict and the
supported largest inode number is less than LLONG_MAX/8\-1.
----------------------------------------------------------------------
J. R. Okajima
------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
