Thank you Jacob, the tmpfs-idr.patch did the trick.
Cheers,
Koral
On 08/11/14 16:50, Jacob Burkamper wrote:
Hello Koral.
I am not an aufs developer, just a user. However, I was seeing a similar
problem; for me the issue was resolved by applying the tmpfs-idr.patch to my
kernel. It is available in the aufs-aufs3-standalone repository for your
kernel version.
I hope I have been helpful.
-Jacob
On Mon, Aug 11, 2014 at 6:40 PM, koral <[1]koral.il...@calix.com> wrote:
<sfjro <at> [2]users.sourceforge.net> writes:
>
>
> Jacek Konieczny:
> > IMHO a hash table should be used instead of the linear (even if
sparse)
> > array for the xino data. Then the storage space could be used much
more
> > efficiently.
>
> Currently I am considering how can aufs reduce the size of XINO.
> Won't you tell me why hash table can use space much more efficiently?
>
> As you might know, current XINO file is a linear table for translation.
> When you give an inode number as input, aufs multiply it by the size of
> inum, seeks the file with the calculated value as the file offset, and
> reads a new inum. If you put the file on HDD (other than tmpfs), then
> you will not see the memory pressure.
> On the other hand, if aufs puts the translation table as a hash table in
> memory, then we need additional pointers other than the inum data, don't
> we? Or do you say that put the hash table in a file? Then is it easy to
> implement?
>
> J. R. Okajima
>
>
--------------------------------------------------------------------------
----
> Master Visual Studio, SharePoint, SQL, [3]ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> [4]http://p.sf.net/sfu/learnmore_122912
>
>
Has there been a resolution on this issue?
I am seeing a similar (or same?) problem when using aufs on tmpfs.
kernel 3.10.35-ltsi-yocto-standard.
aufs branch info:
Mount Point AUFS-id Br# Directory
Flags
========================= ======== ==== =============================
=====
/ 9d4b66b8 br0 /mnt/rw rw
/ 9d4b66b8 br1 /mnt/ro rr
========================= ======== ==== =============================
=====
related mounts:
tmpfs on /mnt/rw type tmpfs (rw,relatime,size=65536k)
/dev/loop0 on /mnt/ro type squashfs (ro,relatime)
none on / type aufs (rw,relatime,si=9d4b66b8,trunc_xino)
I can reproduce it by continuously copying files to and deleting from
tmpfs.
After a few iterations, I notice a 4k leak on the tmpfs, as reported by
df.
If I instead mount tmpfs with trunc_xino, the df no longer shows a leak,
but
the size in /sys/kernel/debug/aufs/si_*/xi0 shows continuous growth. When
it
eventually reaches around 64Mb (my tmpfs size), I start getting no space
left on device errors:
aufs au_xino_create2:187:kworker/1:2[2593]: .aufs.xino copy err -28
Happy to share more details. First want to make sure someone is listening
:)
Cheers,
Koral
--------------------------------------------------------------------------
----
References
1. mailto:koral.il...@calix.com
2. http://users.sourceforge.net/
3. http://ASP.NET/
4. http://p.sf.net/sfu/learnmore_122912
------------------------------------------------------------------------------
