bl4:
> With linux 2.6.18 and aufs1 (compiled from cvs but also reproducible
> with a binary package from 2007) and root filesystem mounted as aufs, I
> found that doing "auplink / flush" causes the system to freeze for about
> 2 minutes. During this time I can't press any keys on the console and
> can't ssh to this machine over the network, yet it responds to ping.
:::
> # mount -o remount /
> # find / -xdev > /dev/null
> # mount -o remount /
> # find / -xdev -inum 987654
> # date; mount -o remount /; date
> Wed Mar 24 21:00:29 CET 2010
> Wed Mar 24 21:02:28 CET 2010
>
> Any ideas why it's happening?
While I don't know how many files your / has and how large your system
RAM is, I guess your system was discarding caches.
(related desciptions from the aufs manual)
----------------------------------------------------------------------
:::
At remount time, cached but unused inodes are discarded.
:::
If you want to clear caches on your system, there are several tricks
for that. If your system ram is low,
try `find /large/dir \-ls > /dev/null'.
It will read many inodes and dentries and cache them. Then old caches will be
discarded.
But when you have large ram or you do not have such large
directory, it is not effective.
If you want to discard cache within a certain filesystem,
try `mount \-o remount /your/mntpnt'. Some filesystem may return an error of
EINVAL or something, but VFS discards the unused dentry/inode caches on the
specified filesystem.
:::
Since aufs uses its own inode and dentry, your system may cache huge
number of inodes and dentries. It can be as twice as all of the files
in your union.
It means that unmounting or remounting readonly at shutdown time may
take a long time, since mount(2) in VFS tries freeing all of the cache
on the target filesystem.
----------------------------------------------------------------------
You may want to ask why the first remount didn't take so long time, and
why the system didn't repond to keyborad or ssh access. I don't know
why precisely. But I guess it may be due to very old kernel. If you dive
into the long git-log world, you may be able to find something.
To discard caches quickly, /proc/sys/vm/drop_caches may be useful.
If you run "echo 2 > /proc/sys/vm/drop_caches", it will free unused
inodes and dentries quickly.
But /proc/sys/vm/drop_caches is not a generic solution. I think it is
just a trick for developers. So be caraful when you try this trick.
J. R. Okajima
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
