Steffen Dettmer:
> I tested with artifical files created by dd, I cannot imagine
> someone hold open filedescriptors on them.

Hmm,
I don't know why /rw is still full even you ran
        /rw/root# rm large.log.*

And why your rootfs is equivalent to /rw?
Will you show me how you mounted aufs and branchs, and how you chroot or
switch_root?


> # n=0; while true; do dd if=/dev/zero of=large.log.$((n++)) bs=1M
> 2>/dev/null ; done
> ....wait...wait...wait...
> ^C

I am afraid you missed "count=xx" for dd(1).


> Repeating. Once again the procedure.
        :::
> # ls
> ls: reading directory .: Input/output error
> # ls /
> bin   dev  home        lib        ....
> # cd /rw/root
> /rw/root# ls -rt|tail
> -bash: tail: command not found

This EIO might be caused by disk full and aufs could not write XINO.
But the message "command not found" looks strange to me.
As you wrote in the first mail, aufs returns EIO when writing XINO
failed.
Weren't any kernel log messages left?


> /rw/root# rm large.log.*
> -bash: /bin/rm: No space left on device

The current working dir is /rw/root which is not aufs.
I don't know why tmpfs behaves like this. This situation looks out of
aufs.
One possibility which aufs may concern is the shared objects and the
command binary. The command rm(1) exists in /bin/rm which is in
aufs. And when /bin/rm is accessed, aufs writes the inode number to the
XINO file and it may be necessary to allocate a new disk block. But it
happens at the first time only. Later when /bin/rm is accessed, XINO
file doesn't require a new disk block.
If aufs failed to write XINO, then aufs returns EIO instead of ENOSPC.
So "/bin/rm: No space left on device" on tmpfs is really really strange.

By the way, here is another approach to free disk blocks.
        $ for i in large.log.*; do > $i; done
It doesn't load and execute the external binaries and libraries.


> Do I understand correctly that calling "mount -o remount /" every
> few minutes is recommended?

Not recommended because it is meangless.
The simple remount has an effect to discard caches. I don't think it is
necessary for you.
If you try bypassing aufs regularly, it is recommended to enable
CONFIG_AUFS_NOTIFY and specify "udba=notify".
Since you may want to stick on the vanilla debian wheezy kernel (and
aufs module), it may not be an option for you.


J. R. Okajima

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk

Reply via email to