Tomas M:
> Aufs manual says:
> These options are already implemented, but its design is not fixed
>
> Junjiro, would you please explain what that means? Is it safe to use
> trunc_xino? Is there a huge performance penalty? Thank you
It means some details of these features may be changed in the fut
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
> > automatic
> 2. to prevent this from happening I can enable automatic truncation by:
>
> mount -t aufs -o 'br=...,,trunc_xino" none mountpoint
Aufs manual says:
These options are already implemented, but its design is not fixed
Junjiro, would you please explain what that means? Is it safe to use
trunc_xi
On Wed, Nov 07, 2012 at 08:53:20PM +0900, sf...@users.sourceforge.net 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
> /aufs//{xib,xi[0-9]*,xigen}. I'd suggest you to check
> them first.
# grep /et
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.
>> That may be the xino file, which is stored on the first writable
>> branch as a deleted file.
>
> And it probably should not be created and live forever for each deleted file,
> right?
I don't know, really :) It is a 'hidden' file which Junjiro uses in
AUFS to store mappings for persistent ino
On Wed, Nov 07, 2012 at 10:40:39AM +0100, Tomas M wrote:
> > 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.
And it probably should not be created and live fore
> 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.
Try to put the xino file on some other file
Hello,
I found tmpfs usage grow unexpectedly on my systems until crash when it
reaches 100%. The system use aufs to unite tmpfs and squashfs. After
long investigation I am able to reproduce it now. 4 blocks are allocated each
time a file is created via aufs (in addition to the file size), but the
