On Wed, Nov 07, 2012 at 08:53:20PM +0900, [email protected] wrote:
> 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.
# grep /etc /proc/mounts
none /etc aufs rw,relatime,si=142e1bbf 0 0
# for f in /sys/kernel/debug/aufs/si_142e1bbf/* ; do echo -n "$f: "; cat $f ;
done
/sys/kernel/debug/aufs/si_142e1bbf/xi0: 1, 104x4096 69524
/sys/kernel/debug/aufs/si_142e1bbf/xi1: 1, 32x4096 37516
/sys/kernel/debug/aufs/si_142e1bbf/xib: 8x4096 4096
[root@pbx7 ~]# dd if=/dev/zero of=/etc/test bs=1024 count=100
100+0 records in
100+0 records out
102400 bytes (102 kB) copied, 0.00279516 s, 36.6 MB/s
[root@pbx7 ~]# for f in /sys/kernel/debug/aufs/si_142e1bbf/* ; do echo -n "$f:
"; cat $f ; done
/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
[root@pbx7 ~]# rm /etc/test
[root@pbx7 ~]# for f in /sys/kernel/debug/aufs/si_142e1bbf/* ; do echo -n "$f:
"; cat $f ; done
/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.
> .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.
# mount -o remount,itrunc_xino=0 /tmp/mnt
Does seem to recover the leaked space. Only the first 4 blocks allocated
by the 'dd' seems still taken.
> .TP
> .B trunc_xino | notrunc_xino
> Enable (or disable) the automatic truncation of xino files.
Doesn't seem to help either…
> 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.
…but I guess this may be because of the limit.
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 – 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.
And mounting the aufs with the 'trunc_xino' does seem to help. 'Used'
space does increase first, but then decreases a bit. And I never got it
above 140kB this way.
> 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).
That does not seem to explain the lost space I have seen on a production
system… We will see…
So, now I know:
1. as an ad-hoc solution to fix tmpfs space already lost I can use:
mount -o remount,itrunc_xino=0 mountpoint
2. to prevent this from happening I can enable automatic truncation by:
mount -t aufs -o 'br=...,,trunc_xino" none mountpoint
instead of my current mounting command.
3. I can also add the mount option to a mounted system by:
mount -o remount,trunc_xino mountpoint
Tests show this should solve my problem.
Thanks a lot for the hints!
Greets,
Jacek
------------------------------------------------------------------------------
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
