First of all, sorry for not being more specific in my initial email, I will try to give all the the required information now.
On Friday 02 October 2009 16:00:15 [email protected] wrote: > Rene Mayrhofer: > > I currently use aufs from the Debian unstable package version > > 0+20090302-2.= 1=20 > > and have a reproducible problem of deleted files not being reclaimed. > > That = is, > > I have not released such version of aufs1. Probably it is a version of > debian aufs1 package. So before of all, let's make it clear. Correct, this is the Debian aufs1 package (which is still the most recent one for the current stable release). > (from READM of aufs1) > ---------------------------------------------------------------------- > When you have any problems or strange behaviour in aufs, please let me > know with: > - /proc/mounts (instead of the output of mount(8)) [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 tmpfs /live/cow tmpfs rw,noatime,mode=755 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=76a81819,xino=/system/ramdisks/etc/.aufs.xino,br:/system/ramdisks/etc=rw:/system/root/etc=rr 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=32768k,mode=755 0 0 aufs /var aufs rw,mand,relatime,si=772cd879,xino=/system/ramdisks/var/.aufs.xino,br:/system/ramdisks/var=rw:/system/root/var=rr 0 0 tmpfs /var/tmp tmpfs rw,mand,relatime,size=32768k,mode=755 0 0 > - /sys/fs/aufs/* (if you have them) [r...@gibraltar-500 ~]# cat /sys/fs/aufs/* CONFIG_AUFS=m CONFIG_AUFS_BRANCH_MAX_127=y CONFIG_AUFS_STAT=y CONFIG_AUFS_EXPORT=y CONFIG_AUFS_RR_SQUASHFS=y CONFIG_AUFS_SPLICE_PATCH=y CONFIG_AUFS_BR_NFS=y CONFIG_AUFS_BR_XFS=y CONFIG_AUFS_GETATTR=y cat: /sys/fs/aufs/si_76a81819: Is a directory cat: /sys/fs/aufs/si_772cd879: Is a directory wkq max_busy: 1 0 0 0, 0(generic) > - /sys/module/aufs/* [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 28AF1060B30122FE3053016 20090126 > - linux kernel version 2.6.30.8 > if your kernel is not plain, for example modified by distributor, > the url where i can download its source is necessary too. The kernel is publicly available in a GIT repository at https://www.gibraltar.at/git/linux-2.6-gibraltar.git in branch gibraltar-3.0. > - aufs version which was printed at loading the module or booting the > system, instead of the date you downloaded. aufs 20090126 > - configuration (define/undefine CONFIG_AUFS_xxx, or plain local.mk is > used or not) This is done by the Makefile shipped with the Debian aufs-source package: export CONFIG_AUFS := m export CONFIG_AUFS_BRANCH_MAX_127 := y export CONFIG_AUFS_LOCAL := y export CONFIG_AUFS_RR_SQUASHFS := y export CONFIG_AUFS_EXPORT := $(if $(CONFIG_EXPORTFS),y) export CONFIG_AUFS_BR_XFS := $(if $(CONFIG_XFS_FS),y) export CONFIG_AUFS_BR_NFS := $(if $(CONFIG_NFS_FS),y) export CONFIG_AUFS_GETATTR := $(if $(CONFIG_AUFS_BR_NFS),y) export EXTRA_CFLAGS := -I $(M)/include \ -DCONFIG_AUFS_BRANCH_MAX_127 \ -DCONFIG_AUFS_MODULE \ -DCONFIG_AUFS_LOCAL \ -DCONFIG_AUFS_RR_SQUASHFS \ -DCONFIG_AUFS_SPLICE_PATCH \ -$(if $(CONFIG_EXPORTFS),D,U)CONFIG_AUFS_EXPORT \ -$(if $(CONFIG_XFS_FS),D,U)CONFIG_AUFS_BR_XFS \ -$(if $(CONFIG_NFS_FS),D,U)CONFIG_AUFS_BR_NFS \ -$(if $(CONFIG_AUFS_BR_NFS),D,U)CONFIG_AUFS_GETATTR aufs-$(CONFIG_SYSFS) += sysfs.o aufs-$(CONFIG_AUFS_BR_NFS) += br_nfs.o aufs-$(CONFIG_AUFS_BR_XFS) += br_xfs.o aufs-$(CONFIG_AUFS_WORKAROUND_FUSE) += br_fuse.o aufs-$(CONFIG_AUFS_DLGT) += dlgt.o aufs-$(CONFIG_AUFS_HINOTIFY) += hinotify.o aufs-$(CONFIG_AUFS_HIN_OR_DLGT) += hin_or_dlgt.o aufs-$(CONFIG_AUFS_GETATTR) += getattr.o aufs-$(CONFIG_AUFS_EXPORT) += export.o aufs-$(CONFIG_AUFS_ROBR) += robr.o # reserved for future use #aufs-$(CONFIG_AUFS_XATTR) += xattr.o aufs-$(CONFIG_AUFS_DEBUG) += debug.o aufs-$(CONFIG_AUFS_MAGIC_SYSRQ) += sysrq.o > - kernel configuration or /proc/config.gz (if you have it) Attached. > - behaviour which you think to be incorrect > - actual operation, reproducible one is better With [r...@gibraltar-500 ~]# du -sh /system/ramdisks/var/ 6.8M /system/ramdisks/var/ I would expect [r...@gibraltar-500 ~]# df -h /system/ramdisks/var/ Filesystem Size Used Avail Use% Mounted on tmpfs 32M 10M 23M 32% /system/ramdisks/var to also report 6.8M as used instead of as 10M. This case is not extreme, I have seen others where actual disk usage (as reported by du) was in the area of a few hundred kB, while the 32MB ramdisk was over 80% full. > I guess du(1) calls readdir(3) recursively, and stat(2) for every > entires. It means the removed-but-still-alive files are not counted. Correct. I was, however, unable to locate which process might still have such files open. > For > instance aufs XINO files are such files, and the size of these files are > listed in /sys/fs/aufs/si_*/xino. They may be the one you are looking > for. (but I am not sure) Possibly. However, I am unable to interpret these: [r...@gibraltar-500 ~]# cat /sys/fs/aufs/si_7*/xino 8x4096 4096 0: 1, 696x4096 3320260 1: 1, 48x4096 43540 8x4096 4096 0: 1, 6544x4096 3358868 1: 1, 56x4096 152592 Are the used internally by aufs or do these give some indication of processes still keeping removed files open (are these inode numbers)? > > Is there a problem with our usage? Can this be worked around somehow? If > > no= t,=20 > > how stable is aufs2 currently considered to be? > > I cannot recognize the problem before you give me the necessary > information. Anyway aufs2 is much better than aufs1, but your kernel > version has to be linux-2.6.27 or later. The kernel is 2.6.30.8 (with 2.6.30.9 building right now). However, the reason why we haven't yet switched to aufs2 is that its integration in our kernel build process is more difficult - Debian already ships packages for aufs1 (userspace tools as well as building the module outside the kernel), while for aufs2 we would need to build it manually. best regards, Rene -- ------------------------------------------------- Gibraltar firewall http://www.gibraltar.at/
config-2.6.30.8.gz
Description: GNU Zip compressed data
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf
