Dear Junjiro, I have now updated to aufs2, but still have the same problem:
According to "df -h": tmpfs 70M 29M 42M 42% /system/ramdisks/var aufs 70M 29M 42M 42% /var According to "du -sh": 11M /system/ramdisks/var/ [r...@gibraltar-500 ~]# cat /proc/mounts rootfs / rootfs rw 0 0 none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 none /proc proc rw,nosuid,nodev,noexec,relatime 0 0 udev /dev tmpfs rw,relatime,size=10240k,mode=755 0 0 /dev/hda1 /live/image vfat ro,noatime,fmask=0022,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8 0 0 /dev/loop0 /gibraltar.squashfs squashfs ro,noatime 0 0 /dev/loop0 / squashfs ro,relatime 0 0 tmpfs /live tmpfs rw,relatime 0 0 /dev/loop0 /system/root squashfs ro,noatime 0 0 tmpfs /system/ramdisks tmpfs rw,mand,relatime,size=256k,mode=755 0 0 tmpfs /system/ramdisks/etc tmpfs rw,relatime,size=8192k,mode=755 0 0 aufs /etc aufs rw,relatime,si=674de70c 0 0 tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0 /dev/loop0 /system/root squashfs ro,relatime 0 0 tmpfs /system/ramdisks/var tmpfs rw,mand,relatime,size=71680k,mode=755 0 0 aufs /var aufs rw,mand,relatime,si=6536656c 0 0 tmpfs /var/tmp tmpfs rw,mand,relatime,size=32768k,mode=755 0 0 [r...@gibraltar-500 ~]# cat /sys/fs/aufs/si_6536656c/* /system/ramdisks/var=rw /system/root/var=rr /system/ramdisks/var/.aufs.xino (The /etc aufs mount is not problematic, as there seems to be less change and thus less wasted memory on it). [r...@gibraltar-500 ~]# cat /sys/module/aufs/* cat: /sys/module/aufs/holders: Is a directory live cat: /sys/module/aufs/notes: Is a directory cat: /sys/module/aufs/parameters: Is a directory 2 cat: /sys/module/aufs/sections: Is a directory 0DF296E5F0FDB957E401F8F 2-standalone.tree-30-20090727 My linux kernel source is still publicly available in a GIT repository at https://www.gibraltar.at/git/linux-2.6-gibraltar.git in branch gibraltar-3.0. Kernel config and config.mk from aufs2-standalone.git are attached. [r...@gibraltar-500 ~]# grep aufs /var/log/dmesg [ 0.000000] Kernel command line: vga=normal initrd=/live/initrd.img boot=live bootdelay=10 union=aufs exposedroot skipunion nopersistent selinux=0 enforcing=0 console=tty0 console=ttyS0,115200n8 quiet BOOT_IMAGE=/live/linux [ 7.956924] aufs 2-standalone.tree-30-20090727 Am Dienstag, 6. Oktober 2009 19:20:43 schrieb Rene Mayrhofer: > > For /var, there are one XIB(inode bitmap) and two XINO files. > > Your /sys/fs/aufs/si_772cd879/xino shows that, > > - XIB consumes 8 blocks in /system/ramdisks/var, > > - one of XINO files consumes 6544 blocks, > > - and the other consumes 56 blocks. With aufs2, this seems different. There is no xino file, but a xi_path file - which gives me the (invisible) file /system/ramdisks/var/.aufs.xino but no indication of its size. If I try to estimate the size of this xino file based on the documentation, I count the number of files in all branches: [r...@gibraltar-500 ~]# find /system/ramdisks/var/ /system/root/var/ | wc -l 6794 which should result in a bitmap of less than 1kB. Trying to figure out the inode table size, the number of inodes is around 32k on both branches: [r...@gibraltar-500 ~]# df -i /system/ramdisks/var/ Filesystem Inodes IUsed IFree IUse% Mounted on tmpfs 31698 592 31106 2% /system/ramdisks/var [r...@gibraltar-500 ~]# df -i /system/root/ Filesystem Inodes IUsed IFree IUse% Mounted on /dev/loop0 38250 38250 0 100% /system/root which should result in a maximum size of roughly 150kB. If I interpret the debugs info correctly, then [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)? However, I am puzzled by the file size of ca. 20MB printed for xi0 - what does this mean? Does /system/ramdisks/var/.aufs.xino really consume 20MB of memory to track only less than 7000 files on both branches? Truncating the bitmap file doesn't change anything (which is expected, when my calculation of roughly 1kB size is correct): [r...@gibraltar-500 ~]# df -h /var/ Filesystem Size Used Avail Use% Mounted on aufs 70M 30M 41M 42% /var [r...@gibraltar-500 ~]# mount -o remount,trunc_xib /var [r...@gibraltar-500 ~]# df -h /var/ Filesystem Size Used Avail Use% Mounted on aufs 70M 30M 41M 42% /var Remounting all file systems doesn't free memory either: [r...@gibraltar-500 ~]# mount -o remount /var/ [r...@gibraltar-500 ~]# mount -o remount /system/root/ [r...@gibraltar-500 ~]# mount -o remount /system/ramdisks/var/ [r...@gibraltar-500 ~]# df -h /var/ Filesystem Size Used Avail Use% Mounted on aufs 70M 30M 41M 42% /var Only removing the xino file does: [r...@gibraltar-500 ~]# mount -o remount,noxino /var/ [r...@gibraltar-500 ~]# df -h /var/ Filesystem Size Used Avail Use% Mounted on aufs 70M 11M 60M 15% /var Which is exactly how much du shows: [r...@gibraltar-500 ~]# du -sh /system/ramdisks/var/ 11M /system/ramdisks/var/ Therefore, only without the xino file I get "expected" behaviour. > Why are there two XINO files - for the two lower branches, I assume? > > > Since the block size of /system/ramdisks/var is 4k, all of your XINO > > files for /var consumes (8+6544+56) x 4k = about 2.7MB. I don't understand this, unfortunately. Does aufs(2) consume 4kB RAM for each file on any of the branches? These roughly 2-3MB don't seem to be correct, as detailed above. Without the xino file, I suddenly have roughly 20MB more RAM free (which seems to match the size given in debug/aufs/si_6536656c/xi0). I read in the manual page that "noxino" might break some applications, but I don't yet have a feeling which one they might be. Is noxino in common use among other users of aufs(2)? If not, how do others cope with this huge "waste" of RAM, especially on embedded systems for which aufs2 is otherwise a huge advantage? best regards, Rene -- ------------------------------------------------- Gibraltar firewall http://www.gibraltar.at/
config-2.6.30.9.gz
Description: GNU Zip compressed data
# Kconfig
# instead of setting 'n', leave it blank when you disable it.
CONFIG_AUFS_BRANCH_MAX_127 = y
CONFIG_AUFS_BRANCH_MAX_511 =
CONFIG_AUFS_BRANCH_MAX_1023 =
#CONFIG_AUFS_BRANCH_MAX_32767 =
CONFIG_AUFS_HINOTIFY = y
CONFIG_AUFS_EXPORT =
CONFIG_AUFS_RDU =
CONFIG_AUFS_SHWH =
CONFIG_AUFS_BR_RAMFS =
CONFIG_AUFS_BR_FUSE =
CONFIG_AUFS_DEBUG = y
CONFIG_AUFS_MAGIC_SYSRQ =
CONFIG_AUFS_BDEV_LOOP =
CONFIG_AUFS_INO_T_64 =
CONFIG_AUFS_POLL =
########################################
define conf
ifdef $(1)
AUFS_DEF_CONFIG += -D$(1)
export $(1)
endif
endef
$(foreach i, BRANCH_MAX_127 BRANCH_MAX_511 BRANCH_MAX_1023 \
BRANCH_MAX_32767 \
HINOTIFY \
EXPORT INO_T_64 \
RDU \
SHWH \
BR_RAMFS \
BR_FUSE POLL \
DEBUG MAGIC_SYSRQ \
BDEV_LOOP, \
$(eval $(call conf,CONFIG_AUFS_$(i))))
########################################
ifdef CONFIG_AUFS_HINOTIFY
ifndef CONFIG_INOTIFY
$(error CONFIG_AUFS_HINOTIFY requires CONFIG_INOTIFY)
endif
endif
ifdef CONFIG_AUFS_EXPORT
ifndef CONFIG_EXPORTFS
$(error CONFIG_AUFS_EXPORT requires CONFIG_EXPORTFS)
endif
endif
ifdef CONFIG_AUFS_MAGIC_SYSRQ
ifndef CONFIG_AUFS_DEBUG
$(error CONFIG_AUFS_MAGIC_SYSRQ requires CONFIG_AUFS_DEBUG)
endif
ifndef CONFIG_MAGIC_SYSRQ
$(error CONFIG_AUFS_MAGIC_SYSRQ requires CONFIG_MAGIC_SYSRQ)
endif
endif
ifdef CONFIG_AUFS_BDEV_LOOP
ifndef CONFIG_BLK_DEV_LOOP
$(error CONFIG_AUFS_BDEV_LOOP requires CONFIG_BLK_DEV_LOOP)
endif
endif
ifdef CONFIG_AUFS_INO_T_64
ifndef CONFIG_AUFS_EXPORT
$(error CONFIG_AUFS_INO_T_64 requires CONFIG_AUFS_EXPORT)
endif
ifdef CONFIG_64BIT
ifdef CONFIG_ALPHA
$(error ino_t on ALPHA is not 64bit)
endif
ifdef CONFIG_S390
$(error ino_t on S390 is not 64bit)
endif
else
$(error ino_t is not 64bit)
endif
endif
ifdef CONFIG_AUFS_POLL
ifndef CONFIG_AUFS_BR_FUSE
# this is not an error
$(warning AUFS_POLL is enabled but AUFS_BR_FUSE)
endif
else ifdef CONFIG_AUFS_BR_FUSE
$(error AUFS_POLL is disabled but AUFS_BR_FUSE)
endif
ifdef CONFIG_AUFS_BR_FUSE
ifndef CONFIG_FUSE_FS
# this is not an error
$(warning AUFS_BR_FUSE is enabled but FUSE_FS)
endif
endif
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
