<sfjro <at> 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, 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: > 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 ------------------------------------------------------------------------------
