Comment 4 for bug 1208978

Okay, I think I can recreate this fairly reliably.

mkdir /tmp/original
mkdir /tmp/cow
mkdir /tmp/mountpoint

mount -t tmpfs none /tmp/mountpoint
mount -t aufs -o br:/tmp/cow:/tmp/original none /tmp/mountpoint

for j in {1..15} ; do dd count=$RANDOM if=/dev/zero of=/tmp/original/data$j bs=5120 ; done

for i in {1..150} ; do echo $i ; rm /tmp/mountpoint/* 2>&- ; (for j in {1..15} ; do dd count=$RANDOM if=/dev/zero of=/tmp/mountpoint/data$j bs=5120 ; done) ; done

rm /tmp/cow

The for j statement is to create some original files that will be changed. I just had it create random files.

The for i statement does the same thing but so that the new files are in the copy-on-write folder. I tried creating one large file but it was hard to recreate, so I used the loop to create a bunch of random-size files, then remove them, then do it again.

Once cleaned I'm still left with an apparently full mount despite the fact I have removed all the new files:

none 1003M 955M 48M 96% /tmp/cow
none 1003M 955M 48M 96% /tmp/mountpoint

There's a number of different issues that pop up here:

1. rm /tmp/mountpoint/* should be removing the new files I have created. They are not being removed. rm reports that these files cannot be removed. They should be removed and either show an empty directory, or show the original files. Either way there should be some logic here that results in those files being removed.

2. rm /tmp/cow removes the files but aufs/tmpfs do not see the change, even though ls /tmp/cow and ls /tmp/mountpoint show empty directories.

There's something very wrong here.

My original test is slightly different in that it removed /tmp/cow/* in the loop. For example:

for i in {1..150} ; do echo $i ; rm /tmp/cow/* 2>&- ; (for j in {1..15} ; do dd count=$RANDOM if=/dev/zero of=/tmp/mountpoint/data$j bs=5120 ; done) ; done

Either way aufs/tmpfs seem to pick up the change for a while, then give up and simply report the mount full.

Will try the mainline kernels tomorrow.