Rene Mayrhofer:
> Dear Junjiro,
> 
> I have now updated to aufs2, but still have the same problem:

I have almost forgotten you at all. :-)


> With aufs2, this seems different. There is no xino file, but a xi_path file=
>  -=20
> which gives me the (invisible) file /system/ramdisks/var/.aufs.xino but no=
> =20
> indication of its size.

Yes, the information of XINO are moved to debugfs.


> If I try to estimate the size of this xino file based on the documentation,=
        :::
> inode table size, the number of inodes is around 32k on both branches:
> 
> [r...@gibraltar-500 ~]# df -i /system/ramdisks/var/
> =46ilesystem            Inodes   IUsed   IFree IUse% Mounted on
> tmpfs                  31698     592   31106    2% /system/ramdisks/var
> [r...@gibraltar-500 ~]# df -i /system/root/
> =46ilesystem            Inodes   IUsed   IFree IUse% Mounted on
> /dev/loop0             38250   38250       0  100% /system/root
> 
> which should result in a maximum size of roughly 150kB.

No, you are misunderstanding the aufs manual and the size of XINO.
The size depends upon the maximum inode number, instead of the number of
inodes. If you have 10 inodes, you may expect the inode numbers are
assigned such like 100, 101, 102 ... 109. But the filesystem can assign
any number for them such like 99, 9000, 100, 9999, 2222, 10000 ....
If your maximum inode number is 10000 even if you have only 10 inodes,
then the size of XINO will look about 10000 x 4 bytes = 40KB (if the
size of your inode is 4bytes).

But the size of XINO is not an issue. You should look at how many blocks
it consumes. Generally, a file on a filesystem may not be assigned disk
blocks for the hole in it. It is called sparse file. If you create a new
file, write a byte at the top of it, seek to 1MB , and write another
byte, then the filesize will look as 1MB+1. But the allocated disk
blocks are only two. If the block size of your filesystem is 4k, then
the file which looks 1MB+1 as its size, consumes only 8kb actually.


> If I interpret the debugs info correctly, then=20
> 
> [r...@gibraltar-500 ~]# cat /tmp/debug/aufs/si_6536656c/xi*
> 1, 38440x4096 20338388
> 1, 72x4096 133484
> 8x4096 4096
> 
> the xino file should be at 32kB (8x4096)?=20

No, it means,
- one XINO for the first branch consumes 38440 blocks, the size of a
  block is 4096, and it looks 20338388 bytes as its size.
- the other XINO for the second branch consumes 72 blocks, and it looks
  133484 bytes
- XIB (xino bitmap) file also consumes 8 blocks, and it looks 4096
  bytes.

Do I make my clear?
Another example for the size and block to help your understanding,

$ ls -ls /etc/hosts
4 -rw-r--r-- 1 root root 1434 Jul  7 17:50 /etc/hosts
$ stat -c "%bx%B %s" /etc/hosts 
8x512 1434


> However, I am puzzled by the file size of ca. 20MB printed for xi0 - what d=
> oes=20
> this mean? Does /system/ramdisks/var/.aufs.xino really consume 20MB of memo=
> ry=20
> to track only less than 7000 files on both branches?

It consumes 38440 blocks and it depends on your inode number (instead of
the number of inodes).


> Truncating the bitmap file doesn't change anything (which is expected, when=
>  my=20
> calculation of roughly 1kB size is correct):

Since it is small enough. The size 4096 tells us that the size of xib is
within one block. The allocated blocks are 8, according to your
output. I guess it is pre-allocted by your filesystem.


> I don't understand this, unfortunately. Does aufs(2) consume 4kB RAM for ea=
> ch=20
> file on any of the branches? These roughly 2-3MB don't seem to be correct, =

It depends upon your branch filesystem. If its block size is 1kb, then
every small file (less than 1kb) may consume 1kb (one block). It is out
of aufs issue.


> don't yet have a feeling which one they might be. Is noxino in common use=20
> among other users of aufs(2)? If not, how do others cope with this huge=20
> "waste" of RAM, especially on embedded systems for which aufs2 is otherwise=
>  a=20
> huge advantage?

While I don't know how many people uses noxino actually, the xino=
option is set by default and I guess many people are using it.


J. R. Okajima

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Reply via email to