Rene Mayrhofer: > Why are there two XINO files - for the two lower branches, I assume?
Exactly, one for /system/ramdisks/var and the other is for /system/root/var. > Ok, but that still leaves me about 1MB short. "du -sh" shows 7.3MB, while "= > df=20 > =2Dh" shows 11M used. 7.3+2.7 is roughly 10MB. Is there any indication wher= > e=20 > that extra 1MB is left? I don't know, but I guess it is related to the internal of du and df. For example, on my system, the numbers don't match. $ d=/usr; sudo du -sh $d; df -h $d 1.9G /usr Filesystem Size Used Avail Use% Mounted on /dev/sda9 1.9G 1.7G 54M 98% /usr Are you sure that these numbers should always match? > Thanks for the pointer. With the details you gave above, I was able to=20 > interpret the manual page a little better.=20 I you point me out where my description is wrong or hard to understand, or suggest the correction, I will gladly fix it. > Could these XINO files be responsible for consuming up to 15MB when overlay= > ing=20 > a read-only /etc tree with a tmpfs, when there are only less than 4000 file= > s in=20 > the first branch and roughly less than 100 in the tmpfs branch? It depends on the inode numbers on your branch fs. See the aufs manual in detail. ---------------------------------------------------------------------- The maximum file size of the bitmap is, basically, the amount of the number of all the files on all branches divided by 8 (the number of bits in a byte). For example, on a 4KB page size system, if you have 32,768 (or 2,599,968) files in aufs world, then the maximum file size of the bitmap is 4KB (or 320KB). The maximum file size of the table will be `max inode number on the branch x size of an inode number'. For example in 32bit environment, .nf $ df -i /branch_fs /dev/hda14 2599968 203127 2396841 8% /branch_fs .fi and /branch_fs is an branch of the aufs. When the inode number is assigned contiguously (without `hole'), the maximum xino file size for /branch_fs will be 2,599,968 x 4 bytes = about 10 MB. But it might not be allocated all of disk blocks. 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. ---------------------------------------------------------------------- > The manual page mentions that "noxino" should not be used for the general=20 > case. However, when it is highly important to minimize disk space usage (th= > at=20 > is, memory usage when tmpfs is used), would it be an option to use "noxino"= > =20 > for /etc and /var? In your experience, which applications break with such a= > =20 > setting? (from the manaul again) ---------------------------------------------------------------------- If you do not want to use xino, use noxino mount option. Use this option with care, since the inode number may be changed silently and unexpectedly anytime. For example, rmdir failure, recursive chmod/chown/etc to a large and deep directory or anything else. And some applications will not work correctly. If you want to change the xino default path, use xino mount option. ---------------------------------------------------------------------- > PS: I have now updated to aufs2-30 standalone for a test system. However, I= > =20 > assume the XINO file handling will not have changed and this would therefor= > e=20 > not solve my current problem, correct? I guess so. J. R. Okajima ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
